us-east-1リジョンでAWSの複数サービスで障害発生

• AWSのus-east-1リジョンにあるさまざまなサービスで障害が発生
• この障害によりクラウドインフラ利用企業がサービス停止を経験
• API Gateway, Lambdaなど主要サービスの可用性問題が報告
• エンジニアは迂回経路の整備と緊急対応策の検討が必要になる可能性を認識
• AWS Health Dashboardでリアルタイムの障害情報と更新が提供される

---

AWS us-east-1 リジョン障害概要

• 2025年10月21日、AWS Health Dashboardでus-east-1リジョンに属する複数サービスに障害が発生
• 代表的にAPI Gateway, Lambda, S3など重要サービスが影響を受け、多くの顧客がサービス中断を経験
• 障害が発生した時点からAWS側が問題を認知し、原因分析と復旧作業を即時開始
• 当該リジョンに依存するSaaS、スタートアップ、IT企業でサービス遅延およびダウンタイムが報告される
• エンジニアとIT管理者は緊急迂回経路の構築、重要サービスのリージョン冗長化戦略の必要性を強調

障害の影響と対応

• us-east-1リジョンはグローバルクラウドインフラで最もトラフィックが多い地域の一つで、障害時の波及効果は非常に大きい
• 実際に多くの顧客企業でサービス提供停止、API応答遅延、データ処理障害などの問題が同時に発生
• AWSはHealth Dashboardを通じてリアルタイム状況を通知し、サポートドキュメントとアップデートを提供
• 顧客企業のITチームは障害状況の監視、一時的な迂回、ユーザー向け告知によって影響を最小化する取り組みを実施

エンジニア向け示唆

• 障害発生時のモニタリングシステムと障害通知体制の重要性を再確認する必要が示された
• マルチリージョン展開、自動化された障害対応、バックアップ戦略などレジリエントなアーキテクチャ設計の価値が際立つ
• AWS Health Dashboardは障害状況での迅速な情報確認と意思決定支援ツールとして活用される

結論

• 大規模クラウドサービス事業者は必須的にサービス障害の可能性に対する備えを整備する必要がある
• 障害発生時の迅速な復旧プロセスと透明なコミュニケーション、そして効率的なインフラ障害対応能力の重要性が改めて明確になった

[GN⁺]

Hacker Newsのコメント

• 今日は本当に興味深い一日だった。午前3時からインシデント対応ブリッジに参加していた。システムはほぼ復旧したが、バックオフィス側ではまだリソース不足に苦しむ部署がある。私たちが最大に失敗したのは、マルチリージョンで動くよう設計しておきながらフェイルオーバー手順を実行できなかったことだ。理由は、セキュリティチームが我々を Identity Center に移行させた際、それを us-east-1 のみに配置したため、会社全体が AWS コントロールプレーンに完全にロックされた状態になったからだ。ルートクレデンシャルを金庫から取り出したときには、すでにシステムはほぼ復旧していた。この件は、弱い一部が全体の強さを決めることを改めて思い出させた
  • 数年前、Googleのパリデータセンターが浸水後の火災で騒然となったときを思い出す。私たちはそこにコンピュートリソースを直接置いたわけではないが、AWS EUデータセンターで計算しており、Googleサービス向けDNSリゾルバがパリにホストされていたため、接続経路はパリへ優先ルーティングされていた。暫定的な解決策はかなり面白かった。当時、Kubernetesにデプロイした /etc/hosts を全体で簡単に編集できることを初めて知り、実際に必要なほど必死だった。普段ならその用途で /etc/hosts を使うことはないが、応急パッチとしてはちょうどよい抽象化だった
  • FacebookがBGP更新のミスでボールトアクセスを完全に不可能にしていた似たような例が思い出される。認証経路が循環構造なら、DNSが一度壊れると何もできなくなる
  • 最後には誰かがハードウェアトークンを持って別データセンターへ飛行機で移動し、世界中のシステムを動かす主要装置をリセットしなければならない瞬間が来る
  • Identity Centerをus-east-1のみに置いている話が出ていたので、複数リージョンに置けるか気になる。最後に確認したときは1リージョンでしか使えず、移動するにはまず削除する必要があった
  • 過剰なセキュリティ境界は逆に動けなくしてしまう。セキュリティチームが今回の責任を取るのか気になる。これで今後はすべてのプロジェクトが遅くなりそうだ。セキュリティチームはこれまであまりにもスリルを追いかけてきたようだ。監督者を監督する者は誰かという問いが残る
