AWS CloudFrontの障害でCanvasやHugging Faceが停止、セキュリティ機能「VPC Origins」の死角が浮き彫りに

2026年7月16日、AWS CloudFrontの「VPC Origins」機能においてグローバルなコントロールプレーン障害が発生し、CanvasやBlackboard、Hugging Faceなど多数の主要サービスが一時的にオフラインとなった。原因はドイツ・フランクフルトの単一アベイラビリティゾーンにおける内部容量制限だったが、影響は世界中のエッジネットワークに波及した。セキュリティ向上を目的としたVPC Originsの設計が、結果として障害発生時の代替経路（フォールバック）を失わせるという、運用のトレードオフが浮き彫りになっている。

■世界規模で連鎖したAWS CloudFrontの障害

米国東部時間2026年7月16日午前3時45分（日本時間同日午後4時45分）、AWS CloudFrontは「VPC Origins」機能を使用しているすべての顧客に対して5xxエラーの返却を開始した。その後3時間33分にわたり、この障害は少なくとも10件の主要なダウンストリームサービスのインフラストラクチャスタックへと連鎖した。これにより、北米全域の大学で学習管理システム（LMS）の「Canvas」と「Blackboard」がオフラインになり、AI・機械学習プラットフォームの「Hugging Face」、英国の国民宝くじ（National Lottery）のギャンブルインフラ、ネットワーク機器メーカーUbiquitiのクラウドサービスなどが相次いで停止した。AWS自身の復旧タイムラインによると、同社はこの障害の原因について、ドイツ・フランクフルトの単一のアベイラビリティゾーン（AZ）における単一の内部容量制限が原因で、接続管理フリートが世界中に分散されたエッジネットワークにルーティング更新を配信できなくなったためだと説明している。

高等教育機関で圧倒的なシェアを誇る2大LMSであるCanvasとBlackboardが、AWSのCDN障害によって同時にオフラインになったのは、過去9ヶ月間で2回目のことである。IncidentHubの事後分析によると、2025年10月に発生したAWSの「US-EAST-1」リージョンにおけるDNS障害の際にも、両プラットフォームは17時間以上にわたって停止していた。

■「VPC Origins」の仕組みと、セキュリティが障害を悪化させた理由

2024年11月20日の「AWS re:Invent」で発表されたCloudFrontのVPC Origins機能は、長年のアーキテクチャ上のセキュリティギャップを解消するものだった。この機能が登場する前は、CloudFrontの背後に配置されたアプリケーションロードバランサー（ALB）、EC2インスタンス、またはAPI Gatewayは、CloudFrontからのトラフィックを受信するためにパブリックIPアドレスを必要としていた。しかし、そのパブリックIPアドレス自体が攻撃対象領域（アタックサーフェス）となり、IPアドレスを特定した攻撃者がCloudFrontを完全にバイパスして、Webアプリケーションファイアウォール（WAF）のルールや地理的制限、レート制限を回避するリスクが存在していた。

VPC Originsは、Elastic Network Interface（ENI）を中心としたアーキテクチャによってこのギャップを解消した。AWS CloudFrontの開発者ガイドによると、顧客がVPC Originsを設定すると、AWSは顧客が指定したプライベートサブネット内にサービス管理型のENIを作成する。CloudFrontのエッジサーバーはこのENIに接続し、インターネットに公開されたホップを経由することなく、顧客のプライベートなALB、Network Load Balancer（NLB）、またはEC2インスタンスにトラフィックをルーティングする。これにより、バックエンドはパブリックIPアドレスやインターネットゲートウェイへのルートを一切必要としなくなる。また、AWSは顧客のALBがCloudFrontからのトラフィックのみを受け入れるように参照できる、管理されたセキュリティグループも作成する。

しかし、このアーキテクチャに組み込まれたエンジニアリング上のトレードオフこそが、今回の障害をこれほどまでに深刻化させた原因となった。パブリックなオリジンを排除することで、VPC OriginsはCloudFrontを唯一の侵入経路にしてしまう。CDNの接続レイヤーが破損したとき、フォールバック（代替）として機能するパブリックなエンドポイントは存在しなかった。障害発生中にAWS自身が推奨した回避策は「一時的にオリジンのタイプをパブリック設定に切り替える」というものだったが、これはセキュリティの退行を意味し、安全に実行するためには事前の計画や、あらかじめ用意されたInfrastructure as Code（IaC）、そして深夜の午前3時45分に即座に対応できる運用チームが必要となる。セキュリティ向上のためにVPC Originsを採用した組織は、そのセキュリティ向上策によって、運用上の「非常口」を失っていたことに気づかされる結果となった。

