CloudFront のオリジンフェイルオーバー機能で 2 つの S3 バケットを切り替える構成を試してみた

CloudFront のオリジンフェイルオーバーを利用して、プライマリオリジンの障害時にセカンダリ S3 バケットへ自動で切り替える構成を実装してみました。設定手順と動作確認を紹介します。

2026.07.03

 はじめにテクニカルサポートの 片方 です。
本ブログでは、CloudFront のオリジンフェイルオーバーを利用して、プライマリオリジンで指定したステータスコードが返された場合に、セカンダリオリジンとして設定した S3 バケットへリクエストを切り替える構成を試しました。

構成としては、プライマリ用とセカンダリ用の S3 バケットを用意し、CloudFront のオリジングループに登録します。通常はプライマリオリジンへリクエストされ、プライマリオリジンがフェイルオーバー条件として設定した HTTP ステータスコードを返した場合に、CloudFront がセカンダリオリジンへフェイルオーバーする動作を確認します。
なお、Amazon S3 Standard は高い耐久性と可用性を備えているため、すべての静的サイトで本構成が必須というわけではありません。本ブログでは、CloudFront のオリジンフェイルオーバーの動作理解を目的として検証している点にご注意ください。
!本記事では、検証目的で 2 つの S3 バケットを利用します。

本番運用では、要件に応じて S3 レプリケーションや CI/CD による複数の S3 バケットへの同期も検討してください。

また、プライマリとセカンダリで同じコンテンツを配信する場合は、オブジェクトの同期方法もあわせて設計しておく必要があります。
 前提条件本記事では、以下の構成がすでに作成済みであることを前提とします。
S3 バケットをオリジンとする CloudFront ディストリビューションが作成済み
S3 バケットはパブリックアクセスをブロック済み
CloudFront から S3 へのアクセスには Origin Access Control（OAC）を利用
https://dev.classmethod.jp/articles/s3-cloudfront-acm-route53-https-static-site/
今回は、既存の CloudFront ディストリビューションにセカンダリ用の S3 バケットを追加し、オリジンフェイルオーバーを設定します。

構成イメージは以下です。
CloudFront
  └─ Origin Group
      ├─ Primary Origin: 既存の S3 バケット
      └─ Secondary Origin: 追加する S3 バケット
 CloudFront のオリジンフェイルオーバーについてCloudFront のオリジンフェイルオーバーでは、オリジングループにプライマリオリジンとセカンダリオリジンを設定します。

通常はプライマリオリジンへリクエストされ、プライマリオリジンが指定した HTTP ステータスコードを返した場合に、セカンダリオリジンへリクエストされます。

なお、CloudFront のオリジンフェイルオーバーは、ビューワーリクエストの HTTP メソッドが GET、HEAD、OPTIONS の場合にのみ動作します。静的サイト配信では主に GET、HEAD が対象になります。
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
 設定してみた S3 バケットまず、フェイルオーバー先となるセカンダリ用 S3 バケットを作成します。

既存の S3 バケットと同様に、パブリックアクセスのブロックはすべて有効にします。

次に、セカンダリ用 S3 バケットへ index.html をアップロードします。フェイルオーバー後にセカンダリ側へ切り替わったことを判別しやすいよう、プライマリ側とは表示内容を変えておきます。

なお、セカンダリ用 S3 バケットは、プライマリとは別のリージョンに作成しても問題ありません。
例）
プライマリ用 S3 バケット: ap-northeast-1
セカンダリ用 S3 バケット: ap-northeast-3
今回は、以下のような index.html をセカンダリ用 S3 バケットにアップロードしました。
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Secondary</title>
</head>
<body>
    <h1>Hello from Secondary S3</h1>
</body>
</html>
 CloudFront にセカンダリオリジンを追加する続いて、CloudFront の対象ディストリビューションを開き、セカンダリ用 S3 バケットをオリジンとして追加します。

オリジンタイプは S3 を選択し、OAC を利用します。

