概要
CloudFrontの多段構成を構築運用した際の、記録を残します。
内容
既に運用しているCloudFront+αの環境において、既存環境（CloudFront）を手前に置きつつ、全く別な環境をさらにCloudFrontを利用して組みたかったので
いわゆる「CloudFront多段構成」をした際のメモを残しました。
構成
次のような構成例で考えます。
※AWSアーキテクチャ図作成はこちらからお好みのツールを
以下に構築・設定メモを残します。
ドメイン購入＋Route53 HostedZoneでの用意
購入したドメインを使用できるように設定しておきます。
さらに、ACMを*.example.comでカバーしておきます。
忘れがちですが、CloudFrontはバージニアリージョンであることに注意しましょう。
ALBの用意
今回は配下のサーバーを割愛して固定レスポンスにします。
固定レスポンスは200で返すように設定します。
CloudFrontの用意
1段目のCloudFrontは最も手前にあり、www.example.comとします。
※CloudFrontのCNAME設定+Aレコード登録
2段目のCloudFrontは、サブドメインなどで名前解決せずそのままでも良いのですが、わかりやすく今回はbehind-cf.example.comとします。
※CloudFrontのCNAME設定+Aレコード登録
2段目のCloudFrontに、ALBをOrigin登録
CloudFrontの配下には今回ALBをおいてルーティングさせたいのでOrigin登録、及びBehaviorにも登録します。
尚、ALBもAレコード登録している際は、カスタムドメイン名でCloudFrontにOrigin登録をしないとACMがカバーされないことにも注意が必要です（502になります）
1段目のCloudFrontに、2段目のCloudFrontをOrigin登録
Origin登録時ですが、登録名はそのままカスタムドメイン名behind-cf.example.comをそのまま入れれば済みます。
Behavior設定では、今回の場合/service2024のパスの場合後ろのサービスにルーティングさせたいので、パスも指定します。Behaviorの優先順位も気をつけましょう
気になったことに関して
AWSサポートの方に確認+調査したメモです。
CloudFrontはどこまで多段でできるのか？
2段までは可能ということでした。
2段構成時に気をつけることはあるか？
1段目のCloudFrontから2段目のCloudFrontに、Hostヘッダーを転送することはできません。
Apache HTTP ServerのName-based VirtualHostのように、CloudFront自体がHostヘッダーの値に基づいてルーティング先ディストリビューションを決定しているので、Hostヘッダーを使用すると結果としてループ処理となるため、使用しないようにとの事でした。一定の状況下では注意する必要があります（403になります）
運用上のTips
アクセス制御
アクセス制限やWAFをかける際は、WAFも安くはないですし最低限で済ませるためにまずはPublicにおいてある各リソースの状況を確認しましょう。
例えば今回の例だと、最も手前にあるCloudFront、２段目のCloudFront、ALBがパブリックにあるので、AWSのIPに絞ればよいのか？WAFをかけて公開するのか？などの対策を練ります。
メンテナンスモード
工夫次第で様々な実装方法があります。
いまはCloudFront FunctionsでIP制限をかけて開発者以外をメンテナンスページに遷移させたり、特定パスに遷移させてALB側でメンテナンスページに遷移させることも出来ます（Amazon CloudFront KeyValueStore も神アプデなので使えそう）
今回の構成であれば、後ろにあるマイクロサービスのみをメンテナンスモードにするケースも対応できるようにしておき、可能な限り少ない手順かつ短い時間で対応できるようにすることでトラブルを最小限にすることを心がけましょう。
まとめ
- CloudFrontを2段で実装する際は、1段目=手前にあるCloudFrontに2段目のCloudFrontをOrigin登録して使用する。登録時のオリジンドメイン名は、代替ドメインでもデフォルト名(xxxxxxx.cloudfront.net)でもどちらでも良い
- 1段目から2段目のCloudFrontへの設定に関しては、ホストヘッダーを転送しないよう注意が必要
という2点が要点でした。
AWSでは様々な構成パターンがあります。
今回の内容も。背景次第で代替手段は考えられますし、状況を踏まえたベストプラクティスを設計していくと良さそうです。
今回のユースケースとしては例えば、Webアプリケーションにおいて同ドメイン内のサブサービス（マイクロサービス）を展開する際に、全く別なアカウントでリソースを管理・展開するような背景のときに有効です。
ありがとうございました。