■フランクフルトの局所的制限がグローバル障害へ発展した背景

The Registerの報道によると、AWSは根本原因を「EU-CENTRAL-1（ドイツ・フランクフルト）リージョン内のeuc1-az2アベイラビリティゾーンにおける、プライベートVPCオリジンへの接続を管理するフリートの内部制約」と特定した。この制約に達した際、CloudFrontのネットワークプロセッサにルーティング設定を配信するシステムが、更新された設定データの読み込みに失敗した。各エッジサーバーにおいて、受信したリクエストをVPC Originsにどのようにルーティングするかを決定するコンポーネントであるネットワークプロセッサが、指示を受け取れなくなったのである。

CloudFrontのPOP（Point of Presence）に世界規模で分散されている数百台のエッジサーバーで構成されるデータプレーン（転送面）自体は稼働し続けていた。しかし、有効なVPC Originsのルーティング設定がない状態で動作していたため、ユーザーの所在地やバックエンドをホストしているAWSリージョンに関係なく、すべてのVPC Originsの顧客に対して一律で5xxエラーが返される結果となった。

これは、グローバルなスコープを持つコントロールプレーン（制御面）における典型的な障害モードである。IncidentHubの分析が説明するように、分散システムにおいて、ルーティングの決定と設定の配信を行うコントロールプレーンと、それらの決定を実行するデータプレーンを分離することは標準的なアーキテクチャである。これにより、少数のコントロールプレーンサーバーで膨大なグローバルエッジフリートを管理できるというスケールメリットが得られる。しかし、その脆弱性はスケールメリットの裏返しでもある。コントロールプレーンの障害によって設定の更新が読み込めなくなると、物理的な場所や、通常であればハードウェアやソフトウェアの障害を封じ込めるはずのリージョン間の隔離境界に関係なく、すべてのデータプレーンノードに同時に障害が伝播してしまう。

AWSのレトロスペクティブ（振り返り）サマリーによると、同社のエンジニアは米国東部時間午前7時16分（日本時間午後8時16分）頃にパケット処理サブシステム内のルーティングテーブル容量の問題を特定し、段階的なアプローチで緩和策をデプロイして、午前7時18分（日本時間午後8時18分）に完全な復旧を確認した。ただし、IncidentHubのタイムラインによると、午前7時27分および午前7時57分のライブステータス更新では、依然として復旧作業中であると説明されていた。最終的な解決サマリーは午前8時21分（日本時間午後9時21分）に投稿された。

■教育テクノロジー（EdTech）における一極集中リスクの顕在化

影響を受けたダウンストリームサービスの中でも、CanvasとBlackboardの停止は特に大きな影響を及ぼした。両プラットフォームは米国の認可大学の大部分で採用されており、いずれも1年足らずの間にAWSのCDN障害によって2回も停止に追い込まれたことになる。

ラトガース大学のITオフィス（OIT）が発表したアラートによると、米国東部時間午前6時8分（日本時間午後7時8分）に公開された通知で、AWS CloudFrontの障害によりCanvasがアクセス不能になっていることを指摘し、「複数の機関に影響を与えているベンダー起因の全国的な事象」と説明した。Blackboardのステータスページでは、午前4時33分（日本時間午後5時33分）に初期調査を開始し、午前5時40分（日本時間午後6時40分）にCloudFrontが根本原因であることを確認、午前8時57分（日本時間午後9時57分）に復旧の兆候を観測し始めた。Canvasを運営するInstructureも、自社のステータスページでAWS CloudFrontが根本原因であることを確認している。

EdTech分野における集中リスクは極めて明確である。CanvasとBlackboardはどちらもコンテンツ配信をCloudFrontに依存しており、標準構成ではマルチCDNのフェイルオーバーを備えていない。その結果、AWSの単一の機能レベルの障害（CloudFront全体の障害ではなく、一部の顧客が使用する特定の機能の障害）が発生しただけで、何百もの教育機関で両プラットフォームが同時にオフラインになってしまう事態が発生した。

IncidentHubの検出によると、他にも機械学習モデルの開発者プラットフォームである「Hugging Face」、コラボレーションツールの「Coda」、遠隔医療プロバイダーの「Doxy」、アイデンティティ・アクセス管理プラットフォームの「Frontegg」、データインフラプロバイダーの「TigerData」などのダウンストリームサービスが影響を受けた。また、Cybernewsの独自確認により、Tailscaleの管理コンソールとパッケージリポジトリが影響を受け、英国の国民宝くじのウェブサイトも同じ時間帯にオフラインになったことが報じられている。さらに、日本のブログサービスである「はてなブログ」も、この障害の発生時間帯に504エラーが発生したことを報告している。

