2026-09-10（木）Route 53, CloudFront

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

本範囲（第6章、p.159-174）は、グローバル規模のWebアプリケーションにおいて、ネットワークの「低遅延（低レイテンシー）」、「高可用性（耐障害性）」、および「セキュリティ」をエッジで一元的に最適化する配信ネットワークサービス群を扱います [p.159]。

DNS名前解決と高度なトラフィック制御を司る「Route 53」 [p.164]、静的コンテンツをエッジに一時保存して配信負荷を軽減する「CloudFront」 [p.160]、そして動的データやTCP/UDP通信をAWS専用閉域網を使って超高速化する「Global Accelerator」 [p.168]の機能境界を正確に見極め、最適なグローバルインフラを設計・構成する能力が問われます [p.170]。

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

キーワード	説明
Amazon CloudFront [p.160]	世界中に分散するエッジロケーションを利用し、HTMLや画像、動画などの静的コンテンツをキャッシュ配信することで、オリジナルサーバーの負荷を下げながら表示を高速化するCDN（コンテンツ配信）サービス。
Lambda@Edge [p.162]	CloudFrontに統合された機能。ユーザーに最も近いエッジロケーションで軽量なプログラムコードを実行し、リクエスト/レスポンスヘッダーの動的書き換えや簡易的なセキュリティ認証をミリ秒レベルで処理する仕組み。
Amazon Route 53 [p.164]	ドメイン管理機能と権威DNS機能を備えた可用性に極めて優れたDNSサービス。各種トラフィック制御やヘルスチェックと連動したフェイルオーバーをフルマネージドで提供する。
Alias（エイリアス）レコード [p.165]	Route 53独自の拡張レコード機能。DNSの規格上CNAMEをマッピングできない「Zone Apex（サブドメインなしのドメイン）」に対しても、ELBやCloudFront、S3などのAWSリソースドメインを直接指定して名前解決をマッピングできる。
DNSフェイルオーバー [p.167]	Route 53のヘルスチェック（稼働監視）と連動し、メインの接続先がクラッシュしたことを検知した際、自動的に名前解決の向き先を正常なバックアップ（Sorryサーバー）へ迂回させるセルフヒーリング設計。
AWS Global Accelerator [p.168]	ユーザーからパブリックインターネットを経由した接続経路を最小限に抑え、最寄りのエッジロケーションからAWS独自の超高速グローバル専用閉域網にトラフィックを乗せて、アプリ（ALB/EC2）まで低遅延でルーティングする最適化サービス。
エニーキャスト静的IPアドレス [p.169]	Global Acceleratorが接続用エンドポイントとして常時固定で提供する「2つの静的IPアドレス」。クライアントのDNSキャッシュ（TTL）によるDR切り替えのタイムラグを完全にバイパスし、即時フェイルオーバーを可能にする。

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

① エッジアクセラレーションサービス比較：CloudFront vs Global Accelerator [p.170]

「プロトコルレイヤー（対応規格）」と「キャッシュ機能の要否」を決定シグナルとして使い分けます [p.170]。

比較項目	Amazon CloudFront [p.170]	AWS Global Accelerator [p.170]
対応プロトコル	HTTP / HTTPS のみ（L7アプリケーション層） [p.170]。	TCP / UDP 全般（L4トランスポート層） [p.170]。
キャッシュ機能	あり。エッジロケーションにデータを一時保管し、自ら応答配信を行う [p.170]。	なし。データの一時保存はせず、パケットを最速ルートで右から左へ転送する [p.170]
提供するエンドポイント	専用ドメイン名（FQDN） [p.165]。	固定された「2つの静的IPアドレス」 [p.169]。
主な接続先（オリジン）	S3、ALB、EC2、カスタムWebサーバー [p.160, p.170]。	ALB、NLB、EC2、Elastic IPアドレス [p.169, p.170]。
試験での選択要件	・静的な画像・動画や動的なWeb APIの応答をエッジで高速化・キャッシュさせたい [p.160]。	・「オンラインゲームのUDPパケットや非HTTPプロトコルの遅延を極小化したい」 [p.170]。・「DNSのTTLキャッシュ影響を一切受けずに、複数リージョン間で即時に自動フェイルオーバーさせたい」 [p.169]。

② Zone Apexへの名前解決：CNAMEレコード vs Aliasレコード [p.165]

比較項目	CNAMEレコード [p.165]	Alias（エイリアス）レコード [p.165]
定義	ドメイン名を別のドメイン名（別名）にマップするDNSの標準仕様。	ドメイン名をAWSリソースドメインへ直接マッピングするRoute 53独自の仕様。
Zone Apexへの登録	不可能（仕様上、`example.com` に直接CNAMEは記述できない） [p.165]。	可能（`example.com` に直接ロードバランサーやS3を指定可能） [p.165]。
DNSクエリの利用料金	有料（名前解決クエリが発生するたびに費用が発生する）。	無料（AWSリソースをAliasレコードで名前解決するクエリは完全無料） [p.165]。
裏側のIPアドレス変更	宛先の動的IP変化には追従できるが、クライアントが複数回問い合わせるオーバーヘッドがある。	ALBやCloudFront等の裏側でIPアドレスが変動しても、AWS内部で完全に自動追従される [p.165]。