セカンダリ用 S3 バケットには、CloudFront ディストリビューションからの読み取りアクセスのみを許可するバケットポリシーを設定します。
以下はバケットポリシーの例です。
{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "AllowCloudFrontServicePrincipalReadOnly",
        "Effect": "Allow",
        "Principal": {
            "Service": "cloudfront.amazonaws.com"
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-SECONDARY-BUCKET/*",
        "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
            }
        }
    }
}
!実際の環境では、ご自身の S3 バケット名、AWS アカウント ID、CloudFront ディストリビューション ID に置き換えてください。
Origin domain には、先ほど作成した S3 バケットを指定します。

Origin access control では、既存の OAC を利用するか、必要に応じて Create new OAC をクリックして新規作成します。
 オリジングループを作成するその後、CloudFront でオリジングループを作成します。

プライマリオリジンには既存の S3 オリジン、セカンダリオリジンには追加した S3 オリジンを指定します。

フェイルオーバー条件は、今回は検証しやすいように以下を選択しました。
403
500
502
503
504
!検証目的で 403 をフェイルオーバー条件に含めています。

本番環境では、403 をフェイルオーバー条件に含めるかどうかは要件に応じて慎重に判断してください。
403 を含めると、バケットポリシーや OAC の設定不備など、本来検知すべき問題をフェイルオーバーによって解らなくなる可能性があります。
以降の一部スクリーンショットでは、検証環境の都合により別のディストリビューションを使用しています。設定内容は同じです。

オリジングループを作成したら、デフォルトビヘイビアの向き先を変更します。
Behaviors タブを開き、デフォルトビヘイビアを編集します。
Origin and origin groups で、先ほど作成したオリジングループを選択します。
変更前は既存の S3 オリジンを直接指定していましたが、変更後はオリジングループを指定します。
これで、CloudFront のオリジンフェイルオーバー設定は完了です。
 確認してみた今回は検証のため、プライマリ用 S3 バケットのバケットポリシーを一時的に変更し、CloudFront からプライマリオリジンへアクセスできない状態にします。

これにより、プライマリオリジンが 403 を返す状態を意図的に作り、CloudFront がセカンダリオリジンへフェイルオーバーすることを確認します。
!この操作は検証目的です。

確認後は、必ずプライマリ用 S3 バケットのバケットポリシーを元に戻してください。
プライマリ用 S3 バケットのバケットポリシーを一時的に削除するか、Resource のバケット名を存在しない名前に変更します。
設定変更後、CloudFront のキャッシュが残っている場合は、対象パスのキャッシュを無効化します。

今回は検証のため、以下のパスを指定してキャッシュを無効化します。
/*
!本番環境では、必要なパスに限定してキャッシュを無効化することを推奨します。
キャッシュ無効化のステータスが Completed または「完了」になったら、再度、独自ドメインにアクセスします。
セカンダリ用 S3 バケットのコンテンツが表示され、CloudFront のオリジンフェイルオーバーが動作することを確認できました。成功です！
 検証後の戻し作業検証後は、プライマリ用 S3 バケットのバケットポリシーを元に戻します。

その後、必要に応じて CloudFront のキャッシュを無効化し、プライマリ側のコンテンツが再度表示されることを確認してください。
 まとめCloudFront のオリジンフェイルオーバーを利用し、プライマリ用 S3 バケットで 403 が返された場合に、セカンダリ用 S3 バケットへフェイルオーバーする動作を確認しました。

本番環境で利用する場合は、以下の点をあわせて検討することをおすすめします。
フェイルオーバー条件に含める HTTP ステータスコード
403 をフェイルオーバー条件に含めるかどうか
プライマリ用 S3 バケットとセカンダリ用 S3 バケット間のオブジェクト同期方法
CloudFront のキャッシュ設計
障害時と復旧時の運用手順
本ブログが誰かの参考になれば幸いです。
 参考資料S3 + CloudFront + ACM + Route53 を利用して独自ドメインの静的サイトを HTTPS 配信してみた | DevelopersIO
CloudFront オリジンフェイルオーバーを使用して高可用性を最適化する - Amazon CloudFront
Amazon CloudFront を活用したウェブサイトの可用性向上 | Amazon Web Services ブログ
 クラスメソッドオペレーションズ株式会社についてクラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました

CloudFront のオリジンフェイルオーバー機能で 2 つの S3 バケットを切り替える構成を試してみた

はじめに

前提条件

CloudFront のオリジンフェイルオーバーについて

設定してみた

S3 バケット

CloudFront にセカンダリオリジンを追加する

オリジングループを作成する

確認してみた

検証後の戻し作業

まとめ

参考資料

クラスメソッドオペレーションズ株式会社について

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS