ある企業が AWS 上で大規模な B2B SaaS アプリケーションを構築しており、顧客企業（テナント）ごとにカスタムドメイン（例: tenant-a.example.com、tenant-b.example.com）でアクセスできるようにしたいと考えています。各テナントのドメインは顧客が管理する独自ドメインで、HTTPS 接続が必須です。SSL 証明書の管理と更新を自動化し、テナント数が増えても手動作業なしに対応できるアーキテクチャを設計したいと考えています。最も適切な設計はどれですか？
- A. テナントのカスタムドメインを受け付けるリバースプロキシ（nginx）を EC2 クラスターに構築し、AWS Certificate Manager Private CA でプライベート証明書を発行する
- B. 各テナントごとに独立した EC2 インスタンスを起動し、Let's Encrypt で証明書を取得して nginx で SSL 終端を行う
- C. 各テナントのドメインに対してワイルドカード証明書（*.example.com）を購入し、ALB に登録する
- D. Amazon CloudFront の Alternate Domain Names（CNAME）機能と AWS Certificate Manager（ACM）のカスタムドメイン証明書を使用する。各テナントのドメインを CloudFront ディストリビューションの CNAME に追加し、ACM で各テナントドメインの証明書を DNS 検証で自動発行・自動更新する。API Gateway または ALB をオリジンとして設定する
解答と解説を見る
正解: D
ACM は DNS 検証を使った証明書の自動発行と自動更新を提供します。CloudFront の Alternate Domain Names に各テナントのドメインを追加し、ACM の証明書を関連付けることで、テナントごとのカスタム HTTPS ドメインが実現できます。テナントが増えても API 経由で自動的にドメインと証明書を追加できます。ACM の証明書は無料で 90 日ごとに自動更新されます。 C: ワイルドカード証明書はサブドメイン（*.example.com）には有効ですが、顧客の独自ドメイン（tenant-a.customdomain.com）には使用できません。 B: テナントごとの EC2 インスタンスは管理が煩雑でコストが高く、テナント数に比例してインフラが増大します。スケーラビリティに欠けます。 A: AWS Certificate Manager Private CA のプライベート証明書は内部通信用であり、パブリックの HTTPS 接続（インターネットからのアクセス）には使用できません。ブラウザは信頼できないプライベート CA の証明書に警告を表示します。
📚 関連サービスの解説: Amazon CloudFront ・ Amazon API Gateway