はじめに
日本時間2026年7月16日 16:45頃〜21:20頃、Amazon CloudFrontで障害が発生し、日本国内ではPayPay・note・ニコニコ生放送などが影響を受けました。
影響を受けたのはVPC Originsという機能を使っていた利用者のみになります。
本記事では、この障害について整理してみます。
障害のタイムライン
AWS Health DashBoardに記載されている情報を元に作成しています。
| 時刻 (JST) | 出来事 |
|---|---|
| 16:45頃 | VPC Origins利用構成で5xxエラーが増加開始 |
| 17:44頃 | AWSから「VPC Origins接続を利用しているCloudFrontのお客様で、5xxエラーが増加している件について調査中」と発表 |
| 18:21頃 | 他のオリジンタイプでは問題ないことが確認され、オリジンタイプ変更による回避策を案内される |
| 21:21頃 | 完全復旧がアナウンスされる |
CloudFrontとは
Amazon CloudFrontは、AWSが提供するCDN（Content Delivery Network）サービスです。
世界各地に配置されたエッジロケーションを利用して、ユーザーに近い拠点からコンテンツを配信することで、通信のレイテンシを低減できます。
また、コンテンツ配信の高速化以外にも、以下のような目的で利用されます。
- オリジンへのアクセス制限：OACやVPC Originsなどを利用することで、S3、ALB、EC2などのオリジンへの直接アクセスを制限できる
- DDoS対策：AWS ShieldによるDDoS保護をエッジで受けられる。
- オリジン負荷の軽減：コンテンツをエッジロケーションにキャッシュすることで、オリジンへのリクエスト数を削減できる
- 他にも、コンテンツの自動圧縮、HTTP/2・HTTP/3、HTTPS通信、エッジでのリクエスト処理などを設定できる
今回影響を受けたVPC Originsとは
VPC Originsは2024年11月に登場した比較的新しい機能です。
プライベートサブネット内のリソース（ALB / NLB / EC2）を、パブリックIPなしでCloudFrontのオリジンにすることが可能になりました。
VPC Origins登場以前の構成
従来、CloudFrontのオリジンにALBを指定する場合、インターネットから到達可能なinternet-facing ALBを使用する必要がありました。
そのため、ALBの公開DNS名を指定することで、CloudFrontを経由せずにALBへ直接アクセスできる経路が残っていました。
ALBへの直接アクセスを防ぐため、以下のような追加の対策が必要でした。
- CloudFrontからオリジンへ送信するリクエストにカスタムヘッダーを付与し、ALBのリスナールールでヘッダーを検証する
- ALBのセキュリティグループで、CloudFrontのオリジン向けマネージドプレフィックスリストからの通信のみを許可する
VPC Originsを使った構成
VPC Originsを使うと、LBやEC2をプライベートサブネットに閉じ込めたままCloudFrontから到達できます。
VPC内に作成されるENIを経由してオリジンへプライベートに接続します。そのため、オリジンにパブリックIPアドレスやインターネットから到達可能なエンドポイントを持たせる必要がありません。
CloudFrontを経由せずにインターネットから直接アクセスされる経路を排除できます。
しかし、セキュリティを高めるためのこの新機能を利用していたシステムだけが、今回の障害の影響を受けることとなりました。
なぜVPC Originsだけ影響を受けたのか
AWSからは、障害の原因について以下のような説明がありました。
Private VPC Originsへの接続を管理するフリートの内部制約が問題の根本原因であることが判明しました。この制約に達したため、ルーティング構成をネットワークプロセッサに配布するシステムが更新された構成データを正しくロードできず、VPC Origins接続のルーティングに影響が出ました。
要するに、問題が発生したのは、CloudFrontからVPC内のALBやEC2へ通信するための、VPC Origins専用の接続基盤でした。
そのため、S3やinternet-facing ALBなどの従来型オリジンはパブリックIP宛の別経路を通るため影響がなく、この専用基盤を経由するVPC Origins構成だけが影響を受けたというわけです。
回避策
障害発生中、AWSからは「他のオリジンタイプへの変更」が回避策として案内されました。
internet-facing ALBなどのパブリックオリジンに切り替えれば、VPC Origins専用基盤を経由しない経路に逃がすことができます。
ただし、いざ実行するとなるとハードルがあると思います。
- ALBのスキーム（internet-facing / internal）は作成後に変更できないため、新たにinternet-facing ALBを作り直す必要がある
- パブリック公開するため、カスタムヘッダー検証やマネージドプレフィックスリストによるセキュリティ対策も必要になる
そのため、障害が起きてからゼロから準備するのではなく、事前に準備しておくことが必要です。
対策としては、以下のような備えが考えられます。
- 緊急時に構成を切り替えられるよう、IaCで代替構成をコード化しておく
- AWS Health Dashboardの通知をEventBridge経由でSlackなどに連携し、障害を早期に検知できるようにする
おわりに
今回の障害は、セキュリティ向上のために新機能を採用したシステムだけが影響を受けるという、皮肉な結果でした。。。
AWS側で障害が発生すると、利用者側ではどうしようもないと感じてしまうこともあります。
しかし、障害の影響範囲を小さくする構成や、フェイルオーバーの仕組みをあらかじめ検討しておくなど、利用者側でできる対策もあります。
新しい機能を使うときは、便利さだけでなく、障害が起きたときのことも考えておく必要があると感じました。
最後までお読みいただき、ありがとうございました！