AWS CloudFront と Global Accelerator：CDN、キャッシュ、オリジン、エッジネットワーク

CloudFront を CDN として

Amazon CloudFront は AWS のコンテンツ配信ネットワーク（CDN）。試験では CDN → CloudFront と考える。

読み取り中心のコンテンツを世界中のエッジロケーション（PoP）にキャッシュし、ユーザーは低遅延とより良い体験を得る。
グローバルな展開（コース：200+ PoP 規模 — 最新数値は確認）。
エッジへのトラフィック分散は DDoS 耐性にも寄与；AWS Shield や WAF と連携（セキュリティは別途深掘り）。

例：オリジンがオーストラリアの S3 バケット；米国のユーザーは近いエッジにアクセス。最初のリクエストはオリジン取得の可能性；その後の米国ユーザーはオーストラリアへの往復なしにエッジでキャッシュヒットしがち。

オリジン

CloudFront はオリジン（バックエンド）から取得する。

オリジン種別	メモ
Amazon S3	オブジェクトの配信とキャッシュ；CloudFront 経由のアップロードパターンも可能。Origin Access Control（OAC）とバケットポリシーで S3 を保護（現代的な構成では従来の OAI パターンに置き換わる）。
VPC オリジン	VPC 内のプライベート ALB、NLB、EC2 — アプリをパブリックインターネットに晒さなくてよい（プライベートアプリ向けに推奨；コンソールの層によって VPC オリジンが制限される場合あり）。
カスタムオリジン（HTTP）	任意の HTTP サーバー：S3 静的ウェブサイトエンドポイント（ウェブサイトホスティング有効）、パブリック ALB、オンプレなど。

リクエストフロー（キャッシュの基本）

クライアント → エッジロケーション。
エッジがそのオブジェクトのキャッシュを確認（キャッシュキー / 下記ポリシー参照）。
キャッシュヒット → エッジから配信。
キャッシュミス → CloudFront がオリジンから取得し、エッジに保存（TTL/ポリシーに従い）、クライアントへ返す。

S3 オリジン：CloudFront と S3 の間のトラフィックは多くの場合 AWS ネットワーク；OAC と バケットポリシーであなたのディストリビューションだけがプライベートオブジェクトを読める — オブジェクトはプライベートのまま、ビューアーは CloudFront ドメインを使う。

CloudFront と S3 クロスリージョンレプリケーション（CRR）

	CloudFront	S3 CRR
モデル	グローバルエッジキャッシュ；オブジェクトはTTLの間エッジにキャッシュ	別リージョンへのバケット全体のレプリケーション
カバレッジ	設計上世界中に多数の PoP	設定したリージョンのみ
鮮度	キャッシュ；TTL または無効化で更新	オブジェクトのほぼリアルタイムレプリカ
向いている用途	グローバルな静的（またはキャッシュ可能）コンテンツ	動的または強い一貫性のマルチリージョン読み取り、リージョン数が少ない場合

実践パターン：プライベート S3 + CloudFront

S3 バケットを作成しオブジェクトをアップロード（プライベート — 直リンクは 403、コンソールの Open はプリ署名 URL）。
CloudFront ディストリビューションを作成；プラン選択（コース：無料枠でデモ可；セキュリティや製品機能で pay-as-you-go / 上位層）。
オリジン種別 S3；プライベートバケットアクセス / OAC を有効（推奨設定）。
デプロイ後、S3 バケットポリシーに CloudFront への GetObject を許可するステートメントが表示されることが多い（サービスが自動追加/更新）。
ビューアーは https://<distribution-domain>/<object-key>（例：/coffee.jpg、/index.html） — パブリック S3 ACL は不要。

キャッシュ：TTL、ポリシー、無効化

