【CloudFrontの役割（耐障害性と高可用性）】
目次
🔍 1. 結論
💎 一言でいうと セキュリティだけでなく「弾力性」の観点での CloudFront の最大の役割は、「急激なアクセス集中（スパイク）をエッジロケーションで吸収し、背後のEC2やS3をパンクさせないこと（オフロード）」 です。
- ユーザーからのリクエストの大部分を、オリジン（サーバー）の代わりにキャッシュで返す。
- これにより、サーバーの台数（Auto Scalingの規模）を小さく抑えつつ、落ちないシステムを作れる。
📈 2. SAAで出やすいポイント
- オリジン（バックエンド）の負荷軽減: テレビ放送やSNSのバズ等でトラフィックが100倍に跳ね上がった際、EC2のAuto Scalingだけではスケールアウト（起動）が間に合わずダウンする可能性があります。CloudFrontを前に置いておけば、静的コンテンツ（画像やHTML）はCloudFrontが瞬時に返すため、EC2に負荷がかかりません。
- 動的コンテンツの配信最適化: キャッシュできない動的コンテンツ（APIやユーザー別データ）であっても、CloudFrontを経由させることで、AWSの高品質なグローバルプライベートネットワークを通って通信が最適化されるため、パフォーマンスと安定性が向上します。
- 高可用性エラーページ (Custom Error Pages): オリジン（EC2やS3）が万が一ダウンして「503 Service Unavailable」などを返した場合でも、CloudFront側で用意した「お詫びページ（カスタムエラーページ）」をキャッシュしてユーザーに返すことで、システムとしての体裁（可用性）を保つことができます。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うサービス・構成 |
|---|---|
| 📈 「予測不可能なスパイクによるWebサーバーの過負荷を防ぎたい」 | CloudFront (キャッシュによるオフロード) |
| 🌍 「世界中のユーザーに同じ静的コンテンツを高速に配信したい」 | CloudFront |
| 🛠️ 「オリジンサーバーのダウン時に、代替の静的ページを見せたい」 | CloudFront カスタムエラーレスポンス |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「EC2インスタンスのスペックを最大にする（垂直スケーリング）」 → 突発的な負荷に対する正解にはなりません。キャッシュ（CloudFrontやElastiCache）で負荷自体を減らすアプローチが優先されます。 – 「Global Accelerator との混同」 → どちらもグローバル配信を最適化しますが、「HTTP(S)のキャッシュ」が目的なら CloudFront、「非HTTP（TCP/UDP）や、キャッシュ不要でとにかく一番早い経路を通したい」なら Global Accelerator です。
💡 5. 覚え方
🧠 暗記ショートカット – CloudFront = 「お店（サーバー）の前に立った優秀な呼び込みスタッフ」。 – 客からのよくある質問（静的コンテンツ）にはスタッフがその場で答えて帰すので、店長（EC2）は本当に大事な仕事（動的処理）だけに集中でき、過労死しない。
📚 6. 関連サービス
| アイコン | サービス名 | CloudFrontとの役割分担 |
|---|---|---|
| 🪣 | Amazon S3 | CloudFrontのオリジン（データの元）として最も一般的な組み合わせ |
| ⚖️ | ALB | CloudFrontの背後で、動的リクエストを複数EC2に分散する |
| 🌍 | AWS Global Accelerator | キャッシュではなく「IPエニーキャスト」を用いたネットワークルーティング最適化 |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: 負荷分散戦略、キャッシュレイヤーの設計学習時
- 関連ノート候補:
AWS_SAA_CloudFront_vs_GlobalAccelerator
8. HTMLファイル名:
AWS_弾力性設計_CloudFront.html
