1. CloudFrontのカスタムドメイン設定と証明書活用の全体像
    1. なぜカスタムドメインとSSL証明書が重要なのか
    2. CloudFrontにおける証明書活用の基本ルール
    3. 最新TLSプロトコル強制によるセキュリティレベルの向上
  2. CloudFrontでのカスタムドメイン、SSL証明書導入ステップ
    1. ステップ1: AWS Certificate Manager (ACM) で証明書を発行する
    2. ステップ2: CloudFrontディストリビューションにカスタムドメインを設定する
    3. ステップ3: DNS設定を更新しCloudFrontへトラフィックを誘導する
  3. サブドメイン振り分けとカスタムエラーページの具体的な設定例
    1. 複数のサブドメインをCloudFrontで管理する方法
    2. ブランドに合わせたカスタムエラーページを設定する手順
    3. カスタムエラーページのコンテンツ要件とベストプラクティス
  4. CloudFront設定で陥りやすいトラブルと対策
    1. 証明書のリージョン不一致と502エラーの解決策
    2. TLSプロトコル設定ミスとセキュリティリスク
    3. IaCツールと手動設定の競合問題
  5. 【ケース】証明書更新忘れによるサービス停止と復旧からの学び
    1. 架空のケース：証明書期限切れによるサービス影響
    2. 迅速な復旧と再発防止のための対応策
    3. 継続的なセキュリティ運用とモニタリングの重要性
  6. まとめ
  7. よくある質問
    1. Q: CloudFrontでカスタムドメインを設定するメリットは？
    2. Q: CloudFrontのSSL証明書はどのリージョンで発行すべきですか？
    3. Q: サブドメインごとに異なるコンテンツを振り分ける方法は？
    4. Q: カスタムエラーページを設定する際の注意点は？
    5. Q: CloudFrontのSSL証明書更新は自動でできますか？

CloudFrontのカスタムドメイン設定と証明書活用の全体像

なぜカスタムドメインとSSL証明書が重要なのか

現代のウェブサイト運営において、カスタムドメインとSSL証明書（HTTPS）の導入は、もはや選択肢ではなく必須の要件となっています。まず、HTTPSによる暗号化通信は、ユーザーとサーバー間のデータ通信を保護し、情報漏洩のリスクを大幅に低減します。これにより、ユーザーは安心してサイトを利用でき、企業は信頼性の高いブランドイメージを構築できます。Googleなどの検索エンジンもHTTPS対応サイトを優遇するため、SEO（検索エンジン最適化）の観点からもメリットがあります。暗号化されていないサイトはブラウザで警告が表示されることもあり、ユーザー離れの原因にもなりかねません。

さらに、セキュリティ対策の実施状況を示すデータがあります。総務省の調査（令和7年通信利用動向調査報告書）によると、常用雇用者規模100人以上の企業のうち、98.3%がインターネット利用時のセキュリティ対策を実施している一方で、過去1年間に情報通信ネットワーク利用に関連してセキュリティ被害を受けた企業は48.1%に上ります。これらの数字は、対策の重要性と、それでもなお脅威が存在する現状を浮き彫りにしており、CloudFrontのようなCDN（コンテンツデリバリーネットワーク）を利用した高度なセキュリティ設定が求められていることを示唆しています。

CloudFrontにおける証明書活用の基本ルール

CloudFrontでカスタムドメインを利用する際、SSL/TLS証明書はAWS Certificate Manager (ACM) を通じて発行・管理するのが一般的です。ACMは、無料で証明書を発行し、自動更新してくれるため、運用負荷を軽減できます。しかし、ここで一つ重要な制約があります。CloudFrontに適用するACM証明書は、必ず「米国東部（バージニア北部/us-east-1）リージョン」で発行する必要があります。これはCloudFrontがグローバルサービスであり、そのインフラストラクチャがこのリージョンに依存しているためです。他のリージョンで発行された証明書はCloudFrontでは利用できません。この点を誤ると、ディストリビューションにカスタムドメインを関連付けられず、設定が進まなくなるため注意が必要です。

証明書発行後は、CloudFrontディストリビューションの「Alternate Domain Names (CNAMEs)」にカスタムドメインを追加し、先ほどACMで発行した証明書を選択するだけで、HTTPSでの配信が可能になります。この一連の流れを正確に実行することが、安全かつ効率的なコンテンツ配信の第一歩となります。証明書の有効期間管理や更新プロセスもACMが自動で行ってくれますが、設定時のリージョン選択は手動で正しく行う必要があります。

