こんにちは、AWSグループの藤岡です。
2025年4月28日に、Amazon CloudFront SaaS Manager（以降SaaS managerと記載）の一般提供（GA）が発表され、「マルチテナントディストリビューション」が作成できるようになりました。
SaaSに特化したCloudFrontの新機能は、これまでのSaaSアプリケーションの設計や運用に一石を投じる存在ではないかと個人的には感じています。
そこで本ブログでは、SaaS Manager・マルチテナントディストリビューションを実際に構築して、そこから得た特徴や機能を図解しながら整理することで、SaaS Managerを実務利用する上でのポイント・注意点をお伝えしたいと思います。
本ブログを、マルチテナントディストリビューションの実戦投入を検討する判断材料の1つとして読んでいただけますと幸いです。
※お急ぎの方は まとめ をご確認ください
目次
Amazon CloudFront SaaS Managerとは
CloudFrontは従来より、AWSが提供するグローバルCDN（コンテンツデリバリーネットワーク）サービスとして、多くのSaaSサービスやWebアプリケーションの高速配信を支えてきました。
これに対してSaaS Managerは、マルチテナントSaaS向けにスケーリングと運用管理の簡素化を提供するサービスです。
メリットやユースケースに目を通すと、共通化したディストリビューションへ設定管理を集約することによって、共通設定によって運用負荷を下げられつつ、テナントごとの個別制御も可能にするという点が強調されています。これはなかなか嬉しいポイントと思います。どこまで実用的か、作成して確認してみましょう。
検証環境の構築
マルチテナントディストリビューションの作成
それではSaaS Managerを体験してみましょう。 CloudFrontコンソールから、新規ディストリビューションを作成します。
作成を始めると、まず始めに以下の選択画面が表示されます。
ここで「Multi-tenant architecture」を選択すると、マルチテナントディストリビューションの作成ウィザードに切り替わります。
ディストリビューション名と、共通利用するワイルドカード証明書を設定します。
共通利用するワイルドカード証明書に関するInfoを確認すると、以下のように書かれています。
ここで選択したワイルドカード証明書は、このマルチテナントディストリビューションに関連するすべてのディストリビューションテナントと共有されます。us-east-1 AWS リージョンにある ACM 証明書またはサードパーティー証明書を AWS アカウントで使用できます。
つまり、ここで設定したワイルドカード証明書は、マルチテナントディストリビューションに関連するすべてのディストリビューションテナントで共通利用されることになります。ただ一方で、今後作成するディストリビューションテナントによって、個別に証明書を設定して上書きすることも可能です。
こういったマルチテナントディストリビューションと各ディストリビューションテナントの関係性は、AWS公式にて以下のように図示されています。
※ブログ後半にて、自分の理解も加えて、SaaS Managerの構成を分かりやすく図示して説明いたします。
次ステップは、オリジン設定です。今回はS3を指定して検証を進めます。
ここでマルチテナントディストリビューションの特徴的な機能となるパラメータの設定を行います。
今回の検証では、テナントごとにアクセスするS3バケットを分離したいと思ったため、スクショのように、バケット名の一部を"tenant_name"とパラメータ設定します。 この設定によって、今後作成するディストリビューションテナントでは、個別にオリジン設定をせずにtenant_nameパラメータの値を設定するのみで、tenant_nameが一致するS3バケットにアクセスできるようになります。
オリジンの設定・管理を一元化して、パラメータで切り替えできることが、SaaS Managerの大きな特徴の1つです。
作成を実行して、マルチテナントディストリビューションが作成できました。
ディストリビューションテナントの作成
次に、作成完了したマルチテナントディストリビューションに対して、個別のディストリビューションテナントを作成します。
まず、ディストリビューション名を入力し、作成したマルチテナントディストリビューションを関連付けます。
次に、証明書の設定とドメインの設定を行います。
ドメインは、サブドメインでテナントを区別する方針をとって、"tenant1.example.com"とします。
証明書は、上記ドメインを満たせれば何でも良いのです。（今回は既にマルチテナントディストリビューションで設定したものと同じワイルドカード証明書を選択します。）
次にパラメータの設定を行います。ココがSaaS Managerの肝の1つです。 マルチテナントディストリビューションで定義したパラメータtenant_nameを入力することで、パラメータに応じたオリジンリソースやオリジンパスに動的にルーティングされます。
今回はパラメータ名に応じてS3バケット名が決まります。（バケットも併せて作成しておきましょう。）
次に個別ディストリビューションにおけるセキュリティ設定を行います。 以下のセキュリティ設定は、「Override distribution settings」を有効にすることで、マルチテナントディストリビューションで設定した共通設定を上書きすることができます。
- WAFの有効化
- 地理的制限の有効化
最後に作成を実行することで、ディストリビューションテナントの作成が完了しました。
Aレコードの登録
登録したドメインを名前解決させるために、Aレコードを登録します。登録に必要なCloudFrontのエンドポイントは、作成した任意のディストリビューションテナント画面から確認・取得できます。 以下キャプチャはRoute53ホストゾーンに登録したドメインにAレコードを登録する例になります。
アクセスしてみよう
マルチテナントディストリビューション・ディストリビューションテナントが用意できたので、実際にアクセスしてみます。しかし、以下のように表示されて403エラーが発生しました。
これはCloudFrontではお馴染みの「オリジンにアクセスできない」という403エラーです。 つまり今回S3バケットをオリジンに指定しているので、最も疑わしいのはOAC（オリジンアクセスコントロール）とS3のバケットポリシーです。
実際にオリジンのS3バケットのバケットポリシーを以下のように設定すると表示されるようになりました。
{ "Version": "2008-10-17", "Id": "{任意のId}", "Statement": [ { "Sid": "{任意のSid}", "Effect": "Allow", "Principal": { "Service": "cloudfront.amazonaws.com" }, "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::{バケット名}/*", "arn:aws:s3:::{バケット名}" ], "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::{アカウントID}:distribution/{マルチテナントディストリビューションのID (Ex. E1A2B3C4D5E6F7)}" } } } ] }
無事にサイト表示できました。
※ OAC、バケットポリシーの設定は、作成したマルチテナントディストリビューションのオリジンを更新することで、以下のようにオリジンアクセスの設定箇所が表示されますので、ここから設定しましょう。（作成時点では何故か表示されないように思えますが、ここは今後改めて確認したいと思います...）
同様の流れでパラメータtenant_nameを変更することでアクセス確認できました。
たとえば、サブドメインを"tenant3"に変更したディストリビューションテナントを作成し、以下のようにアクセス確認できました。
また更に異なるパターンとして、ドメインを完全に変えたディストリビューションテナントを作成しても、ホストゾーンにAレコードを登録することで同様にアクセスできました。（ドメインが異なっていても、マルチテナントディストリビューションに所属をすれば、共通設定は継承されるということが分かりました。）
SaaS Managerを図解して整理
ここまで一気に構築・アクセス確認を行いました。ただ、CloudFrontは設定項目が多く複雑さもあって、全体像が掴みにくいかと思います。
そこで、クライアントからのリクエスト経路を示す形で、マルチテナントディストリビューションと個別のディストリビューションテナントの関係性を図示してみました。
図を元にSaaS Managerの各リソースを大雑把に説明すると、以下のようになります。
| リソース | 概要 |
|---|---|
| コネクショングループ | リクエストを受け取るエンドポイント |
| マルチテナントディストリビューション | 所属する個別のディストリビューションテナントに対して共通設定を反映する、共通的なディストリビューション |
| ディストリビューションテナント | 個別のセキュリティ設定とパラメータ設定を持つ、テナントごとのディストリビューション |
シンプルに説明をすることで、それぞれの役割が少し掴めてきました。それでは更に、クライアントからのリクエスト経路を追うことで理解してみましょう。
たとえば、tenant3のクライアントが「https://tenant3.app.com/action-a」 にアクセスした場合、以下のような経路となります。
流れとしては以下のステップになります。
- *.app.comで名前解決されて、コネクショングループにリクエストが到達
- 個別のディストリビューションテナントのドメイン設定によって、一致するディストリビューションテナントにリクエストが振り分けられる
- 振り分けられたディストリビューションテナントのパラメータ設定によって、tenant_nameが"tenant3"に置き換えられる
- キャッシュビヘイビアにて、tenant_nameが"tenant3"に一致して、かつパスパターンが"action-a"に一致するオリジンに対してリクエストが振り分けられる
全体の振る舞いを理解することで、SaaS Managerの各リソースの役割や挙動が分かりやすくなったかと思います。
メリット・デメリット
SaaS Managerの機能・特徴について理解できたので、メリット・デメリットを整理してみましょう。
メリット
①設定の一元管理による、運用負荷・設定ミスの軽減
マルチテナントディストリビューションでWAF・地理的制限・オリジン・キャッシュビヘイビア・ロギング などの設定を一元管理することで、コンソールやIaCでの繰り返し作業・定義を避けることができます。これによって、単純に設定管理を省力化できるだけでなく、作業が煩雑化しにくくなることで設定ミスも減らせます。
また、複数のユニークなドメインを扱う場合に、SaaS Managerの共通設定のメリットが最大限発揮されると個人的に感じています。（※単一ドメイン上でサブドメインを切ってテナントのアクセスを制御する構成であれば、既存のCloudFrontでも1つのディストリビューションで賄えるため、さほどメリットがないかもしれません）
実際に図を書いて説明しましょう。複数のユニークなドメインを扱う場合に、従来のCloudFrontでは、以下図のような構成が必要となり、ドメインが増えるほどディストリビューションが増えて運用管理の手間が増加していました。
従来では上図のようにテナント毎の個別設定を持つことが必然でしたが、テナントを設計・構築する上では、キャッシュビヘイビアのパスパターンやロギング設定など、テナント毎でさほど変わらないケースが多いかと思います。そのため、不必要に設定を個別管理する手間が発生していました。
一方でSaaS Managerを用いることで以下のような構成となります。個別にオリジンやキャッシュビヘイビアを設定管理する必要が無くなり、代わりにパラメータ設定のみで簡単に運用できるようになります。
オリジンとキャッシュビヘイビアの設定は、CloudFrontの肝となる設定でありますが、その分設定項目が多く、私自身これまで担当したプロジェクトで運用負荷の高さを感じていました。これに対して、SaaS Managerを活用してオリジンやビヘイビアを共通設定・管理することで、運用負荷や設定ミスの軽減に貢献できます。
また、テナント固有の差分は、WAF・地理的制限・証明書のみ個別に設定できるため、一定の柔軟性を持たせることができます。
※複数ドメインが単一コネクショングループを共用していることに不安を感じする方もいるかもしれませんが、コネクショングループは複数設定することも可能ですので、トラフィックを踏まえてコネクショングループの分割を検討しましょう。
②パラメータ駆動による、オンボードの省力化・短縮化
ディストリビューションテナントは、最低限の作業としてパラメータ入力のみで簡単に作成でき、マルチテナントディストリビューションの設定を継承します。したがって、構築時の設定作業を最小化することができ、新規テナントのオンボーディングを省力化できます。
パラメータの設定のみで簡単にテナントを準備できることで、ディストリビューションテナントのためのデプロイパイプラインの複雑化を防ぎつつ、テナントのスケールアウトに対応しやすくなります。
今回の検証のように、パラメータとオリジンを対応づけることで、テナント毎に異なるオリジンへアクセスできたりと、思ったよりも柔軟に対応できます。
デメリット
①ディストリビューションテナントで上書き設定できるのは、セキュリティ設定とTLS証明書のみ
メリット①の裏返しでもあるのですが、テナント毎に上書き設定できるのは、セキュリティ設定とTLS証明書のみです。 そのため、テナント毎に個別にオリジンやキャッシュビヘイビアなどを設定できませんので注意が必要です。
共通設定項目が大きく制約が大きいが故に、ピッタリハマるケースでは強力な効果を発揮しますが、テナント固有の要件が生じる場合には、安易にSaaS Managerを導入することはオススメできません。
②共通設定を誤った場合の全テナントへの影響
マルチテナントディストリビューションの良さでもあるのですが、テナントを跨いで共通設定を運用管理できるからこそ、もし誤って設定してしまった場合に、マルチテナントディストリビューションに所属する全てのテナントに影響が出てしまいます。そのため、共通設定を更新する際には細心の注意が必要です。
また設定ミスを防ぐために、以下の対策・対応とセットでSaaS Managerを導入するのが実務では求められると考えます。
| カテゴリ | 項目 | 内容 |
|---|---|---|
| CI/CD導入 | IaC設定管理 | 手動オペレーションを削減 |
| CI/CDパイプライン構築 | 自動検証やデプロイ | |
| 監視強化 | AWS Config設定監査 | リソース構成の継続的記録とルール評価 |
| CloudWatchアラーム | システムメトリクスやログに基づくアラートの設定 | |
| Lambdaによるカスタム監視 | Lambda関数で独自の監視ロジックを実装 |
ただしSaaS Managerは新しいサービスのため、AWS ConfigやIaC（Ex. Terraformなど）での設定管理はこれからサポートされていくと思いますため、今後のアップデートに期待しながらより良い方法を模索していきたいと思います。
まとめ
GAされたSaaS Managerの魅力を知るために、マルチテナントディストリビューション及びディストリビューションテナントを構築して、特徴やメリット・デメリットを整理・考察してみました。
以下が、SaaS Managerを把握する上での重要なポイントです。
- 共通設定管理＋パラメータによって、大量ドメインの効率的な一元管理を実現している
- 一方で個別カスタマイズは WAF・地理的制限・証明書に限定されているため、要件に応じてSaaS Managerの使いどころを見極める必要がある
- 共通設定しているリスクへの対策として、併せてIaC・CI/CD・監視の対応が求められる
SaaS Managerを導入することで、運用負荷を軽減しつつ、テナントのスケールアウトに対応できるような大きなメリットを得られます。使いどころを見極めながら、積極的に導入していきましょう！
