2026-09-09（水）Route 53, CloudFront
1. 【この範囲の全体像】
本範囲（第6章6-3、p.168-174）は、グローバル規模でのネットワーク通信性能を最適化し、信頼性を高める 「 AWS Global Accelerator 」 の仕様と、「 Amazon CloudFront 」 との境界線を扱います [p.168, p.170]。
不安定なパブリックインターネットの経路をバイパスし、AWS専用のグローバルネットワークに通信を乗せることで、レイテンシー（遅延）を極小化する仕組みを理解することが重要です [p.168]。
試験では、動的データ（キャッシュ不可）やTCP/UDP通信をミリ秒レベルで高速化する「Global Accelerator」と、静的Webコンテンツの配信（キャッシュあり）に特化した「CloudFront」の特性をコストおよびパフォーマンスの面から正しく選択・マッピングする設計能力が問われます [p.170]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| AWS Global Accelerator [p.168] | AWSのグローバル専用ネットワーク網を経由して通信を効率的にルーティングし、エンドユーザーとアプリケーション間の接続遅延（レイテンシー）と可用性を劇的に改善する高性能ネットワーク最適化サービス [p.168]。 |
| 静的IPアドレスによるエントリーポイント [p.169] | Global Acceleratorがユーザー接続用に常時固定で提供する「2つの静的エニーキャストIPアドレス」 [p.169]。クライアントによるDNSキャッシュ（TTLの影響）を回避し、最寄りのエッジロケーションからAWSネットワークへパケットを瞬時に取り込みます [p.169]。 |
| AWSグローバルネットワーク [p.168] | パブリックインターネットを一切経由せず、世界中のエッジロケーションから各リージョンのAWSバックエンドまでをセキュアに最短直結する、AWS自身が自社保有・運用している超高速な専用プライベート閉域網 [p.168]。 |
| マルチリージョンフェイルオーバー [p.169] | 世界最大10個の異なるリージョンに配置されたバックエンドリソースを登録・一元管理し、特定のリージョン障害発生時にDNSレコードの書き換えや浸透待ちなしに、残りの健全なリージョンへトラフィックを即時に自動転送（フェイルオーバー）する仕組み [p.169]。 |
| エッジロケーション [p.168, p.170] | エンドユーザーに最も近い位置に配置されたAWSの物理データセンター拠点 [p.160]。CloudFrontのキャッシュサーバーとして機能すると同時に、Global Acceleratorのパケット吸い上げ口（エントリーポイント）としても共通利用されます [p.168, p.170]。 |
3. 【試験で問われる比較ポイント】
AWSエッジネットワークの使い分け：CloudFront vs Global Accelerator [p.170]
「キャッシュの要否」と「通信に使用される下位プロトコル（プロトコルレイヤー）」のシグナルから完全に100%切り分けます [p.170]。
| 比較項目 | Amazon CloudFront [p.170] | AWS Global Accelerator [p.170] |
|---|---|---|
| 対応プロトコル | HTTP / HTTPS のみ（L7 Web通信専用） [p.170]。 | TCP / UDP 全般（L4レベル。Web以外のカスタムプロトコルや非HTTPアプリケーションに対応） [p.170]。 |
| キャッシュ機能 | あり。画像、動画、CSSなどの静的オブジェクトをエッジ側に一時保存し、直接オリジナルに代わって即時高速応答する [p.170]。 | なし。データの一時保存は一切行わず、すべてのパケットをリアルタイムで右から左へ最速ルート転送する [p.170]。 |
| 提供されるエンドポイント | ドメイン名（FQDN。例: xxxx.cloudfront.net） [p.109, p.165]。 |
「 2つの固定静的IPアドレス 」 （Anycast IP） [p.169]。 |
| 主な接続オリジン | Amazon S3、ALB、EC2、カスタムWebサーバー [p.160, p.170]。 | Network Load Balancer (NLB)、Application Load Balancer (ALB)、EC2、Elastic IPアドレス (EIP) [p.169, p.170]。 |
| 試験での決定的な選定シグナル | ・ 「 世界中へ配信するWeb画像やPDF等の静的メディアを高速表示したい 」 [p.160] ・「オリジンサーバーへのAPI通信負荷をキャッシュで激減させたい」 [p.160] |
・ 「 リアルタイムオンラインゲームのUDP通信やIoTデータの転送遅延をミリ秒単位で削減したい 」 [p.170] ・「DNSキャッシュ（TTL）によるDR切り替えのタイムラグを排除し、複数リージョン間で即時フェイルオーバーさせたい」 [p.169] |
4. 【ひっかけ注意ポイント】
ひっかけ①：「世界中からアクセスされるマルチプレイヤー型オンラインゲームにおいて、クライアント・サーバー間で激しく往来する独自のUDP/TCPデータ通信のネットワーク応答速度（レイテンシー）を高めたい。このパフォーマンス向上を達成するため、ゲームサーバー（EC2）の前段に『Amazon CloudFront』をデプロイし、接続用のキャッシュディストリビューションを構成する。」
- 真実: 通信自体が成立せず、ゲームが完全に起動・稼働しない物理的アンチパターンです [p.170, p.173]。
- 解決理由: Amazon CloudFrontは「HTTP/HTTPSプロトコル」専用のL7配信サービスです [p.170]。ゲームクライアントがやり取りする独自プロトコル（生TCPやUDPパケット）をCloudFront経由で透過的に中継・転送することは物理仕様として不可能です [p.170]。
- 対策: L4レベルのカスタムTCP/UDP通信に対して、エッジロケーションからAWS専用ネットワークを介して超高速に転送・最適化を課したい場合は、CloudFrontではなく必ず 「 AWS Global Accelerator 」 を選択マッピングしてください [p.170, p.173]。
ひっかけ②：「複数リージョン（東京・シドニー）に冗長デプロイしたWebアプリケーションにおいて、特定のアベイラビリティゾーン全体がダウンする災害が起きた際、数秒以内に自動ですべてのクライアント接続をもう片方の健全なリージョンへ完全に切り替えたい（ディザスタリカバリ要件）。これを達成するため、Route 53の『フェイルオーバールーティングポリシー』のみを設定した。」
- 真実: Route 53単体では、DNSレコードの切り替え完了（パケットの迂回）までに数分〜数時間以上の深刻なタイムラグが発生します [p.167, p.169]。
- 解決理由: クライアント端末、社内プロキシ、インターネットプロバイダー（ISP）は、名前解決（DNS）情報を「TTL（生存時間）」に従ってローカルにキャッシュし続けます [p.164, p.167]。そのため、Route 53側でレコードを即時切り替えても、クライアントが手元の古いキャッシュを使い続け、クラッシュした無応答のリージョン宛てにリクエストを送信し続けてしまうため、数秒レベルのDRを確立することは不可能です [p.167, p.169]。
- 対策: クライアント端末のDNSキャッシュを完全にバイパスし、即時のマルチリージョン切り替えを行いたい場合は、「 AWS Global Accelerator 」 をデプロイします [p.169]。Global Acceleratorは、固定された「2つの静的IPアドレス」をエントリポイントとするため、クライアント側でDNSの再名前解決（キャッシュ）が発生せず、Global Acceleratorの内部（AWSバックボーン内）で即時に転送先リージョンを切り替えるため、極小のタイムラグでの自動フェイルオーバーを完成させることができます [p.169]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。