SAA S3 設計問題の頻出パターン10選|ストレージクラス・暗号化・CRR を要件文で即断する

AWS SAA-C03 で S3 は全問の 15〜25% に絡む最大の得点源。本記事は S3 設計問題を「ストレージクラス選択/ライフサイクル階層化/Intelligent-Tiering の使い分け/SSE-S3・SSE-KMS・SSE-C の暗号化/バケットポリシーと Block Public Access/VPC Gateway エンドポイント/クロスリージョンレプリケーション(CRR)+バージョニング/Object Lock の WORM/CloudFront + OAC 配信/Transfer Acceleration とマルチパート」の頻出10パターンに分解する。各パターンで「要件文のどのキーワードが正解を一意に決めるか」を示し、本番のシナリオでそのまま選択肢を絞れる粒度まで落とす。結論は「S3 問題はサービス名ではなく、アクセス頻度・耐久性・取得時間・コスト・アクセス経路という評価軸で解く」こと。

S3 の設計問題を「S3 のどの機能を使うか」で解こうとすると、選択肢の細かな違いに溺れる。 SAA-C03 で Amazon S3 は全問の 15〜25% に直接・間接で絡む、単一サービスとしては最大の得点源だ。だが出題は「S3 の仕様暗記」ではなく、アクセス頻度・耐久性・取得時間・コスト・アクセス経路という5つの評価軸のどれが要件文で問われているかを読み取れるかを試してくる。攻略の鍵は、頻出テーマを「ストレージクラス」「ライフサイクル」「暗号化」「アクセス制御」「レプリケーション」「配信・転送」の6系統×10パターンに畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、S3 設計問題の頻出10パターンを分解する。読み終えれば、「最もコスト効率が高く要件を満たす構成はどれか」という問いに、迷わず正解を当てられるようになる。

※ 本記事はアフィリエイト広告(Amazon アソシエイト等)を含みます


📑 目次

  1. 結論:S3 問題は「サービス名」ではなく「評価軸」で解く
  2. パターン1〜3:ストレージクラスとライフサイクル
  3. パターン4〜5:暗号化とアクセス制御
  4. パターン6〜8:接続・レプリケーション・コンプライアンス
  5. パターン9〜10:配信と大容量転送
  6. 頻出ひっかけパターンと打ち手の整理
  7. 次のアクション チェックリスト
  8. 関連記事
  9. 関連サイト

1. 結論:S3 問題は「サービス名」ではなく「評価軸」で解く

SAA-C03 の S3 問題を最短で解く骨格は、**「要件文が5つの評価軸——アクセス頻度・耐久性・取得時間・コスト・アクセス経路——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。

理由は明快で、S3 の機能群はどれも「ある評価軸を最適化するための道具」だからだ。ストレージクラスは「アクセス頻度×取得時間×コスト」を、ライフサイクルは「時間経過に伴うコスト最適化」を、暗号化は「鍵の管理責任をどこに置くか」を、VPC エンドポイントは「アクセス経路をインターネットから隔離するか」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の機能を一意に決める構造になっている。

具体例で見よう。「めったにアクセスしないが即時取り出したいログを最安で」——これはアクセス頻度(低)×取得時間(即時)の軸だから Standard-IA が正解だ。「アクセスパターンが読めないデータを自動で最適化」——予測可否の軸だから Intelligent-Tiering。「オンプレの鍵管理ポリシーに準拠して監査ログも残す」——鍵の管理責任の軸だから SSE-KMS。ここで「S3 のどの暗号化が高機能か」と機能の優劣で考えると誤答する。軸で解く——この一点が S3 問題の攻略法だ。


2. パターン1〜3:ストレージクラスとライフサイクル

最も出題頻度が高いのが、ストレージクラスとライフサイクルの3パターンだ。ここは S3 問題の“主砲”であり、確実に得点したい。

パターン1:ストレージクラス選択(アクセス頻度×取得時間×コスト)

S3 のストレージクラスは、要件文の「アクセス頻度」と「取り出しの速さ」で一意に決まる。

主要ストレージクラスの選び分け(要件キーワード → 正解)
評価項目
Standard
Standard-IA 推奨
One Zone-IA
Glacier / Deep Archive
想定アクセス頻度 高頻度 低頻度・即時取り出し 低頻度・再作成可 アーカイブ(ほぼ無)
取得時間 即時 即時 即時 数分〜数時間
可用性/AZ 冗長 複数 AZ 複数 AZ 単一 AZ 複数 AZ
コスト 中(保存安・取出課金) IA より安 最安
キーワード 「頻繁にアクセス」 「めったに使わないが即時」 「失っても再生成できる」 「長期保管」「監査保存」
迷ったら『アクセス頻度が低い+即時取り出し=Standard-IA』『再作成可能=One Zone-IA』『取り出しに時間許容=Glacier』の3点で振るう。

パターン2:ライフサイクルによる自動階層化

