- 世界最大のクラウドサービスであるAWSの障害で、数千のウェブサイトとアプリが停止し、インターネットインフラが少数企業に過度に依存していることへの警告が提起された
- Snapchat, Roblox, Signal, Duolingoなど主要サービスや、**Lloyds Bank, Ring, HMRC（英国税務当局）**など公共・金融機関まで障害の影響範囲に含まれた
- AWSは米国東部リージョン（US-East-1）の内部システムエラーを原因として挙げ、サイバー攻撃の可能性は除外し、数時間でほとんどが復旧した
- 専門家は「民主的な議論と独立したジャーナリズムの基盤が少数企業インフラに依存してはならない」と述べ、クラウドインフラの分散化の必要性を強調した
- 大手クラウド企業中心の構造が世界のインターネットの脆弱性を露呈したという評価とともに、公共インフラの技術主権に関する議論が喚起された
障害の概要
- AWSの**米国東部リージョン（US-East-1）**で発生した内部エラーにより、世界規模で多数のサービス停止が発生した
- 現地時間の月曜日午前8時（英国時間16時）ごろから障害が発生
- Amazonは「APIエラー率とレイテンシ（遅延）が増加した」と発表
- Downdetectorによると、世界で約2,000社が影響を受け、米国190万・英国100万・オーストラリア41万人以上が問題を報告
- AWSは「内部ロードバランサー監視サブシステムの問題」を原因と指摘し、サイバー攻撃の可能性を排除した
- AWSのDynamoDB関連のエラーでAPI応答が失敗したと報告された
- トラフィックの急増を防ぐためリクエスト数制限を一時的に導入
- AWSは夜のうちに「正常運用への復帰」を公式発表したが、一部サービスでは継続的な障害報告を受けていた
影響範囲
- 主な影響サービス：Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Pelotonなど多数
- 英国ではLloyds, Halifax, Bank of Scotlandなど金融サービスと**HMRC（英国税務当局）**のウェブサイト接続障害が発生
- Ringドアベル利用者は、玄関開錠監視サービスが中断したと不便を訴えた
- Epic Games, Pokémon Go, Wordleなどのグローバルプラットフォームでも接続不可の報告があった
専門家の分析
- Dr. Corinne Cath-Speth（Article 19）：「民主主義の議論と独立系ジャーナリズムの基盤が少数企業インフラに依存するのは危険だ。クラウド分散化は喫緊の課題だ」
- Cori Crider（Future of Technology Institute）：「英国は米国ビッグテックへの依存から脱却すべきだ。AWS一社の障害で現代経済全体が停止した事例だ」
- Madeline Carr（UCL）：「大手クラウド企業の資本力によりセキュリティとスケーラビリティは維持されているが、世界中が同じリスクに縛られる構造は非常に危険だ」
- Steven Murdoch（UCL）：「サイバー攻撃ではなくAWS内部運用の過誤が原因と推定される」
政府および規制対応
- 英国政府はAWSと緊急連絡体制を立ち上げ、復旧状況を監視したと発表した
- 英国下院財務委員会は、AWSを金融部門の『重要第三者（critical third party）』に指定するべきだと求めた
- 指定されれば金融規制当局の監督対象となり、金融インフラの安定性確保が可能となる
- 委員長のMeg Hillierは「AWSは‘レジリエンス’を提供すると言いながら、実際には脆弱性を露出した」と批判した
背景と示唆
- AWSは世界のクラウド市場シェア30%以上で首位を占める
- Microsoft AzureとGoogle Cloudとともに、**『3大クラウド寡占構造』**が形成されつつある
- 2024年にもCrowdStrikeのソフトウェアエラーにより、世界中のWindows PCで“ブルースクリーン”事故が発生した
- 今回の事態はデジタルインフラの集中化がもたらすシステムリスクを再度浮き彫りにし、各国政府の技術主権とクラウド分散戦略に関する議論を活発化させた
3件のコメント
ネイバー・クラウド、がんばれ！
「クラウドが嫌なら自分で構築して使え」と言われて、議論なんて成立するのだろうか。
マルチクラウド？構築と運用管理は、先祖が代わりにやってくれるわけでもないし。
Hacker News の意見
現在、AWS us-east-1 で複数のサービスが停止中であることについて議論されており、関連する長いスレッドはこちらにある
2021年の Fastly 障害の時にも「専門家」と呼ばれる人々が同様の批判をしていたが、実際には明確な変化はなかった。この種の話題は1週間後には新聞でも取り上げられなくなることが多い。実務者は AWS の規模で運用することがどれほど難しいかを知っている。こうした状況に備える本当の対策は費用が非常に高く、ほとんどの企業では費用対効果が極めて低い。もし本当に「致命的」なサービスなら、このような障害に備えて設計するのが当然だ。Fortnite にログインできないことは、そうした対策を現実的に実装するのが簡単ではなく、どれほどのコストがかかるかを示している。メディアも普段はマルチリージョンやマルチクラウドの重要性を取り上げず、事故が起きるときだけ触れてすぐ忘れてしまう。結局、みんなが知りたいのは技術的な原因だけだ。フォローアップのない「専門家」の非難はあまり意味を持たない。重要なのは、非難だけでなく建設的なインシデント対応と、責任追及をしない事後分析である
クラウド依存を批判していると、結局 1 年に 16 時間を超えるダウンタイムを前提にすることに同意してしまうことになる。数時間の障害は個人にとっては体感しやすいが、実際には残りの 8,742 時間のパフォーマンス低下のほうが致命的なことがある。もし 16 時間のダウンタイムで会社が潰れるなら、私も相手もそのビジネスをよく理解していないだろう。私は高可用性、地理的冗長化、耐久性の高いシステムにより関心がある
必要だからといって莫大な費用をかける必要はない。サービスごとに耐えるべきレベルは同じではない。異なるプロバイダを2つ用意すれば、全社的に同時障害を受けることはなくなる
新聞で扱われるマルチリージョン／マルチクラウドの冗長化は、実際の効果が薄いことを強調している。見た目上は1つのリージョンだけの問題に見えても、実際には複数リージョンに跨ってサービスが影響を受けるケースが多い。マルチクラウドのホットスタンバイは、インフラが複雑になるほどコスト負担がかなり大きい。最初から計画せずに後から導入するのは非常に難しい
AWS の報告書を見ても、特定のリージョンや特定のサービス（例: DynamoDB）に過度に依存している。10 年以上このような集中型アーキテクチャが観察されてきた。そのため変わらないのはなぜか疑問だ。今回の障害で、2,000 以上のサービスが長時間ダウンした。AWSステータスページを参照
「クラウド」や「インターネット」という言葉を「バージニアの倉庫」と言い換えてみるべきではないか。例えば「我々のサービスは完全にバージニアの倉庫にある」「私のすべてのファイルはバージニアの倉庫にある」「バージニアの倉庫は核戦争に耐えるよう設計されている」など。原文
すでにさまざまな VPS 会社が存在しており、そちらへ移行してコストを下げたという事例が継続的に上がっているなど、実態はクラウドロックインとマーケティングの問題である
今の企業は低レイヤーの IaaS である EC2 のようなものではなく、DynamoDB、RedShift など AWS の高レベルの PaaS を使うことが多い。Azure、Google Cloud も同様だ。このような高レベルサービスに依存していると、Hetzner のような VPS やセルフホスティングへの移行は、AWS スタックを再構築して運用することになるため極めて複雑になる。PostgreSQL をインストールすれば解決する話ではない
いつも「AWS の VPS に移してコストを下げた」という記事には、「AWS はウェブスケールで絶対落ちない、VPS は1か月でも1日しか稼働率がない」という反論が付く
アマゾンも EC2 のような VPS を提供しているのに、今回の障害で EC2 が影響を受けたのか気になる
専門家の意見は、実は技術より地政学的文脈（例: 国家全体のシステムが海外企業にリアルタイムで依存している問題）に焦点が当たっている。普通の会社が単一サプライヤーに依存することは複雑さを下げ、障害頻度の面でも無理はない。わざわざマルチクラウドを使う必要はない。片方だけ使っていてもダウンタイム頻度が改善することすらある
業界全体がクラウドロックインに陥っていると思う。今後これをどう逆転できるのか疑問だ。Docker も、大手クラウド企業と同様にロックイン問題の一因だと考える
現場エンジニアや運用サポートの立場で言えば、深夜1時に AWS 全体障害で全部崩れたことを発見した際、誰もこの状況を変えようとしないのが現実だ
Docker がなぜ問題なのか知りたい
クラウド現場を離れてから随分経つが、当時は基本機能（primitive）が全てのプロバイダで均されつつあった。マルチクラウド冗長化は、コストが高すぎたのか、技術的差が大きかったのか、あるいはビジネス的に検討する価値すらなかったのか気になる。pets vs cattle スライド
複数クラウドへのデプロイ／運用は、チームの管理・認知負荷が大きすぎる。2つ以上のクラウドインフラについて専門知識を維持するには人員も必要だ。小さなチームや素早いチームには不向き。1つのクラウドを使うシンプルさこそがすなわちアップタイムにつながる。大企業でもほとんどは1クラウドで大口購入して単価を下げる方がメリットがある。そして誰も AWS を選んだからといって解雇されることはない
別のクラウドが自分のリージョンで障害を起こしても対応できない点で、マルチクラウドは実効性が低い。ベンダーは依然として 100% 自社標準を主張しており、コントロールプレーンも Kubernetes。結果としてみんな Kubernetes に収束してしまった
すべてのクラウドがコンピュートは安価に提供するが、ネットワークエグレスは法外に高い。マルチクラウドを組むならトラフィックコストが爆発する。これは意図的だと思う
実際、クラウドはイグレス課金で収益を成り立たせているようだ。そのため、マルチクラウド構成だけでなく、単一クラウド内のリージョンや AZ 間の冗長化も、多くのクラウド/アプリケーションで高すぎる。単一クラウド内のグローバル障害なら、リージョン冗長化も無意味だ。さらに、1クラウドがダウンしたときに他のクラウドへトラフィックを移すのも難しく、費用対労力を考えると割に合わない。多くのアプリケーションでは、その数時間のダウンを受け入れて、その分のコストと労力を別のことに使う方がよい
クラウドにファイル／データを保有する顧客が多いが、ベンダーが別のクラウドだとサービス運用が難しく、実際の顧客獲得にも不利だ。ベンダーがすぐに市場標準になるため、顧客もそのクラウドにデータを集中させるので、両方のクラウドでストレージを使うコストを正当化しにくい。私も当初はプラットフォーム非依存を目指して始めたが、実際にはすべての潜在顧客が同じクラウドを使っているので複雑性が減った
今年は AWS us-east-1 のアップタイムが 2 桁の 9 だけに収まるだろうという予測は、事前に立てることはできなかった
AWS を約20年使ってきた者として、トラフィックが多く重要度も高い us-east-1 をわざわざ選ぶ理由が理解できない。最も古く、最も不安定な場所だ
EC2 のようなインスタンスも実際に影響を受けたのか気になる
皆がダウンすれば免責されるという考えでいるが、実際には一般顧客向けのサービスならそれが通用する経験ではない
今回の障害の原因は、ネットワーク・ロードバランサーのヘルスチェックを担当する内部サブシステムに問題があったことだ。AWS サービスステータスページ