• まだ主要な障害が続いているようだ。4時間前より状態はさらに悪い。私はデータエンジニアで、RedshiftとAirflow（AWSのマネージドサービス）が完全にめちゃくちゃだ
  • 障害がかなり長引いているので、いくつの9が消えたのか気になる。365日×24時間×0.0001を計算すると約8時間で、すでに99.99%の可用性を失っていることになる
  • どうしてまだ多くの企業がus-east-1に固執するのか分からない。障害の頻度で見れば圧倒的に最悪だ。うちの会社は以前、us-east-1を避けて他リージョンのみを使うと決めた。もちろんサービスが「グローバル」と言っていても実質的にus-east-1を意味する場合は、そうした配慮が役立たないこともある
  • Lambda create-functionのコントロールプレーン作業はまだ InternalError で失敗している。ほかのサービス（Lambda、SNS、SQS、EFS、EBS、CloudFront）は回復済み。私はクラウド可用性をテーマにしたCS修士研究をしており、複数のAWSテストアカウントで検証しながら障害のタイムラインと影響を整理して記事に残した。分析ポスト
  • Down DetectorではAWS障害が依然深刻であることが示されている。Amazon側は「サービスは復旧中」と言うが、実際にはAmazon.comでも商品検索ができない。AWSヘルスページ
  • Down Detectorを見ると、PT 12:52（ET 3:53）時点でAWS問題の報告は5,755件だったが、PT 4:22（ET 7:22）では1,190件に減少し、PT 9:32（ET 12:32）には再び9,230件へ急増した。米西部で目が覚めた影響で報告が増えた可能性もあるが、AWSはまだ状況をしっかり制御できていないようだ
• 今回の障害は私の日常にも直接影響した。ニューヨークの Hudson Yards Whole Foods でチョコレートバーを買おうとしたがプライム割引が適用されず、結局買わなかった。なのでチョコレート在庫はかなり減った
  • 今朝は「alexa、コーヒーポットつけて」と言っても反応しなかった。気が遠くなるような感覚だった
  • 昼食でホットバーの料理を詰めてセルフチェックアウトしようとしたら、なぜWhole Foodsのバーコードが動かないのかしばらく考えていた。20秒ほどしてからようやく、障害のせいだと気づいた
  • 面白い事例を共有してくれてうれしい。そういえばAWS障害が起きたときAmazon Goにいた人たちはどうなったのか、気になる
• 今日AWSアカウント担当とミーティングがある。これから「All in on AWS」から抜けてワークロードを分散する方針を説明する予定だ。主な理由は、コアサービスのイノベーション速度が鈍化し、AIサービスも競合に対してあまりに遅れているからだ。AWSチームは常にAWSの圧倒的な安定性を理由に、クラウド分散をしないよう主張してくる。今日の会議が楽しみだ
  • AWS、Cloudflare、Google Cloud、Akismetなど、どこでも一度は障害を経験する。そうなるたびにインハウス運用に戻ることを考える。最終的に払い戻しを受けてまた動かすことになる。結果は似ているので、わざわざもっと苦労する必要はない
  • 先日の業績発表でAndy JassyがAWSの革新遅れを指摘されると、主張したのは安定性、信頼性、耐久性だった。しかしいまの状況を見ると、その言い訳は通らない
  • us-east-1を除けば、他のリージョンはかなり安定して運用されている。うちの会社もほとんどeu-west-1に置いているだけで、事故なしに問題なく動いている
  • AWSは長期的に衰退しつつある。いまは既存サービスの維持にとどまっている印象だ。革新的な人材が社内の官僚主義と成果圧力で押しつぶされ、AIでも遅れが生じている
  • AWSの優れた安定性という主張は最初から真実ではなかった。以前、複数のクラウドと専用サーバーでマルチクラウド監視を組んだとき、どこが最初に壊れるかを実際に見られた。結果を見るとAWSが常に1位ではなかった。netcraft.comのデータともほぼ一致していた
  • 今日のプレミアリーグも、VARと自動オフサイド判定システムがAWS障害のため限定的にしか運用されない予定だ。本当に奇妙な時代を生きている。BBCリンク
    • クラウド（障害）には一つだけプラス要素があると感じる
• us-east-1を主要リージョンにすると、障害が起きたときみんな同時に止まるので、誰かだけが苦労することはない。他の米国リージョンではこの特権は得られない
  • 元のデータセンターからAWSへ移行したときの予期せぬ利点の一つは、リージョン全体がダウンした場合、顧客の理解がかなり増えることだった。皆が同時に不便を感じるため、ただそれで済む
  • 時々は誰もが技術ダウンタイムを一度は経験する必要がある
  • よし、みんなでUS-East-1にインフラを上げよう
  • 企業環境で本当に重要なものに気づくのにかなり時間がかかる。実際には可用性より、誰かのせいにできる構造が重要だ。スタッフのミスで1年に5分停止するとCTO責任だが、AWS障害で5時間停止すると、全員が不便を感じるだけなので「仕方ないこと」とされる。AWSやCrowdstrikeも結局、システムの堅牢性、コストパフォーマンス、リスク管理ではなく、みんなが一緒に苦しむ時代のほうが重要だ。残念だが現実そのもの。技術がうまく動くのが好きな人間としては悔しい
  • 東京リージョンは今問題なく動いている！ただコンソールログインなど一部の機能にはまだ問題がある