「時間が経つほどアクセスが減るデータをコスト最適化したい」——これは ライフサイクルポリシーで、Standard → Standard-IA(30日後)→ Glacier(90日後)→ 削除 or Deep Archive のように自動遷移させる。ポイントは最低日数の制約で、Standard から Standard-IA への移行は最短30日を待つ必要があり、「7日後に IA へ」のような設定はできない。この制約が選択肢の妥当性を判定する問題が定番だ。

パターン3:Intelligent-Tiering vs ライフサイクル(予測可否)

同じコスト最適化でも、アクセスパターンが予測できるかで道具が変わる。

  • 予測できる(時間で単調に減る)→ ライフサイクル:明確な移行スケジュールを日数で組める場合。
  • 予測できない・変動が激しい → Intelligent-Tiering:S3 がアクセスを監視し、自動で最適な階層へ移動する。移行日数を人が決められないときの正解。

3. パターン4〜5:暗号化とアクセス制御

セキュア設計ドメインの主役がこの2パターン。鍵の管理責任と公開防止の設計を問う。

パターン4:暗号化(SSE-S3 / SSE-KMS / SSE-C / クライアントサイド)

S3 の暗号化は「鍵を誰が管理するか」で決まる。

方式鍵の管理キーワード
SSE-S3AWS が完全管理(AES-256)「暗号化したいが鍵管理は任せたい」
SSE-KMSKMS の CMK・監査ログ・ローテーション「鍵の使用を監査したい」「アクセス制御したい」
SSE-C顧客が鍵を持参・S3 に渡す「鍵は自社保持、暗号化処理は S3 に」
クライアントサイド顧客がアップロード前に暗号化「S3 に渡す前から暗号化したい」

パターン5:アクセス制御と公開防止

「S3 の意図しない公開を防ぐ」は SAA 頻出だ。基本は Block Public Access(アカウント/バケット単位で公開を強制ブロック) を有効化し、アクセスは IAM ポリシーとバケットポリシーで最小権限に絞る。第三者への一時的なファイル共有は**署名付き URL(Pre-signed URL)**で期限付きに。クロスアカウント共有はバケットポリシーで相手アカウントを許可する。ACL は現在非推奨で、「ACL で公開」を選ばせる選択肢は多くがひっかけだ。


4. パターン6〜8:接続・レプリケーション・コンプライアンス

パターン6:VPC Gateway エンドポイントでプライベート接続

「インターネットに出さずに VPC 内の EC2 から S3 にアクセスしたい」——これは S3 用の Gateway 型 VPC エンドポイントが正解だ。NAT ゲートウェイ経由のインターネット通信を避けられ、通信がプライベート化される上に NAT の転送料金も不要になる(コスト面でも有利)。S3 と DynamoDB だけが Gateway 型、他サービスは Interface 型(PrivateLink)という区別も頻出。

パターン7:クロスリージョンレプリケーション(CRR)+バージョニング

「別リージョンに全データの複製を保持して DR に備える」——これは クロスリージョンレプリケーション(CRR)で、前提として バージョニングの有効化が必須だ。同一リージョン内の複製なら SRR。要件が「コンプライアンスで地理的に離れた複製」「リージョン障害への備え」なら CRR、「ログ集約」「同一リージョンで別アカウントへ」なら SRR で切り分ける。

パターン8:Object Lock による WORM(コンプライアンス保持)

「規制で一定期間、誰も(管理者すら)削除・変更できない状態で保管したい」——これは S3 Object Lock の WORM(Write Once Read Many)モデルだ。コンプライアンスモードなら保持期間中は root ユーザーでも削除不可。「改ざん防止」「監査ログの不変保管」「規制要件で削除禁止」がキーワードになる。


5. パターン9〜10:配信と大容量転送

パターン9:静的コンテンツ配信は CloudFront + OAC

「S3 の静的サイト/画像を世界中に低レイテンシで配信し、S3 バケットは直接公開したくない」——これは CloudFront をS3 の前段に置き、**OAC(Origin Access Control)**で「CloudFront 経由のアクセスのみ許可、S3 直アクセスは遮断」する構成が正解だ。Block Public Access を維持したまま配信でき、キャッシュで転送コストも下がる。「S3 を公開して静的ホスティング」だけの選択肢は、セキュリティ要件があるとひっかけになる。

パターン10:大容量アップロードは Transfer Acceleration とマルチパート

  • 遠隔地からの大容量アップロードを高速化Transfer Acceleration。エッジロケーション経由で AWS バックボーンに乗せ、長距離転送を加速する。
  • 100MB 超のファイル:マルチパートアップロードで分割並列転送し、失敗時は該当パートのみ再送。5GB 超の単一 PUT はそもそも不可でマルチパート必須。

6. 頻出ひっかけパターンと打ち手の整理

S3 問題は、正しい打ち手と“やりがちな誤答”が明確に対になっている。表で押さえれば本番で機械的に振るえる。


7. 次のアクション チェックリスト

S3 設計パターンを、今日からの学習に落とし込むための具体アクションをまとめる。


8. 関連記事


9. 関連サイト

AWS 公式