画面に大きく「504」と出ると、まずWi-Fiやスマホ回線を疑いたくなります。けれど、同じ時間に複数のサイトやアプリが重いなら、自分の端末だけで判断しない方が早く整理できます。
2026年7月16日、Amazon CloudFrontで障害が確認され、CloudFront customers utilizing VPC Origins connectivityで5xx errorsが増えていることがAWS Health Dashboardで示されました。GIGAZINEも同日、日本時間16時45分頃からCloudFrontで問題が発生し、各種Webサイトで接続しにくい状態が出ていると報じています。
ここで大事なのは、「AWSが止まったらしい」で終わらせないことです。CloudFront、VPC Origins、サービス個別のステータス、利用者側の通信状態は別々に確認する必要があります。順番を持っておけば、次に同じ504を見た時に、原因探しで時間を失いにくくなります。
CloudFront障害で何が起きたか
Amazon CloudFrontは、Webサイトやアプリのコンテンツをユーザーに近い場所から配信するCDNです。多くのサービスは、ユーザーのブラウザやアプリから直接本体サーバーへ行くのではなく、CDNを通って画像、HTML、API応答などを受け取ります。
今回の焦点になったVPC Originsは、AWS公式ドキュメントでは、VPCのprivate subnetsにあるApplication Load Balancer、Network Load Balancer、EC2 instanceをCloudFrontのoriginとして使う仕組みとして説明されています。originを外部に直接さらさず、CloudFrontを入口にしやすい設計です。
そのため、VPC Origins connectivityで問題が起きると、利用者からは「サイトが壊れた」「ログインできない」「504が出る」と見えても、実際にはサービス本体、CDN、origin接続のどこで詰まっているのかを分ける必要があります。
まず押さえたいのは、5xxや504は「利用者のスマホが必ず悪い」という意味ではないことです。ブラウザ再読み込みや回線切り替えで直ることもありますが、広い範囲で同時に起きているなら、公式ステータスを見る方が確実です。
504が出た時に最初に見る公式情報
最初に見る場所は、利用しているサービスの公式お知らせです。予約、決済、動画、行政手続き、ECサイトなどは、それぞれ独自の障害情報ページ、アプリ通知、公式X、ヘルプページを持っていることがあります。
次に、基盤側の公式ステータスを見ます。今回のようにAWSが関係する可能性がある場合は、AWS Health DashboardのService healthで、対象サービス、開始時刻、影響範囲、更新履歴を確認します。CloudFrontと書かれていても、すべてのCloudFront利用サイトが同じ影響を受けるとは限りません。
3つ目は、自分側の切り分けです。同じサイトをモバイル回線と固定回線で試す、別ブラウザで開く、公式アプリのお知らせを見る、同じサービスのステータスページを直接開く。ここまでで、少なくとも「自分の端末だけ」「サービス個別」「クラウド基盤」のどれに近いかが見えてきます。
SNS検索は最後で十分です。早い反応は役に立つことがありますが、原因の断定、影響範囲、復旧見込みは公式情報で確認し直す必要があります。
VPC Originsの影響は「全サイト停止」とどう違うか
VPC Originsという言葉が出ると難しく見えますが、利用者向けには「サービス本体の手前にあるprivate originへの接続」と考えると分かりやすくなります。CloudFrontが入口になり、裏側のALB、NLB、EC2などへつなぐ構成です。
この構成は、originをインターネットに直接公開しにくくする利点があります。AWS公式ドキュメントも、CloudFrontをsingle point of entryにし、originへprivateでsecureな接続を通す設計を説明しています。
一方で、障害時の見え方は単純ではありません。同じCloudFrontでも、VPC Originsを使っているサービス、通常のorigin構成のサービス、キャッシュで一部表示できるページ、ログインや決済のようにorigin応答が必要な機能では影響が違います。
そのため、「あのサイトは開けるのに、このサイトは504」という状態は不自然ではありません。利用者は、開けるサービス名を根拠に「障害ではない」と決めつけず、対象サービスの公式情報を見る必要があります。
利用者と小規模事業者が残す代替導線
利用者ができることは多くありませんが、確認順を決めておくだけでも混乱は減ります。急ぎの予約、支払い、行政手続き、チケット表示、配送確認などは、公式アプリ、メール、電話窓口、店舗窓口、紙の控えなど、代替経路があるかを先に見ます。
小規模事業者は、さらに準備が必要です。Web予約が止まった時の電話受付、決済が不安定な時の案内、問い合わせフォームが使えない時のメール、SNS告知の文面、復旧後にどの管理画面を照合するかを決めておきます。
重要なのは、障害中に原因を断定しない案内です。「現在、外部サービスまたは通信経路の影響を確認しています」「公式情報を確認し、復旧まで代替窓口で受け付けます」のように、事実と対応を分けると誤案内を避けやすくなります。
前日のカード決済障害と同じく、外部基盤が止まる時は、現場の説明が雑になりやすい場面です。サービス名や原因より先に、利用者が次に取れる行動を示す方が役に立ちます。
次に同じ障害が起きた時の確認メモ
同じような504や5xxが出た時は、次の順に見ます。
1つ目は、利用中サービスの公式障害情報です。ログイン、決済、予約、動画、行政手続きなど、機能ごとに影響が違う場合があります。
2つ目は、基盤側の公式ステータスです。AWS Health Dashboard、各クラウドのService Health、CDNや決済基盤のstatus pageを確認し、対象サービス名、対象リージョン、開始時刻、更新時刻を見ます。
3つ目は、自分側の最低限の確認です。回線切り替え、別端末、公式アプリ、ブラウザの再読み込み、時間を置いた再試行を行います。ただし、何度も送信すると二重申込や二重決済につながる場面では、公式案内を優先します。
4つ目は、復旧後の照合です。予約番号、購入履歴、支払い履歴、問い合わせ送信履歴、メール通知を確認し、失敗に見えた操作が後から成立していないかを見ます。
CloudFrontのような基盤障害は、利用者にとっては見えにくい場所で起きます。だからこそ、障害名を覚えるより、公式情報の読み順を持っておく方が、次のトラブルに強くなります。
