AWS Summit 2019のセッション「データレイク構築における成功の秘訣 ～マインドと進め方、設計ベストプラクティス～」において、データレイクを設計する際の指針の１つとして「S3バケットの分け方」が紹介されていて、データレイク構築に限らず汎用的な指針としてわかりやすかったので抜粋して一部を編集・補足してみました。
セッション動画では25:06から
資料や動画はセッション資料・動画一覧 - AWS Summit 2019 | AWSにあります。
まず真っ先に考えるべきこととして「人が見て直感的にわかりやすい」ことがあげられています。これは当たり前ですね。
次に考えることはS3バケット（とアカウント）の機能仕様・制約の考慮です。具体的には以下の７つが挙げられていました。
これらの機能仕様や制約は、バケット単位（もしくはアカウント単位）での制御となる（表現を変えると下位のディレクトクトリレベルでは制御不可）ので、扱いが異なる場合（もしくは上限制約に達しそうな場合）は必然的に「わける」必要があります。
| # | 考慮事項 | 説明 | 設定の粒度 |
|---|---|---|---|
| 1 | バージョニング | オブジェクトを上書き、削除しても過去バージョンを保持する機能 | バケット |
| 2 | ライフサイクルポリシー | 指定した期間を過ぎるとオブジェクトをアーカイブしたり削除する機能 | バケット |
| 3 | オブジェクトロック | 指定した期間、バージョニングされたオブジェクトの削除を禁止する機能 | バケット |
| 4 | 1アカウント当たりのバケット数 | デフォルト100 、ハードリミットは 1000 | アカウント |
| 5 | バケットポリシーサイズ | バケットポリシーサイズの上限は20KB | バケット |
| 6 | コスト管理 | コスト配分タグはバケット単位で設定可能。コスト配分を区別したい単位でバケットを分ける。 | バケット |
| 7 | 監査証跡 | S3アクセスログはバケット単位で出力される。 | バケット |
補足説明
なお、「5.バケットポリシーサイズ」はこれはデータレイク特有といって良い考慮事項で、上記の記載だけだとちょっとわかりづらいと思うので補足します。
AWSでは、プロジェクトやシステムごとにアカウントを分離（さらに本番・開発・サンドボックス）することを推奨しています。それら各アカウントのS3バケット上にあるデータがデータレイクに蓄積するデータソースとなります。これらのデータソースをデータレイク用アカウントのS3バケットに集約する方法として「S3間で転送」することを推奨しています。（理由は１．性能 ２．コスト（同じリージョンならデータ転送料金かからない）３．便利（VPC間の通信設定不要））
この時に「（異なるアカウントの）データをS3間転送する」には、明示的に許可するポリシーを記載する必要があり、これがバケットポリシーとなります。
このバケットポリシーにアカウントIDを書き連ねると、以下のように記述が肥大化して、上限の20KBを越えてしまうので、これを避けるために「aws:PrincipalOrgID」で書きましょう。というプラクティスです。
アカウントIDを書き連ねた例（資料の53ページ）
PrincipalOrgIDで記載した例（資料の54ページ）