■4つのクラウドプロバイダーで14ヶ月間にわたり繰り返されるパターン

今回の障害は、分散型クラウドインフラストラクチャにおいて文書化されている障害パターンに合致している。それは、1つのアベイラビリティゾーンや設定システムにおける局所的なイベントが、データプレーンを管理するコントロールプレーンがグローバルに動作しているために、世界規模のデータプレーン障害を引き起こすというパターンである。

2025年6月から11月にかけて、これに類似した3つの事象が発生している。Cisco ThousandEyesの分析によると、2025年6月には、Google Cloud Platform（GCP）の認可インフラストラクチャを通じて不正な設定更新がグローバルに伝播し、SpotifyやCloudflareを含むサービスで認証エラーが発生した。また、2025年10月には、Microsoft Azureがエッジネットワーク全体に互換性のないメタデータの変更を配信し、世界的な接続障害を引き起こした。さらに2025年11月には、Cloudflareがグローバルに展開されているボット管理システムに対して制限値を超えるデータベース権限の変更をプッシュし、すべてのエッジノードで同時にシステムがクラッシュした。これらの事例はいずれも、IncidentHubの「2025年主要クラウド障害レポート」に詳細が記載されている。いずれのケースでも、設定のプッシュ、メタデータの更新、データベースファイルといった局所的に開始されたイベントが、リージョンやアベイラビリティゾーンの隔離境界を無視するコントロールプレーンを通じてグローバルに伝播した。

2026年7月のAWSの障害はその変種と言える。不正な設定がグローバルに配信されたのではなく、障害によって正しい設定自体が読み込めなくなった。しかし、運用上の結果は同じであり、世界中に分散されたエッジサーバーが有効なルーティング指示なしで動作することになった。

APIオブザーバビリティ企業APIContextのCEOであるMayur Upadhyaya氏は、Cybernewsに対し、この構造的な動向について次のように述べている。より懸念すべき傾向は、業界が「利便性と経済的な魅力から、少数のプロバイダーへの集約をますます進めている」ことであり、「かつては一握りの組織にしか影響しなかったはずの障害が、今では非常に多くの企業が同じインフラに依存しているために、何千もの組織に同時に影響を与えるようになっている」という点である。

この一極集中の傾向は市場の数値にも表れている。Rest of Worldによる2025年のクラウド障害分析によると、世界中のエンタープライズサービスの約94%がAWS、Microsoft Azure、Google Cloudの少なくとも1つに依存しており、これら3つのプロバイダーが世界のクラウド市場の62%以上を占めている。2024年8月から2025年8月までの間に、これら3社を合わせて100件以上の文書化されたサービス障害が発生している。

■AWSのこれまでの説明と未回答の疑問

Cybernewsの報道によると、AWSは影響を受けたすべてのサービスが復旧し、オリジンタイプの切り替えによる回避策を実施した顧客は安全にVPC Originsに戻すことができると発表した。しかし、同社は「内部制約」が具体的に何であったのか（接続数制限、スレッドプール、メモリしきい値、あるいはその他のリソース上限なのか）、またその制限を調整したのか、再発防止のためのサーキットブレーカー機構を追加したのかといった詳細なポストモータム（事後分析）を公開していない。

この障害は、AWSがVPC Originsの機能を拡張し続けている最中に発生した。2025年11月にはクロスアカウントのVPC Originsサポートが追加され、2026年5月にはVPC OriginsのWebSocketサポートが開始された。機能が拡張されるたびに、将来的にVPC Originsの障害が発生した際に影響が及ぶ依存関係のグラフはより深く、複雑になっていく。

プラットフォームチームにとって、根本原因の詳細が明らかにされていないことは実務上の懸念をもたらす。何が容量制限を引き起こしたのかが分からなければ、エンジニアは自社の利用パターンによって次に制限に達してしまうリスクがあるのか、あるいはその制限が個々の顧客の影響範囲を超えたフリートレベルのものであるのかを判断できないためである。

■次の障害に備えてSREやプラットフォームチームが取るべき対策

リアルタイムで連鎖障害を検出した監視サービスIncidentHubの創設者であるHrishikesh Barua氏は、事後分析において重要な準備ステップを提示している。AWSが推奨した「パブリックオリジンへの切り替え」という回避策は、事前にテストとリハーサルが行われている場合にのみ有効である。TerraformなどのInfrastructure as Code（IaC）ツールを使用しているチームにとって、これは障害が発生してから午前3時45分にコードを書いてデバッグするのではなく、オリジンタイプの変更を事前にステージングし、テストを完了させて、すぐにデプロイできる状態にしておくことを意味する。