キャッシュは各エッジに存在。目標：キャッシュヒット率を高く → オリジンヒットを減らす。
TTL： キャッシュ内でオブジェクトが有効な時間（0 ～ 約 1 年）。オリジンの Cache-Control（例：max-age）と Expires の影響；ヘッダーがない場合や値を抑えるための最小/デフォルト/最大 TTL 設定も可能。
キャッシュポリシー / レガシーキャッシュ設定： どのヘッダー、Cookie、クエリ文字列がキャッシュキーに含まれるか（バリアントが多いほどヒット率は下がる）。
CreateInvalidation： エッジキャッシュからパスを強制削除（例：/index.html、/images/*、または /*）し、次のリクエストが TTL 切れ前にオリジンを再取得するようにする。

Origin Shield

Shield なしでは多数のエッジがそれぞれミスし、同じオブジェクトでオリジンを叩き続ける可能性がある。

Origin Shield はエッジとオリジンの間にリージョナルキャッシュ層を追加（「キャッシュのためのキャッシュ」）：最初のエッジミスが Shield を満たす；他のエッジは S3/ALB に毎回当てず Shield から取得 — オリジンロードを減らし、負荷下の可用性を改善しうる。

VPC オリジンとレガシーのパブリックオリジン

推奨（現代的）： VPC オリジン — CloudFront が VPC 内のプライベート ALB / NLB / EC2 に到達。

レガシーパターン： オリジンはパブリックである必要があった；セキュリティグループで CloudFront エッジ IP レンジを許可（煩雑、レンジ変更や SG 誤設定でミスしやすい）。古いアーキテクチャでは依然として認識しておく価値あり。

地理的制限

geo-IP データベースで国単位にビューアーを制限。

許可リスト（承認国のみ）またはブロックリスト（禁止国）。
よくある用途：著作権 / ライセンス。

コンソールの利用可否はディストリビューションプラン / 課金モードに依存（コース：geo UI に pay-as-you-go が要る場合あり）。

ログ、レポート、モニタリング

標準ログ（S3）

ビューリクエストのオプションログを S3 バケットへ（多くはオリジンのコンテンツバケットとは別）；ディストリビューションごとにプレフィックス。
CloudWatch Logs や Kinesis Data Firehose へのストリームも可能。
Athena で分析（他のアクセスログと同様）。

組み込みレポート（コンソール）

キャッシュ統計、人気オブジェクト、トップリファラー、使用量、ビューアー — CloudFront 独自のテレメトリ；S3 アクセスログを有効にしなくても利用可能。

トラブルシューティング

CloudFront はオリジンの HTTP エラーレスポンス（4xx、5xx）を一定期間キャッシュしうる — 悪い 403/404/502 は TTL または無効化まで残る。

メトリクス

例：リクエスト数、ビューアーへのバイト、キャッシュヒット/ミス、4xx/5xx、オリジン遅延 — 運用とチューニング向け。

深掘り：キャッシュキーの要素

3 つのレバー（それぞれ none / whitelist / all に近いモード）：

ヘッダー
- すべて転送 → 実質キャッシュなし（TTL は多くの場合 0）。
- ホワイトリスト → それらのヘッダー値でキャッシュが分岐。
- 転送なし（デフォルト除く） → アプリがオリジンでビューアーヘッダーを要しないとき最良のヒット率。
Cookie（実質 Cookie ヘッダーのキー/値）
- レスポンスを変えなければならない Cookie のみホワイトリスト（例：A/B や言語）。
クエリ文字列
- オブジェクトに影響しなければならないパラメータのみ（例：size、version）。

オリジンカスタムヘッダーとキャッシュビヘイビア

オリジンカスタムヘッダー： CloudFront のオリジンで設定；すべてのオリジンリクエストに追加される一定の名前/値（例：CloudFront 由来を示す共有秘密）。キャッシュキーには使わない。
キャッシュビヘイビアのヘッダーホワイトリスト： 転送されキャッシュ判断に含まれる。

キャッシュヒットを最大化（試験スタイル）

静的アセット（S3、Cookie/クエリなしまたは少ない）と、ヘッダー/Cookie が要る動的 API/HTML を分離。
オリジンから Cache-Control: max-age を優先；ビヘイビアで最小/デフォルト/最大 TTL を調整。
TTL が長いときはデプロイ後に無効化。

CloudFront + ALB スティッキーセッション

ALB のスティッキーは Cookie（例：AWSALB）を使う。CloudFront がその Cookie をオリジンに転送しないと、スティッキーは壊れる。

対処： キャッシュビヘイビアでスティッキー Cookie をホワイトリストし ALB に届ける。（コースでは、認証/セッション Cookie よりキャッシュ TTL を短く保つ衛生習慣に言及 — 多くの試験項目より深い。）

AWS Global Accelerator

課題： 世界中のユーザーがリージョンの 1 エンドポイントにパブリックインターネット経由で当たる → ホップが多く、遅延とパケット損失リスク。

Unicast と Anycast

Unicast： 1 IP → 1 サーバー。
Anycast： 同一 IP を複数拠点からアドバタイズ；ルーティングがクライアントを最寄り PoP へ送る。

Global Accelerator の動作

アクセラレータ用に2 つの静的 Anycast IPv4（グローバル）をプロビジョニング。
クライアントトラフィックは最寄りエッジに入り、AWS グローバルネットワークで 1 つ以上のリージョンのエンドポイント（ALB、NLB、EC2、EIP — パブリックまたはプライベート）へ。
キャッシュなし — パケットはアプリまでプロキシ。
ヘルスチェック + 高速リージョンフェイルオーバー（コース：約 1 分以内に健全なエンドポイントへ）。
Shield による DDoS 支援；クライアントは2 IP だけ許可すればよい。

Global Accelerator と CloudFront

	CloudFront	Global Accelerator
主な役割	HTTP(S) CDN — エッジでキャッシュ	TCP/UDP プロキシ — キャッシュなし
トラフィック	多くはエッジキャッシュから配信	常にリージョナルエンドポイントへ転送
向いている用途	静的アセット、多くの HTTP キャッシュ；一部動的加速	非 HTTP（ゲーム、IoT、VoIP）、世界中の固定 IP 入口、予測可能なフェイルオーバー
共通	AWS エッジ / グローバルネットワーク、Shield 連携	同様の広いエッジ/ネットワークの話

実習の要約（コース）

Global Accelerator はグローバルコンソール（リージョン選択なし）。リスナー（例：TCP 80）、リージョンごとのエンドポイントグループ、エンドポイント（EC2、ALB、NLB、EIP）、ヘルスチェック（例：HTTP /）を設定。異なる地理的観点から同じ Anycast IP が最寄りの健全なリージョナルエンドポイントへルーティング（デモで VPN で US と EU のルーティングを説明）。クリーンアップ： アクセラレータを無効/削除、テストインスタンスを終了。

要点

試験で CDN → CloudFront；エッジキャッシュで遅延とスケール；プライベート S3 は OAC + バケットポリシー。
オリジン： S3、VPC（プライベート ALB/NLB/EC2）、カスタム HTTP；可能ならパブリックオリジン + CloudFront IP 許可リストより VPC オリジン。
キャッシュ： TTL、キャッシュキー（ヘッダー/Cookie/クエリ）、無効化のバランス；Origin Shield でオリジンへの fan-out を削減。
地理制限 = 国の許可/ブロックリスト（プラン/課金がコンソールオプションに影響）。
S3 へのログ（別バケット）とオプションのストリーム；コンソールのレポートは S3 ログ有効化と独立；エラーもキャッシュされうる。
ALB スティッキー → CloudFront でセッション Cookie をホワイトリスト。
Global Accelerator = 静的 Anycast IP、キャッシュなし、TCP/UDP、ヘルスチェックと高速フェイルオーバー；エッジキャッシュモデルの CloudFront との対比。

Claudeによる翻訳