目的
CloudFrontを利用して、パスの振り分けをやる。
今回は、移行中のWebサービスがあり、一部のパスをAWSアカウントAのAmplifyに他のパスをAWSアカウントBのALBに振り分ける。
またアカウントAにおいて、画像はS3で管理しており、画像はCloudFront経由で取得する。
この記事では、CloudFrontでAmplifyへの連携とS3アクセスの部分について触れる。
大事なポイントを3つ記載する↓
ビヘイビアのオリジンリクエストのHostヘッダー
Amplifyは内部にCloudFrontを持っているめ、CloudFront→Amplifyというアクセスの際、Hostヘッダーを送ると、自身からリクエストと勘違いしてループする。
これに対して2つの対応方法がある。
| 方法 | 詳細 |
|---|---|
| HostヘッダーをAmplifyに送らない | これは事例としていくつか見つかる。シンプルだが、Amplifyの中でリダイレクトなどがあると問題になる可能性があるらしい。ビヘイビアのオリジンリクエストポリシーで以下を選択するとできる。Managed-AllViewerExceptHostHeader |
| Hostヘッダーにオジリンのドメインで送る | これはあまり情報がないのでリスクがあるかも？あまり記事がないが、カスタムヘッダーを用いるとできるっぽい？ |
キャッシュポリシー
Amplifyにも内蔵されたCloudFrontがあり、そこでもキャッシュは働いているはずなので、Amplify用のCloudFrontは、Managed-CachingDisabled としCloudFrontではキャッシュしないようにする。実際、CloudFrontを活用することでさらに細かい制御ができると思うが、まずはシンプルにということでこの方法を選んだ。
・その他
Amplify用のキャッシュポリシーで以下がある。
-
Managed-Amplify-StaticContent -
Managed-Amplify-ImageOptimization
ただしこれらは、キャッシュヘッダーとして Hostヘッダーが含まれている。
そのため、Hostヘッダーをオリジンリクエストで送るなら(Hostヘッダーにオジリンのドメインで送るを選択した場合）使えるがそうでない場合は使えない。
最終的にAmplifyオリジンを持つCloudFrontビヘイビアの設定は以下のようになる
マルチオリジンとシングルオリジン
今回、CloudFront経由にするのはAmplifyとS3。それをマルチオリジンかシングルオリジンとして扱うか。
マルチオリジンのケース(今回は採用しなかった)
1つのCloudFrontでAmplifyとS3をオリジンとして登録
→ビヘイビアに問題あり。画像はNext.jsの配下に/images/publicで存在するめ単純に /*.jpeg などでS3のオリジンに振り分けてしまうと、Next.jsの画像を見に行けなくなる。S3とNext.jsでパスを事前に分けておけば良いが、現時点でS3の構成を見直すのは影響が大きくなりそうなので避けたい。
シングルオリジン(こちらを採用)
二つのCloudFrontを作成
- Amplifyをオリジンとして持つCloudFront
- S3をオリジンとして持つCloudFront
CloudFrontは二つになるがシンプルになる。用途としてもAmplifyをオリジンとしてもつCloudFrontはあくまで振り分け用として使うことで分ける意味はありそう。
