AWS CloudFront障害の教訓：VPC Originsの死角とエンジニアの備え

深夜のオンコール、突如として鳴り響くアラート。ダッシュボードを覗けば、そこには真っ赤に染まった5xxエラーのグラフが広がっている。2026年7月16日、多くのエンジニアが直面したのは、まさにこの悪夢のような光景でした。日本時間16:45頃から21:20頃にかけて発生したAmazon CloudFrontの障害は、PayPayやニコニコ生放送といった国内の主要サービスを直撃し、多くのユーザーに混乱をもたらしました。しかし、この障害の最も恐ろしい点は、AWSの全ユーザーが等しく被弾したわけではないという点です。影響を受けたのは、セキュリティを強化するために『VPC Origins』という比較的新しい機能を採用していたシステムのみでした。

VPC Originsは、2024年11月に登場した機能であり、プライベートサブネット内のリソースをパブリックIPなしでCloudFrontのオリジンにできるという、セキュリティ意識の高いエンジニアにとっては福音とも言える機能でした。従来、ALBをオリジンにする際にはinternet-facingな構成が必要であり、CloudFrontを経由しない直接アクセスの経路を塞ぐために、カスタムヘッダーの検証やマネージドプレフィックスリストによる制御といった、いわば『泥臭い』対策を積み重ねる必要がありました。VPC Originsは、この複雑な構成をENI経由のプライベート接続で一掃し、ネットワークレベルでの隔離を実現したのです。しかし、皮肉なことに、この『強固な隔離』こそが、今回の障害の引き金となりました。

AWSの発表によれば、原因はPrivate VPC Originsへの接続を管理するフリートの内部制約にありました。ルーティング構成をネットワークプロセッサに配布するシステムが、更新された構成データを正しくロードできず、結果としてVPC Origins専用の接続基盤が機能不全に陥ったのです。S3や従来のinternet-facing ALBを利用していたシステムは、パブリックIP宛の別経路を通るため難を逃れました。つまり、セキュリティを向上させようと最新のベストプラクティスを導入したエンジニアほど、今回の障害の直撃を受けたのです。これは、技術選定における『新機能の採用』と『可用性のトレードオフ』という、我々が常に抱えるジレンマを改めて突きつける結果となりました。

今回の障害のタイムラインを振り返ると、AWSのマネージドサービスであっても、その内部構造がブラックボックスである以上、我々利用者は常に『最悪の事態』を想定した設計を強いられていることが分かります。以下に、障害発生から復旧までの推移を整理します。

注目すべきは、18:21頃に提示された『回避策』の現実味です。AWSは、internet-facing ALBなどのパブリックオリジンへの切り替えを推奨しましたが、これは現場のエンジニアからすれば極めてハードルの高い要求です。ALBのスキームは作成後に変更できないため、緊急時にインターネット公開可能なALBをゼロから構築し、DNSを切り替え、さらにカスタムヘッダー検証等のセキュリティ対策を再設定する必要があります。障害対応の極限状態で、これらをミスなく実行できるチームがどれほど存在するでしょうか。この事実は、我々が『マネージドサービスを使っているから安心』という幻想を捨て、障害時のフェイルオーバー経路をIaC（Infrastructure as Code）として事前にコード化し、テストしておくことの重要性を物語っています。

また、今回の障害は、CloudFrontという巨大なCDN基盤の内部で、特定の機能群が独立した接続基盤を持っているという『疎結合の落とし穴』を露呈させました。VPC Originsという機能は、利便性とセキュリティを両立させる素晴らしい技術ですが、その裏側にある制御プレーンやデータプレーンの冗長性までを、我々利用者が完全にコントロールすることは不可能です。だからこそ、マルチリージョンやマルチCDN、あるいは今回のようなオリジンタイプの切り替えを想定した『疎結合なアーキテクチャ』を、アプリケーション層でどう担保するかが、シニアエンジニアとしての腕の見せ所となるのです。

今回の障害を単なる『AWSの不具合』として片付けるのは、エンジニアとしてあまりに怠慢です。我々が明日から取り組むべきは、クラウドベンダーの障害を『前提条件』としてシステムを設計する、いわゆる『Design for Failure』の徹底です。具体的には、まずEventBridgeを活用したAWS Health Dashboardの通知連携をSlack等のチャットツールに統合し、障害検知の初動を数分単位で短縮すること。そして、何よりも重要なのは、今回のような『特定の機能が死んだ場合』の代替経路を、あらかじめIaCで定義し、いつでもデプロイ可能な状態にしておくことです。

我々エンジニアは、新しい技術が登場すると、その機能性やセキュリティ上のメリットに飛びつきがちです。しかし、その技術が『どの基盤の上で動いているのか』『障害時にどの経路が遮断されるのか』という依存関係の地図を、頭の中に描けているでしょうか。今回のVPC Originsの件は、セキュリティを強化したつもりが、実は単一障害点（SPOF）を増やしていたという、皮肉な教訓を残しました。技術選定において、その機能がもたらす恩恵と、それがダウンした際に支払うコストを天秤にかける能力こそが、今まさに問われています。

最後に、読者であるあなたに問いかけたい。あなたのシステムは、もし明日、利用している特定のクラウド機能が数時間停止したとして、ビジネスを継続できるだけの『逃げ道』を確保できていますか？『クラウドだから落ちない』という神話は、もはや過去の遺物です。障害は必ず起きるという前提に立ち、その影響を最小化するための『冗長性の設計』を、あなたは今日、コードの中に書き込めますか？この問いに対する答えが、あなたのエンジニアとしてのキャリアの厚みを決めることになるでしょう。今すぐ、TerraformやCloudFormationのコードを見直し、緊急時の切り替え手順をドキュメント化し、チームで共有してください。それが、この障害から我々が持ち帰るべき唯一の、そして最大の成果物なのです。