最新TLSプロトコル強制によるセキュリティレベルの向上

SSL/TLSプロトコルは、インターネット通信の暗号化に用いられる技術ですが、そのバージョンによってセキュリティレベルが大きく異なります。特にTLS 1.0や1.1は、既に複数の脆弱性が発見されており、現在では非推奨とされています。古いプロトコルを許可したままにしておくと、中間者攻撃や情報漏洩のリスクが高まり、セキュリティ監査で指摘される可能性も高まります。そのため、CloudFrontではセキュリティポリシーを設定することで、最新かつ安全なTLSプロトコルのみを強制することが推奨されます。

具体的には、CloudFrontディストリビューションの「セキュリティポリシー」設定において、最低限TLS 1.2以上を要求するオプション（例: `TLSv1.2_2021` など）を選択するようにしてください。これにより、TLS 1.0や1.1を使用する古いクライアントからのアクセスは制限される可能性がありますが、現代のセキュリティ基準を満たし、より強固な通信環境を構築できます。ウェブサイトやアプリケーションの利用者が主に最新のブラウザを利用している場合、この設定はセキュリティとユーザビリティの両面でメリットをもたらします。

出典：令和7年通信利用動向調査報告書（企業編）（総務省 / 2026年6月15日公表）
出典：CloudFront で SSL/TLS 証明書を使用するための要件（AWS Documentation / 閲覧時点 2026年6月24日）

重要ポイント
CloudFrontでカスタムドメインのSSL化を行う際、ACM証明書の発行リージョンは必ず「米国東部（バージニア北部/us-east-1）」を選択してください。これ以外のリージョンで発行された証明書は、CloudFrontでは利用できません。この一点がカスタムドメイン設定成功の鍵となります。

CloudFrontでのカスタムドメイン、SSL証明書導入ステップ

ステップ1: AWS Certificate Manager (ACM) で証明書を発行する

CloudFrontでカスタムドメインを利用するための最初のステップは、AWS Certificate Manager (ACM) でSSL/TLS証明書を発行することです。まずAWSコンソールにログインし、ACMサービスにアクセスします。「証明書のリクエスト」を選択し、「パブリック証明書のリクエスト」に進んでください。ここで最も重要なのが、必ず「米国東部（バージニア北部/us-east-1）リージョン」を選択して証明書をリクエストすることです。この選択を誤ると、後続のCloudFront設定で証明書が利用できなくなります。

次に、証明書を適用したいカスタムドメイン名（例: `www.example.com` や `example.com`）を入力します。サブドメインもまとめて保護したい場合は、ワイルドカード証明書（例: `*.example.com`）をリクエストすることも可能です。ドメイン検証方法として、「DNS検証」または「Eメール検証」を選択します。DNS検証が推奨されており、ACMが提示するCNAMEレコードをRoute 53などのDNSサービスに追加することで、自動的に検証が完了します。検証が成功すると、証明書の状態が「発行済み」となり、CloudFrontで使用できる状態になります。

ステップ2: CloudFrontディストリビューションにカスタムドメインを設定する

ACMで証明書が発行されたら、次にCloudFrontディストリビューションにカスタムドメインとSSL証明書を関連付けます。AWSコンソールでCloudFrontサービスに移動し、設定したいディストリビューションを選択して「編集」画面を開きます。一般設定セクションにある「代替ドメイン名 (CNAMEs)」の欄に、先ほどACMで証明書を発行したカスタムドメイン名（例: `www.example.com`）を入力します。複数のサブドメインを扱う場合は、カンマ区切りで追加できます。

次に、「カスタム SSL 証明書」のドロップダウンメニューから、ACMで発行した「米国東部（バージニア北部/us-east-1）リージョン」の証明書を選択します。もしここで証明書が表示されない場合は、リージョン選択が間違っているか、証明書がまだ「発行済み」になっていない可能性があります。適切な証明書を選択後、必要に応じて「セキュリティポリシー」（最低TLS 1.2以上を推奨）や「サポートされるHTTPバージョン」などを設定し、変更を保存します。この設定がCloudFrontの各エッジロケーションに伝播するまでには、数分から数十分かかる場合があります。

ステップ3: DNS設定を更新しCloudFrontへトラフィックを誘導する

