はじめに
2026年7月16日の夕方、PayPayが使いにくくなりました。note、ニコニコ生放送、はてなブログでも、同じ時間帯に接続しにくい状態が発生しました。この時間帯、AWSではCDNサービス「Amazon CloudFront」のVPC Originsを利用する配信に障害が発生していました。
この障害を追いかけていて強く感じたのは、「単なるAWSの障害ニュースとして消費して終わらせるにはもったいない」ということです。今回問題が起きたのは、よりによって「セキュリティを高めるための機能」でした。安全にするために入れた仕組みが、サービスを止める側に回った。ここには、クラウドで基盤を設計するすべての人にとっての教材が詰まっています。
本記事では、公開情報を整理したうえで、この障害から設計者が持ち帰るべき学びを3つに絞って解説します。事実として確認できていることと、現時点では分かっていないことを明確に分けて記載します。障害対応で避けなければならないのは、推測を事実として扱うことです。誤った前提で調査や判断が進めば、真の原因から遠ざかるだけでなく、対応に当たる現場を混乱させます。根拠のない断定や、事実と推測が混在した説明に接したときは、情報の出典と確度を確認する必要があります。
1. 何が起きたのか（事実の整理）
まず確定している事実からです。
AWSの公表によると、障害は日本時間の7月16日16時45分から20時18分まで続きました。影響を受けたのは、CloudFrontの「VPC Origins」という接続機能を利用している配信で、5xxエラー（504 Gateway Timeoutを含む）が増加しました。AWSの公表では、S3やパブリックALBといった他のオリジンタイプを利用する配信には影響がなかったとされています。障害中にAWSが案内した回避策も「VPC Originsを使わない構成に変更すればエラーを回避できる」というものでした。障害はVPC Origins固有の経路に局在していた。ここが本記事の出発点になります。
原因についても、AWSは障害終息後の終報で概要を公表しています。VPC Originsへの接続を管理する内部フリートが内部的な制約（constraint）に達し、ルーティング設定をネットワークプロセッサへ配布するシステムが、更新された設定データを正しく読み込めなくなった。この結果、VPC Origin接続のルーティングに影響が生じた、という説明です。サイバー攻撃を示唆する情報は出ておらず、公表内容を見る限り、外部からの攻撃ではなくAWS内部の接続管理とルーティング設定配布に関する問題として整理できます。
ただし、まだ分かっていないこともあります。なぜその制約に達したのか、到達を事前に検知・抑制できなかったのはなぜか、再発防止として何をするのか。ここは公表されていません。より詳細なPost-Event Summaryが公開された場合は、本記事にも追記します。
国内サービスへの影響も見ておきます。PayPayの公表では、16時55分ごろから影響が発生し、一部の支払いは18時30分ごろまで、サービスサイトの一部は19時35分ごろまで、アプリの一部機能は20時15分ごろまで利用できない場合がありました。
機能ごとに影響と復旧の時刻が分かれている点は、後半の縮退の話につながるので覚えておいてください。なお、PayPayが公表したのは「利用しているAWSの障害」という事実までで、VPC Originsを利用していたと構成まで明かしたわけではありません。AWS側の障害対象がVPC Origins利用者に限定されていたことから、関係は強く推定されますが、あくまで推定です。マイナポータルでも同時間帯に、利用中のクラウドサービスを原因とするログイン障害が発生しましたが、公式発表ではCloudFrontやVPC Originsまでは特定されていません。
2. VPC Originsとは何か――なぜ「良い機能」なのか
学びに入る前に、VPC Originsがどういう機能なのかを押さえておきます。ここを理解しないと、今回の障害の皮肉さが伝わらないからです。
図のとおり、VPC OriginsはCloudFrontからVPC内のプライベートオリジンへ直接接続する仕組みです。internal ALBやNLB、EC2などをインターネットへ直接公開せず、利用者からのアクセスをCloudFront経由に集約できます。
CloudFrontの背後に置くオリジン（ALB、NLB、EC2など）は、従来はインターネットから到達可能な場所に置く必要がありました。オリジンを直接利用されないようにするには、CloudFrontのAWS管理プレフィックスリストでセキュリティグループを制限し、CloudFrontから付与する秘密のカスタムヘッダーをALBのリスナールールで検証する、といったアクセス制御を利用者側で設計する必要があった。設計書に「CloudFront経由以外のアクセスを遮断する方式」という一節を書いた経験のある方なら、この面倒さはよくご存じだと思います。
VPC Originsは、この問題を機能として解決しました。CloudFrontからVPC内のプライベートサブネットにあるオリジンへ直接接続できる。オリジンをインターネットに一切公開しなくてよくなり、攻撃面は縮小し、利用者側のアクセス制御設計も簡素になります。内部的にはCloudFrontがサービス管理のENI（Elastic Network Interface）やセキュリティグループを作成・管理し、VPC内のオリジンへのプライベートな接続経路を維持する仕組みです。2024年11月に一般提供が始まりました。
セキュリティ設計の観点では、文句なしに筋の良い機能です。私が今、CloudFront配下にALBを置く構成を設計するなら、VPC Originsは第一候補に挙げます。それは今回の障害を踏まえても変わりません。問題は「使うかどうか」ではなく、「使うと決めたときに何を一緒に設計するか」です。
3. 学びその1：機能の採用判断に「壊れ方」の評価を含める
今回の障害で最も示唆的なのは、影響がVPC Origins利用者に限定されたという事実です。これは裏を返せば、機能を一つ採用するということは、その機能を支える見えない仕組みへの依存を一つ増やすということを意味します。
今回の原因はまさにその「見えない仕組み」で起きました。接続を管理する内部フリートの内部的な制約、ルーティング設定の配布システム。いずれも利用者からは見えず、触れず、監視もできない層です。マネージドの価値は、利用者がこれらを意識せずに済むことにあります。意識せずに済むことと、依存していないことは別です。今回はその見えない部分が不調になり、機能を使っている配信で5xxエラーが一斉に増加しました。
現場の設計レビューで長年感じてきたのは、機能採用の判断材料が「何ができるか」に偏りがちだということです。比較表にはメリット、デメリットなど制約事項が並びます。ただ、「この機能が壊れたとき、システムはどう見えるか。切り分けはできるか。逃げ道はあるか」という壊れ方の評価が載っている設計書は、ほとんど見たことがありません。
VPC Originsは2024年11月に一般提供された、CloudFrontの中では比較的新しい機能です。新しい機能が危険だという意味ではありません。長く使われてきた構成と比べれば、利用者側が参照できる大規模障害の事例や運用知見の蓄積はまだ少ない。採用するなら、実績の量だけでなく、障害時に切り替えられるか、どこが共通障害点になるかを、設計の段階で明示的に評価しておく必要があります。それが基盤設計者の仕事だと思っています。
4. 学びその2：「逃げ道」は、設計してあるものしか使えない
AWSが案内した回避策をもう一度見てください。「VPC Originsを使わない構成に変更すればエラーを回避できる」。
一行で書けば簡単そうに見えます。では、障害の渦中にこれを実行できた利用者がどれだけいたでしょうか。
AWSの回避策を障害中に実行できるか
VPC Originsを前提に設計されたシステムでは、オリジンはプライベートサブネットの中にいます。パブリックオリジンに切り替えるには、オリジンをインターネットから到達可能にする必要がある。internal構成のALBならinternet-facingのALBを別に用意するか作り直すかが要る。セキュリティグループの変更、CloudFront経由に限定するためのカスタムヘッダー検証の復元、配信設定の変更。VPC Originsが「不要にしてくれた」設計要素を、障害対応の最中に、ぶっつけ本番で組み上げることになります。夕方のピーク帯、決済が滞っている状況で、これをノーミスでやり切れる組織は多くないはずです。
Origin GroupではPOST系の処理を救えない
事前の備えとしてよく挙がるのが、CloudFrontのOrigin Groupによるオリジンフェイルオーバーです。プライマリへの接続失敗やタイムアウト、フェイルオーバー条件として設定したHTTPステータスコードの応答が発生した場合、CloudFrontはセカンダリオリジンへリクエストを切り替えます。
ここに見落とされがちな制約があります。フェイルオーバーの対象はGET、HEAD、OPTIONSリクエストに限られ、POSTやPUTは対象外です。決済、ログイン、送金、チャージといった更新系の処理は通常POSTを使います。要するに、Origin GroupはWebページや画像の配信、読み取り専用API、静的な障害案内ページの継続には有効でも、POSTを使う決済実行や送金といった更新トランザクションをフェイルオーバーする仕組みにはなりません。加えて、セカンダリもVPC Originにしてしまえば、今回のようなVPC Origins共通基盤の障害では両方が同時に倒れます。
逃げ道は処理の性質ごとに分けて設計する
この制約を踏まえると、逃げ道は処理の性質で分けて設計することになります。静的コンテンツや障害案内ページは、S3などをセカンダリに置いたOrigin Groupで配信を継続できます。動的な参照系APIには、VPC Originsとは別の経路で到達できるパブリックオリジンなどを用意する方法があります。
更新系はCloudFront層では救えない以上、別の公開エンドポイントやクライアント側での接続先切替を用意したうえで、代替経路で受け付けた処理をキューへ退避する方式、端末内に処理を保持して復旧後に再送する方式など、アプリケーション層まで含めた縮退設計が必要になります。キューイングも、受付口が同じ経路の先にあるならリクエスト自体が届かず機能しません。CDNのフェイルオーバー機能を設定して安心する、では決済系の可用性対策として不十分だということです。
なお、セカンダリとしてinternet-facingのオリジンを平時から維持する場合、ネットワーク上はパブリック到達可能な構成になります。プレフィックスリストとカスタムヘッダー検証で直接アクセスはかなり制限できるものの、VPC Originだけで閉じた構成と比べれば、管理対象と設定ミスの余地が増えることは避けられません。逃げ道を用意するということは、セキュリティ設計の前提を一部緩めるということでもある。このトレードオフをどこまで許容するかを決めるのが設計です。
方式と運用の両方がなければ逃げ道は使えない
私はかねてから、以下の記事にもある通り、処理方式設計と運用設計は双方向に結合していると書いてきました。
基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
今回の件はその典型例です。「障害時に別経路へ切り替える」という運用上の逃げ道は、処理方式の側で切替可能な構成を平時から維持していなければ成立しません。逆に、処理方式で用意した逃げ道は、運用の側に切替判断の基準と手順と訓練がなければ、障害の渦中では誰も引き金を引けません。方式と運用のどちらか片方だけ設計しても、逃げ道は絵に描いた餅で終わります。
5. 学びその3：「待つしかない障害」を運用設計に織り込む
もう一つ、目を背けてはいけない現実があります。マネージドサービスの内部障害は、根本対処そのものがクラウド事業者に委ねられるということです。
自社管理のインフラであれば、機器交換や設定変更など、利用者側が直接打てる復旧手段を比較的多く持てます。マネージドの内部で起きた障害では、利用者に残されるのは、影響を切り分け、用意してあった別経路に切り替え、復旧まで縮退運転を続けることです。ならば運用設計で決めておくべきは、「待っている間に何をするか」になります。
第一に切り分けの速さです。CloudFrontの5xxErrorRateや、追加メトリクスとして有効化した504ErrorRateに加え、障害中の分析にはリアルタイムアクセスログを利用します。sc-status、処理結果を示すx-edge-result-type、より詳細な結果分類が記録されるx-edge-detailed-result-typeを、ALB側のリクエスト数・5xx・ターゲット応答時間、アプリケーションログへの到達有無、外形監視と突き合わせます。標準アクセスログは配信が遅れることがあるため、主に事後分析に使用します。
CloudFrontで5xxが急増しているのにALBへのリクエストが減っており、ターゲットは正常という形が見えれば、CloudFrontからオリジンまでの経路に問題がある可能性が高い。AWS Health Dashboardは重要な判断材料ですが、掲載があるからといって自社側の異常が併発していないとは言い切れません。自社の観測結果と突き合わせて、AWS起因の可能性を早期に高く見積もり、縮退判断と利用者への周知に人を回す。この一連の流れを、障害が起きる前に監視設計と対応フローへ落としておきます。
第二に縮退運転です。今回の障害中、PayPayではオフライン支払いモード（1回あたり上限5万円）の利用が案内されていました。この機能は今回、基盤側の障害時にも一部の支払いを継続できる縮退手段として機能しました。インフラ経路だけに可用性を委ねず、アプリケーションの機能でも影響を抑える設計の参考例といえます。PayPayの公表で、支払い、サービスサイト、アプリの一部機能で影響時間が異なっていたことも思い出してください。機能ごとに影響と復旧の時刻が分かれている点は、後半で依存関係と縮退設計を考える際の材料になります。設計時にはサービス全体を一枚岩として扱わず、どの機能を継続し、どの機能を止めるのかをあらかじめ分けて考えておくことです。
第三に説明責任です。原因がクラウド事業者側でも、ユーザーへの説明責任は開発元にあります。事業者側の障害だと説明できるだけの切り分け根拠と、事業者側と公表の体制、判断基準を平時に決めておくこと。これも立派な運用設計の要素です。
6. 所感――セキュリティと可用性の天秤、という単純な話ではない
今回の障害は「セキュリティを取ったら可用性を失った」という構図で語られがちです。ただ、話はもう少し立体的です。
VPC Originsを使わなければ安全だったわけではありません。使わない構成には使わない構成のリスク（オリジンの公開、アクセス制御の設定ミス）があり、そちらで事故る確率のほうが、現場の体感としてはよほど高い。今回の教訓は「便利な機能を疑え」ではなく、「機能を足すたびに依存が増えることを自覚し、その依存の壊れ方まで設計に含めよ」ということだと私は受け取っています。
制約値に達した背景や再発防止策など、AWSからさらに詳しい情報が出れば追記します。ただ、そこで何が明らかになっても、利用者側が持ち帰るべき学びは変わりません。障害は起きる。起きたときの姿を先に決めておくことが設計である。当たり前の原則を、生活に密着した複数のサービスが夕方の3時間半にわたって影響を受ける形で、改めて突きつけられた一日でした。
皆さんの環境でも、CloudFrontの構成図を開いて、「この線が切れたらどうなるか」を一度なぞってみてください。逃げ道が設計されているか、それとも祈りになっているか。GET系とPOST系で逃げ道が分かれているか。それを確かめるのに、今週ほど良いタイミングはないと思います。
※障害時の切替判断や縮退運転を「誰が・何を見て・いつ決めるか」まで落とし込む考え方は、運用設計シリーズで体系的に書いています。興味のある方はそちらもどうぞ。
コメント