週6Route 53 / CloudFront

2026-09-08(火)Route 53, CloudFront

この記事の目次
  1. この範囲の全体像
  2. 重要キーワード・サービス一覧
  3. 試験で問われる比較ポイント
  4. ひっかけ注意ポイント
  5. 一問一答セルフテスト

1. 【この範囲の全体像】

本範囲は、DNSサービスである Amazon Route 53 と、コンテンツ配信ネットワーク(CDN)である Amazon CloudFront が緊密に連携する「グローバル統合ネットワーク設計」を学ぶ、SAA-C03試験の超頻出エリアです [p.160, p.164]。

単なる名前解決を超えて、Zone Apex(裸のドメイン)からCloudFrontへの安全かつ無料なルーティングを実現する Aliasレコードの統合 [p.165]、HTTPS化に不可欠な ACM証明書の配置リージョン制約 [p.204]、そして世界中からのアクセスを最も効率よく処理する 高度なトラフィック配信・DR(災害復旧)設計 の実装能力が問われます。

丸暗記ではなく、「どのサービスを、どのリージョンで、どのように組み合わせるのが最適か」という機能境界とベストプラクティスをロジカルに理解することが合格への絶対条件です [p.6]。


2. 【重要キーワード・サービス一覧】

キーワード 説明
Alias(エイリアス)レコード(CloudFront連携) [p.165] Route 53独自の拡張仕様 [p.165]。DNSの標準仕様(RFC)制限をバイパスし、Zone Apex(例: example.com)に対してCloudFrontディストリビューション(xxxx.cloudfront.net)を直接安全にアタッチでき、かつ名前解決のDNSクエリ料金が 「 完全無料 」 となる超重要レコード [p.165]。
代替ドメイン名(Alternate Domain Names / CNAME) [p.161, p.165] CloudFrontでデフォルトのドメインの代わりに、独自のカスタムドメイン(例: www.example.com)を使用して配信を行うために、CloudFront側とRoute 53レコード側の双方で一致させる必要がある登録ドメイン設定 [p.161, p.165]。
ACM(AWS Certificate Manager)証明書のリージョン配置境界 [p.204] CloudFrontにSSL/TLS証明書を適用してHTTPS通信を強制する場合、ACM証明書は必ず 「 米国東部(バージニア北部)リージョン(us-east-1) 」 で作成・保管されていなければならないという極めて厳格な仕様ルール [p.204]。
プライベートホストゾーン (Private Hosted Zone) [p.165] 指定した1つ以上のVPC内部だけで有効なDNS名前解決を提供するホストゾーン [p.165]。社内システムやVPC内部のサーバー間(例:db.internal)の名前解決情報を、パブリックインターネットに一切晒すことなく安全に完結させたい場合に必須となる設計 [p.165]。
Route 53 ヘルスチェック(計算機式ヘルスチェック) [p.167] パブリックリソースの死活監視だけでなく、他の複数のヘルスチェック(例:サーバーAのヘルスと、データベースのヘルス双方)の成否を論理的(AND/OR)に統合し、高度なDR(自動フェイルオーバー)を判断するための機能 [p.167]。

3. 【試験で問われる比較ポイント】

① グローバルパフォーマンス向上の使い分け:CloudFront vs Route 53 レイテンシールーティング [p.160, p.166]

「エンドユーザーの体感速度を高める」という目的は共通していますが、アプローチと機能境界が全く異なります。

比較項目 Amazon CloudFront (CDN) [p.160] Route 53 レイテンシールーティング [p.166]
主な機能特性 世界各地の「エッジロケーション」で静的・動的アセットをキャッシュして超高速配信する [p.160]。 ネットワーク遅延(レイテンシー)が最も少ない 「リージョン」のIPアドレスをDNS回答として返却する [p.166]。
キャッシュ機能 あり。オリジンの負荷を激減させる [p.160]。 なし。トラフィックのルーティング先を決定するのみ [p.166]。
主な用途・ターゲット 画像、動画、HTML、CSS、JS、およびAPIリクエスト全体の高速化 [p.160]。 マルチリージョンに冗長展開されたWebサーバー(ALB)へのアクセス最適配分 [p.166]。
決定的な選定シグナル 🎯 「 WebサーバーやS3の負荷を下げつつ、静的ファイルのグローバル読み込み遅延を極小化したい 」 [p.111, p.160] 🎯 「 東京とバージニアの双方で稼働するバックエンドシステム(ALB)のうち、ユーザーにとって最もネットワーク応答が速いリージョンへ通信を振り分けたい(キャッシュ不要) 」 [p.166]。

