TITLE

AWS CloudFrontで約3時間半の障害——影響は新機能「VPC Origins」利用者に限定

投稿日：2026.07.18

AWS CloudFrontで約3時間半の障害——影響は新機能「VPC Origins」利用者に限定

2026年7月16日、Amazon CloudFrontで障害が発生し、日本時間16時45分頃から20時18分頃まで、約3時間33分にわたってサービスが不安定になりました。影響を受けたのは、CloudFront の中でも「VPC Origins」という機能を使っている顧客に限られ、S3やパブリックALB経由でオリジンを設定している顧客への影響はありませんでした。長年運用されてきた大規模なCDNサービスであっても、比較的新しい一機能に閉じた原因でこれだけの障害が起きる——それが今回の障害から読み取れる事実です。

何が起きたか——約3時間半のダウンと影響サービス

障害が発生していたのは2026年7月16日07:45から11:18(UTC)の間、日本時間では16時45分頃から20時18分頃にあたります。この間、VPC Origins機能を使っているCloudFrontディストリビューションでエラーが発生し続けました。

各社の公式発表を集約したまとめ(piyolog)によれば、日本国内ではPayPay、ニコニコ生放送、はてなブログ、モバイルSuica、モバイルPASMO、マイナポータルで影響が確認されています。海外でもHugging Face、Frontegg、Instructure(Canvas)、Blackboard、Coda、Ubiquiti、英国のNational Lotteryなど、業種を問わず多数のサービスで障害が報告されました。AWSが緩和策を実施したことで完全復旧しており、障害中に一時的にオリジンタイプを変更して回避していた顧客は、設定を元に戻して問題ないとされています。

なぜ VPC Origins だけが影響を受けたのか——原因は「内部的な制約」

VPC Originsは2024年後半に追加されたCloudFrontの機能で、顧客のVPC(顧客専用の仮想ネットワーク)内にある非公開のロードバランサ(ALB/NLB)やEC2インスタンスに、オリジンを外部公開しないままCloudFrontから接続できるようにするものです。S3やパブリックに公開されたALBをオリジンとする従来の構成とは、内部的に別の経路を通ります。

AWSが公表した説明によれば、今回の障害は「VPC Originsへの接続を処理するサーバー群(fleet)が内部的な制約に達し、ネットワークプロセッサへのルーティング設定を配信するシステムが、更新済みの設定データを正しく読み込めなくなった」ことが原因です。この「内部的な制約」の具体的な中身や、恒久的な再発防止策については、記事執筆時点でAWSから詳細な公表はありません。

私たちが自社のクラウド依存構成をどう点検しているか

私たちは複数のクライアントのプロダクトを開発・運用の両面で預かっています。案件ごとにCDN・マネージドデータベース・認証基盤といった外部のマネージドサービスに依存する構成を組みますが、今回のような障害は「サービス全体が落ちる」のではなく「特定の機能・オプションだけが落ちる」形で起きることがあります。構成を点検する際に私たちが意識しているのは、①各サービスのどの機能(オプション)を使っているかを構成図として明示しておくこと、②その機能が止まった場合に別経路(別のオリジンタイプ・別の認証方式など)へ切り替えられるか、切り替えにどれだけ時間がかかるかを事前に把握しておくこと、③障害発生時は原因の特定より先に切り替えの実行を優先できる手順になっているか、の3点です。CloudFrontのように長く使われてきた基盤でも、比較的新しく追加された機能の単位でリスクが切り分けられているという今回の構図は、クラウド依存構成を点検するときの着眼点の一つになります。

まとめ

AWS CloudFrontの今回の障害は、基盤全体が壊れたのではなく、2024年後半に追加された「VPC Origins」という一機能に閉じた内部的な制約から起きました。影響はこの機能を使っている顧客に限られ、他のオリジンタイプでは問題は起きていません。今回のCloudFrontの事例は、長年使われてきた大規模なクラウド基盤であっても、その中の個々の機能まで同じように成熟しているとは限らない場合があることを示す一つの実例です。どのサービスを使っているかだけでなく、そのサービスのどの機能をどう使っているかまで一段掘り下げて把握しておくことが、今回のような部分的な障害への備えになります。