CloudFront 導入を検討している環境で、「FQDN ごとにキャッシュクリアをしたい」という要望がありました。
新機能の Amazon CloudFront SaaS Manager がこの要件にぴったりだと思ったので検証をしてみます。

CloudFront SaaS Manager とは

1つの CloudFront ディストリビューションに複数のテナントのドメイン (FQDN) を CNAME で登録する構成は一般的です。
しかし、この方法ではディストリビューションごとのキャッシュクリアしかできません。
FQDN ごとのキャッシュクリアを実現するには、FQDN ごとにディストリビューションを作成するしかなかったのですが、クオータ制限や管理コスト増加への配慮が必要でした。

CloudFront SaaS Manager では、テンプレートとしてのディストリビューション(マルチテナントディストリビューション)に、複数のドメインごとのディストリビューション(ディストリビューションテナント)が紐づく形になっています。
テンプレートディストリビューションの設定を引き継ぎつつ、ドメインごとに設定をカスタマイズすることが可能になります。

簡単にいうと、全ドメイン共通の設定を定義し、各ドメインごとにカスタマイズ、管理も分離できるという機能のようです。
FQDN ごとのキャッシュクリアも可能です。


テンプレートディストリビューションは、オリジン設定、キャッシュ動作、セキュリティ設定など、ドメイン全体で使用される基本設定を定義します。各テンプレートディストリビューションには、ウェブアクセスコントロールリスト (ACL) のオーバーライドやカスタム TLS 証明書など、ドメイン固有のオリジンパスまたはオリジンドメイン名を表すディストリビューションテナントが含まれています。
https://aws.amazon.com/jp/blogs/news/reduce-your-operational-overhead-today-with-amazon-cloudfront-saas-manager/

検証

実際に CloudFront SaaS Manager を使ったテナントごとのキャッシュクリアを検証してみます。

今回は、よくあるWebページの構成を想定し、 ALB → EC2 の構成で、stgy-ishikawa-test.example.com、devy-ishikawa-test.example.com、prdy-ishikawa-test.example.comの3つのドメインをそれぞれキャッシュクリアしてみます。

パラメータ機能や、各設定の引き継ぎや上書き等の解説は割愛し、ALB → EC2 の構成でのFQDNごとのキャッシュクリアのみ手っ取り早く検証します。

1: マルチテナントディストリビューションの作成

今までのディストリビューション作成画面に、「Distribution options」という項目が追加されています。
ここで「Multi-tenant architecture」を選択します。

次に適用する証明書を選択します。後からドメインごとに選ぶことも可能です。

「次へ」をクリックし、オリジンタイプで「ELB」を選択します。
オリジンで「オリジンにしたいELB」を選択します。

あとは、コンソールの指示に従い、よしなに設定し作成を完了させます。

2: ディストリビューションテナントの作成

「ディストリビューションテナントを作成」をクリックし、テナント名を入力、作成したマルチテナントディストリビューションを選択します。

次の画面で、ドメイン名と証明書を指定します。

あとは、コンソールの指示に従い、よしなに設定し作成を完了させます。
それを、全ドメイン分行います。

3: Route53 のAレコードを登録

各ディストリビューションテナントごとにエンドポイントがあります。
これを、Route53 の Aレコードに登録します。

これも全ドメイン分行います。

4: キャッシュの作成と確認

各テナントのドメインにアクセスし、CloudFront にコンテンツをキャッシュさせます。

1.　まず devy-ishikawa-test.example.com にアクセスします。

初回のレスポンスヘッダーでは x-cache: Miss from cloudfront となり、キャッシュが存在しないことが確認できます。

2.　もう一度同じコマンドを実行します。

今度は x-cache: Hit from cloudfront となり、コンテンツが CloudFront にキャッシュされたことが確認できます。

3.　同様に prdy-ishikawa-test.example.com と stgy-ishikawa-test.example.com にもアクセスし、両方とも x-cache: Hit from cloudfront の状態にします。

これで、3つのテナント全てでキャッシュが効いている状態になりました。

5: FQDN ごとのキャッシュクリアの実行

devy-ishikawa-test.example.com のキャッシュだけをクリアしてみます。
1. Distribution tenants > devy-ishikawa-test.example.comを選択 > invalidation から、Create invalidation をクリック
この時点で、テナント(ドメイン)ごとにキャッシュがクリアできる機能が用意されていることが確認できると思います。
2. キャッシュをクリアしたいパスを入力し、「Create invalidation」をクリックします。

6: 結果の確認

最後に、キャッシュクリアが意図通りに実行されたかを確認します。

1.　キャッシュクリアした devy-ishikawa-test.example.com を確認
再度 devy-ishikawa-test.example.com にアクセスします。

レスポンスヘッダーが x-cache: Miss from cloudfront に戻りました。
devy-ishikawa-test.example.com のキャッシュが正しくクリアされたことが確認できます。

2.　影響を受けていない prdy-ishikawa-test.example.com を確認
次に prdy-ishikawa-test.example.com にアクセスします。

レスポンスヘッダーは x-cache: Hit from cloudfront のままです。
devy-ishikawa-test.example.com のキャッシュクリアが prdy-ishikawa-test.example.com には影響していないことが確認できます。

この結果から、CloudFront SaaS Manager を使うことで、他のテナントに影響を与えることなく、特定の FQDN のキャッシュだけを安全にクリアできることが確認できました。

まとめ

今回は、CloudFront SaaS Manager のユースケースの一つとして、FQDN ごとのキャッシュクリアを検証してみました。

多数のドメインがあり、ドメインごとの設定や管理方法が微妙に異なる時などに、運用がとても楽になりそうです。

参考になったら幸いです。

参考ドキュメント

Amazon CloudFront SaaS Manager を利用して今すぐ運用上のオーバーヘッドを削減しましょう
https://aws.amazon.com/jp/blogs/news/reduce-your-operational-overhead-today-with-amazon-cloudfront-saas-manager/

Understand how multi-tenant distributions work
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-config-options.html