② 高可用・DR(災害復旧)のトラフィック設計:アクティブ - アクティブ vs アクティブ - パッシブ [p.165, p.166, p.167]

システムの許容ダウンタイム(RTO)と予算に応じて、Route 53を用いたDRアプローチを切り分けます [p.165, p.167]。

設計モデル アクティブ - アクティブ (Active - Active) [p.166] アクティブ - パッシブ (Active - Passive) [p.165]
トラフィック挙動 複数のリージョン全てに、平常時から同時にトラフィックを分散・処理させる [p.166]。 平常時はプライマリ(本番環境)のみに100%接続させ、障害時のみ予備環境へ切り替える [p.165]。
使用するルーティングポリシー 加重(Weighted)[p.166]、レイテンシー [p.166]、または位置情報 [p.166]。 フェイルオーバールーティングポリシー(Primary / Secondaryの2択構成) [p.165]。
ヘルスチェックの役割 異常が発生したリージョンのレコードを自動で除外し、正常な他方へDNS解決を継続させる [p.167] プライマリのダウンを検知した瞬間、セカンダリ(S3でホストしたSorryページ等)へ自動迂回させる [p.165, p.167]。
決定的な選定シグナル 🎯 「 片方のリージョンが大規模被災しても、ダウンタイムをほぼゼロに抑えて世界中からのサービス提供を止めずに並行処理させたい(高可用最優先) 」 [p.167, p.291] 🎯 「 インフラコストを最小限に抑えつつ、本番環境の全停止(被災)を検知した際、手動介入なしで自動的に静的Sorryページ(S3)へ安全に切り替えたい 」 [p.108, p.165]。

4. 【ひっかけ注意ポイント】

  • ひっかけ①:CloudFront用のACM証明書を、自社がメインで使う「東京リージョン」で発行してしまう罠 [p.161, p.204]

    • 罠: 「東京リージョン(ap-northeast-1)に構築したアプリケーション(ALB/EC2)の前段に、グローバル高速化のためCloudFrontディストリビューションをデプロイした。独自ドメインでHTTPS暗号化を行うため、東京リージョン(ap-northeast-1)のACMでSSL/TLS証明書をリクエストして取得し、CloudFrontの設定画面で適用しようとしたが、証明書が選択肢に一覧表示されず適用できなかった。」
    • なぜ間違いか: CloudFrontはグローバルに配信されるサービスですが、仕様上、カスタムSSL/TLS証明書をCloudFrontに紐づけるためには、証明書が「米国東部(バージニア北部)リージョン(us-east-1)」のACMで作成・保管されていなければならない という強固なルールがあります [p.161, p.204]。
    • 正しい解決策: バックエンドのサーバーが東京リージョンで動作していても、CloudFrontで独自ドメインHTTPS通信を行うためのACM証明書だけは、必ず バージニア北部リージョン(us-east-1) で作成・取得してください [p.161, p.204]。
  • ひっかけ②:VPC内部のプライベートな名前解決に、安易に「パブリックホストゾーン」を構成してしまう情報暴露の罠 [p.165]

    • 罠: 「本番VPC内のWebサーバーから、同じVPC内の非公開データベース(RDS)へ接続するために、Route 53で db.internal というレコードを定義したい。手順を簡略化するため、標準のパブリックホストゾーンを作成してレコードを登録した。データベース自体はプライベートIPアドレスであり、セキュリティグループでVPC内からのみアクセス許可しているため、この名前解決設定はセキュアであるとした。」
    • なぜ間違いか: パブリックホストゾーンに登録されたドメイン情報は、インターネット上の全世界から容易にDNSクエリを投げてルックアップ(名前解決)することが可能です。たとえ返ってくる解決先が「10.0.1.5」のようなプライベートIPであっても、「自社の社内システムがどのようなドメイン名とIP構成で動いているか」という内部機密情報が完全に世界へ暴露されるため、偵察攻撃の足がかりとなるセキュリティ上の致命的な欠陥(非推奨) となります。
    • 正しい解決策: VPC内部や社内組織でのみ使用するドメイン解決は、必ず 「 プライベートホストゾーン(Private Hosted Zone) 」 としてRoute 53に作成し、対象のVPCを明示的にアタッチして、名前解決の問い合わせ自体をVPCの境界内(閉域網内)に完全遮断するよう構成してください [p.165]。

5. 【一問一答セルフテスト】

選択肢を選ぶと、その場で正誤と解説が表示されます。