2番目の準備ステップは、依存関係のマッピングである。CanvasとBlackboardの障害は三次的な影響だった。すなわち、「AWSが容量制限に達した」→「CloudFront VPC Originsのルーティングが破損した」→「InstructureとBlackboardがトラフィックを処理できなくなった」→「大学がLMSにアクセスできなくなった」という流れである。ラトガース大学のIT部門も学生も、AWSに直接の依存関係を持っていなかったが、直接のAWS顧客と同様に深刻な障害を経験した。IDプロバイダー（IdP）も同様のリスクプロファイルを持つ。CloudFront VPC Originsを使用しているIDプロバイダーがオフラインになると、アプリケーション自体は正常に動作していても、ユーザーがアプリケーションからロックアウトされる可能性がある。

3番目の考慮事項はアーキテクチャ設計である。グローバルなコントロールプレーンは、クラウドプロバイダーが回復性のためのメカニズムとして提供しているアベイラビリティゾーンやリージョン間の隔離境界を無視する。ゾーン障害に対する標準的な対応であるリージョンフェイルオーバーは、障害がグローバルスコープのコントロールプレーンにある場合には防御策にならない。マルチクラウドアーキテクチャは、自社運用のインフラにおけるこのリスクを軽減するが、サードパーティのSaaS依存関係にまでは及ばない。例えば、Canvasを使用している大学には、Canvas自体のマルチCDNフェイルオーバーを選択する手段はない。

AWSの2026年7月のCloudFront障害は、記憶に新しい中では最大の障害というわけではない。SDxCentralが指摘するように、2025年10月のDNS障害では1,000社以上の企業で650万件以上のDowndetector報告が生成され、今回の障害における報告数350件を大きく上回っている。しかし、今回の件は、多くの組織にとって見えていなかったトレードオフを浮き彫りにした点で注目に値する。すなわち、セキュリティアーキテクチャによってオリジンの露出を排除すると、同時に運用上の柔軟性も失われるという点である。現在のVPC Originsの設計において、これら2つの結果は不可分であり、AWSは顧客がこの機能を採用するかどうかを決定するにあたって、この不可分性についてまだ十分なドキュメントを提供していない。

■注目ポイントQ&A

●2026年7月16日のAWS CloudFront VPC Origins障害の原因は何ですか？

AWSの調査によると、ドイツ・フランクフルト（EU-CENTRAL-1リージョン）の「euc1-az2」アベイラビリティゾーンにおける、接続管理フリートの内部容量制限が原因です。この制限に達したことで、エッジネットワークプロセッサにルーティング設定を配信するシステムが更新データを読み込めなくなり、世界中のエッジサーバーがVPC Originsのバックエンドへのルーティング指示を失って5xxエラーを返しました。

●なぜ一部の顧客は障害発生時に代替経路（フォールバック）を利用できなかったのですか？

VPC Originsはバックエンドサーバーをパブリックインターネットから完全に隠すセキュリティ機能であるため、CloudFrontが唯一の侵入経路となります。そのため、この機能が停止した際、パブリックなエンドポイントが用意されておらず、トラフィックを迂回させることができませんでした。AWSが推奨したパブリックオリジンへの切り替えには、事前のインフラコードの準備が必要でした。

●複数リージョンやアベイラビリティゾーン（AZ）の利用で、この障害は防げましたか？

防げませんでした。今回の障害は、エッジサーバーにルーティング設定を配信する「グローバルなコントロールプレーン」で発生したためです。フランクフルトの1つのAZで発生した容量制限が、世界中のすべてのAWSリージョンとエッジサーバーに波及しました。通常のAZフェイルオーバーやリージョン冗長化は、このようなグローバルなコントロールプレーンの障害には効果がありません。

●次のCloudFront障害に備えて、プラットフォームチームは何をすべきですか？

3つの対策が推奨されています。1つ目は、TerraformなどのIaCでパブリックオリジンへのフェイルオーバーを事前にステージング・テストしておくこと。2つ目は、IDプロバイダーや依存しているSaaSのCDNなど、二次的な依存関係をマッピングして監視に加えること。3つ目は、採用しているSaaS製品にマルチCDN構成やフェイルオーバー機能があるかを評価し、ベンダーリスクを把握することです。

元記事: AWS CloudFront Took Down Canvas, Blackboard, Hugging Face in Control-Plane Failure