はじめに
S3のバケットを作ると、プロパティとアクセス許可のタブに設定がずらっと並びます。私は毎回ここで固まっていました。どれが必須で、どれが放っておいていいのか分からないからです。
そこで公式ドキュメントから主要なバケット設定を拾い、目的別に7つのグループへ分類しました。この記事は個々の設定の深掘りではなく、地図です。
対象読者
- S3を触り始めたばかりで、設定項目の全体像を掴みたい人
- AWS認定試験の勉強中で、S3の機能名を整理したい人
結論を3行で。設定は「入れ物・守る・失わない・安くする・つなぐ・見る・まとめて操作する」の7つに畳めます。既定で効いているのはアクセス制御と暗号化、それに一部の監視だけです。残りは自分でオンにしないと何も起きません。
この記事が扱うのは汎用バケット（general purpose bucket）のバケットレベル設定です。後述するディレクトリバケットやテーブルバケットでは、ここで挙げる設定の多くが未対応です。
参考文献
先に一次情報を置いておきます。この記事はここから拾って整理したものです。
S3の設定は、目的で7つに分けられる
① 入れ物を決める ― バケットには4種類ある
S3のバケットは1種類だと思っていませんか。いまは4つあります。
| 種類 | 用途 |
|---|---|
| 汎用バケット | ほとんどの用途。迷ったらこれ |
| ディレクトリバケット | 単一のZoneに配置。AZではS3 Express One Zone、Local ZoneではS3 One Zone-IA |
| テーブルバケット | Apache Iceberg形式の表データ。AthenaやSparkから問い合わせる |
| ベクトルバケット | 埋め込みベクトルの保存と類似検索 |
このグループだけ性質が違います。バケット名・リージョン・種類は、作成後に変更できません。他の設定と違ってやり直しが効かないので、ここだけは先に決める必要があります。
そして重要なのが、以降の②〜⑦は汎用バケットを前提にしているという点です。ディレクトリバケットではバージョニング、レプリケーション、Object Lock、イベント通知、静的ウェブサイトホスティングなどが使えません。「S3の設定」として一緒くたに覚えると、ディレクトリバケットを触ったときに混乱します。
② 守る ― デフォルトで閉じているものを、開けすぎない
アクセス制御と暗号化のグループです。
| 設定 | 既定値 |
|---|---|
| ブロックパブリックアクセス | オン（4項目すべて） |
| デフォルト暗号化 | SSE-S3でオン |
| バケットポリシー | なし |
| S3 オブジェクト所有権 / ACL | 「バケット所有者の強制」＝ACLは無効 |
| アクセスポイント | なし |
| IAM Access Analyzer for S3 | 別途有効化 |
ここは既定値がいちばん安全という珍しいグループです。公開バケットの事故は、この既定値を自分で解除したときに起きます。新規バケットではACLも既定で無効になっているので、アクセス制御はバケットポリシーとIAMポリシーに寄せるのが現在の推奨です。
③ 失わない ― 消えた・上書きされたを取り返す
| 設定 | 既定の状態 | ひとこと |
|---|---|---|
| バージョニング | 未バージョニング | 一度有効にすると「停止」にしかできず、未バージョニングには戻せない |
| オブジェクトロック | オフ | WORM。バージョニングが前提で、有効化後は無効化できない |
| MFA Delete | オフ | 有効化はルートユーザーがCLI/APIから行う |
| レプリケーション | なし | 同一リージョン（SRR）と別リージョン（CRR） |
このグループは不可逆な操作が多いのが特徴です。特にオブジェクトロックは、試しに有効化して戻す、ということができません。
レプリケーションには前提があります。送信元と送信先の両方でバージョニングが有効である必要があり、さらに設定した時点で既に存在していたオブジェクトは自動では複製されません。既存分も複製したい場合はS3 バッチレプリケーションを別途実行します。
MFA DeleteとS3 ライフサイクル設定は併用できません。公式ドキュメントに明記されています。誤削除対策としてMFA Deleteを選ぶと、④のライフサイクルによる自動削除が使えなくなる、というトレードオフがあります。
私がハマったのもこのグループです。バージョニングを有効にしたバケットに、ライフサイクルの Expiration だけを設定して「これで古いログは消える」と思っていました。しかし数か月経っても使用容量が減りません。
原因は、バージョニング有効バケットの Expiration が現行バージョンに削除マーカーを付けるだけで、非現行バージョンをそのまま残すことでした。実際に減らすには NoncurrentVersionExpiration が別途必要です。バージョニングをオンにしたら、ライフサイクルは現行と非現行の両方を書く。これは体で覚えました。
④ 安くする ― 置き場所を自動で移す
| 設定 | 役割 |
|---|---|
| ストレージクラス | 標準 / 標準-IA / 1ゾーン-IA / Glacier 3種 など |
| ライフサイクルルール | 日数をトリガーに、別クラスへ移行したり削除したり |
| S3 Intelligent-Tiering | アクセス傾向を見てS3が自動で階層を移す |
| ストレージクラス分析 | 標準から標準-IAへ移す時期を判断する材料 |
ライフサイクルはバケットあたり1,000ルールまで設定できます。アクセス頻度が読めるならライフサイクル、読めないならIntelligent-Tiering、という分け方が素直です。ストレージクラス分析が推奨してくれるのは標準から標準-IAへの移行だけで、Glacier系への移行時期までは面倒を見てくれません。
ライフサイクルで移行スケジュールを組むときの注意点が2つあります。
- 一部のストレージクラスには最小保存期間があります（標準とIntelligent-Tieringにはありません）。期間内に削除や再移行をすると残り日数分が課金され、1つのルールでその期間を跨ぐ移行は定義できません。
- 2024年9月以降に作成・変更したライフサイクル設定では、128KB未満のオブジェクトは既定でどのクラスにも移行しません。移行したい場合はオブジェクトサイズのフィルターを明示します。
最新の条件は公式のストレージクラス比較表で確認するのが確実です。
⑤ つなぐ ― 他のサービスや外部に口を開ける
| 設定 | 役割 |
|---|---|
| イベント通知 | アップロードや削除をSNS / SQS / Lambda / EventBridgeへ通知 |
| 静的ウェブサイトホスティング | バケットをそのままWebサイトとして配信 |
| CORS | ブラウザから別オリジンのJSがアクセスする際の許可 |
| Transfer Acceleration | エッジロケーション経由で遠距離転送を速くする |
| リクエスタ支払い | 転送料とリクエスト料を利用者側に負担させる |
| S3 Object Lambda | GET・HEAD・LISTの応答を自分のコードで加工して返す |
このグループは全部オフから始まります。必要になったときだけ開ける、という理解で十分です。
ただし2つ、そのまま真似してはいけないものがあります。
静的ウェブサイトホスティングが提供するウェブサイトエンドポイントはHTTPSに対応していません。そのまま公開するにはバケットをパブリック読み取りにする必要もあります。実運用では、バケットは非公開のままRESTオリジンとしてCloudFrontのOrigin Access Control（OAC）から参照する構成が定石です。OACはウェブサイトエンドポイントには使えないので、この2つは別物として覚えてください。
S3 Object Lambdaは2025年11月7日からメンテナンスモードに入りました。既存の利用者と一部のAPNパートナー以外は新規に使えません。同じことをやりたい場合は、CloudFront、API Gateway、Lambda関数URLなどからLambdaを呼ぶ構成を検討することになります。
⑥ 見る ― 誰が何をしたか、何がどれだけあるか
| 設定 | 見えるもの | 既定 |
|---|---|---|
| CloudWatch日次ストレージメトリクス | 容量やオブジェクト数の推移 | 自動で提供 |
| CloudWatchリクエストメトリクス | 分単位のリクエスト数やエラー率 | 要設定 |
| S3 Storage Lens | 組織・アカウント横断の利用状況ダッシュボード | 既定ダッシュボードあり |
| サーバーアクセスログ | バケットへの個々のリクエスト記録 | オフ |
| CloudTrailデータイベント | オブジェクト単位のAPI操作。監査向け | オフ |
| S3 Inventory | オブジェクト一覧をCSVやParquetで定期出力 | なし |
| S3メタデータテーブル | 変更イベントや在庫をIcebergテーブルで問い合わせ | なし |
このグループは既定の扱いがまちまちなので、表の右列を見てください。容量の推移とStorage Lensの基本ダッシュボードは最初から見られますが、「誰がいつ何を取得したか」を追うログ系はオフです。何か起きてから有効化しても過去は見られないので、本番バケットでは先に入れておくほうが安全だと思います。
S3メタデータテーブルには3種類あります。設定を作ると必ず作られるジャーナルテーブルと、任意で足せるライブインベントリテーブル、アノテーションテーブルです。
⑦ まとめて操作する ― S3 バッチオペレーション
ここまでの設定には、既存オブジェクトに遡って効くものと、効かないものが混ざっています。
- 遡って効く：バケットポリシーなどのアクセス制御、ライフサイクルルール
- 遡らない：デフォルト暗号化、通常のレプリケーション
つまり暗号化設定を変えても、既に置いてあるオブジェクトは暗号化し直されません。すでにあるオブジェクトをまとめて直したいときの手段が、S3 バッチオペレーションです。コピー、復元、暗号化の更新、Lambda関数の実行、タグ付けなどを一括で実行できます。
対象の指定にはマニフェストを使います。S3 Inventoryのレポートを渡してもいいですし、自分で書いたCSVや、バケット・プレフィックス・作成日・ストレージクラスなどの条件から自動生成させることもできます。レプリケーション対象の既存オブジェクトを埋めるS3 バッチレプリケーションも、この仲間です。
まとめ
S3の設定が多く感じるのは、役割の違うものが同じ画面に並んでいるからでした。目的で7つに束ねてしまえば、初見の設定に出会っても「これは④の話だな」と置き場所が決まります。
個人的には、この整理をしてから設定画面で固まらなくなりました。地図を持って歩くと道に迷わない、という当たり前のことだったわけです。
次は④のライフサイクルルールだけを掘り下げた記事を書く予定です。もし「このグループの分け方は違うんじゃないか」と思ったら、ぜひ教えてください。