AWS CloudFrontに、プライベートなVPC内バックエンドを公開せずCDN配信できる「VPC Origins」という機能がある。2024年11月に登場した比較的新しい仕組みで、オリジンをインターネットに晒さずに済む点が評価されてきた。この機能で2026年7月16日、CloudFrontの5xxエラーが約3時間33分続く障害が発生した[1][3]。影響はHugging FaceやUK National Lottery、Tailscaleなど幅広いサービスに及んだ[1][5]。
CDNや配信基盤の運用を担う技術者にとって、この障害は他人事ではない。新しいマネージド機能は便利さが先に語られがちだが、内部でどんな依存関係を抱え、障害時にどこまで影響が波及するかは使ってみるまで見えにくい。既存の公開オリジン構成からVPC Originsへ移行する動きは、セキュリティ強化の文脈で今後も広がると見られる。本稿は今回の障害を題材に、新機能を採用する際のフォールバック設計と単一障害点（SPOF）評価の実務指針を整理する。
予備知識
- CDN（コンテンツ配信ネットワーク）: 利用者に近い拠点からコンテンツを配信し、応答速度と耐障害性を高める仕組み。
- オリジン: CDNが配信するコンテンツの取得元となるサーバーやロードバランサー。
- VPC: AWS上に構築する、外部から論理的に隔離されたプライベートネットワーク。
- ブラストラディウス（影響範囲）: 一箇所の障害が波及して影響を受ける範囲の広さ。爆発の半径になぞらえた表現。
CloudFrontやVPCがネットワーク経路上でどう連携するかを基礎から押さえられる
障害の経緯 — 3時間33分続いた5xxエラー
CloudFrontのVPC Origins機能を使う配信で、2026年7月16日にエラーが増加した。発生は協定世界時07時45分から11時18分まで、日本時間では同日16時45分から20時18分にあたり、継続時間は約3時間33分だった[1][3]。
原因は、プライベートVPCオリジンへの接続を管理する内部フリートの制約にあった。この制約に達したことで、エッジのネットワーク処理系にルーティング設定を配信する仕組みが、最新の設定を正しく読み込めなくなった[3][4]。結果としてVPC Origin宛ての接続が正しく経路制御されず、利用者には5xxエラーが返り続けた。
問題の起点はフランクフルト（eu-central-1）の単一アベイラビリティーゾーンだったと報じられているが、影響はVPC Originsを使う世界中のディストリビューションに及んだ[3]。Hugging Face、UK National Lottery、Tailscale、Ubiquiti、Canvas、Blackboardなど、教育・開発者向けサービスを含む幅広いサービスが停止や機能低下を経験した[1][5]。特定の一リージョンの内部制約が、地理的に無関係な利用者にまで波及した点が、この障害の特徴である。
CloudFront自体はグローバルに分散したエッジロケーションで構成されるが、VPC Origins宛ての接続を仲介する管理フリートは、必ずしもエッジと同じ粒度で分散していない。今回の障害は、この管理フリート側の制約がボトルネックになった構図と読める[3][4]。
単一障害点の評価やフォールバック設計を体系立てて学ぶ土台になる
VPC Originsとは何か — 見えにくさの正体
VPC Originsは、プライベートサブネット内のALBやNLB、EC2インスタンスを、インターネットに公開せずCloudFrontのオリジンとして使える機能である。2024年11月に発表され、CloudFrontを唯一の入り口にしてオリジンへの直接アクセスを防ぐ設計を後押ししてきた[2]。
従来の公開オリジン構成では、CloudFrontとオリジンの間は通常の経路で直接つながる。VPC Origins構成では、CloudFrontとプライベートオリジンの間に、AWS側が管理する接続管理層が介在する[2][3]。
この接続管理層は、利用者からは見えない内部コンポーネントである。便利さの裏側で、公開オリジン構成にはなかった依存先が一つ増えていることになる。今回の障害は、この見えない依存先が単一障害点として機能した例といえる。
構成図やアーキテクチャ設計書には、CloudFrontとオリジンの二層だけが描かれることが多い。実際には接続管理層という三層目が存在し、この層の可用性は利用者側のドキュメントだけでは把握しづらい。新機能を採用する際は、公式の構成図だけでなく、機能の内部動作に関する追加情報源を確認する姿勢が求められる。
2026年6月22日、CDN大手Cloudflareのネットワークが劣化し、X、Reddit、Microsoft Teams、Zoomなど数多くのサービスで遅延やタイムアウトが発生した[1][2]。原因は設定変更のミスではなく、北米[…]
オリジン種別ごとのSPOFリスクをどう評価するか
オリジンの種類によって、単一障害点になり得る要素は異なる。採用前に、経路上の依存先とフォールバック手段の有無を一覧化しておくと、障害発生時の判断が早くなる。
| オリジン種別 | 経路上の主な依存先 | フォールバック手段 | 今回の障害の該当有無 |
|---|---|---|---|
| 公開オリジン（S3/公開ALB） | インターネット経路、DNS | 別リージョンへの複製がしやすい | 非該当 |
| VPC Origins（プライベートALB/NLB/EC2） | AWS管理の接続管理フリート | 利用者側で制御できない内部依存 | 該当（今回の障害） |
| Lambda@Edge/CloudFront Functions併用 | エッジ実行環境 | ロジック不具合時は無効化で切り離し可能 | 非該当 |
| マルチCDN構成 | DNS切替、複数ベンダーの独立性 | ベンダー単位で迂回できる | 非該当（単一CDN前提の構成では緩和されない） |
表からわかるのは、VPC Originsのようにマネージド機能が経路に加わる構成では、利用者側でフォールバックを制御しにくい依存先が増える点である。障害発生時に自社側で打てる対処が限られることを、採用段階で把握しておく必要がある。
一方で、VPC Originsを避ければよいという単純な結論にもならない。オリジンを公開しない構成は、攻撃対象領域を狭める効果があり、セキュリティ要件の面では優位がある。可用性とセキュリティのどちらを優先するかは、扱うシステムの性質によって変わる判断であり、一律の正解はない。
2026年7月15日（太平洋夏時間、日本時間では16日早朝）、Google Cloud（グーグルが提供するクラウド基盤サービス）のオランダ拠点で電源網の異常が発生し、冷却設備の停止を経て、europe-west4-a（オランダに置かれたア[…]
新機能導入時のフォールバック設計とチェックリスト
新しいマネージド機能を採用する際は、利便性だけでなく、障害時に自社側で打てる手が残っているかを合わせて評価するとよい。
具体的には、まず新機能が経路に追加する内部依存先を洗い出す。次に、その依存先が停止した場合に、公開オリジンへの切り戻しやマルチCDNへの迂回など、既存の代替経路を維持できるか確認する。AWSの正式なインシデント記録が公開された際には、想定していた依存範囲と実際の障害範囲を突き合わせる運用も有効である。
この棚卸しは、機能を導入する前に一度実施すれば終わりではない。AWSがVPC Originsのような機能に改良を重ねるたびに、内部の依存構造も変わり得る。年に一度程度の頻度で、主要な依存先とフォールバック手段を見直す運用を組み込んでおくと、構成変更による見落としを減らせる。
今回の障害の継続時間は、直近にこのブログで扱った他のクラウド障害と比べて突出して長いわけではない[6][7]。それでも、影響範囲が事前に読みにくい新機能である点が、今回のケースを特に注意すべき事例にしている[1][3]。
⚠️ 結論：Sora 2（OpenAI）は提供終了しました Web版・アプリ版：2026年4月26日に提供終了（OpenAI公式ヘルプの案内）。 API：2026年9月24日に終了予定。 これ[…]
よくある質問（FAQ）
Q1. VPC Originsを使うとCDN経由の障害リスクは高まるか。
A. リスクの性質が変わる。公開オリジン構成では発生しなかった内部の接続管理層への依存が加わる分、利用者側で制御できない障害要因が一つ増える。
Q2. 今回の障害はVPC Originsを使っていない構成にも影響したか。
A. 報道によれば、影響はVPC Origins機能を利用するCloudFrontディストリビューションに限られている[1][3]。公開オリジンのみの構成は対象外とされている。
Q3. 新機能の採用前にできる備えは何か。
A. 採用前に、その機能が経路に追加する内部依存先を洗い出し、障害時に切り戻せる代替経路があるかを確認しておくとよい。
まとめ
2026年7月16日のCloudFront障害は、VPC Originsという比較的新しい機能が抱えていた内部の接続管理制約が引き金だった。約3時間33分にわたり5xxエラーが発生し、影響は世界中の関連サービスに及んだ[1][3]。
新しいマネージド機能は、利便性の裏に利用者から見えない依存先を抱えていることがある。採用前にオリジン種別ごとのSPOFリスクを評価し、フォールバック設計を用意しておくことが、今回のような障害への現実的な備えになる。
CDNや配信基盤を運用する立場であれば、自社が使っている機能の内部依存を一度棚卸ししておく価値がある。VPC Originsを使うか使わないかではなく、使う前提でどこまで代替手段を残せるかを考える方が、実務としては現実的である。
出典
[1] AWS CloudFront outage serves errors instead of websites, The Register, https://www.theregister.com/off-prem/2026/07/16/aws-cloudfront-outage-serves-errors-instead-of-websites/5272421[2] Amazon CloudFront announces VPC origins, AWS What’s New, https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-cloudfront-vpc-origins
[3] The July 2026 AWS CloudFront Outage: VPC Origins, Cascade Impact, and What Broke, IncidentHub Blog, https://blog.incidenthub.cloud/aws-cloudfront-outage-jul-16-2026
[4] AWS CloudFront suffers partial outage due to configuration failure, SDxCentral, https://www.sdxcentral.com/news/aws-cloudfront-suffers-partial-outage-due-to-configuration-failure/
[5] AWS CloudFront Took Down Canvas, Blackboard, Hugging Face in Control-Plane Failure, Tech Times, https://www.techtimes.com/articles/320971/20260719/aws-cloudfront-took-down-canvas-blackboard-hugging-face-control-plane-failure.htm
[6] Azure Status History, “Azure OpenAI Service” incident report for 2026-05-29, https://azure.status.microsoft/en-us/status/history/
[7] Grafana Status History, https://status.grafana.com/history