CloudFrontディストリビューションにカスタムドメインと証明書が設定できたら、最後にDNSプロバイダの設定を更新し、カスタムドメインへのアクセスをCloudFrontに誘導します。Route 53を利用している場合は、ホストゾーンに移動し、カスタムドメイン（例: `www.example.com`）に対して「エイリアスレコード」または「CNAMEレコード」を作成します。エイリアスレコードを使用する場合、エイリアスターゲットとしてCloudFrontディストリビューションのドメイン名（例: `dxxxxxxxxxxxx.cloudfront.net`）を選択します。

Route 53以外のDNSプロバイダを利用している場合は、CNAMEレコードとしてカスタムドメインをCloudFrontのドメイン名に向ける設定を行います。このDNSレコードの変更がインターネット全体に伝播するまでには、数分から最大で48時間程度かかることがあります（DNSキャッシュのTTL設定による）。伝播が完了すると、カスタムドメインでウェブサイトにアクセスした際に、CloudFrontのエッジロケーションを経由してコンテンツが安全に配信されるようになります。設定後は、複数のネットワーク環境からカスタムドメインにアクセスし、HTTPS接続が正しく確立されているか、また意図したコンテンツが表示されるかを確認することが重要です。

出典：AWS Certificate Manager とは（AWS Documentation / 閲覧時点 2026年6月24日）

チェックリスト

  • ACMで証明書を「米国東部（バージニア北部/us-east-1）」で発行しましたか？

  • カスタムドメイン名が証明書に含まれ、「発行済み」の状態になっていますか？

  • CloudFrontディストリビューションのCNAMEsにカスタムドメインを追加しましたか？

  • カスタムSSL証明書として、ACMで発行した証明書を選択しましたか？

  • DNSプロバイダで、カスタムドメインをCloudFrontのドメイン名に紐付ける設定をしましたか？

  • 設定後、ブラウザでカスタムドメインにアクセスし、HTTPS接続とコンテンツ表示を確認しましたか？

サブドメイン振り分けとカスタムエラーページの具体的な設定例

複数のサブドメインをCloudFrontで管理する方法

CloudFrontでは、複数のサブドメインを効率的に管理する方法がいくつかあります。最も一般的なのは、単一のCloudFrontディストリビューションで複数のサブドメインを処理する方法です。例えば、`www.example.com` と `blog.example.com` を同じディストリビューションで配信したい場合、ACMで `example.com` と `*.example.com` のワイルドカード証明書を発行し、その証明書をCloudFrontディストリビューションに適用します。

次に、CloudFrontディストリビューションの設定で「代替ドメイン名 (CNAMEs)」に `www.example.com` と `blog.example.com` の両方を追加します。その後、DNSプロバイダで各サブドメイン（`www` と `blog`）のCNAMEレコードをCloudFrontディストリビューションのドメイン名に誘導する設定を行えば、単一のCloudFrontエッジからこれらのサブドメインが配信されます。これにより、管理が簡素化され、コストも抑制できる場合があります。ただし、各サブドメインで異なるオリジンやキャッシュ動作が必要な場合は、行動（Behaviors）の設定でパスパターンに基づいてルーティングを制御するか、サブドメインごとに別のディストリビューションを立てることも検討が必要です。

ブランドに合わせたカスタムエラーページを設定する手順

ウェブサイトにアクセスした際に発生する403（アクセス拒否）や404（見つからない）などのエラーは、ユーザー体験を損なうだけでなく、ブランドイメージの低下にも繋がりかねません。CloudFrontでは、これらのエラー時にデフォルトのエラー画面ではなく、自社ブランドに合わせたカスタムエラーページを表示させることができます。この設定は、CloudFrontディストリビューションの「エラーページ」タブで行います。

設定手順としては、「カスタムエラー応答を作成」をクリックし、対象となるHTTPエラーコード（例: 403, 404）を選択します。次に、そのエラーコードが発生した際に表示させたいカスタムエラーページのパス（例: `/error-404.html`）を指定します。このカスタムエラーページは、S3バケットなどのオリジンに事前にアップロードしておく必要があります。また、「HTTP レスポンスコード」で、CloudFrontが最終的にクライアントに返すHTTPステータスコードを「200 OK」などに変更することも可能です。これにより、S3が403を返しても、CloudFrontがカスタムエラーページを200で表示し、ユーザーには正常にコンテンツが配信されたかのように見せることができます。

カスタムエラーページのコンテンツ要件とベストプラクティス

カスタムエラーページを設定する際は、そのコンテンツにも配慮が必要です。単にエラーが発生したことを伝えるだけでなく、ユーザーが次に取るべき行動を促す情報を提供することが、ユーザーエクスペリエンスの向上につながります。具体的には、以下の要素を含めることがベストプラクティスとされます。