③ Route 53 主要ルーティングポリシーの機能特徴 [p.165-166]

ルーティングポリシー [p.165-166]	制御ロジックの概要	主な試験シナリオの選定シグナル
加重 (Weighted) [p.166]	指定した任意の比率（%）に基づいてトラフィックを複数のターゲットに分散解決させる [p.166]。	「新バージョンのテストリリース時に、全通信の10%だけを新サーバーに流して検証したい（ABテスト・カナリアリリース）」 [p.173]。
レイテンシー (Latency) [p.166]	ユーザーにとって、最もネットワーク往復遅延が少ない（最速応答する）AWSリージョンのサーバーへ自動転送する [p.166]。	「マルチリージョン構成において、ヨーロッパからのアクセスは最速応答するアイルランドリージョンへ自動誘導したい」 [p.166]。
位置情報 (Geolocation) [p.166]	ユーザーがアクセスしている物理的な地理的位置（国や大陸単位）に基づいてルーティング先を決定する [p.166]。	「地域の法令に適合したサーバーに接続させたい」、または「アクセス元（例：日本）に応じてサイト表示言語（日本語）を出し分けたい」 [p.166]。
複数値回答 (Multivalue Answer) [p.166]	最大8つの稼働している（正常な）IPアドレスをランダムに返却し、クライアントにアクセスさせる [p.166]。	「高価なELBを使わずに、簡易的なDNSヘルスチェック機能付きのロードバランシング（負荷分散）を行いたい」 [p.166]。
フェイルオーバー (Failover) [p.165]	アクティブ/スタンバイ構成。メイン系統の障害を検知したらバックアップ（Sorryサーバー）へ切り替える [p.165]。	「本番EC2のダウン時に、自動的にS3の静的ウェブサイトホスティング（Sorry画面）へトラフィックを自動迂回させたい」 [p.165, p.167]。

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

ひっかけ①：「ユーザーのクライアント（ドメイン名）から、Amazon S3バケットで独自に有効化された『S3静的ウェブサイトホスティング（例: http://www.example.com）』に直接アクセスさせたい。バケットの整理整頓のため、バケット名称を『my-corporate-s3-bucket』という任意のグローバルに一意な名称で構築マッピングした。」
- 真実: Route 53等のDNS名前解決を介したS3の直接アクセスは、ドメイン不一致エラーを招き完全に接続に失敗します [p.109, p.165]。
- 対策: CloudFrontを前段にデプロイしない状態で「S3の静的ウェブサイトホスティング機能にドメインをマップさせる」場合、バケット名は『公開したい独自ドメイン名（この場合 www.example.com）』と1文字も違わずに完全に一致している必要があるという極めて厳しい命名規則仕様があります [p.109]。
ひっかけ②：「リアルタイム性を最優先するグローバルオンラインゲームにおいて、通信相手（EC2）との間で大量かつ動的なTCP/UDPデータパケットを高スループット・低遅延でやり取りさせたい。このパフォーマンス向上を達成するため、ゲームサーバーの手前に『Amazon CloudFront』をデプロイし、配信キャッシュ設定を有効化した。」
- 真実: CloudFrontを経由した生TCP/UDPの通信は成立せず、システム全体が全く稼働しません [p.170, p.173]。
- 対策: Amazon CloudFrontは「HTTP / HTTPS（L7プロトコル）」のみに対応したWeb配信サービスです [p.170]。L4レベルでの非HTTPプロトコル（独自のTCPやUDP）データ伝送性能を引き上げる目的においては、エッジからAWSグローバル閉域網へデータを流し込んで転送する「 AWS Global Accelerator 」の構成が絶対的なアーキテクチャ上の正解マッピングとなります [p.170, p.173]。
ひっかけ③：「東京リージョンとシンガポールリージョンのそれぞれにApplication Load Balancer（ALB）を分散配置してマルチリージョン高可用システムを構築した。プライマリリージョン（東京）で大災害が発生した際、DNSの『フェイルオーバールーティングポリシー』のみを適用して、数秒レベルでの自動フェイルオーバーを完成させた。」
- 真実: Route 53によるDNSルーティングの切り替えは、クライアント端末や中継プロバイダーによる「DNSキャッシュ（TTLの浸透待ち）」の影響を強く受けるため、数秒レベルでの完全な迂回は物理的に不可能です [p.167, p.169]。
- 対策: 端末のDNS名前解決（DNSキャッシュ）の障壁を完全に無視した超高速フェイルオーバーを実現させるには、固定の「 2つのエニーキャスト静的IPアドレス」をエンドポイントに提供する「AWS Global Accelerator 」を適用します [p.169]。障害発生時、クライアントは同一固定IPにアクセスし続けたまま、Global Acceleratorの内部（AWSバックボーン内）において数秒以内に自動ルーティング先が健全なバックエンド（シンガポール）へスイッチされるため、瞬時の自動切り替え要件をクリアできます [p.169]。