週6Route 53 / CloudFront

2026-09-06（日）Route 53, CloudFront

この記事の目次
  1. 予習ポイント
  2. 図解イメージ（言葉で説明）
  3. 視聴後に自分でチェックしたい項目

1. 【予習ポイント】

  • Amazon CloudFront（CDN）：エッジでのキャッシュによる「オリジナルサーバーの保護」と「表示の高速化」 [p.160]

    • なぜ使うのか: ユーザーが世界中からWebサイトにアクセスする際、毎回東京のオリジナルサーバー（S3やEC2など）までデータを取りに行くと、ネットワークの距離（レイテンシー）により表示が遅くなります [p.160]。
    • AWSのベストプラクティス: 世界中に分散配置された「エッジロケーション」に、画像や動画などの静的コンテンツを一時保存（キャッシュ）して配信します [p.28, p.160]。これにより、ユーザーの物理的距離が縮まり高速表示されると同時に、オリジナルサーバーのCPU負荷やデータ転送コストが大幅に激減します [p.160]。
    • Lambda@Edgeの必然性: ユーザーに最も近いエッジロケーションで、リクエストヘッダーの書き換えや簡単なセキュリティ認証などの軽量プログラムを実行できる機能です [p.162]。わざわざオリジナルサーバーまでパケットを通さずに水際で動的な処理を完結できるため、応答速度を極限まで引き上げられます [p.162]。

  • AWS Global Accelerator：パブリックインターネットをバイパスする「世界規模の超高速専用レーン」 [p.168]

    • なぜ使うのか: 通常、インターネット経由の通信は、世界中の無数のプロバイダー（ISP）を経由するため、経路が不安定で遅延が発生します [p.168]。
    • AWSのベストプラクティス: ユーザーの最寄りのエッジロケーションから通信を吸い上げ、そこから先は 「 AWSが保有する極めて安定したグローバル専用プライベートネットワーク 」 にトラフィックを乗せて、最速のルートで世界中のバックエンド（ALBやEC2）へパケットを届けます [p.168, p.169]。
    • 2つの「静的IPアドレス」がエントリーポイントである理由: DNSの名前解決は、クライアント端末やISPのキャッシュ（TTL）に強く依存するため、障害発生時の切り替えに数分〜数日かかることがあります [p.169]。Global Acceleratorは、ドメイン名ではなく固定された2つの静的IPアドレスを提供するため、DNSキャッシュの影響を完全に無視できます [p.169]。裏側の特定リージョンのサーバーがダウンした際も、DNSの更新を待つことなく、別リージョンの健全なサーバーへ瞬時にトラフィックを自動転送（フェイルオーバー）できます [p.169]。

2. 【図解イメージ（言葉で説明）】

「世界中に展開するお弁当チェーンと、渋滞ゼロのVIP専用ヘリポート」

CloudFront（キャッシュ配信）と Global Accelerator（ネットワーク高速化）の役割の違いを、日々の流通に例えてイメージ化します。

【CloudFront（コンビニ型）】
[ユーザー] ➡ 目の前の [ローカルコンビニ（エッジ）] ※お弁当（キャッシュ）がある
　　　　　　　　❌お弁当がない場合のみ ➡ [東京の巨大お弁当工場（オリジナル）]

【Global Accelerator（高速ヘリポート型）】
[ユーザー] ➡ 目の前の [ローカルヘリポート（エッジ）] ➡【AWS超高速プライベート空路】➡ [世界各地の工場（バックエンド）]
  1. CloudFrontは「街のコンビニ（キャッシュストア）」 [p.160]: 東京に「お弁当の巨大工場（オリジナルサーバー）」があるとします [p.160]。世界中の人々がお腹を空かせた（アクセスした）とき、全員が東京の工場に直接買いに行くと大渋滞して時間がかかります [p.160]。そこで、世界中の駅前（エッジロケーション）に「小さなお弁当屋さん（CloudFront）」を出店し、人気のお弁当（静的画像・動画）を事前に並べておきます [p.160]。ユーザーは目の前の店舗で即座にお弁当を買えるため待ち時間はゼロになり、東京の工場も大混雑から守られます [p.160]。
  2. Global Acceleratorは「渋滞ゼロのVIP専用ヘリコプター」 [p.168]: キャッシュができない「オーダーメイドの熱々スープ（動的なTCP/UDPデータやゲームのリアルタイム通信）」を、どうしても東京や世界各地の工場から届ける必要があるとします [p.170]。普通に一般道（パブリックインターネット）を走ると、信号待ちや渋滞（他の無関係な通信パケット）に巻き込まれてスープが冷めてしまいます [p.168]。 そこで、ユーザーの最寄りのヘリポート（エッジ）からスープを回収し、そこからは 「 一般車が1台も走っていない、AWS専用の最高速ヘリコプター（AWSグローバル閉域網） 」 を使って、世界の目的地までダイレクトに超高速空輸します [p.168, p.169]。

3. 【視聴後に自分でチェックしたい項目】

  • ⬜︎ チェック1: CloudFrontとGlobal Acceleratorの「対応プロトコル（レイヤー）」の決定的な違いを説明できるか？ [p.170]
    • CloudFrontは「HTTP/S（Web通信）専用」であり、Global AcceleratorはWebだけでなくゲームや音声通話などの「TCP/UDP（幅広いパケット）」をすべて高速化できる違いを意識して動画を見られたか？ [p.170]
  • ⬜︎ チェック2: 双方の「キャッシュ機能」の有無を明確に識別できているか？ [p.170]
    • CloudFrontはコンテンツを「一時保存して自ら配信する（キャッシュあり）」のに対し、Global Acceleratorは「キャッシュは行わず、パケットを世界一速いルートで右から左へ届ける（キャッシュなし）」転送特化型サービスである挙動の違いを腹落ちできたか？ [p.170]
  • ⬜︎ チェック3: Global Acceleratorが提供する「2つの静的IPアドレス」が、複数リージョンへの可用性をどのように高めているか？ [p.169]
    • アクティブ・アクティブで世界中の複数リージョン（ALBやEC2）へリクエストを自動分散でき、特定リージョンで災害が起きた際も「DNSのキャッシュ更新を待たずに」トラフィックをバイパスできるDR（災害復旧）設計の利点を理解できたか？ [p.169]

🎧 予習資料の整理が完了しました。ネットワークパフォーマンスとエッジ配信の最適化を司るこの範囲は、SAA-C03本試験でも「パフォーマン効率（24%）」や「可用性の高いアーキテクチャ（26%）」の得点源となる超重要領域です。