AWS PRACTICAL COURSE 09

Amplifyデプロイと二段CloudFront
— 共通玄関で理解する

CloudFrontを二つ通るのは、キャッシュを二倍にするためではありません。外側はURLをまとめる共通玄関、Amplify側はNext.jsを届ける配信基盤です。

TL;DR

  1. 外側CloudFrontは /static/* とそれ以外を振り分けるリバースプロキシ。
  2. S3向けは外側でキャッシュし、Amplify向けは外側キャッシュを無効にする。
  3. 一つのカスタムドメインで、既存S3とAmplifyアプリを同じサイトに見せる。

01この章で完成するもの

GitHubへのpushから、安全に公開されたstgフロントエンドまでを一周する。

Amplify講座の全6工程を示す図
講座はデプロイだけでなく、入口・権限・ブラウザ通信・stg保護まで完成させる。
段階やること学ぶもの
01–02配信方式を選びdevelopを用意Amplifyを選ぶ理由とGit連携
03AmplifyへデプロイCI/CD、環境変数、SSRビルド
04サービスロールを整理IAMの信頼と最小権限
05CloudFrontで入口を統合オリジン、ビヘイビア、リバースプロキシ
06CORSとBasic認証ブラウザ境界とstg保護

現在地は05。 Amplifyでアプリが動いた後、そのアプリと既存S3を一つの入口から公開する工程。

02CloudFrontは「店舗」より共通玄関

キャッシュは重要だが、転送先を選ぶリバースプロキシの役割も中心にある。

CloudFrontとオリジンを店舗に例えた図
キャッシュヒットなら入口で返し、なければ選ばれたオリジンへ取りに行く。
用語店舗のたとえ実際の役割
CloudFront共通玄関・受付・近所の受取棚URLを受け、転送先を決め、必要なら応答をキャッシュ
Origin倉庫・専門売場元データや処理を持つS3、Amplifyなど
Behavior受付の案内ルールパスごとに転送先とキャッシュ方針を選ぶ
Cache受取棚の在庫元の倉庫まで行かず、近い拠点から返せる応答

CloudFront＝キャッシュだけと捉えると今回の狙いを見失う。外側CloudFrontで最も重要なのは、同じ入口からS3とAmplifyへ振り分けること。

03二段CloudFrontの正体

二つとも同じものを積極的にキャッシュするのではなく、所有者と役割が違う。

自前CloudFrontとAmplify管理CloudFrontの二層構成図
二層なのはAmplify経路だけ。外側は振り分け、内側はアプリ配信を担当する。
利用者
  ↓ https://api.stg.example.com/<path>
自前CloudFront（共通玄関）
  ├─ /static/* → S3
  └─ default   → Amplify developドメイン
                    ↓
                 Amplify管理CloudFront
                    ↓
                 Next.js成果物 / SSR

正確には「Amplifyの後ろにCloudFrontを置く」のではない。Amplify Hostingの配信入口として、AWSがCloudFrontを管理している。

外側CloudFront：自分が管理

共通ドメインを受け、パスを見てS3かAmplifyへ案内する。Amplify向けキャッシュは無効。

内側CloudFront：Amplifyが管理

Next.jsの成果物やSSR応答を、Amplifyの仕組みとして配信・最適化する。

04カスタムドメインで何をまとめるのか

別々の配信元を、利用者には一つのWebサイトのパスとして見せる。

カスタムドメインがURL空間を統合する図
Originの実ドメインは別でも、ブラウザからは同じapi.stg.example.com配下に見える。
利用者が開くURL前段の判定実際の転送先
https://api.stg.example.com/defaultAmplify
https://api.stg.example.com/channels/1defaultAmplify
https://api.stg.example.com/_next/...defaultAmplify
https://api.stg.example.com/static/.../static/*S3

APIは別。 sm-api.stg... は別サブドメインなので、この構成だけでUI・S3・APIすべてが同一オリジンになるわけではない。ブラウザからAPIを呼ぶには次レッスンのCORS設定が必要。

05キャッシュはどこで効かせるか

S3は外側で、AmplifyアプリはAmplify側で。一つの責任を一つの層に持たせる。

BehaviorOrigin外側Cache policy理由
/static/*S3CachingOptimized更新頻度が低い画像などを近いエッジから高速配信
default (*)AmplifyCachingDisabledAmplify側の最適化へ任せ、二重キャッシュを避ける

二段構成でも、Amplifyアプリの有効なキャッシュ責任者は内側だけ。二重に在庫する設計ではない。

外側でもAmplify応答をキャッシュすると、デプロイ後に古い画面が残ったとき、外側と内側のどちらが原因か分かりにくくなる。

06この講座の設定を一枚で確認

仕組みが分かれば、各設定が暗記ではなく役割から読める。

設定値意味
S3 behavior path/static/*静的ファイルだけをS3へ送る
S3 cache policyCachingOptimizedS3応答を外側でキャッシュ
Default originAmplify develop domain多様なNext.jsパスをまとめてAmplifyへ送る
Default cache policyCachingDisabledAmplify向け二重キャッシュを避ける
Origin request policyAllViewerExceptHostHeader閲覧者側HostをAmplifyへ転送しない
Amplify単体で要件を満たせるなら、前段CloudFrontは不要。今回の多段構成は、既存S3との同一ドメイン統合とリバースプロキシの学習が目的。

結論

  1. CloudFrontはキャッシュ装置であると同時に、パスでオリジンを選ぶ共通玄関。
  2. 二段CloudFrontは二重キャッシュのためではなく、自前の入口とAmplify管理の配信基盤が連なるため。
  3. 今回のカスタムドメインは、AmplifyのUIとS3の/static/*を同じapi.stg.example.comのURL空間へまとめる。