年三日坊主のKKです。
地域によっては7月からお盆参りが始まっていると思いますが、普段冷房の効いたデータセンターに勤める拙僧は酷暑の8月のお盆参りに耐えられるのでしょうか。
毎度のことながら自分でも心配になります。
2025年4月28日、突然それまで1種類しかなかったCloudFrontのディストリビューションに「マルチテナントディストリビューション」が追加されました。複数ブランドのWebサイトを運営する企業や、SaaS事業者、多数のランディングページを管理するWeb制作・運用事業者も想定された「CloudFront SaaS Manager 」という機能の一部です。
参考：Amazon CloudFront 向け SaaS Manager の発表
名前から、いかにも「1つのCloudFrontディストリビューションで複数ドメインを配信する機能」とわかりますが、実際にはそれだけではありません。
また、人によって感じ方はいろいろだとは思いますが、ちょっと名前から期待される機能とは違うところもあります。
従来の標準（シングルテナント）ディストリビューションでも、1つのディストリビューションに複数の代替ドメイン名を登録できます。標準ディストリビューションに登録できる代替ドメイン名は、デフォルトクォータで100個です。
したがって、マルチテナントディストリビューションの本質は、単に複数ドメインを登録できることではなく、共通設定をテンプレート化し、サイトごとの差分だけをテナント単位で管理できることにあります。
参考：ドキュメント ＞ Amazon CloudFront ＞ デベロッパーガイド ＞ クォータ
本記事では、マルチテナントディストリビューションの仕組み、標準ディストリビューションとの違い、強みと弱み、適した用途について解説します。
なお、今のところマルチテナントディストリビューションは従量プランでの提供のみで、定額プランでの利用は出来ません。
マルチテナントディストリビューションを構成する3つのリソース
マルチテナントディストリビューションを理解するには、次の3つのリソースを区別する必要があります。
- マルチテナントディストリビューション
- ディストリビューションテナント
- 接続グループ
全体像は次のようになります。
| lp-a.example.com ─────┐ │ campaign.example.net ─┼── DNS │ lp-b.example.com ─────┘ │ ▼ +-----------------------------------+ | 接続グループ | | dxxxxxxxxxxxxx.cloudfront.net | | CloudFrontへのルーティング入口 | +-----------------------------------+ │ ▼ Host名からテナントを特定 +----------------------+ +----------------------+ | テナントA | | テナントB | | Domain: lp-a... | | Domain: campaign... | | fqdn: lp-a... | | fqdn: campaign... | +----------------------+ +----------------------+ │ │ └───────────┬───────────┘ ▼ +-----------------------------------+ | マルチテナントディストリビューション | | ・オリジン | | ・キャッシュ動作 | | ・WAF | | ・Origin Shield | | ・パラメータ定義 | +-----------------------------------+ │ ▼ S3 / ALB / APIなど |
マルチテナントディストリビューション
マルチテナントディストリビューションは、各Webサイトで共有する設定をまとめたブループリント、つまりテンプレートです。
ここには、次のような設定を定義します。
- オリジン
- オリジンパス
- キャッシュ動作
- AWS WAF
- Origin Shield
- CloudFront Functions
- レスポンスヘッダーポリシー
- オリジンリクエストポリシー
- パラメータ定義
重要なのは、マルチテナントディストリビューション自体にはCloudFrontのルーティングエンドポイントがなく、直接アクセスできないことです。
実際にユーザーからのアクセスを受け付けるには、後述するディストリビューションテナントと接続グループが必要です。
参考：ドキュメント ＞ Amazon CloudFront ＞ デベロッパーガイド ＞ マルチテナントディストリビューションの仕組みを理解する
ディストリビューションテナント
ディストリビューションテナントは、個々のWebサイトに相当するリソースです。
例えば、次の2つのサイトを配信する場合は、基本的に2つのディストリビューションテナントを作成します。
| lp-a.example.com campaign.example.net |
各テナントは、マルチテナントディストリビューションの設定を継承します。そのうえで、テナントごとに次のような値を変更できます。
- ドメイン名
- サーバー証明書
- オリジンドメイン名に埋め込むパラメータ
- オリジンパスに埋め込むパラメータ
- AWS WAF Web ACL
- 地理的制限
- キャッシュ無効化対象
ディストリビューションテナントには最低1つのドメイン名が必要です。また、そのドメインをカバーする有効なサーバー証明書も必要です。
参照：ドキュメント ＞ Amazon CloudFront ＞ デベロッパーガイド ＞ ディストリビューションテナントのカスタマイズ
接続グループ
接続グループは、ディストリビューションテナントがCloudFrontネットワークへ接続するためのルーティングエンドポイントを提供します。
例えば、次のようなCloudFrontドメイン名です。
| d111111abcdef8.cloudfront.net |
各WebサイトのDNSレコードは、この接続グループのエンドポイントを参照します。
マルチテナントディストリビューションを作成すると、デフォルト接続グループが自動的に作成されます。特別な分離要件がなければ、通常はこのデフォルト接続グループを利用します。
リクエストはどのように処理されるのか
例えば、ユーザーが次のURLへアクセスしたとします。
| https://lp-a.example.com/ |
処理の流れは次のようになります。
- 「lp-a.example.com」のDNSレコードから、接続グループのCloudFrontエンドポイントが返される
- CloudFrontがリクエストのホスト名から対象のディストリビューションテナントを特定する
- テナントが継承しているマルチテナントディストリビューションの設定を読み込む
- テナント固有のパラメータや証明書、WAF設定を適用する
- 解決されたオリジンおよびオリジンパスからコンテンツを取得する
- CloudFrontからユーザーへコンテンツを返す
マルチテナントディストリビューションでは、オリジンドメイン名とオリジンパスにパラメータを設定できます。
例えば、オリジンパスを次のように定義します。（本来｛｝は半角文字です）
| /html/｛｛fqdn｝｝ |
テナント側で次のパラメータ値を指定します。
| fqdn = lp-a.example.com |
すると、このテナントのオリジンパスは次のように解決されます。
| /html/lp-a.example.com |
この仕組みにより、同じS3バケットをオリジンとして使用しながら、テナントごとに異なるディレクトリのコンテンツを配信できます。パラメータはオリジンドメイン名またはオリジンパスで使用でき、各フィールドでは最大2つまで利用できます。
標準ディストリビューションとの比較
標準ディストリビューションとマルチテナントディストリビューションの主な違いを整理すると、次のようになります。
| 比較項目 | 標準ディストリビューション | マルチテナントディストリビューション |
|---|---|---|
| 主な用途 | 1つのWebサイトまたはアプリケーション | 同一構成を共有する多数のWebサイト |
| CloudFrontエンドポイント | ディストリビューション自身が持つ | 接続グループが持つ |
| 直接アクセス | 可能 | テンプレート自体には直接アクセス不可 |
| 設定の再利用 | IaCなどで複製 | テナントが共通設定を自動継承 |
| ドメインの登録先 | ディストリビューション | ディストリビューションテナント |
| サイト固有のオリジンパス | ディストリビューションごとに設定 | テナントパラメータで変更可能 |
| サイト固有の証明書 | ディストリビューション単位 | テナント単位または共通証明書を継承 |
| サイト固有のWAF | ディストリビューション単位 | テナントごとに上書き可能 |
| デフォルトクォータ | 500ディストリビューション／アカウント | 10,000テナント／アカウント |
| 機能互換性 | CloudFrontの基本機能を広く利用可能 | 一部未対応機能あり |
標準ディストリビューションは、デフォルトで1アカウントあたり500個です。
一方、マルチテナント構成では、デフォルトで1アカウントあたり10,000個のディストリビューションテナントと20個のマルチテナントディストリビューションを作成できます。
いずれも一部のクォータは引き上げ申請が可能です。
ここで注意したいのは、標準ディストリビューションでも複数ドメインを登録できる点です。
例えば、次の2つのドメインで完全に同じサイトを公開するだけなら、標準ディストリビューションに2つの代替ドメイン名を登録するだけで十分です。
| www.example.com example.com |
一方、次のようにサイトごとにコンテンツや証明書、オリジンパスを切り替えながら、キャッシュやWAFの基本設定を共通化したい場合は、マルチテナントディストリビューションが適しています。
| customer-a.example.com → /html/customer-a customer-b.example.com → /html/customer-b campaign.example.net → /html/campaign |
マルチテナントディストリビューションの強み
1. CloudFront設定をテンプレート化できる
多数のWebサイトを標準ディストリビューションで運用すると、サイトごとに似た設定が複製されていきます。
例えば、次の設定を100個のディストリビューションへ個別に設定することになります。
- HTTPSへのリダイレクト
- キャッシュポリシー
- OAC
- セキュリティヘッダー
- AWS WAF
- Origin Shield
- CloudFront Functions
- ログ出力
最初は同じ設定でも、運用を続けるうちに一部のディストリビューションだけ設定変更が漏れ、構成差分が生じることがあります。
マルチテナントディストリビューションでは、共通設定をテンプレート側で管理し、各テナントが自動的に継承します。AWSの公式ドキュメントにおける説明でも、構成の再利用、一貫したリソースパターンの維持、運用負担の軽減を主な利点として挙げています。
2. サイト追加時に必要な設定を減らせる
新しいサイトを追加するときは、CloudFrontの設定を一から作成するのではなく、ディストリビューションテナントを追加します。
テナント作成時に必要な主要情報は、次のようなものです。
- テナント名
- ドメイン名
- サーバー証明書
- オリジンパスなどのパラメータ
- 必要に応じたWAFや地理的制限の上書き
手動でサイトを追加する際は勿論、APIやAWS CLI、CloudFormationなどと組み合わせれば、サイトの追加処理をオンボーディングワークフローとして自動化しやすくなります。
3. オリジンの違いをパラメータで吸収できる
前述の通りマルチテナントディストリビューションのパラメータは、次の2か所で使用できます。
- オリジンドメイン名
- オリジンパス
例えば、サイトごとにS3バケットを分ける場合は、オリジンドメイン名の一部をパラメータ化できます。（本来｛｝は半角文字です）
| ｛｛customer｝｝-contents.s3.ap-northeast-1.amazonaws.com |
あるいは、1つのS3バケット内でディレクトリを分ける場合は、オリジンパスをパラメータ化できます。 （本来｛｝は半角文字です）
| /html/｛｛fqdn｝｝ |
同じCloudFront設定を使いながら、コンテンツの取得先だけをテナントごとに変更できます。
4. サーバー証明書をサイトごとに管理できる
同じ親ドメイン配下のサイトであれば、マルチテナントディストリビューションに設定したワイルドカード証明書を各テナントへ継承できます。
| *.example.com |
顧客独自ドメインなど、共通証明書でカバーできない場合は、テナントごとにACM証明書を設定できます。
また、CloudFrontはディストリビューションテナント用のマネージド証明書にも対応しています。
CloudFrontがACM証明書の取得や更新を補助するため、多数の独自ドメインを扱う構成で証明書運用を簡素化できます。
（標準ディストリビューションでもマルチドメインかつワイルドカードのサーバ証明書を用意出来れば、ひとつのディストリビューションで多数のドメインをホストできなくはないです。）
5. テナントをサービス階層ごとに分けられる
すべてのサイトを1つのマルチテナントディストリビューションへ集約する必要はありません。
例えば、次のような分類ができます。
| lp-basic └─ 基本キャッシュ、共通WAF lp-premium └─ Origin Shield、有償WAFルール lp-enterprise └─ テナント固有WAF、専用オリジン |
AWSの公式例では、Basic、Premium、Enterpriseといったサービス階層ごとにマルチテナントディストリビューションを分ける構成が紹介されています。
マルチテナントディストリビューションの弱みと注意点
1. すべてのCloudFront機能に対応しているわけではない
2026年7月30日時点では、マルチテナントディストリビューションで利用できない機能があります。
代表例は次のとおりです。
- CloudFront Continuous Deployment
- Origin Access Identity（OAI）
- AWS WAF Classic
- AWS Firewall ManagerによるCloudFrontポリシー適用
- 専用IPカスタムSSL
- 標準ログ記録のレガシー版
- Price Class
- Smooth Streaming
- IAMサーバー証明書
- SSLv3
S3オリジンへのアクセス制御では、OAIではなくOACを使用する必要があります。
（これはどちらかというと標準ディストリビューションの方が後方互換のためにサポートを残していると考えた方が良いとは思います）
IPv6やAnycast静的IPの設定は、マルチテナントディストリビューションやテナントではなく、接続グループで管理します。
特に、Price ClassやContinuous Deploymentが必須要件の場合は、標準ディストリビューションの利用を検討する必要があります。
2. テンプレート変更の影響範囲が広い
共通設定を一元管理できることは強みですが、同時にリスクでもあります。
マルチテナントディストリビューションのキャッシュ動作やオリジン設定を変更すると、その設定を継承している複数のテナントへ影響する可能性があります。
そのため、次のような分類でテンプレートを分けることが重要です。
- 本番と検証
- 一般公開サイトと会員サイト
- 通常LPと大規模キャンペーン
- 標準セキュリティと高セキュリティ
- 共通S3オリジンと顧客専用オリジン
「1つに集約できるから集約する」のではなく、変更時の影響範囲を考えて境界を設計しましょう。
3. テナント単位で変更できる項目には限りがある
テナント単位で変更できる主な項目は、パラメータ、サーバー証明書、ドメイン名、WAF、地理的制限などです。
一方、キャッシュ動作やCloudFront Functions、オリジンリクエストポリシーなどをテナントごとに大きく変えたい場合は、別のマルチテナントディストリビューションへ分けた方が管理しやすくなります。
また、パラメータには次のデフォルトクォータがあります。
- マルチテナントディストリビューションあたり5個
- ディストリビューションテナントあたり5個
- 1つのオリジンドメイン名またはオリジンパス内で2個
複雑な差分をすべてパラメータで吸収しようとすると、かえって構成が分かりにくくなりますので、無理せずディストリビューションは分けましょう。
4. 「共通S3バケット」は厳格なセキュリティ分離ではない
1つのS3バケット内でテナントごとにプレフィックスを分ける構成は、静的な公開コンテンツを整理する用途には適しています。
ただし、次のような構成は、主に論理的な分離です。
| html/customer-a/ html/customer-b/ |
CloudFrontの設定ミスや、テナント作成時のパラメータ指定ミスにより、別テナントのプレフィックスを参照させてしまう可能性があります。
公開LPであれば許容できる場合が多いですが、顧客ごとの機密情報や認可が必要なコンテンツを格納する場合は、次のようなより厳格な分離を検討しましょう。
- テナントごとにS3バケットを分ける
- AWSアカウントを分ける
- マルチテナントディストリビューションを分ける
- アプリケーション側で認証・認可する
- 署名付きURLや署名付きCookieを利用する
5. 接続グループも共有リソースである
通常はデフォルト接続グループを利用しますが、特定のテナントを他と分離したい場合はカスタム接続グループを作成できます。
接続グループを変更した場合は、新しいCloudFrontエンドポイントに合わせてDNSレコードも更新する必要がありますが、逆に言えば接続グループ以外のディストリビューション設定を再設定することなくDDoS攻撃を受けたテナントを別接続グループへ移動して他テナントへの影響を抑えるような運用が可能になるということでもあります。
どのような用途に向いているのか
マルチテナントディストリビューションは、次のような用途に向いています。
多数のランディングページを運用する
例えば、キャンペーンごとに異なるFQDNを発行し、同じセキュリティ設定とキャッシュ設定でLPを配信するケースです。
| summer.example.com winter.example.com product-a.example.net product-b.example.org |
コンテンツだけをS3内の別ディレクトリへ配置し、CloudFront設定は共通化できます。
SaaSで顧客独自ドメインを提供する
SaaS利用者ごとに次のような独自ドメインを提供するケースです。
| portal.customer-a.example service.customer-b.example |
テナント単位の証明書、ドメイン、オリジンパスを管理できます。
複数ブランドのWebサイトを運用する
企業が複数ブランドや事業部のWebサイトを持ち、基本的なCDN・WAFポリシーを統一したい場合に適しています。
Web制作・ホスティングサービスを提供する
顧客サイトの追加時に、ディストリビューションを一から作成する代わりに、テナントを作成するワークフローへ統一できます。
向いていないケース
一方、次のような場合は標準ディストリビューションの方がシンプルです。
- 管理するサイトが1つか2つしかない
- サイトごとにキャッシュ動作が大きく異なる
- サイトごとに異なるCloudFront FunctionsやLambda@Edgeが必要
- Continuous Deploymentが必須
- Price Classを利用したい
- AWS Firewall Managerによる一元適用が必須
- サイトごとにAWSアカウントや権限境界を完全に分けたい
- テンプレートの共通部分がほとんどない
マルチテナントディストリビューションは、サイト数が多いほど効果が大きくなりますが、サイト数だけで判断するものではありません。
次の問いに対して多くが「はい」になる場合に適しています。
- 各サイトのCloudFront設定の大部分は共通か
- サイトごとの差分はドメイン、証明書、オリジンパスなどに限定できるか
- サイトの追加と削除を定型化したいか
- 同じWAFやキャッシュポリシーを一括管理したいか
- 将来的にサイト数が増えるか
- テナント作成をAPIやIaCで自動化する予定があるか
まとめ
CloudFrontマルチテナントディストリビューションは、単に1つのCloudFront設定で複数ドメインを配信するだけの機能ではありません。
実際には、次の3層で構成される管理モデルです。
| マルチテナントディストリビューション └─ 共通設定を持つテンプレート ディストリビューションテナント └─ 各Webサイトのドメイン・証明書・パラメータ 接続グループ └─ CloudFrontへのルーティングエンドポイント |
同じ構成のWebサイトを多数管理する環境では、設定の重複や構成差分を減らし、サイト追加を定型化できる点が大きな利点です。
一方で、標準ディストリビューションの全機能を利用できるわけではなく、テンプレート変更時の影響範囲や、テナント間の分離方法も設計する必要があります。
次回の記事では、1つのS3バケット内にFQDNごとのディレクトリを作り、オリジンパスを次のようにパラメータ化して複数のLPを配信する構成を実際に作成します。（本来｛｝は半角文字です）
| /html/｛｛fqdn｝｝ |
