🔄
CloudFront オリジンフェイルオーバー
配信元が壊れても自動で切り替わる「保険」の仕組み
Amazon CloudFront ネイティブ機能
⚡ CONCLUSION FIRST
まず結論：30秒で分かるオリジンフェイルオーバー
CloudFront のオリジンフェイルオーバーとは、配信元（オリジン）が障害を起こした際に、自動的にバックアップのオリジンへ切り替える仕組みです。ユーザーは障害に気づかずにコンテンツを受け取り続けることができます。
1
オリジングループ＝ メインとバックアップの2つのオリジンをセットにしたもの
2
自動切り替え＝ 特定のHTTPエラー（5xx/4xx）を検知すると自動でバックアップに転送
3
設定のみ＝ コードの変更不要、CloudFront の設定だけで有効化できる
4
高可用性＝ ダウンタイムなしでユーザー体験を維持できる
🏪 ANALOGY
たとえ話：2つの倉庫を持つネットショップ
あなたが運営するネットショップを想像してください。メイン倉庫（東京）から商品を出荷していますが、もしメイン倉庫が火災や停電で使えなくなったら？注文した全てのお客様に「発送できません」と連絡するのは大損害です。そこで、バックアップ倉庫（大阪）を用意しておき、メインが使えない時は自動的にバックアップから出荷する仕組みを作ります。これが CloudFront のオリジンフェイルオーバーです。
📦 ネットショップ
→
CloudFront ディストリビューション
🏭 メイン倉庫
→
プライマリオリジン（S3 / ALBなど）
🏭 バックアップ倉庫
→
セカンダリオリジン（別リージョンS3など）
📋 出荷管理システム
→
オリジングループ（自動切替ルール）
通常時
メイン倉庫から出荷 ✅
注文が入ると、出荷管理システムはまずメイン倉庫（東京）に指示を出します。メイン倉庫が正常に稼働していれば、そのまま出荷完了です。
👤 → 📋 → 🏭✅ → 📦
障害発生時
バックアップ倉庫に自動切替 🔄
メイン倉庫がダウン（停電・火災）した場合、出荷管理システムが自動的にバックアップ倉庫（大阪）へ出荷指示を切り替えます。お客様は遅延に気づきません。
👤 → 📋 → 🏭❌ → 🏭✅ → 📦
🏗️ STRUCTURE
オリジングループの構造
オリジングループは、プライマリオリジンとセカンダリオリジンの2つをセットにして、CloudFront のキャッシュビヘイビアに紐づけます。リクエストは常にプライマリに送られ、失敗した場合のみセカンダリに転送されます。
📐 構造図：オリジングループの全体像
📦 オリジングループ
優先
プライマリオリジン
例：S3バケット（東京リージョン）
↕ フェイルオーバー時に自動切替
予備
セカンダリオリジン
例：S3バケット（大阪リージョン）
ℹ️
ポイント：オリジングループ内のプライマリとセカンダリは、S3、ALB、カスタムオリジン、MediaStore など異なる種類のオリジンを自由に組み合わせ可能です。同じ種類である必要はありません。
🔄 FAILOVER FLOW
フェイルオーバーの仕組み（ステップ解説）
CloudFront がどのようにオリジンの障害を検知し、セカンダリに切り替えるのか、4つのステップで見ていきましょう。
📐 フロー図：フェイルオーバーの流れ
ユーザーがリクエスト送信
ユーザーが画像やページなどのコンテンツをリクエストすると、最寄りの CloudFront エッジロケーションが受け取ります。キャッシュにない場合、オリジンへ転送します。
👤 → CloudFront エッジ
プライマリオリジンへリクエスト転送
CloudFront はまずプライマリオリジンにリクエストを送ります。プライマリが正常に応答（200 OK）すれば、ユーザーにコンテンツが配信されて完了です。
エッジ → プライマリオリジン
プライマリが失敗 → フェイルオーバー条件を判定
プライマリから設定済みのHTTPステータスコード（例: 500, 502, 503, 504, 403, 404）が返された場合、CloudFront はフェイルオーバー条件に該当すると判断します。接続タイムアウトの場合もフェイルオーバーが発生します。
⚠️ エラーステータス検知
セカンダリオリジンから配信
CloudFront は同じリクエストをセカンダリオリジンに自動的に再送します。セカンダリが正常応答すれば、ユーザーはコンテンツを受け取れます。この切り替えはユーザーには見えず、シームレスに行われます。
✅ セカンダリから配信完了
⚠️
注意：セカンダリオリジンも失敗した場合は、セカンダリのエラーレスポンスがそのままユーザーに返されます。セカンダリからさらに別のオリジンへの「二段階フェイルオーバー」はできません。
🚨 TRIGGER CODES
フェイルオーバーを発動するHTTPステータスコード
以下のHTTPステータスコードをフェイルオーバー条件として設定できます。どのコードを対象にするかはカスタマイズ可能です。
500
Internal Server Error
サーバー内部エラー。アプリがクラッシュした状態。
502
Bad Gateway
上流サーバーから無効な応答を受信。
503
Service Unavailable
サービス過負荷またはメンテナンス中。
504
Gateway Timeout
上流サーバーが応答しない（タイムアウト）。
403
Forbidden
アクセス拒否。権限の問題。
404
Not Found
リソースが存在しない。
✅
ベストプラクティス：一般的には 500, 502, 503, 504 の4つのサーバーエラーを対象にします。403/404 は意図的なレスポンスの場合もあるため、用途に応じて含めるか判断しましょう。
🎯 USE CASES
オリジンフェイルオーバーが活きる場面
🌏
マルチリージョン冗長化
S3バケットを東京と大阪にレプリケーションし、東京がダウンしても大阪から配信を継続。リージョン障害に対応した静的コンテンツ配信の基本パターンです。
🖥️
静的サイトフォールバック
プライマリにALB（動的サーバー）、セカンダリにS3（静的HTML）を設定。サーバーダウン時は「メンテナンス中」ページやキャッシュ済みの静的版を配信します。
🎬
メディア配信の安定化
動画・画像配信でプライマリの MediaStore がダウンした場合、S3にバックアップしたメディアファイルからシームレスに配信を継続します。
🛒
ECサイトの可用性確保
商品画像やCSSなどの静的アセットをフェイルオーバー構成にし、オリジン障害時もサイトの見た目を維持。売上損失を最小限に抑えます。
📊 COMPARISON
通常オリジン vs オリジンフェイルオーバー
| 比較項目 |
通常（単一オリジン） |
オリジンフェイルオーバー |
| 可用性 |
オリジン障害 ＝ 配信停止 |
自動で予備に切替、配信継続 |
| 設定の手軽さ |
オリジン1つ設定するだけ |
オリジングループの追加設定が必要 |
| コスト |
オリジン1つ分 |
予備オリジンの維持費が追加 |
| ユーザー影響 |
障害時にエラーページが表示される |
障害を意識させない透過的な切替 |
| 適用シーン |
開発環境、影響の小さいサイト |
本番環境、ビジネスクリティカルな配信 |
⚙️ CONFIGURATION
CloudFormation テンプレートでオリジンフェイルオーバーを設定する例です。OriginGroups にプライマリとセカンダリを定義し、フェイルオーバー条件のステータスコードを指定します。
# CloudFront Distribution 設定
DistributionConfig:
Origins:
- Id: PrimaryOrigin
DomainName: my-bucket-tokyo.s3.amazonaws.com
S3OriginConfig:
OriginAccessIdentity: ""
- Id: SecondaryOrigin
DomainName: my-bucket-osaka.s3.amazonaws.com
S3OriginConfig:
OriginAccessIdentity: ""
# オリジングループの定義
OriginGroups:
Quantity: 1
Items:
- Id: MyOriginGroup
FailoverCriteria:
StatusCodes:
Quantity: 4
Items:
- 500
- 502
- 503
- 504
Members:
Quantity: 2
Items:
- OriginId: PrimaryOrigin # 1番目 = プライマリ
- OriginId: SecondaryOrigin # 2番目 = セカンダリ
# ビヘイビアでオリジングループを指定
DefaultCacheBehavior:
TargetOriginId: MyOriginGroup # ← オリジングループを指定
ViewerProtocolPolicy: redirect-to-https
ℹ️
設定のポイント：DefaultCacheBehavior の TargetOriginId には、個別のオリジンIDではなくオリジングループのIDを指定します。Members の Items は記述順が重要で、1番目がプライマリ、2番目がセカンダリになります。
✅ SUMMARY
まとめ
🏗️
何を作る？
プライマリ＋セカンダリの2つのオリジンを束ねたオリジングループ
🔄
いつ発動？
設定したHTTPエラーコード（500〜504等）をプライマリが返した時
🎯
なぜ使う？
ユーザーに障害を見せず、ダウンタイムゼロを実現するため
💡
試験対策のキーフレーズ：CloudFront のオリジンフェイルオーバーは「オリジングループ」を使って設定する。オリジングループには「プライマリ」と「セカンダリ」の2つのオリジンを含める。フェイルオーバー条件はHTTPステータスコードで指定する。CloudFront ネイティブの機能であり、Route 53 や Lambda@Edge は不要。