1. 分かりやすいメッセージ: エラーが発生したことを明確に伝え、ユーザーが混乱しないようにします。
2. ブランドロゴとデザイン: ウェブサイトの他のページと一貫したデザインを採用し、ブランドイメージを維持します。
3. ナビゲーションオプション: ホームページへのリンク、サイトマップ、検索ボックスなどを提供し、ユーザーが他のページに移動できるようにします。
4. 連絡先情報: 問題が解決しない場合に備え、サポートへの連絡先を記載します。
これらのカスタムエラーページは、通常のコンテンツと同様にCloudFrontのエッジキャッシュに保存されるため、エラー時でも高速に表示されます。これにより、ユーザーはエラー発生時でもスムーズに情報を得られ、サイトの信頼性を損なうことなく対応できるでしょう。

出典：エラーレスポンスの動作を設定する（AWS Documentation / 閲覧時点 2026年6月24日）

CloudFront設定で陥りやすいトラブルと対策

証明書のリージョン不一致と502エラーの解決策

CloudFrontでカスタムドメインを設定する際に最も頻繁に発生するトラブルの一つが、ACM証明書の発行リージョン間違いです。CloudFrontはグローバルサービスであるため、ACM証明書は必ず「米国東部（バージニア北部/us-east-1）リージョン」で発行されている必要があります。もし他のリージョンで証明書を発行してしまった場合、CloudFrontディストリビューションの設定画面でその証明書が選択肢に表示されず、設定を進めることができません。この場合は、一度発行した証明書を削除し、正しいリージョンで再発行する必要があります。

また、カスタムドメインを設定した後、ウェブサイトにアクセスすると「502 Bad Gateway」エラーが表示されるケースがあります。この問題の主な原因の一つは、SSL証明書のSAN (Subject Alternative Name) に、CloudFrontで設定したカスタムドメインが含まれていないことです。例えば、`www.example.com` をカスタムドメインとして設定したにもかかわらず、証明書が `example.com` しかカバーしていない場合などに発生します。この場合も、ACMで証明書を再発行し、SANにすべての必要なドメイン名（`www.example.com` と `example.com`、または `*.example.com` など）が含まれていることを確認した上で、CloudFrontに再適用することで解決できます。

TLSプロトコル設定ミスとセキュリティリスク

CloudFrontディストリビューションのセキュリティポリシー設定を適切に行わないと、セキュリティ上のリスクが発生したり、セキュリティ診断で脆弱性を指摘されたりする可能性があります。特に、TLS 1.0や1.1といった古いプロトコルを許可したままにしておくことは推奨されません。これらのプロトコルは既知の脆弱性を持っており、安全な通信が確保できないためです。企業における情報通信ネットワーク利用に関連したセキュリティ被害の割合が高い現状（約48.1%の企業が過去1年間に被害経験、総務省調査）を鑑みても、最新のプロトコルへの対応は喫緊の課題です。

この問題への対策としては、CloudFrontディストリビューションの「セキュリティポリシー」設定において、必ず「TLSv1.2_2021」やそれ以降の、TLS 1.2以上を強制するポリシーを選択することです。これにより、古いTLSバージョンを使用するクライアントからのアクセスは拒否されますが、現代のセキュリティ要件に準拠した強固な通信環境を構築できます。設定変更後は、主要なブラウザでアクセスし、HTTPS接続が問題なく確立され、セキュリティ警告が表示されないことを確認してください。

IaCツールと手動設定の競合問題

AWSリソースをInfrastructure as Code (IaC) ツール（例: AWS CDK, Terraform）で管理している環境では、手動での設定変更が予期せぬトラブルを引き起こすことがあります。例えば、CloudFrontディストリビューションの設定（特にカスタムSSL証明書やCNAMEなど）をAWSコンソールで手動で変更した後、IaCツールで再度デプロイを行うと、IaCのコードに記述された設定が優先され、手動で行った変更が上書きされてしまう可能性があります。これにより、一時的に有効にしたはずの証明書が外れてしまい、サービス停止につながるケースも少なくありません。

この問題を防ぐための最も効果的な対策は、IaCで管理されているリソースに対しては、原則としてIaCツールのみで変更を行うことです。緊急でコンソールから手動変更が必要になった場合でも、その変更内容を速やかにIaCコードに反映させ、バージョン管理下に置くプロセスを確立することが重要です。これにより、設定の一貫性が保たれ、意図しない変更の上書きやコンフィグレーションドリフト（設定のずれ）を防ぎ、安定した運用が可能になります。変更管理のプロセスを明確にし、チーム内で共有することも、トラブル防止に繋がります。

