AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA CloudFront 設計問題の頻出パターン10選｜OAC・署名付きURL・キャッシュ・オリジン保護を要件文で即断する

AWS SAA-C03 で CloudFront は配信・キャッシュ・オリジン保護・エッジ機能を横断する頻出テーマ。本記事は CloudFront 設計問題を「S3 オリジンの非公開化（OAC）／プライベート配信（署名付きURL・Cookie）／キャッシュ動作とTTL／HTTPS化とACM（us-east-1）／動的コンテンツとオリジンフェイルオーバー／地理制限とWAF／CloudFront・Global Accelerator・Transfer Acceleration の使い分け／Lambda@Edge と CloudFront Functions／キャッシュ無効化／Origin Shield とコスト」の頻出10パターンに分解する。各パターンで要件文のどのキーワードが正解を一意に決めるかを示す。結論は「CDN 問題はサービス名の暗記ではなく、キャッシュ・オリジン保護・経路・エッジ機能という4つの評価軸で解く」こと。

#AWS #SAA #SAA-C03 #Solutions Architect #CloudFront #CDN #OAC #署名付きURL #WAF #試験対策 #AWS認定資格

CloudFront の設計問題を「CDN だから速くなる」で片づけようとすると、オリジンの保護方法・キャッシュの効かせ方・エッジ機能の選択・経路最適化の使い分けで足をすくわれる。 SAA-C03 で Amazon CloudFront は、コンテンツ配信・キャッシュ・S3 オリジン保護・HTTPS 化・エッジ処理・DDoS 対策と、複数ドメインを横断して顔を出す頻出サービスだ。だが問われるのは「CloudFront の機能暗記」ではなく、何をどうキャッシュするのか・オリジンをどう守るのか・どの経路とエッジ機能で最適化するのかという設計判断である。攻略の鍵は、頻出テーマを「キャッシュとオリジン保護」「HTTPS と動的配信」「経路と使い分け」「エッジ機能とコスト」の4系統×10パターンに畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、CloudFront 設計問題の頻出10パターンを分解する。読み終えれば、「最も安全・低レイテンシで、かつ要件を満たす配信構成はどれか」という問いに、迷わず正解を当てられるようになる。

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

📑 目次

  1. 結論：CDN 問題は「サービス名」ではなく「4つの評価軸」で解く
  2. パターン1〜3：オリジン保護（OAC・署名付きURL・キャッシュ動作）
  3. パターン4〜5：HTTPS化（ACM）と動的コンテンツ・オリジンフェイルオーバー
  4. パターン6〜7：地理制限・WAF と CloudFront・Global Accelerator の使い分け
  5. パターン8〜10：エッジ機能・キャッシュ無効化・Origin Shield とコスト
  6. 頻出ひっかけパターンと打ち手の整理
  7. 次のアクション チェックリスト
  8. 関連記事
  9. 関連サイト

1. 結論：CDN 問題は「サービス名」ではなく「4つの評価軸」で解く

SAA-C03 の CloudFront 問題を最短で解く骨格は、**「要件文が4つの評価軸——キャッシュの効かせ方・オリジンの保護・経路と可用性・エッジ機能——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。

理由は明快で、CloudFront の構成要素はどれも「ある評価軸を制御するための道具」だからだ。オリジンアクセスコントロール（OAC）は「S3 オリジンの保護」を、署名付き URL / Cookie は「限定ユーザーへのプライベート配信」を、キャッシュ動作（Cache Behavior）と TTL は「キャッシュの効かせ方」を、AWS WAF や地理制限は「エッジでの防御」を、Lambda@Edge / CloudFront Functions は「エッジでの処理」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の機能を一意に決める構造になっている。

具体例で見よう。「S3 に直接アクセスさせず、CloudFront 経由のみに絞りたい」——これはオリジン保護の軸だから OAC で S3 バケットを非公開化。「有料会員だけに一時的に動画を配信したい」——プライベート配信の軸だから 署名付き URL / Cookie。「特定の国からのアクセスを遮断したい」——エッジ防御の軸だから 地理制限（Geo Restriction）。「動的サイトの世界中からの応答を速くしたい（キャッシュは効かない）」——経路の軸だから Global Accelerator。ここで「CloudFront を挟めば全部速くて安全」と考えると、動的配信や経路最適化を問う設問で誤答する。軸で解く——この一点が CDN 問題の攻略法だ。

2. パターン1〜3：オリジン保護（OAC・署名付きURL・キャッシュ動作）

最も出題頻度が高いのが、この3パターンだ。ここは CloudFront 問題の“主砲”であり、確実に得点したい。

パターン1：OAC で S3 オリジンを非公開化する

CloudFront 問題で最初に問われるのがオリジン保護だ。「S3 バケットを直接公開せず、CloudFront 経由のアクセスだけを許可したい」——これは OAC（Origin Access Control） が正解になる。S3 バケットは Block Public Access で非公開のまま、バケットポリシーで「CloudFront ディストリビューションからのリクエストのみ許可」とし、利用者は CloudFront の URL だけを踏む。これで S3 の直接 URL を叩かれても届かない。

パターン2：署名付きURL・署名付きCookie でプライベート配信

「有料コンテンツを、認可された利用者にだけ、期限付きで配信したい」——これは 署名付き URL（Signed URL）／署名付き Cookie（Signed Cookie） が正解だ。有効期限や許可 IP レンジをポリシーに埋め込み、期限が切れれば弾かれる。

  • 個別ファイル単位で限定配信 → 署名付き URL：1つの動画・1つのファイルへの一時アクセス。
  • 複数ファイル・サイト全体をまとめて限定 → 署名付き Cookie：会員サイト配下の多数コンテンツを一括で保護。

パターン3：キャッシュ動作（Cache Behavior）とTTL

CloudFront の性能を決めるのがキャッシュだ。**パスパターンごとに挙動を変える「キャッシュビヘイビア」**を理解すると、多くの設問が即断できる。

  • 静的コンテンツ（画像・CSS・JS）→ 長い TTL でキャッシュ：オリジン負荷を減らし、エッジから高速返却。
  • 動的 API（/api/*）→ TTL を短く／キャッシュしない：都度オリジンへ。パスパターンでビヘイビアを分ける。
  • キャッシュキー：クエリ文字列・ヘッダー・Cookie のうち「キャッシュを分ける必要があるものだけ」を含める。含めすぎるとヒット率が落ちる。

3. パターン4〜5：HTTPS化（ACM）と動的コンテンツ・オリジンフェイルオーバー

パターン4：独自ドメインの HTTPS 化と ACM 証明書（us-east-1 の罠）

「CloudFront で独自ドメインを HTTPS 配信したい」——これは AWS Certificate Manager（ACM） で発行した証明書を CloudFront に紐付けるのが正解だ。ここに SAA 頻出の“地雷”がある。

パターン5：動的コンテンツ配信とオリジンフェイルオーバー

CloudFront は静的配信専用ではない。ALB や API Gateway をオリジンにして動的コンテンツも配信でき、TLS 終端・WAF・エッジ経由の経路最適化を効かせられる。可用性を高める仕組みも押さえたい。

  • 複数オリジンの振り分け：パスパターンごとにオリジンを変える（/img/* は S3、/api/* は ALB）。
  • オリジンフェイルオーバー（オリジングループ）：プライマリオリジンが 5xx / タイムアウトを返したら、自動でセカンダリオリジンへ切り替える。「配信元の障害時も止めたくない」がキーワード。
CloudFront のオリジンと使い分け（要件キーワード → 正解）
評価項目
S3 オリジン 推奨
ALB / API Gateway オリジン
オリジングループ
主な用途 静的コンテンツ配信 動的コンテンツ・API 配信 オリジン障害時の冗長化
保護方法 OAC でバケット非公開 WAF・SG・カスタムヘッダー プライマリ＋セカンダリ
キャッシュ 長 TTL が効く パスで短 TTL / 無効化 オリジンごとに設定
キーワード 「静的サイト」「画像・動画」 「動的」「API」「TLS 終端」 「配信元障害でも継続」
迷ったら『静的＝S3＋OAC』『動的＝ALB/API Gateway』『冗長化＝オリジングループ』で振るう。

4. パターン6〜7：地理制限・WAF と CloudFront・Global Accelerator の使い分け

パターン6：地理制限（Geo Restriction）と WAF による エッジ防御

「特定の国だけに配信を許可／遮断したい」——これは CloudFront の 地理制限（Geo Restriction） で国単位のホワイトリスト／ブラックリストを設定するのが正解だ。さらにアプリ層の攻撃対策は WAF を組み合わせる。

  • 国単位のアクセス制御 → 地理制限：ライセンス地域外を遮断、など。
  • SQL インジェクション・XSS 等の L7 攻撃対策 → AWS WAF を CloudFront に紐付け：OWASP Top 10 相当をエッジでブロック。
  • 大規模な L3/L4 DDoS 対策 → AWS Shield：CloudFront は Shield Standard が自動適用、より高度な防御は Shield Advanced。

パターン7：CloudFront・Global Accelerator・Transfer Acceleration の使い分け

「速くしたい」という要件で、3つの“アクセラレーション”サービスを取り違えるのが SAA 頻出の罠だ。キャッシュできるか／プロトコルは何か／何を速くするかで一意に決まる。

3つの高速化サービス（要件キーワード → 正解）
評価項目
CloudFront 推奨
Global Accelerator
S3 Transfer Acceleration
本質 エッジキャッシュ CDN AWS 網での経路最適化 S3 への高速アップロード
得意な対象 キャッシュ可能な静的/動的 Web キャッシュ不可の動的・非 HTTP 遠距離からの S3 転送
プロトコル HTTP / HTTPS TCP / UDP（任意ポート） HTTP（S3 API）
固定 IP なし あり（Anycast 静的 IP） なし
キーワード 「CDN」「キャッシュ」「Web 配信」 「動的」「TCP/UDP」「固定 IP」 「遠隔から S3 へ大容量アップ」
迷ったら『キャッシュ可能な Web＝CloudFront』『動的・非 HTTP・固定 IP＝Global Accelerator』『S3 への遠距離アップロード＝Transfer Acceleration』で振るう。

5. パターン8〜10：エッジ機能・キャッシュ無効化・Origin Shield とコスト

パターン8：Lambda@Edge と CloudFront Functions の使い分け

「エッジでリクエスト/レスポンスを加工したい」——これはエッジコンピューティングの軸だ。2つの選択肢を用途で切り分ける。

エッジ処理の選択（要件キーワード → 正解）
評価項目
CloudFront Functions 推奨
Lambda@Edge
実行場所 エッジロケーション リージョナルエッジキャッシュ
処理内容 軽量・超低レイテンシ 重い処理・外部アクセス可
代表用途 ヘッダー書き換え・URL リライト・簡易認可 A/B テスト・SSR・別サービス呼び出し
キーワード 「単純なヘッダー操作」「大量・低コスト」 「外部/AWS 連携」「複雑なロジック」
迷ったら『軽量・高頻度・低コスト＝CloudFront Functions』『複雑・外部アクセスあり＝Lambda@Edge』で振るう。

詳細は Lambda@Edge と CloudFront Functions の使い分けで深掘りしている。「単純なヘッダー/URL 操作を大量に低コストで」なら CloudFront Functions、「外部 API や AWS サービスを呼ぶ／重い処理」なら Lambda@Edge が正解になる。

パターン9：キャッシュ無効化（Invalidation）とバージョニング

「デプロイしたのに古いコンテンツが表示される」——これはキャッシュ更新の設問だ。打ち手は2つ。

  • 即時反映が必要 → Invalidation（キャッシュ無効化）：/* などパスを指定してエッジのキャッシュを削除。ただし多用すると課金対象で、大量無効化はアンチパターン。
  • 恒常的な運用 → ファイル名バージョニング：style.v2.css のようにパスを変える運用にすれば、無効化に頼らず常に最新を配信できる。SAA では「無効化の乱用を避け、バージョン付きパスで解決」が推奨解。

パターン10：Origin Shield・Price Class によるコスト最適化

CloudFront の総仕上げが、キャッシュ効率とコストの最適化だ。

  • オリジン負荷をさらに減らす → Origin Shield：オリジン手前に集約キャッシュ層を追加し、オリジンへのリクエストを束ねる。「オリジン負荷が高い／キャッシュヒット率を上げたい」がキーワード。
  • 配信範囲でコスト調整 → Price Class：全エッジ（All）か、主要地域に絞る（200 / 100）かを選び、不要地域のエッジを外してコストを最適化する。「特定地域のユーザーだけ」がキーワード。

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

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

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

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

8. 関連記事

9. 関連サイト

AWS 公式