2026-09-11（金）Route 53, CloudFront

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

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

名前解決と高度なトラフィック分散を司る「Route 53」 [p.164]、静的ファイルの配信負荷を劇的に下げる「CloudFront」 [p.160]、そして動的データやL4レベルのパケットをAWS専用網で超高速転送する「Global Accelerator」 [p.168]の機能境界を正確に見極め、最適なグローバルインフラを設計する能力が問われます [p.170]。

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

キーワード	説明
Amazon CloudFront [p.160]	世界中に分散するエッジロケーションを利用し、HTMLや画像、動画などの静的コンテンツをキャッシュしてエンドユーザーに最も近い場所から高速配信するCDNサービス [p.160]。
Lambda@Edge [p.162]	CloudFrontに統合されたサーバーレス機能。ユーザーに近いエッジロケーションで軽量なプログラムを実行し、リクエスト/レスポンスヘッダーの動的書き換えや簡易認証をミリ秒単位で処理する [p.162]。
Amazon Route 53 [p.164]	ドメイン管理機能と権威DNS機能を備えた高可用なDNSサービス [p.164]。ヘルスチェックと連動したフェイルオーバーや、位置情報・遅延に基づいたルーティングをサポートする [p.165-167]。
Alias（エイリアス）レコード [p.165]	Route 53独自の拡張DNS機能 [p.165]。標準のDNS仕様ではCNAMEを設定できない「Zone Apex（サブドメインのないドメイン）」に対しても、ELBやCloudFrontなどのAWSリソースのFQDNを直接マッピングできる [p.165]。
DNSフェイルオーバー [p.167]	Route 53のヘルスチェック（疎通監視）と連動し、プライマリのサーバー（EC2やALB）がダウンした際に、DNSの名前解決先を自動的にバックアップサーバー（S3のSorry画面など）へと切り替える仕組み [p.165, p.167]。
AWS Global Accelerator [p.168]	ユーザーからパブリックインターネットを経由する距離を最小化し、最寄りのエッジからAWS保有のグローバル専用ネットワーク（閉域網）にパケットを乗せて、最速ルートでバックエンド（ALB/NLB/EC2）へ届けるネットワーク最適化サービス [p.168, p.169]。
エニーキャスト静的IPアドレス [p.169]	Global Acceleratorがエントリーポイントとして常時固定で提供する「2つの静的IPアドレス」 [p.169]。クライアントによるDNSのキャッシュ（TTLの影響）を完全にバイパスし、即時フェイルオーバーを可能にする [p.169]。

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

① エッジネットワーク：CloudFront vs Global Accelerator [p.170]

「プロトコルレイヤー」と「キャッシュ機能の有無」が、設計判断における最大の境界線です [p.170]。

比較項目	Amazon CloudFront [p.170]	AWS Global Accelerator [p.170]
対応プロトコル	HTTP / HTTPS のみ（L7 Web通信に特化） [p.170]。	TCP / UDP 全般（L4レベル。ゲーム、音声通話、独自プロトコルを含む） [p.170]。
キャッシュ機能	あり。エッジサーバーでコンテンツを一時保存し、オリジナルに代わって直接高速応答する [p.170]。	なし。データの一時保存は一切せず、パケットを最速で右から左へルーティング転送する [p.170]。
提供エンドポイント	専用ドメイン名（FQDN。例: `xxxx.cloudfront.net`） [p.109, p.165]。	固定された「2つの静的IPアドレス」 [p.169]。
試験での選択シグナル	「世界中からアクセスされる静的画像・動画コンテンツを高速配信し、配信コスト（Egress料金）を削りたい」 [p.160]。	「リアルタイムオンラインゲームのUDP通信を高速化したい」 [p.170]、または「 DNSキャッシュに依存しない即時リージョン間フェイルオーバーを実現したい」 [p.169]。

② 独自ドメインの最上位（Zone Apex）マッピング：CNAME vs Alias [p.165]

比較項目	CNAME レコード [p.165]	Alias（エイリアス）レコード [p.165]
定義	ドメイン名を別のエイリアスドメイン名にマップするDNS標準規格 [p.165]。	Route 53独自の拡張規格。ドメイン名を特定のAWSリソースに直接紐付ける [p.165]。
Zone Apexへのアタッチ	不可能（仕様上、`example.com` に直接定義することはできない） [p.165]。	可能（`example.com` に直接ロードバランサー（ALB）などを登録できる） [p.165]。
DNSクエリ料金	有料（名前解決クエリが発生するたびに対象となる）。	無料（AWSリソースを解決するAliasレコードへのクエリ料金は完全無料） [p.165]。

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

ひっかけ①：「企業のコーポレートサイトの独自ドメイン（例: example.com）の直下（Zone Apex）に、新規作成したApplication Load Balancer（ALB）を登録してマッピングしたい。Route 53で標準の『CNAMEレコード』を作成し、宛先にALBのDNSホスト名を設定した。」
- 真実: DNSの物理的な仕様制限により、この設定は作成そのものが拒否されるか、名前解決エラーを引き起こします [p.165]。
- 対策: サブドメインを伴わないZone Apexに対してロードバランサー（ELB）やCloudFrontをマッピングさせたい要件が出た場合は、CNAMEではなく、Route 53の独自機能である「 Alias（エイリアス）レコード（Aレコードとしてアタッチ） 」を選択して登録する必要があります [p.165]。
ひっかけ②：「東京リージョンとシンガポールリージョンに冗長デプロイしたWebアプリケーションにおいて、特定のリージョンが災害で壊滅した際、数秒以内に自動でもう片方のリージョンへ通信を100%切り替えたい。これを達成するため、Route 53の『フェイルオーバールーティングポリシー』のみを適用してDR（災害復旧）設計を完結させた。」
- 真実: Route 53単体（DNSルーティングの変更）では、DNSキャッシュ（TTL）の影響により、世界中のクライアント接続が迂回されるまでに数分から数時間の深刻なタイムラグが発生します [p.167, p.169]。
- 対策: 端末や中継ISPのDNSキャッシュを完全にバイパスし、ミリ秒〜数秒レベルでのマルチリージョン切り替えを行いたい場合は、「 AWS Global Accelerator 」をデプロイします [p.169]。これにより、ユーザーは払い出された「2つの静的IPアドレス」に接続し続けたまま、Global Acceleratorの内部（AWSバックボーン内）で即座にルーティング先を正常なバックエンドへ迂回させることができます [p.169]。