AWS 実践コース / CLOUDFRONT 深掘り道場

CloudFront Q1-Q6を、ひとつの判断軸で解く

難しく感じる原因は、ビヘイビア・オリジン・HTTPS・CORSを一度に考えているからです。問題ごとに「今は何を比較する問題か」を一つに絞れば解けます。

TL;DR

  1. パス → ビヘイビア → オリジンの順で追う。
  2. HTTPSは ブラウザ→CloudFront と CloudFront→ALB を分ける。
  3. CORSはJavaScriptの有無ではなく、scheme・host・portで判断する。

01最初に覚える一本線

CloudFrontは、受け取ったパスに最も適切なビヘイビアを当て、そのビヘイビアに設定されたオリジンへ送ります。

URLのパスからビヘイビアを選びオリジンへ転送する流れ
この課題の図では、優先度1が /api/v1/*、優先度2が /static/*、最後がデフォルト *。
リクエストのパス
  → 一致するビヘイビアを優先順位順に探す
  → そのビヘイビアのオリジンへ転送
  → 同じビヘイビアにあるキャッシュ・通信設定も適用

ビヘイビア = 「このパスなら、どこへ・どんな方針で送るか」というルール。オリジン = S3、Amplify、ALBなどの実際の転送先。

02Q1・Q2 — 振り分けとHTTPS

Q1はパスマッチ、Q2は通信区間。似て見えて、見る設定は別です。

ブラウザからCloudFrontとCloudFrontからALBの通信区間
CloudFrontに証明書を置いても、CloudFrontからALBまでのプロトコルは自動決定されない。

Q1 あなたの回答「Amplify」正解

/api/_next/* は /api/v1/* に一致しません。/static/* にも一致しないため、デフォルトビヘイビア * の Amplifyオリジンへ流れます。

Q2 あなたの回答「HTTP通信？」要修正

正答は 「これだけでは決定しない」。CloudFrontの証明書はブラウザ→CloudFrontをHTTPSにする設定です。CloudFront→ALBは、オリジンプロトコルポリシーとALB側のリスナーで別に決めます。

区間決める設定選択肢
ブラウザ → CloudFront証明書・Viewer protocol policyHTTP / HTTPS
CloudFront → ALBOrigin protocol policy・ALB listenerHTTP / HTTPS

「CloudFrontでTLS終端するから裏はHTTP」は可能な設計の一つですが、証明書を置いたという事実だけからは決まりません。

03Q3 — CORSはAWSサービス名で決まらない

ブラウザはCloudFrontの裏にS3・Amplify・ALBがいることを見ていません。

あなたの回答「S3は不要、AmplifyとALBは必要」要修正

この例では 3つともCORS設定は不要です。ブラウザから見えるURLはすべて https://cloud-pratica.com で、scheme・host・portが同じだからです。

URLschemehostport判定
/static/icon.pnghttpscloud-pratica.com443同一
/index.htmlhttpscloud-pratica.com443同一
/api/v1/workspacehttpscloud-pratica.com443同一

判断基準は「JavaScriptが関係するか」ではありません。 たとえばHTMLをAmplifyから取得していても、JSがALBのDNS名へ直接fetchすればクロスオリジンになり、CORSが必要です。

04Q4 — dev / stgを同じCloudFrontで分ける罠

「分けたほうがいい」という結論は合っています。理由をCloudFrontの機能に結びつけましょう。

あなたの回答「分けたほうがいい」方向は正しい

3点を合わせた設計は不適切です。通常のCloudFrontビヘイビアは stg.cloud-pratica.com と dev.cloud-pratica.com というHost名ではなく、URLパスを条件にオリジンを選ぶからです。両方が / へ来れば、同じデフォルトビヘイビアに入ります。

stg.cloud-pratica.com/ ─┐
                          ├─ 同じパス「/」─→ 同じデフォルトビヘイビア
dev.cloud-pratica.com/ ─┘

推奨：devとstgでCloudFrontディストリビューションを分け、それぞれ対応するAmplifyをデフォルトオリジンにする。設定・キャッシュ・ログ・障害影響も環境単位で分離できます。

補足：エッジ処理でHostを読み取って転送先を変える高度な構成は可能ですが、この要件に対しては複雑さが増えるだけです。

05Q5 — パス分岐とパス書き換えは別仕事

複数Amplifyとビヘイビアは正解。ただし、アプリを / 前提に保つにはもう一段必要です。

パス別ビヘイビアとCloudFront Functionsによるパス書き換え
元のパスでビヘイビアを選んだ後、CloudFront Functionsが接頭辞を削除する。

あなたの回答「Amplify複数 + CFにパス設計」あと一段

ビヘイビア /slack-metrics/* と /kirara/* を作り、各Amplifyオリジンへ向けます。さらに各ビヘイビアのviewer requestにCloudFront Functionsを関連付け、オリジンへ送る前に接頭辞を削除します。

1. /slack-metrics/report
   → behavior /slack-metrics/* → Slack Metrics Amplify を選択
2. CloudFront Function
   → URIを /report に書き換え
3. Slack Metrics Amplify
   → ルート配下の /report として受け取る

教材の重要な順序は、ビヘイビア評価 → viewer request → origin request。先に振り分けが確定するため、その後でURIを書き換えても別ビヘイビアへ移りません。

実務上の注意：アプリが /assets/app.js や /_next/* のような絶対パスを生成すると、その次のリクエストから接頭辞が消え、どのアプリの資産か判別できません。完全にパスを意識させない設計は、相対URLで動くかを検証するか、base path対応・サブドメイン分割が必要です。

なおCloudFrontにはデフォルトビヘイビアが必須ですが、ルート専用Amplifyを新設することまでは必須ではありません。既存のどちらか、S3の案内ページ、別のルートアプリなど、/* の仕様に合わせて選びます。

06Q6 — 同じS3でキャッシュを分ける

キャッシュの違いはビヘイビアの責務。保存先が同じならオリジンは同じで構いません。

あなたの回答「2つのビヘイビアを別オリジンへ」半分正解

2つのビヘイビアは正しいです。ただし別オリジンにする必要はありません。両ビヘイビアを同じS3オリジンへ向け、それぞれ異なるキャッシュポリシーを設定します。

ビヘイビア例キャッシュポリシーオリジン
/static/assets/*長期キャッシュ同じ S3
/static/runtime-config/*キャッシュ無効 / TTL 0同じ S3

提出で使える一文：「パスごとにキャッシュポリシーの異なる複数のビヘイビアを作成し、どちらのビヘイビアも同一のS3オリジンへ振り分ける。」

07そのまま整理できる提出用回答

短くても、判断根拠を一文入れると理解が伝わります。

Q1

Amplify。/api/_next/* は /api/v1/* と /static/* のどちらにも一致しないため、デフォルトビヘイビア * のAmplifyオリジンへ振り分けられる。

Q2

これだけでは決定しない。CloudFrontのHTTPS証明書はブラウザとCloudFront間の通信に使う。CloudFrontとALB間をHTTPにするかHTTPSにするかは、オリジンプロトコルポリシーとALBのリスナー設定で別に決める。

Q3

CORS設定は不要。3つのURLはすべてschemeが https、hostが cloud-pratica.com、portが443で同一オリジンだから。CloudFrontの裏側の転送先がS3・Amplify・ALBに分かれていても、ブラウザからは見えない。

Q4

3つを合わせた設計は不適切。通常のCloudFrontビヘイビアはHost名ではなくパスを条件にオリジンを振り分けるため、同じパスでアクセスされるdevとstgを期待どおりに分けられない。環境ごとにCloudFrontディストリビューションを分け、それぞれ対応するAmplifyをオリジンにする。

Q5

CloudFrontにSlack Metrics用とKIRARA用のAmplifyオリジンを登録し、/slack-metrics/* と /kirara/* のビヘイビアからそれぞれへ振り分ける。各ビヘイビアにCloudFront Functionsを設定し、選択後に /slack-metrics または /kirara の接頭辞をURIから削除して、各Amplifyには / 起点のパスとして転送する。

Q6

キャッシュ対象と非対象をパスで分け、それぞれに異なるキャッシュポリシーを持つ複数のビヘイビアを作る。保存先は同じなので、どちらのビヘイビアも同一のS3オリジンへ振り分ける。

結論

  1. Q1・Q4・Q5・Q6は「パス → ビヘイビア → オリジン」で解く。
  2. Q2は通信区間を二つに分け、Q3はブラウザから見たオリジンを比較する。
  3. あなたの回答はQ1が正解、Q4も方向は正解。理解ゼロではなく、判断基準の整理があと一段です。