--- title: "CloudFront障害の確認方法と備え：2026年7月のVPCオリジン障害から学ぶ設計" url: "https://www.issoh.co.jp/tech/details/17826/" published: 2026-09-25 updated: 2026-10-03 categories: ["AWS"] publisher: "株式会社一創" --- # CloudFront障害の確認方法と備え：2026年7月のVPCオリジン障害から学ぶ設計 2026年7月16日の夕方、Amazon CloudFrontでVPCオリジンを使う配信に5xxエラーが集中し、PayPayやニコニコ生放送、マイナポータルが数時間つながりにくくなりました。CloudFrontの障害は、自社のオリジン障害と見分けがつきにくく、初動の判断を誤りやすい種類の障害です。この記事では、7月の障害の経緯を押さえたうえで、CloudFront側の障害か自社側の障害かを切り分けるコマンド、5xxエラー率とAWS Healthイベントの通知設定、オリジンフェイルオーバーとstale-if-errorを使った備えまで扱います。数値と仕様は2026年9月時点の公式ドキュメントで確認したものです。 ## まとめ：CloudFront障害で最初に確認する場所と設計で備える要点 CloudFrontの障害を疑ったら、最初に見るのはAWS Health Dashboardと、自分のディストリビューションのレスポンスヘッダです。x-cache が「Error from cloudfront」でステータスが502なら、原因はCloudFrontとオリジンの間の接続にあります。自社オリジンの証明書やポートの問題も同じ表示になるため、Health Dashboardに発表が無ければ自社側から疑うのが順序です。 7月16日の障害は影響がVPCオリジン接続に限られ、S3などほかのオリジン種別は無傷でした。AWSが案内した回避策は「オリジン種別の一時変更」です。VPCオリジンは作成から配置完了まで最大15分かかるため、切り替え先を障害中に作っていては間に合いません。 監視は2本立てにします。無料で1分粒度の5xxエラー率にCloudWatchアラームを掛け、AWS Healthのイベントを us-east-1 のEventBridgeで受けます。どちらもメトリクスやイベントの置き場所が us-east-1 に固定されている点が、最初の設定でつまずく箇所です。 設計での備えは、静的コンテンツなら Cache-Control の stale-if-error だけで効果があります。動的なアプリケーションはオリジングループで待機系へ逃がしますが、フェイルオーバーするのはGET・HEAD・OPTIONSだけで、決済や登録のPOSTは救えません。 ## 2026年7月16日のCloudFront障害で起きたことと影響の範囲 AWSの公表文と各社の障害告知を[時系列で集計した記録](https://piyolog.hatenadiary.jp/entry/2026/07/17/142812)をもとに、何が起き、どこまで影響したかを整理します。時刻はすべて日本時間です。 ### VPCオリジン接続だけで5xxが増えた約4時間半のタイムライン | 時刻 | 出来事 | | ------------ | ------------------------- | | 16:45頃 | VPCオリジン接続で5xxエラーが増え始める | | 16:54〜17:30頃 | PayPay・マイナポータル等で障害が表面化 | | 17:44頃 | AWSが調査中と発表 | | 18:21頃 | AWSが影響範囲を特定し回避策を案内 | | 20:16頃 | AWSがルーティングテーブル容量に関わる原因を特定 | | 21:21頃 | AWSが完全復旧を宣言 | エラーの増加から復旧宣言まで4時間36分です。AWSの第一報は発生から約1時間後で、利用者側の障害告知のほうが先に出ています。Health Dashboardの発表を待ってから動く運用では、最初の1時間を失う計算になります。 ### ルーティング設定の配信失敗が原因で回避策がオリジン種別の変更だった理由 AWSの説明によると、VPCオリジンへの接続を管理するフリートが内部的な上限に達し、ネットワークプロセッサへルーティング設定を配るシステムが更新済みの設定を正しく読み込めなくなりました。壊れたのはVPCオリジン専用の接続経路で、CloudFrontのエッジそのものではありません。S3やインターネット向けALBをオリジンにしていた配信が無傷だったのはこのためです。 回避策が「オリジン種別を一時的に変える」だったのも同じ理屈で、壊れた経路を通らないオリジンへ付け替えれば配信は戻ります。ただし付け替え先のインターネット向けALBを持っていなければ、この回避策は実行できません。なお2026年9月25日時点で、[AWSのPost-Event Summary一覧](https://aws.amazon.com/premiumsupport/technology/pes/)の最新は2025年10月19日のDynamoDBで、7月のCloudFront障害の詳細報告は掲載されていません。 ## CloudFront側の障害か自社オリジンの障害かを切り分ける確認手順 CloudFrontが返す5xxには、CloudFront自身の障害と、オリジンの不調をCloudFrontが中継したものが混ざります。切り分けで確認する順序は、「AWSの発表」「レスポンスヘッダ」「ステータスコードごとの原因」です。AWS全体の障害確認の方法は[AWS障害の確認方法と原因・対策](https://www.issoh.co.jp/tech/details/9464/)で扱っているため、ここではCloudFront固有の見方に絞ります。 ### Health Dashboardと公開RSSでCloudFrontの発表を確かめる手順 [AWS Health Dashboard](https://health.aws.amazon.com/health/status)では、CloudFrontはリージョン単位ではなくグローバルなサービスとして扱われます。公開RSSも、EC2の東京リージョンが ec2-ap-northeast-1.rss のようにリージョン名付きなのに対し、CloudFrontはリージョン名の無い cloudfront.rss です。東京リージョンで絞り込んで眺めていると見落とします。監視ツールに組み込むなら、[CloudFrontの公開RSS](https://status.aws.amazon.com/rss/cloudfront.rss)を1分間隔で取得し、新しい item が増えたら通知する形が手軽です。 ### curlのレスポンスヘッダでx-cacheとエッジ拠点を読む切り分け CloudFrontのレスポンスには、キャッシュの結果を示す x-cache、応答したエッジ拠点を示す x-amz-cf-pop、リクエストを一意に識別する x-amz-cf-id が付きます。障害時はこの3つとステータス行を数秒おきに記録します。 ``` # CloudFront経由の応答を5回記録する（ステータス・キャッシュ結果・エッジ拠点・リクエストID） URL=https://www.example.com/ for i in 1 2 3 4 5; do date '+%H:%M:%S' curl -s -o /dev/null -D - "$URL" \ | grep -i -E '^(HTTP/|x-cache|x-amz-cf-pop|x-amz-cf-id)' sleep 3 done # オリジンがインターネット向けなら、CloudFrontを通さずに直接たたいて比べる curl -s -o /dev/null -w '%{http_code}\n' \ -H 'Host: www.example.com' https://origin.example.com/health ``` x-cache が「Hit from cloudfront」ならキャッシュから返っており、オリジンの状態とは無関係です。「Error from cloudfront」はCloudFrontがオリジンから正常な応答を得られなかったことを示します。オリジン直のリクエストが200を返すのにCloudFront経由だけが5xxなら、疑うべき箇所はCloudFrontとオリジンの間の経路です。VPCオリジンは外部から直接たたけないため、同じVPC内の踏み台からALBの内部DNS名へ投げて比べます。サポートへ問い合わせるときは x-amz-cf-id の値を添えると調査が早く進みます。 ### 502・503・504のステータスごとに疑う原因と確認先の対応表 | ステータス | まず疑う原因 | 確認先 | | ------------------------ | -------------------- | -------------------------- | | 502 | オリジン証明書の名前不一致・期限切れ | openssl s\_client でオリジンへ接続 | | 502（NonS3OriginDnsError） | オリジンのDNS解決失敗 | dig でオリジンの権威サーバーを確認 | | 503 | オリジンの処理能力不足・関数の実行エラー | ALBのターゲット状態とLambdaのログ | | 503（まれ） | エッジ拠点側のリソース制約 | 負荷試験中でなければAWSサポート | | 504 | オリジンの応答が既定30秒を超過 | オリジンの処理時間とタイムアウト設定 | 502の原因は[公式の502トラブルシューティング](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html)に9項目が並びますが、実務で多いのは証明書です。オリジン側で証明書を更新した直後に502が出たら、中間証明書を含むチェーンが揃っているかを最初に見ます。503については[公式の503トラブルシューティング](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-503-service-unavailable.html)が、エッジ側の制約による503は負荷試験で起きやすいと明記しています。本番でこれが続くなら、自社側で打てる手はほぼありません。 ## CloudFrontの5xxエラー率とAWS Healthイベントを通知する監視設定 障害に気づく速さは、監視をどこに置くかで決まります。CloudFrontの監視は、自分のディストリビューションの症状を見るメトリクスと、AWSの公式発表を受けるイベントの2系統で組みます。 ### 5xxエラー率のCloudWatchアラームをus-east-1に作る手順 [CloudFrontのメトリクス](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html)のうち、リクエスト数・4xxエラー率・5xxエラー率などは追加料金なしで1分粒度で出ています。CloudWatchでグラフやアラームを扱うにはバージニア北部（us-east-1）を選ぶ必要があります。 ``` # 5xxエラー率が5分中3分で5%を超えたらSNSへ通知する（SNSトピックもus-east-1に置く） DIST_ID=EDFDVBD6EXAMPLE aws cloudwatch put-metric-alarm --region us-east-1 \ --alarm-name "cf-${DIST_ID}-5xx-rate" \ --namespace AWS/CloudFront --metric-name 5xxErrorRate \ --dimensions Name=DistributionId,Value=$DIST_ID Name=Region,Value=Global \ --statistic Average --period 60 \ --evaluation-periods 5 --datapoints-to-alarm 3 \ --threshold 5 --comparison-operator GreaterThanThreshold \ --treat-missing-data notBreaching \ --alarm-actions arn:aws:sns:us-east-1:111122223333:ops-alert ``` 5分中3分という条件にしているのは、単発のスパイクで夜間に呼び出されないためです。502・503・504を個別に見たい場合は追加メトリクスを有効にします。追加メトリクスはディストリビューションごとに最大8本がus-east-1へ送られ、1本ごとの月額固定で課金されます。障害の種類を区別したい本番のディストリビューションにだけ有効にするのが妥当です。 ### AWS HealthのCloudFrontイベントをEventBridgeで受ける設定 AWS Healthのイベントは、アカウント固有のイベントと、Health Dashboardに載る公開イベントの2種類がEventBridgeに届きます。[公式ドキュメント](https://docs.aws.amazon.com/health/latest/ug/about-public-events.html)は、両方を受けるには source を “aws.health” と完全一致で書く必要があり、ワイルドカードでは一致しないと明記しています。リージョンを持たないグローバルイベントは[us-east-1にルールを作らなければ受け取れません](https://docs.aws.amazon.com/health/latest/ug/choosing-a-region.html)。CloudFrontはリージョンを持たないサービスなので、ルールは us-east-1 に置きます。 ``` # CloudFrontに関するAWS Healthの障害イベントをSNSへ流す aws events put-rule --region us-east-1 \ --name health-cloudfront-issue \ --event-pattern '{ "source": ["aws.health"], "detail-type": ["AWS Health Event"], "detail": { "service": ["CLOUDFRONT"], "eventTypeCategory": ["issue"] } }' aws events put-targets --region us-east-1 \ --rule health-cloudfront-issue \ --targets Id=ops-sns,Arn=arn:aws:sns:us-east-1:111122223333:ops-alert ``` 公式のサンプルでは service の値が EC2 や ELASTICLOADBALANCING のように大文字で入っています。CLOUDFRONT という値は同じ規則に従って書いたものなので、最初は service の条件を外したルールで実際のイベントを受け、値を確かめてから絞り込むと確実です。SNSトピックのアクセスポリシーで events.amazonaws.com からの発行を許可しておかないと、ルールが一致しても通知は届きません。公開イベントはルール作成から配信開始まで最大1時間かかることがあるため、障害が起きてから作るのでは遅れます。 ## オリジン障害に備えるオリジンフェイルオーバーとエラー応答の設計 CloudFrontには、オリジンが不調のときに別の応答を返す仕組みがあります。効く範囲が違うため、コンテンツの性質で使い分けます。 ### オリジングループの失敗判定コードと既定30秒のタイムアウト短縮 [オリジンフェイルオーバー](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high%5Favailability%5Forigin%5Ffailover.html)は、プライマリとセカンダリの2つのオリジンをオリジングループにまとめ、プライマリが指定したステータスを返したときにセカンダリへ再送する仕組みです。失敗として指定できるのは400・403・404・416・429・500・502・503・504で、接続失敗は503、タイムアウトは504を指定したときに切り替えの対象になります。 ``` "OriginGroups": { "Quantity": 1, "Items": [{ "Id": "app-failover", "FailoverCriteria": { "StatusCodes": { "Quantity": 4, "Items": [500, 502, 503, 504] } }, "Members": { "Quantity": 2, "Items": [ { "OriginId": "alb-vpc-origin" }, { "OriginId": "alb-public-standby" } ] } }] } ``` この断片を aws cloudfront get-distribution-config で取得した設定に差し込み、キャッシュビヘイビアの TargetOriginId をグループのIDに変えてから、ETagを付けて update-distribution で反映します。既定の設定では、CloudFrontがプライマリへの接続を10秒×3回、最長30秒試してから切り替える仕組みです。接続タイムアウトは1〜10秒、接続試行回数は1〜3回で指定でき、3秒×1回にすれば切り替えまでの待ちは3秒前後に縮まります。 制約は3つあります。切り替えはリクエスト単位で、直前のリクエストがセカンダリへ逃げても次のリクエストはまたプライマリから試します。切り替わるのはGET・HEAD・OPTIONSだけで、POSTやPUTは切り替わりません。定額料金プランで使う場合はPremiumが必要で、Free・Pro・Businessではオリジンの自動フェイルオーバーを使えません（[定額料金プランの公式ドキュメント](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html)）。階層ごとの金額は[CloudFrontの料金を実額で計算する記事](https://www.issoh.co.jp/tech/details/17751/)で整理しています。 ### stale-if-errorとエラーキャッシュ既定10秒で静的配信を守る設定 静的なページや画像は、フェイルオーバーより先にキャッシュで守るほうが安上がりです。CloudFrontは Cache-Control の [stale-if-error ディレクティブ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html)に対応しており、オリジンに到達できないときや500番台を返したときに、期限切れのキャッシュを返し続けます。 ``` # オリジンが返すレスポンスヘッダの例 # 1時間はキャッシュし、期限切れ後にオリジンが落ちていれば最大24時間は古い版を返す Cache-Control: max-age=3600, stale-if-error=86400 ``` 古い版を返せる期間は、stale-if-error の値とキャッシュビヘイビアの最大TTLの短いほうです。最大TTLを1時間にしていると、stale-if-error を24時間にしても1時間で切れます。 エラー応答そのものは、[既定で10秒キャッシュ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages-expiration.html)されます。この値を0に近づけると、落ちているオリジンへのリクエストが増えて復旧を遅らせます。逆に長くすると、復旧後もエラーページが出続けることになるため注意が必要です。5xxは10〜30秒の範囲に置き、カスタムエラーページは障害の起きたオリジンとは別のS3バケットに置きます。S3を非公開のまま配信する構成は[CloudFront OACの設定手順](https://www.issoh.co.jp/tech/details/3684/)で扱っています。独自ドメインとデプロイまで含めた構築の全手順は[CloudFrontとS3で静的サイトを公開する手順](https://www.issoh.co.jp/tech/details/18064/)にまとめています。 ## VPCオリジン構成で障害時の切り替え先を平時に用意する設計判断 7月の障害で止まったのは、VPCオリジンという比較的新しい接続方式を採用していた配信でした。VPCオリジンは、ALBやEC2をプライベートサブネットに置いたままCloudFrontから公開できる方式です（構築手順は[CloudFront VPCオリジンとは](https://www.issoh.co.jp/tech/details/4767/)で解説）。オリジンを外部に晒さない利点と引き換えに、CloudFront側の専用経路に依存する構成になります。 ### VPCオリジンの作成に最大15分かかるため待機系は平時に作る [公式ドキュメント](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)によると、VPCオリジンは作成してから状態が Deployed になるまで最大15分かかります。既存のVPCオリジンを更新する場合に必要なのは、ディストリビューションから一度外し、編集し、再び関連付ける手順です。作成だけで最大15分、そこへディストリビューションの設定変更がエッジへ行き渡る待ち時間が加わるため、障害が起きてから始める作業としては遅すぎます。 7月のような回避策を即座に実行できるのは、インターネット向けのALBと、それを指すオリジン定義を事前に持っている構成に限られます。待機系のオリジンは、ディストリビューションにオリジンとして登録しておき、キャッシュビヘイビアからは参照しない状態で置いておくのが基本形です。切り替えはビヘイビアの TargetOriginId を書き換えるだけになり、手順書の1行で済みます。 ### インターネット向けの待機ALBとオリジン非公開方針を両立させる条件 待機用のALBをインターネット向けに置くと、VPCオリジンを採用した「オリジンを外部に晒さない」という目的と衝突します。両立させる条件は2つです。1つ目は、待機ALBのセキュリティグループでインバウンドをCloudFrontのマネージドプレフィックスリスト（com.amazonaws.global.cloudfront.origin-facing）に限ること。2つ目は、CloudFrontのオリジン設定で秘密のカスタムヘッダを付け、ALBのリスナールールでそのヘッダが無いリクエストを403で落とすことです。 プレフィックスリストだけでは、他人のCloudFrontディストリビューションからのアクセスを防げません。ヘッダの照合まで入れて初めて、待機中のALBを実質的に自社のCloudFront専用にできます。なお、オリジングループでVPCオリジンをプライマリに置いた場合、7月のようなVPCオリジン基盤側のエラーがフェイルオーバーの条件に該当するかは公式に記載がありません。自動切り替えに頼らず、手動で付け替える手順も併せて持っておくのが確実です。 ## CloudFront障害への対策に投資すべき構成と見送ってよい構成の基準 ここまでの対策を全部入れると、待機ALBの維持費と切り替え訓練の工数がかかります。投資の要否は、配信が止まったときに何が失われるかで決めます。 ### 待機系と切り替え訓練まで用意すべき条件と過剰投資になる配信の規模 待機系を持つべきなのは、決済・ログイン・予約・行政手続きのように、止まった時間がそのまま売上の喪失や利用者の手続き不能につながる配信です。7月の障害で影響が大きかったPayPayやマイナポータルはこの種類でした。この場合は、待機ALB・切り替え手順書・5xxアラーム・Healthイベント通知の4点を揃え、年に1回は検証環境で実際に付け替える訓練を入れます。POSTはオリジングループで救えないため、手動切り替えの手順が本命になります。 見送ってよいのは、S3オリジンのコーポレートサイトやメディアのように、数時間の停止が事業上の損失に直結しない配信です。7月の障害でもS3オリジンは影響を受けていません。stale-if-error とカスタムエラーページだけで十分で、別のCDNを並べる構成は過剰です。複数CDNをDNSで切り替える構成は、TTLの設計とCDNごとの証明書・キャッシュ設定の二重管理が発生し、専任の運用担当がいない体制では障害時に切り替えを失敗させる原因になります。 判断に迷うのは、VPCオリジンを採用した業務システムや会員サイトです。このときの判断基準は、停止を許容できる時間が1時間を切るかどうかです。1時間を切るなら待機系を持ち、1時間以上待てるなら監視と連絡体制の整備に留めます。配信基盤の可用性設計と監視設計は[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)でご相談いただけます。 ## よくある質問 CloudFrontの障害について、検索されることの多い5つの疑問に答えます。仕様は2026年9月時点の公式ドキュメントに基づきます。 ### CloudFrontが今障害中かどうかはどこで確認できますか？ AWS Health Dashboardか、CloudFrontの公開RSS（cloudfront.rss）で確認します。CloudFrontはグローバルなサービスとして扱われるため、東京リージョンで絞り込むと見落とします。2026年7月16日の障害では、エラーの増加からAWSの第一報まで約1時間かかりました。発表を待たず、自分のディストリビューションの5xxエラー率とレスポンスヘッダも同時に見てください。 ### 「Error from cloudfront」と表示されたらCloudFrontの障害ですか？ そうとは限りません。この表示は、CloudFrontがオリジンから正常な応答を得られなかったことを示すだけで、オリジン証明書の期限切れやDNSの解決失敗でも出ます。AWSの発表が無ければ、まずオリジンへ直接接続して応答を確かめるのが順序です。 ### 2026年7月の障害ではS3オリジンも止まりましたか？ 止まっていません。AWSは影響をVPCオリジン接続の利用者に限定しており、S3やインターネット向けALBなど、ほかの種類のオリジンは影響を受けなかったと説明しています。壊れたのはVPCオリジン専用の接続経路です。 ### オリジンフェイルオーバーがあればCloudFront障害にも耐えられますか？ CloudFront自体が応答できない障害には効きません。オリジンフェイルオーバーはCloudFrontの中で動く仕組みで、守れるのはオリジン側の不調です。加えて切り替わるのはGET・HEAD・OPTIONSだけで、POSTを含むAPIは対象外です。CloudFront全体の停止まで想定するなら、DNSで別のCDNや直接配信へ逃がす構成が必要ですが、多くのシステムでは過剰投資になります。 ### CloudFrontの障害でSLAの返金は受けられますか？ [CloudFrontのSLA](https://aws.amazon.com/cloudfront/sla/)は月間稼働率99.9%を約束しており、下回るとサービスクレジットを申請できます。割合は99.0%以上99.9%未満で10%、95.0%以上99.0%未満で25%、95.0%未満で100%です。仮に4時間36分すべての要求が失敗しても、31日の月なら稼働率は約99.4%で10%の段に収まります。クレジットは自動では付かず、発生月の翌々月末までにサポートセンターでエラーを示すログを添えて申請します。定額料金プランで稼働率のSLAが付くのはBusiness以上です。 ## 関連記事 - [Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15431/)：障害の前提となる配信の仕組み - [CloudFront VPCオリジンとは？ALB・EC2をプライベートのまま公開する設定と制約](https://www.issoh.co.jp/tech/details/4767/)：7月の障害で影響を受けた接続方式 - [AWS障害の確認方法と原因・対策｜2025年10月の大規模障害から学ぶ実務ガイド](https://www.issoh.co.jp/tech/details/9464/)：AWS全体の障害確認と過去の大規模障害 - [CloudFrontの料金を実額で計算する：定額プラン4階層と従量課金の分岐点](https://www.issoh.co.jp/tech/details/17751/)：フェイルオーバーとSLAが使える階層 - [CloudFront OAC（オリジンアクセスコントロール）とは？OAIとの違いとS3バケットポリシー設定手順](https://www.issoh.co.jp/tech/details/3684/)：エラーページを置くS3の非公開配信 --- 出典: [CloudFront障害の確認方法と備え：2026年7月のVPCオリジン障害から学ぶ設計]()（株式会社一創）