はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon S3 関連の知識をまとめました。
S3 は SAA の中でも最も出題範囲が広いサービスの一つです。ストレージクラスの選択、暗号化方式、アクセス制御、転送の最適化など、多角的に問われます。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
ストレージクラス
| クラス | 用途 | 最小保存期間 | 取得料金 | 可用性 |
|---|---|---|---|---|
| S3 Standard | 頻繁アクセス | なし | なし | 複数AZ |
| S3 Intelligent-Tiering | アクセスパターン不明 | なし | なし | 複数AZ |
| S3 Standard-IA | 低頻度（再作成不可） | 30日 | あり | 複数AZ |
| S3 One Zone-IA | 低頻度（再作成可能） | 30日 | あり | 単一AZ |
| Glacier Instant Retrieval | アーカイブ（即時取得） | 90日 | あり | 複数AZ |
| Glacier Flexible Retrieval | アーカイブ（分〜時間） | 90日 | あり | 複数AZ |
| Glacier Deep Archive | 長期アーカイブ（時間〜） | 180日 | あり | 複数AZ |
試験での判断ポイントは アクセス頻度、再作成可能かどうか、取得速度の要件 の3つです。
ライフサイクル遷移の最低日数制約
ライフサイクルポリシーで S3 Standard から遷移する場合、最低日数の制約があります。「7日後に IA に遷移」のような設定はできません。
| 遷移先 | Standard からの最低日数 |
|---|---|
| S3 Standard-IA | 30日 |
| S3 One Zone-IA | 30日 |
| S3 Glacier Instant Retrieval | 90日 |
暗号化方式
| 方式 | キー管理 | 暗号化処理 | 監査ログ | キーローテーション |
|---|---|---|---|---|
| SSE-S3 | S3 | S3 | ❌ | AWS 自動（制御不可） |
| SSE-KMS | KMS | S3 | ✅ | 自動/手動 |
| SSE-C | 顧客 | S3 | ❌ | 顧客管理 |
| クライアントサイド | 顧客 | 顧客 | - | 顧客管理 |
「監査ログが必要」なら SSE-KMS 一択です。「キーは自前で管理したいが暗号化処理は S3 に任せたい」なら SSE-C です。
パフォーマンス上限（プレフィックスあたり）
- GET/HEAD: 5,500 req/s
- PUT/COPY/POST/DELETE: 3,500 req/s
- プレフィックス数に制限なし → 並列化で線形にスケール可能
データ転送料金
- インターネット → S3（アップロード）: 無料
- S3 → インターネット（ダウンロード）: 有料
- S3 → 同一リージョンの AWS サービス: 無料
- S3 → CloudFront: 無料
- S3 Transfer Acceleration（加速されなかった場合）: 無料
セキュリティ・アクセス制御
- バケットポリシー: クロスアカウント対応
- IAM ポリシー: 自アカウント内のみ
- Access Points: 複数アプリが1バケットを共有する場合のプレフィックス単位アクセス制御
- OAI / OAC: CloudFront → S3 への専用アクセス（OAC は PUT/POST、SSE-KMS にも対応）
-
Object Lock: WORM 保護
- Compliance Mode: ルートユーザーでも削除不可
- Governance Mode: 特権ユーザーがバイパス可能
- Bucket Keys: SSE-KMS の KMS API 呼び出しを最大99%削減（コスト削減）
- MFA Delete: オブジェクトの永久削除に MFA を要求
その他重要機能
- バージョニング: 全バージョンを保持。削除しても delete marker で復元可能
- Storage Lens: 組織全体のストレージ使用状況・設定状態の可視化
- Inventory: バケット内オブジェクトの一覧
- Replication（CRR/SRR）: クロスリージョン/同一リージョンのレプリケーション。既存オブジェクトには Batch Replication が必要
- Transfer Acceleration: 1GB超の大容量ファイルの長距離転送に最適（CloudFront エッジ経由）
- Multipart Upload: 100MB以上推奨、5GB超は必須
- Gateway VPC Endpoint: S3 と DynamoDB のみ対応、無料
試験で問われる設計パターン
S3 関連の問題は出題範囲が非常に広いため、カテゴリ別に整理します。
データ保護・削除防止
S3 の誤削除防止 → バージョニング + MFA Delete
シナリオ: S3 オブジェクトが誤って削除されるリスクを最小限にしたいです。どのような対策を講じるべきでしょうか？（2つ選択）
正解:
- S3 バージョニングを有効化 — 削除しても delete marker が挿入されるだけで復元可能
- MFA Delete を有効化 — 永久削除に MFA を要求
- SNS 通知は事後通知であり、削除の「防止」にはならない
WORM + 管理者も削除不可 → S3 Object Lock Compliance Mode
シナリオ: 規制により、保存されたデータをルートユーザーを含む誰も削除できないようにする必要があります。どの機能を使うべきでしょうか？
正解: S3 Object Lock Compliance Mode
- Compliance Mode: ルートユーザーでも削除不可
- Governance Mode: 特権ユーザーがバイパス可能 → 厳格な規制には不十分
- バケットポリシーは変更可能なため、イミュータビリティの保証にはならない
保持ポリシー: 即時アクセス → Object Lock / 長期アーカイブ → Glacier Vault Lock
シナリオ: 2つの保持ポリシーがあります。Policy A: 7年間削除不可で即時アクセスが必要。Policy B: 10年間削除不可で低コスト長期保存が必要。それぞれどの機能を使うべきでしょうか？
正解:
-
Policy A → S3 Object Lock（Compliance Mode）
-
Policy B → S3 Glacier Vault Lock
-
即時アクセスが必要 → S3 Object Lock
-
長期アーカイブ + 低コスト → Glacier Vault Lock
ストレージクラスの選択
再作成可能な低頻度アクセスデータ → S3 One Zone-IA
シナリオ: 再作成可能なアセットがあります。最初の数日は頻繁にアクセスされますが、1週間後はほぼアクセスされません。即座にアクセスできる必要はあります。コストを最小化するにはどうすればよいでしょうか？
正解: ライフサイクルポリシーで 30日後に S3 One Zone-IA に遷移
- 「再作成可能」→ One Zone-IA（マルチ AZ 不要で約20%安い）
- 「再作成不可」→ Standard-IA（マルチ AZ で耐久性を確保）
- ライフサイクル遷移は最低30日から（7日は設定不可）
アクセスパターン不明 + 運用負荷最小 → S3 Intelligent-Tiering
シナリオ: どのファイルがいつアクセスされるか予測できません。IT チームの関与を最小限にしつつ、ストレージコストを最適化したいです。どのストレージクラスが適切でしょうか？
正解: S3 Intelligent-Tiering
- アクセスパターンを自動監視し、最適なティアに自動移動
- 30日アクセスなし → 低頻度ティアに移動
- 取得料金なし、運用オーバーヘッドなし
30日後低頻度 + 5年後削除 + 即時アクセス + 再作成不可 → Standard-IA + 削除
シナリオ: データは30日後に低頻度アクセスになり、5年後には完全に削除してよいです。即時アクセスは常に必要で、データは再作成できません。最適なライフサイクル設定はどれでしょうか？
正解: S3 Standard → 30日後に Standard-IA → 5年後に削除（Expiration Action）
- 即時アクセス必要 → Glacier は除外
- 再作成不可 → One Zone-IA は除外（単一 AZ）
- 5年後に削除 → Glacier へのアーカイブは不要
データレイクのコスト最適化 → Raw: Glacier Deep Archive / Refined: 圧縮形式
シナリオ: データレイクの Raw Zone（5年間の保持義務）と Refined Zone（アドホッククエリ用）があります。それぞれのコストを最適化するにはどうすればよいでしょうか？
正解:
- Raw Zone → 1日後に Glacier Deep Archive
- Refined Zone → Glue ETL で圧縮形式に変換（削除不可、即時アクセス必要のため Glacier は不可）
パフォーマンス・転送
S3 のスケーラビリティ → プレフィックスで並列化
シナリオ: S3 への PUT リクエストが5,000 req/s を超え、アップロードが失敗し始めました。リソース・コスト効率の良い対策は何でしょうか？
正解: カスタムプレフィックスを作成してアップロードを分散
- プレフィックスあたり GET 5,500 req/s、PUT 3,500 req/s
- プレフィックス数に制限なし → 並列化で線形にスケール
- バケットを増やす必要はない
最速の S3 アップロード → Multipart Upload + S3 Transfer Acceleration
シナリオ: オンプレミスから2GBの圧縮ファイルを S3 に最速でアップロードしたいです。どの方法を組み合わせるべきでしょうか？
正解: Multipart Upload + S3 Transfer Acceleration
- 100MB以上は Multipart Upload 推奨
- 1GB超の大容量ファイルには S3 Transfer Acceleration が特に有効
大容量ファイル（10GB）のグローバルアップロード/ダウンロード → S3 Transfer Acceleration
シナリオ: 世界中のオフィスから10GBのファイルを S3 にアップロード・ダウンロードします。最もパフォーマンスの良い方法はどれでしょうか？
正解: S3 + S3 Transfer Acceleration
- 1GB超の大容量 + グローバル → S3 Transfer Acceleration
- 1GB未満 + 配信のみ → CloudFront
- Global Accelerator は S3 向けではない
S3 アウトバウンドデータ転送コスト削減 → CloudFront
シナリオ: S3 からインターネットへのデータ転送コストが高額になっています。コストを削減する方法はどれでしょうか？
正解: CloudFront を S3 の前に配置
- S3 → CloudFront は無料
- CloudFront → インターネットは S3 直接より安い
- エッジキャッシュにより S3 へのリクエスト数自体が減る
S3 Transfer Acceleration の料金
シナリオ: S3 Transfer Acceleration を有効にしてファイルをアップロードしましたが、加速効果がなかった場合、料金はどうなりますか？
正解: 転送料金は一切かからない
- アップロードはそもそも常に無料
- S3 TA は加速されなかった場合は課金されない
データ移行・レプリケーション
S3 バケット間の1PBデータコピー（クロスリージョン）
シナリオ: us-west-1 から us-east-1 に1PBのデータを1回コピーしたいです。Snowball は使用不可です。どの方法が使えますか？（2つ選択）
正解:
-
aws s3 sync— CopyObject API を使用、失敗時に再実行しても重複なし - S3 Batch Replication — 既存オブジェクトの一括レプリケーション
- Snowball Edge はクロスリージョン S3 コピーには使えない（オンプレ → AWS 用）
- S3 TA はクライアント → S3 の高速化用（バケット間コピーには使えない）
S3 の CRR + KMS → Multi-Region Keys
シナリオ: S3 のデータを SSE-KMS で暗号化しつつ、別リージョンに自動レプリケーションし、Athena でクエリしたいです。どの構成が必要でしょうか？
正解: 新バケット作成（SSE-KMS Multi-Region Key）+ CRR 有効化 + Athena
- CRR で暗号化データをレプリケーションするなら、両リージョンで同じキーが必要
- KMS Multi-Region Key が必須（シングルリージョンキーは変換不可）
Snowball → 長期アーカイブ → S3 経由 + Glacier Deep Archive
シナリオ: Snowball を使って大量のデータを長期アーカイブしたいです。最もコストを抑えるにはどうすればよいでしょうか？
正解: Snowball → S3 → ゼロデイライフサイクルで Glacier Deep Archive
- Snowball から Glacier に直接データを送ることはできない（S3 のみ対応）
- ゼロデイライフサイクルで S3 Standard の料金を回避
暗号化
暗号化 + 監査ログ + 年次キーローテーション → SSE-KMS
シナリオ: S3 に保存するデータを暗号化し、誰がいつ暗号化キーを使用したかの監査ログを残したいです。キーは年次で自動ローテーションさせたいです。どの暗号化方式が適切でしょうか？
正解: SSE-KMS + 自動キーローテーション
- 監査ログが必要 → SSE-KMS（SSE-S3 では監査ログは取れない）
- 自動ローテーション有効化でキーマテリアルのみ更新 → アプリ変更不要
ファイルごとに異なる暗号化キー → SSE-S3
シナリオ: 各ファイルを異なるキーで暗号化したいですが、鍵管理のオーバーヘッドは避けたいです。どの暗号化方式が適切でしょうか？
正解: 単一 S3 バケット + SSE-S3
- SSE-S3 は各オブジェクトに一意のキーを自動生成
- 2023年1月以降、全 S3 バケットで SSE-S3 がデフォルト有効
- 複数バケットに分ける必要はない
自前キー + S3 で暗号化処理 → SSE-C
シナリオ: 暗号化キーはオンプレミスで管理していますが、データの保存と暗号化処理は S3 にオフロードしたいです。どの暗号化方式を選ぶべきでしょうか？
正解: SSE-C
- SSE-C: 顧客がキーを提供し、S3 が暗号化処理を実行
- クライアントサイド暗号化: 暗号化処理も顧客側（S3 にオフロードされない）
- SSE-S3 / SSE-KMS: キーも AWS が管理
SSE-KMS のコスト削減 → S3 Bucket Keys
シナリオ: SSE-KMS を使っていますが、高頻度アクセスにより KMS リクエストのコストが増大しています。暗号化を維持したままコストを削減するにはどうすればよいでしょうか？
正解: S3 Bucket Keys を有効化
- バケットレベルキーからローカルでデータキーを生成 → KMS API 呼び出しを最大99%削減
- SSE-S3 に切り替えると監査ログを失ってしまう
アクセス制御
S3 共有バケットのプレフィックス単位アクセス制御 → S3 Access Points
シナリオ: 複数のサービスが1つの S3 バケットを共有しています。サービスごとに異なるプレフィックスへのアクセスを制御したいです。バケットポリシーが複雑化しない方法はどれでしょうか？
正解: サービスごとに S3 Access Point を作成 + Access Point ポリシーでプレフィックス制限
- バケットポリシーを肥大化させない
- Access Point の追加だけでサービスを追加できる
CloudFront 経由のみで S3 アクセス → OAI / OAC + バケットポリシー
シナリオ: S3 バケットへの直接アクセスを禁止し、CloudFront 経由のみでアクセスさせたいです。どのように設定すべきでしょうか？
正解: OAI（または OAC）を作成 + S3 バケットポリシーを更新
- S3 にセキュリティグループは存在しない
- CloudFront に IAM ロールは付けられない
- OAC（新）は SSE-KMS / PUT / POST に対応。OAI（旧）は読み取りのみ
CloudFront + S3 でIP制限 → OAI/OAC + WAF
シナリオ: CloudFront + S3 の構成で、特定の IP アドレスからのアクセスのみ許可したいです。どのように設定すべきでしょうか？
正解:
- OAI を CloudFront に関連付け + S3 バケットポリシーで OAI のみ許可
- WAF ACL で IP Match 条件を作成 + CloudFront に関連付け
- CloudFront には Security Group / NACL を関連付けできない
- WAF ACL は CloudFront と ALB に関連付け可能
S3 バケットポリシーの読み解き（IpAddress + NotIpAddress）
シナリオ: S3 バケットポリシーで IpAddress: 54.240.143.0/24 と NotIpAddress: 54.240.143.188/32 が同じ Condition ブロックに記載されています。この意味はどうなりますか？
正解: CIDR 全体（256個の IP）を許可するが、1つの IP（54.240.143.188）を除外
- 同じ Condition ブロック内は AND 条件
-
/24= 256IP、/32= 1IP
S3 IAM ポリシー: ListBucket vs GetObject の ARN
シナリオ: IAM ポリシーで S3 バケットの一覧表示とオブジェクトの取得を許可したいです。ARN はどう記述すべきでしょうか？
正解:
-
s3:ListBucket→arn:aws:s3:::mybucket（バケット自体、/*なし） -
s3:GetObject→arn:aws:s3:::mybucket/*（オブジェクト、/*あり）
2つのステートメントに分けて、正しい ARN を指定する必要があります。
ネットワーク
EC2 → S3 をプライベート通信 → Gateway VPC Endpoint
シナリオ: プライベートサブネットの EC2 から S3 にアクセスしたいですが、インターネットを経由せずにプライベート通信で接続したいです。どの方法が最適でしょうか？
正解: S3 用 Gateway VPC Endpoint + ルートテーブル更新 + IAM ポリシー
- Gateway Endpoint は S3 / DynamoDB のみ対応、無料
- NAT Gateway 経由はインターネット経由になるため、プライベート通信にならない
- Interface Endpoint より Gateway Endpoint の方がコスト効率が良い
コスト比較
ストレージコスト比較: S3 < EFS < EBS
シナリオ: 1GBのテストファイルを S3 Standard、EBS gp2（100GBプロビジョニング）、EFS Standard にそれぞれ保存した場合、月末のコストが安い順は？
正解: S3（$0.023）< EFS（$0.30）< EBS（$10.00）
- S3 / EFS は使用量課金（1GB分のみ課金）
- EBS はプロビジョニング容量課金（100GB分すべてに課金）
おわりに
S3 は SAA の中でも最も守備範囲が広いサービスです。ストレージクラスの選択、暗号化方式、アクセス制御、転送最適化、VPC Endpoint など、あらゆる角度から出題されます。特に「ライフサイクル遷移の最低日数制約」「SSE-KMS と SSE-S3 の違い」「Gateway VPC Endpoint の無料性」は頻出なので、確実に押さえておきましょう。
間違いや補足があればぜひコメントで教えてください。