AWS障害でPayPayやニコニコなど停止…なぜ大規模な障害となったのか？企業の対応策は

「Amazon CloudFront」で世界規模の障害が発生

　2026年7月16日午後5時40分ごろ、アマゾン・ウェブ・サービス（AWS）のコンテンツ配信サービス「Amazon CloudFront」で世界規模の障害が発生した。国内ではPayPayのほか、note、ニコニコ生放送、はてなブログなどが同じ時間帯に利用しにくくなったという。

　AWSによると、CloudFrontからプライベートなシステムへ接続する「VPC Origins」で問題が起きたといい、同機能を使わない構成に変更すればエラーを回避できるとした。つまり、東京リージョン内のサーバが一斉に壊れたわけではなく、利用者とアプリケーションをつなぐ「入り口」の一部が正常に機能しなくなった形だ。

　今回問題が起きたVPC Originsは、本来、セキュリティを高めるための機能である。企業はApplication Load BalancerやEC2などのシステムを、インターネットから直接アクセスできないプライベートなネットワークに配置できる。利用者からの通信はCloudFrontを通じて送られ、CloudFrontをシステムの「単一のエントリーポイント」にできるという。

　インターネットからオリジンサーバを隠せるため、不正アクセスや設定ミスのリスクを減らしやすい。アクセス制御も簡素化でき、個別に複雑なネットワーク設定を持つ必要も小さくなる。便利さと安全性を両立する仕組みだ。

安全性を高める機能が障害の原因になる皮肉

　しかし、CloudFrontだけを正規の入り口とし、オリジンサーバへの直接接続を閉じれば、CloudFrontの特定機能に障害が起きた際の代替経路も失われる。安全性を高めるために入り口を絞り込んだ結果、その入り口が論理的な「共通依存点」になる皮肉である。

　だからといって、オリジンサーバを常にインターネットへ公開しておくべきではない。問題は、非常時に使う経路を事前に用意していたかだ。別のCDN、異なるオリジン方式、緊急用の静的ページなどへ切り替える設計があれば、全面停止を避けられる可能性が高まる。

　ただ、障害発生後に代替経路を即席で作るのは難しい。DNS、電子証明書、ファイアウォール、認証、監視の設定を同時に変える必要があり、作業ミスによって新たな障害を起こす恐れもある。逃げ道は「必要になってから作る」のでは遅い。普段は使わなくても、定期的に接続と切り替えを試すことが欠かせない。 【次ページ】クラウド固有機能は便利なほど移れなくなる