CloudFrontマルチテナントディストリビューションでの Tieringを試してみた
2025年の春に登場した「Amazon CloudFront SaaS Manager」によって、CloudFrontを内蔵した SaaS / IaaS の提供がより簡単になりました。
色々な機能がすでに紹介されていますが、ここでは「プランごとに提供するCDNを変更する」機能について簡単に紹介したいと思います。
プランによるCDNの使い分け
SaaSでは、いわゆる「松竹梅」のように顧客の支払う料金に応じて機能や性能に階層を設けることがあります。これをよく「Tiering」とよんでいます。CloudFrontにおいては、WAFの有無や適用するルールの差、キャッシュ設定のチューニングやレスポンスヘッダーの調整などを差別化要因として挙げることができます。
これまでCloudFrontの設定をプランに応じて変更する場合、CloudFormation / terraformなどを利用した構成変更か、AWS APIを利用した手続的な変更かの2種類が選べました。運用保守を請け負う形で提供されている場合は前者、SaaSに近い形で自動化を実現されたい場合は後者を選ぶことが多かったのではないでしょうか。
Amazon CloudFront SaaS Managerはここにもう1つの選択肢を提供してくれます。
テナントとディストリビューション
Amazon CloudFront SaaS Managerを利用した、マルチテナントディストリビューションでは、1サイトに割り当てるCDNのことをディストリビューションではなくテナントとよびます。マルチテナントとして作成したディストリビューションの設定をベースにした子要素として作られるようなイメージです。
この構成でCloudFrontを構成するメリットの1つは、「複数のサイトに同一の設定を適用しやすい」ことです。ディストリビューション側の設定を変更し、キャッシュポリシーを変更したとしましょう。この場合、テナント側のキャッシュを削除すれば、それ以降は新しい設定でキャッシュが作成されます。
このため、AWS APIを利用してCloudFrontを作成・管理する必要があるケースでも、CloudFrontの設定変更をより簡単に行えるようになります。
テナントは別のディストリビューションに配置できる
そしてSaaS向けを謳うだけあると思える特徴的機能が、テナントの移動です。一度作成したテナントは、ACMなどを利用して証明書を設定していたり、Route53のレコードセットを作成して実際にトラフィックが送られている状態であったとしても、別のディストリビューションへ移動させることができます。
しかも設定の変更はマネージメントコンソールからならほぼ1クリックです。簡単すぎてびっくりしますね。
たとえば以下のようなページがあったとしましょう。
% curl -I "https://1.example.com/index.html"
HTTP/2 200
content-type: text/html
content-length: 49
date: Mon, 06 Oct 2025 07:24:51 GMT
last-modified: Fri, 03 Oct 2025 12:48:41 GMT
etag: "266de3016484362fe5e9567e56737964"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 33803d4c9a2b860b9d73a2e1bcde636a.cloudfront.net (CloudFront)
x-amz-cf-pop: KIX50-P3
x-amz-cf-id: cRzmfNWIqVD8D0waYMXnbRfyLp2Q-UrCa6CQVShhdE4KtQ89r8D9nQ==
age: 44
このテナントを別のディストリビューションに動かしてみました。新しいディストリビューションには、Managed-CORS-and-SecurityHeadersPolicyポリシーが設定されています。
設定を変更した後にcurlで再度アクセスすると、確かにレスポンスヘッダーが追加されました。
% curl -I "https://1.example.com/index.html"
HTTP/2 200
content-type: text/html
content-length: 49
date: Mon, 06 Oct 2025 07:24:51 GMT
last-modified: Fri, 03 Oct 2025 12:48:41 GMT
etag: "266de3016484362fe5e9567e56737964"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 c299cdfd332610b6c7bf9b68a5b762a2.cloudfront.net (CloudFront)
x-amz-cf-pop: KIX50-P3
x-amz-cf-id: glIeNm1NeGMOw1rokwRwLMmTKq_6YR4ca8qsuD6ltClgPvCXiOxRBw==
age: 31
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
strict-transport-security: max-age=31536000
vary: Origin
CDN構成管理も手続型から宣言型へ
CDNやホスティング環境をサービスとして提供する(IaaS化)において、CDNの設定や構成をどのように管理し、更新できるようにするかは重要な課題です。場合によっては、数百数千のCloudFrontを更新するバッチスクリプトやジョブを作る必要も出てきたりします・・・
Amazon CloudFront SaaS Managerを利用した新しい構成管理方法は、構成管理や更新方法を効率化するだけでなく、「CDNの設定によるTiering」という新しいビジネスチャンスまで提供してくれるように感じました。
よりマルチテナント SaaS らしい運用を目指す場合は、たとえば次のような運用法も期待できそうです。
- CDKやterraformでマルチテナントディストリビューションの構成を管理する
- コントロールプレーンにて、ユーザーとCloudFront テナント間の情報管理や構成変更を実施する
「プランごとのCDN設定と、ユーザーそれぞれに払い出すCDN本体を個別管理できる」と考えると、なかなかワクワクしてきますね。
おまけの宣伝
CloudFrontを利用したIaaSを作って運用した時の経験談や、今振り返って感じたことなどを今週末に登壇予定です。
チケットはすでに完売済みですが、登壇後に資料を公開する予定なので、「構成管理をやらないとどれだけつらいか」や「何でこいつこんなにAmazon CloudFront SaaS Managerを推してるんだ?」といった疑問への答えはそちらをご覧いただければと思います。
Discussion