• 「調査の結果、US-EAST-1のDynamoDB APIエンドポイントのDNS解決問題と関連があるようだ。復旧を加速するために、並列経路で作業中である」という通知があった。やはり原因はいつものDNSだ
  • 今回の障害が本当にDNS解決問題か、DNSサーバーの内部設定・データストア問題かも疑問だ。どちらかというと後者だ
  • のちの障害通知はネットワーク・ロードバランサーの失敗を原因として挙げている。DNSは根本原因の『症状』だった。DNSがヘルスチェックを壊した可能性はあるが、私の見立てでは主原因はネットワーク側だ
  • BGPがDNS問題に擬装している可能性もある
  • 原因はいつもus-east-1だ
  • DNSでなくても、結局DNSだ
• レジリエンスを見越して設計どおりに機能した。CloudFrontでマルチリージョンの static サイトのオリジンを置いていたため、今回の障害の影響を受けなかった。コントロールプレーンもネイティブのマルチリージョン構造で、複数サービスに依存しているが可用性は維持された。各リージョンが独立して動作し、データ複製は行うがus-east-1への複製がなくても問題ない。サービス自体はマルチリージョン構造で、フェイルオーバーを複数レイヤー（DNS、ルーティング、宛先選択）で処理する。もちろんこの方法も完璧ではなく失敗要因は多いが、今回はうまくいってほっとした。私がやったことは決してロケット工学でも高価でもないが、慣習とは少し違うアプローチだ。質問があればいつでもどうぞ
  • CloudFrontでマルチリージョンの static オリジンを置いて障害を避けたのは、2025年なら当たり前のはずなのに、今なお称賛されるものだ
  • active/active構成なのか、データスタックはどうなっているのか気になる。ここが特に難しいと思う
  • 鍵と証明書のための耐障害認証をどのように実装しているのか気になる
• 一つの大きな問題は、IAM/認証系統が過負荷または停止したことによって連鎖障害が起きた点だ。DynamoDBが原因という話があるが、IAMも内部的にDynamoに依存しているのか気になる。巨大で複雑なシステムでは依存関係が入り組んでおり、Auth/IAMはグローバルな単一障害点になるリスクがあるため依存を最小化したい。だが拡張性や一貫性も重要なので、実績あるDBを使わざるを得ない。結果として依存は複雑化し、システム停止時には複雑なブートストラップを経るしかないのではないかと思う。どう処理しているのか気になる
  • 2017年ごろDynamoDB障害で大規模障害があった。EC2がサーバー一覧をDynamoDBに保存していたが、DynamoDBが落ちるとEC2も落ちた。DynamoDBがEC2上で動いていたため、新しいEC2インスタンスを起動して復旧することもできなかった。だから数日、手作業でインスタンスを起動しながら復旧した。この経験以来、S3、DynamoDB、EC2など1層システム間の依存をできるだけ分離する方向で取り組んできた。もちろん完璧にはできない
  • 多くのAWS顧客が間違ったリトライポリシーのため、片側が障害になっただけで他方まで過負荷をかける場合が多い。DynamoDB障害がIAMまで過負荷につながった
  • Amazon内部にはDynamoというKVストア基盤が別に存在し、DynamoDBとは異なる。だから障害原因はDNSルーティングやノード展開の問題かもしれない。この種の問題は大規模障害のポストモーテムで繰り返し現れる
  • AWS在籍時はIAMはDynamoに依存していなかった。いまは変わっているかもしれないが確証はない。大規模ネットワーク障害の影響の可能性が高そうだ。Auth/IAMがグローバルな単一接点になってはならないので依存を最小化する設計になっている。IAMは各リージョンごとに読み取り専用キャッシュがあり、AWS SigV4もリージョン別動作を前提に設計されている。(参考文書)
  • 最近のGCP障害の原因も同様の問題だったのが興味深い
• AWSはPT 3:03に復旧中と通知したが、状況はむしろ悪化した。PT 9:13には再び原因分析中だという。AWS自身も正確な原因を分からないようで不安だ
  • 今回のことはディワリ（インド最大の祝日）の週だったため、インドのエンジニアが休暇中だったことも影響したようだ。まさに不運だった