S3を利用するにあたっては、通常、いくつかのバケットに分けて利用することになる。一つのバケットに全部おさめるとバケットの中がカオスになるからだ。
だが思いつき次第にバケットを作っていくのも不味い。今度はS3自体がカオスになってしまう。そもそも1アカウントで作れるバケットの数も上限がある。(緩和できるけど)
従って最適な分け方をしたいわけだが、どうすればいいだろうか。
基準は?
AWSの中の人が考え方を公開してくれている。
- 人が見て直感的に分かりやすい単位で分ける。
- バケット単位の設定を変えたい場合はバケットを分ける。
- バージョニング、ライフサイクルポリシー、オブジェクトロックなど
- バケット単位のサービス上限に達しないよう分ける。
基本、これを元に考えていけばよいと思う。基本は1でまず分け、次に必要に応じて2の条件の違いで分ければよいのではないか。3は制約条件だから、抵触しそうなら気を付ける、で良いと思う。
具体的には?
私見ながら次のように考える。
- まず環境、特に本番用途は必ず分けたい。オペミス防止のためのフールプルーフとして、保全の必要性が高いデータは分離しておくべきである。
- 一般公開用も同じ理由でその他の非公開用バケットから分離したい。機密情報と公開用HTMLが一緒に入っている状況はあまり嬉しいものではない。おそらくバケットの設定も異なる。
- ログも他と混ぜずに分離しておきたい。Athena等から別途使うことがありえるから、ということもあるし、ライフサイクルルールやバケットポリシーも設定したいからでもある。
それを踏まえ、環境が仮にproduct/staging/developの3点、単位を公開用(public)/ログ(log)/その他(general)の3種で分けるとすると、最低でも3*3で9つ必要となる。
- product-public
- product-log
- product-general
- staging-public
- staging-log
- staging-general
- develop-public
- develop-log
- develop-general
さらにCloudTrailやCodePipeline、CloudFrontなど、AWS側で運用するバケットがあり、そちらが加わる。
S3は他のアカウントも含めてバケット名をユニークにしなければならず、従って上述の名前でバケットを作ることは困難だが、そこはそれ、後ろに乱数文字列をつけるなどしてなんとかかわすしかない。