顧客ごとの独自ドメインでサイトを出すSaaSでは、ドメインが増えるたびに、配信の設定と証明書が1組ずつ増える。 設定はどれも同じものの写しで、証明書はそれぞれが更新の期限を持つ。 数が増えるほど、同じ作業の繰り返しと、更新の漏れの心配が増えていく。
CloudFrontのマルチテナント配信は、配信の設定を1つの型にまとめ、ドメインごとに違うところだけをテナントとして持たせる仕組みである。 証明書も、テナントを作るときにCloudFrontが取得し、その後の更新まで引き受ける。
本稿では、この仕組みで何が1つにまとまるのかを整理し、 テナントを1つ増やす、先に準備しておいて持ち主の都合で公開する、既存のサイトから止めずに移す、の3つの使い方を示す。
1. 通常の配信との違い
通常の配信は、1つのサイトの設定をすべて持つ。オリジン、キャッシュの振る舞い、セキュリティの設定、ドメイン、証明書である。 同じ設定で別のサイトを出すには、配信をもう1つ作る。
マルチテナント配信は、それ自体には利用者が到達しない設定の型である。 型から作るテナントが、ドメインを持つ「表玄関」になる。 テナントは型の設定を引き継ぎ、ドメインごとに違うところだけを持つ。
どこで何を決めるかは、次の3か所に分かれる。
AWSは、サイトが1つだけなら通常の配信を勧めている。 同じ設定で多数のドメインを出すときに、この形が効く。
採用の前に、マルチテナント配信では使えない機能を確かめておく。 たとえば継続的デプロイ（CloudFrontの継続的デプロイで、AIに公開前の最終確認をさせるで使っている仕組み）、OAI（OACを使う）、レガシーの標準ログ、最小・既定・最大のTTLの設定は使えない。 WAFは v2 の web ACL だけが使える。
2. ドメインを割り当てるだけでSaaSになる構成
ドメインの持ち主は、自分のドメインのCNAMEを、接続グループの振り分け先へ向ける。 既定の接続グループでは、振り分け先はどのテナントでも同じ名前である。 持ち主に伝える値が、顧客ごとに変わらない。
オリジンの側に、ドメインに応じて表示を変えるアプリケーションを1つ置けば、 新しい顧客を迎える作業はテナントを作ることだけになる。 オリジンにも、型にも、何も足さない。
そのためには、オリジンが「どのドメインの要求か」を知る必要がある。方法は3つある。
オリジンの種類には注意が要る。 API GatewayやLambdaの関数URLは、Hostヘッダーにオリジン自身のドメイン名が入っていることを前提にしており、利用者のHostヘッダーを渡すと動かなくなる。 これらをオリジンにする場合は、パラメータか関数で見分ける。
3. 配信と証明書が一体になっている
テナントを作るとき、または更新するときに、CloudFrontが管理する証明書を要求できる。 CloudFrontがACMからHTTP検証の証明書を取得し、テナントに使う。
更新が自動になる条件は、ドメインのDNSがCloudFrontを向いていることである。 その後の更新はCloudFrontが受け持つ。
最初の発行では、ACMの検証の要求に、どこで応えるかを選ぶ。
どちらを選んでも、取得する証明書は同じである。 違うのは、最初の検証に誰が応えるかだけで、2回目以降の更新はどちらもCloudFrontが行う。
テナントのドメインには状態がある。
証明書の要求が保留中の間、ドメインは inactive で、CloudFrontは検証のパスにしか応えない。
証明書を適用して active になると、すべての要求に応える。
active にしたドメインは inactive に戻せない。 別の配信やテナントへ移すときは、ドメインの付け替えの操作を使う。
4. 使い方① テナントを1つ増やす
新しい顧客が、まだ何も出していないドメインで使い始める場合である。 止めるものがないので、CloudFront方式を選ぶ。
- SaaS事業者がテナントを作る。指定するのはドメインと、証明書の要求（CloudFront方式）と、必要ならパラメータの値だけである。オリジンや振る舞いは型から引き継ぐ。
- 持ち主へ、CNAMEの向け先（振り分け先）を伝える。
- 持ち主がCNAMEを設定する。
- ACMの検証の要求にCloudFrontが応え、証明書が発行される。
- ドメインが有効になり、公開される。
DNSを向けてから発行されるまでの間、そのドメインはサイトとして応えない。 新しいドメインなので、その間に止まるものはない。
5. 使い方② 先に準備し、持ち主の都合で公開する
顧客のサイトを事前に作り込み、公開の時期は顧客に決めてもらいたい場合がある。 マルチテナント配信では、準備と公開を別の操作に分けられる。
準備の間は、テナントのWAFのweb ACLを上書きする。 IPSetで許可した送信元だけを通すweb ACLを割り当て、関係者だけが見られる状態で中身を仕上げる。 型のweb ACLや、ほかのテナントには影響しない。
証明書の検証も先に済ませておく。 ドメインが今向いている先で検証に応えられるなら、自前の方式でDNSを向ける前に発行でき、テナントに適用しておける。
準備が済んだら、web ACLの上書きを外す。 この時点では、ドメインはまだCloudFrontを向いていないので、利用者から見えるものは何も変わらない。
公開の時期は、持ち主がCNAMEを切り替えた時点で決まる。 証明書は発行・適用済みなので、切り替えた瞬間から配信が始まり、SaaS事業者の側で待つ作業はない。
ドメインが今どこも向いておらず、検証に応えられない場合は、CloudFront方式になる。 この場合、発行はCNAMEを切り替えた後になり、公開は発行を待ってからになる。
6. 使い方③ 既存のサイトから止めずに移す
移行元のサーバーが、そのドメインの利用者に配信している場合である。 DNSを先にCloudFrontへ向けると、発行されるまでの間、サイトが応えなくなる。 自前の方式を選び、移行元のサーバーに検証の要求へ応えてもらう。
移行元が検証に応える方法は2つある。 トークンのファイルを移行元に置くか、検証のパスへの要求を、ACMの検証の場所へ301で転送するかである。 ドメインが多い場合は転送のほうが扱いやすい。
# 検証のパスへの要求だけを、ACM の検証の場所へ転送する（概念例）
|
location /.well-known/pki-validation/ {
|
return 301 https://validation.us-east-1.acm-validations.aws/<アカウントID>$request_uri;
|
} |
転送先に付けるパスには、デコードしていない元の要求のパス（nginx では $request_uri）を使う。
デコード済みの値（$uri）を使うと、改行をエンコードして含めた要求で、応答に任意のヘッダーを差し込まれる。
転送先は、テナントを作ったアカウントのIDと、検証のトークンで決まる。
当社の検証では、転送元のパスと転送先のパスの後半（/.well-known/pki-validation/ 以降）は同じだった。
そのため移行元の設定は、ドメインごとに、どのアカウントでテナントを作るかだけを持てばよい。
この設定はテナントを作る前に入れておけて、入れておいたドメインは、テナントを作った直後に発行された。
発行されたら、証明書をテナントに適用する。 その後、持ち主にCNAMEを切り替えてもらう。 切り替えるまでは移行元が配信を続け、切り替えた後はCloudFrontが配信する。 間に止まる時間はない。
切り替えた後の更新はCloudFrontが行う。移行元の転送には依存しない。
7. 運用で気をつけること
当社の検証（2026年10月）で確かめたことと、AWSの文書の記述から、運用に関わるものをまとめる。
同じドメインの証明書は、作り直しや重複によって、ACMに複数ありうる。 証明書はドメイン名で探さず、テナントを作った直後に取得できる証明書のARNを記録して追う。
8. まとめ
マルチテナント配信は、配信を増やす作業を、テナントを足す作業に置き換える。 証明書の取得と更新もその中に入るため、顧客が増えても、SaaS事業者が見る対象はほとんど増えない。 最初の検証にどこで応えるかを顧客のドメインの状況で選べば、新規の顧客も、既存のサイトからの移行も、同じ仕組みで迎えられる。