出典：Amazon CloudFront のインフラストラクチャセキュリティ（AWS Documentation / 閲覧時点 2026年6月24日）

重要ポイント
502エラーやSSL証明書関連のトラブルに直面した場合、まずはACM証明書が「米国東部（バージニア北部/us-east-1）」で発行されているか、そしてその証明書のSAN (Subject Alternative Name) にCloudFrontで設定したカスタムドメインが全て含まれているかを徹底的に確認してください。これらが不足していると、証明書が有効でも正常な通信は確立されません。

【ケース】証明書更新忘れによるサービス停止と復旧からの学び

架空のケース：証明書期限切れによるサービス影響

ここでは、架空のオンラインストア「SampleMarket.com」を運営する企業が直面した、CloudFrontのSSL証明書更新忘れによるサービス停止のケースを紹介します。SampleMarket.comはCloudFrontとACMを利用していましたが、ある日突然、顧客から「サイトにアクセスできない」「セキュリティ警告が出る」という問い合わせが殺到しました。調査の結果、CloudFrontに適用していたSSL証明書が期限切れになっていることが判明。ブラウザでは「このサイトは安全ではありません」という警告が表示され、多くのユーザーがサイトを離脱。結果として、一時的にサイトへのアクセスが途絶え、売上機会の損失やブランドイメージの低下という深刻な影響を受けました。

ACMの証明書は通常自動更新されますが、何らかの理由（例えば、DNS検証レコードの削除、Eメール検証の失敗など）で更新プロセスが中断されることがあります。このケースでは、DNS検証用のCNAMEレコードが意図せず削除されており、ACMが証明書を更新できない状態になっていました。サービス停止期間中、顧客の信頼を失いかねない状況に陥り、担当者は緊急対応に追われることになりました。

迅速な復旧と再発防止のための対応策

SampleMarket.comのチームは、まず迅速なサービス復旧を目指しました。ACMコンソールで証明書のステータスを確認し、期限切れの原因（DNS検証レコードの欠落）を特定。直ちに正しいCNAMEレコードをDNSプロバイダに追加し、ACMに証明書の再発行（または更新）をトリ依頼しました。証明書が発行された後、CloudFrontディストリビューションの設定を再度編集し、新しい証明書を適用することで、サイトは数時間以内にHTTPS通信を再開できました。

しかし、このような事態は二度と起こしたくないと、チームは再発防止策を講じました。まず、AWS CloudWatch Alarmsを設定し、ACM証明書の有効期限が近づいた際に、特定の担当者にEメールやSlackで通知が届くようにしました。また、AWS Health Dashboardを定期的に確認する習慣を確立し、AWSサービスに関する潜在的な問題を早期に把握できるようにしました。さらに、証明書管理に関する社内プロセスを見直し、担当者を明確化するとともに、定期的な棚卸しと確認を行うチェックリストを導入しました。

継続的なセキュリティ運用とモニタリングの重要性

このケースから得られた最も重要な教訓は、SSL証明書の管理を含め、継続的なセキュリティ運用とモニタリングがいかに重要であるかという点です。証明書の自動更新機能に頼りきるだけでなく、それが正常に機能しているかを定期的に確認する仕組みが不可欠です。具体的には、以下のような対策が挙げられます。

1. 定期的な証明書状況の確認: AWSコンソールやAWS CLIを使って、ACM証明書の有効期限とステータスを月に一度など定期的にチェックする。
2. モニタリングとアラート設定: CloudWatchを利用して証明書の有効期限切れイベントを検知し、アラート通知を行う。
3. セキュリティポリシーの定期見直し: TLSプロトコルの最新情報や脆弱性情報を常に収集し、CloudFrontのセキュリティポリシーを最新の状態に保つ。
4. IaCの活用: 証明書のリクエストからCloudFrontへの適用までを一貫してIaCで管理し、手動設定によるヒューマンエラーを防ぐ。
これらの対策を複合的に実施することで、SampleMarket.comは将来的なサービス停止リスクを大幅に低減し、顧客に安全で安定したサービスを提供できるようになりました。セキュリティは一度設定したら終わりではなく、常に変化に対応し続ける動的なプロセスであることを再認識させられる事例です。