AWS大規模障害についての見解

2025年10月20日、AWSのus-east-1リージョンで障害が発生しました。多くの方がこの大規模障害の影響を受けたのではないでしょうか。

私もその一人で、業務中に思いっきり巻き込まれました…。クラウドインフラのスケールの大きさと、それに伴う依存関係の複雑さを改めて痛感した一日でした。

今回はこの障害について、技術的な視点からざっくり振り返りつつ、パブリッククラウドのリスクと恩恵について少し考えてみたいと思います。

何が起こったのか？

AWSのステータス更新や報道によると、障害は日本時間の10月20日午後、主にus-east-1（バージニア北部）リージョンで発生しました。

原因： us-east-1でDNS解決の不具合が起き、それがDynamoDBのAPIエンドポイントに影響したようです。
連鎖反応： このトラブルが、DynamoDBに依存していたEC2のコントロールプレーン（インスタンス起動など）や、NLB（Network Load Balancer）のヘルスチェック機能など、他のサービスにも波及しました。

ここで日本のエンジニアは「自分は関係ないかな」と思った方も多少なりともいたかもしれませんが、実は東京リージョン（ap-northeast-1）で作業していた私にも影響が出ていました。

具体的には、VPCエンドポイントの設定修正作業でエラーが出たり、IAMロールの新規作成や更新がうまくいかないといった事象が発生。

これは、us-east-1がIAMやRoute 53など、AWSのグローバルサービスの「コントロールプレーン」が動いている特別なリージョンだからです。

東京リージョンにワークロードがあっても、管理操作はus-east-1を経由するため、影響を受けてしまうというわけです。

AWSはマルチリージョン構成を推奨しているのに、どうして重要な機能がus-east-1に集中しているのか？

考えられる理由はこんな感じです：

歴史的背景： us-east-1はAWSで最初に作られたリージョンで、規模も最大。多くのサービスの基盤がここにあります。
コントロールプレーンとデータプレーンの分離： 管理操作（コントロールプレーン）はus-east-1に集約されていて、実際のサービス提供（データプレーン）は世界中に分散されています。今回もIAMの認証などは問題なく動いていました。
グローバルな一貫性の確保： IAMのように全リージョンで整合性が必要なサービスは、分散させるよりも一箇所に集約した方が技術的に安定しやすいという事情があります。

もちろん、AWS側でもAZ（アベイラビリティーゾーン）による冗長化や、ある程度のマルチリージョン冗長化はしているはずですが、今回のようにリージョン全体に影響が及ぶ障害は起こり得るということが分かりました。

こういう大きな障害が起きると、「やっぱりクラウドは危ない」「オンプレに戻るべきだ」みたいな声が出てきますよね。

でも、私はそれに対してちょっと冷静になった方がいいんじゃないかなと思っています。

AWSのようなパブリッククラウドから、私たちは本当に多くの恩恵を受けてきました。

こうして見ると、クラウドのメリットってやっぱり大きいんですよね。多少のリスクがあっても、それを上回る価値があると思います。

大事なのは「クラウドを使わない」ことじゃなくて、「クラウドの仕組みを理解して、ちゃんと備える」こと。

AWSはインフラの可用性を担保してくれますが、その上で動かすアプリケーションの設計（例えばマルチリージョン構成にするかどうか）は、私たちユーザーの責任です。

今回の障害は、そのことを改めて教えてくれた気がします。

今回の障害は、私たちの社会がどれだけクラウド、特にAWSに依存しているかを浮き彫りにしました。

でもこれは、クラウドが失敗したというより、それだけ普及して成功している証拠なんじゃないかと思います。

AWSのシェアがこれで大きく落ちるとは思えません。むしろ、今回の経験をもとに、us-east-1の強化や、障害の影響範囲を狭める改善が進むはずです。

そして私たちユーザーも、障害を前提にした、もっと強いアーキテクチャ設計の重要性を学びました。

この出来事は、クラウドがさらに成熟して、もっと頼れる存在になるための大事なステップだったんじゃないかなと、私は思っています。

私のことは嫌いになってもいいですが、、クラウドのことは嫌いにならないで！！