Amazon Web Services（AWS）の北バージニアリージョンで発生したデータセンター冷却系の障害が、暗号資産取引所Coinbaseの取引サービスに波及した。障害は米国時間2026年5月7日、AWSのUS-EAST-1リージョン内にあるAvailability Zone（AZ）「use1-az4」で起きた温度上昇をきっかけに、EC2インスタンスやEBSボリュームへ影響したものだ。AWSは影響を受けたAZから大半のサービスのトラフィックを逃がし、顧客には同リージョン内の他AZを使うよう促した。
Coinbaseは、同社サービスの性能低下と取引不能がAWS障害に関連すると告知し、復旧過程で全市場を一時的に「Cancel Only」モードへ移した。これは既存注文の取消を優先し、新規注文を段階的に再開するための措置である。最終的にCoinbaseは全市場の取引再開を案内したが、24時間稼働を前提とする暗号資産市場において、単一クラウドリージョン内の物理障害が取引所の利用可否を左右する現実を改めて示した。
同じ時間帯にはCME GroupのCME Directでも技術・レイテンシ問題とメンテナンスが報じられた。ただしReutersによれば、CME側はAWS障害の影響を受けていないと説明している。したがって今回の焦点は、CMEをAWS障害の被害例として並べることではなく、Coinbaseのような市場インフラがクラウドの障害境界とどの程度切り離されているのかにある。
AWSで起きたのは「リージョン全体停止」ではなく、use1-az4の熱と電源の問題
AWSの公開情報と各社報道を総合すると、今回の障害はUS-EAST-1全体が一斉に落ちた事象ではない。起点は北バージニアの単一データセンターで発生した急激な温度上昇であり、対象はUS-EAST-1内のAZ ID「use1-az4」だった。AWSは、この熱イベントに伴う電源喪失の影響を受けたハードウェア上のEC2インスタンスとEBSボリュームに障害が出たと説明している。
AWSのAZは、リージョン内の独立した場所として設計されている。公式ドキュメントでは、各AZは1つ以上の独立したデータセンターで構成され、電源、ネットワーク、接続性を冗長化し、別施設に収容されると説明されている。また、AWSはアプリケーションを複数AZに配置することをベストプラクティスとしている。US-EAST-1は公式一覧で6つのAZを持つリージョンで、use1-az1からuse1-az6までがバージニア州に置かれている。
つまり、AWSの設計思想から見れば、今回の障害は「AZという故障境界の中で起きた物理障害」である。問題は、その境界で止められるはずの影響が、顧客側の構成や依存関係を通じてどこまで外へ漏れたかだ。AWSは復旧時、影響AZから多くのサービスのトラフィックを退避させ、既存の他AZ上のインスタンスは影響を受けていないとして他AZ利用を推奨した。これはクラウド事業者側の典型的な切り分けだが、顧客のアプリケーションがAZ障害を前提に設計されていなければ、推奨どおりに即座に逃げられるとは限らない。
Reutersは、AWSが追加の冷却能力を投入していたものの、残る影響システムを安全に戻すには数時間を要すると説明したと報じた。TNWも、AWSが完全復旧時刻を明示せず、追加冷却による安全な再起動に時間がかかっていると伝えている。単なるサーバー再起動ではなく、熱と電源に絡む物理インフラの復旧では、機器を急いで戻すこと自体がリスクになる。
Coinbaseの障害は、資産保全よりも「取引所としての縮退運転」を問うものだった
Coinbaseの利用者に見えた影響は、Webやモバイルでの取引不能、性能低下、取引再開の段階化だった。同社はステータスページやサポート投稿で、顧客資産は安全だと説明しつつ、AWS障害により一部ユーザーが影響を受けていると案内した。取引再開にあたっては、全市場をCancel Onlyモードに置いた後、通常取引へ戻す手順を取った。
Cancel Onlyは、障害復旧時に市場をいきなり通常状態へ戻さないための重要な段階である。利用者は既存注文を取り消せるが、新規の成行注文や指値注文は受け付けない。これにより、復旧直後の価格乖離や注文帳の不整合、遅延した注文処理による混乱を抑えられる。暗号資産市場は週末も夜間も閉じないため、株式市場のように取引時間外で落ち着いて復旧させる余地が小さい。
今回の事故が示したのは、Coinbaseが顧客資産を守れたかどうかだけではない。より実務的な問いは、取引所の各機能がどの単位で縮退できるかである。ログイン、残高参照、注文取消、新規注文、入出金、API、マーケットデータは、それぞれ停止時の優先順位が違う。資産の保全を宣言できても、利用者が注文を取り消せない、価格を見られない、ポジションを調整できないなら、市場サービスとしてのリスクは残る。
Coinbaseの内部構成は公開情報だけでは確定できない。どのサービスがuse1-az4に依存していたのか、どのデータストアやメッセージング基盤が復旧のボトルネックになったのかも、現時点では分からない。だからこそ、同社の事後説明で見るべき点は「AWSで障害が起きた」という外部要因の確認ではなく、どの機能がどの障害境界に巻き込まれ、どの段階復旧で利用者リスクを下げたかである。
AZは魔法の冗長化ではない、アプリケーション側が使い切って初めて効く
AWSの公式ドキュメントは、AZをリージョン内の独立した場所として説明し、アプリケーションを複数AZへ展開することを推奨している。この設計は、単一の火災、洪水、電源障害、ネットワーク障害がリージョン全体を巻き込まないようにするためのものだ。だが、AZが複数あることと、顧客のサービスがAZ障害をまたいで動き続けることは同じではない。
実際のアプリケーションは、コンピュート、ストレージ、キュー、データベース、キャッシュ、認証、監視、デプロイ基盤などの集合体である。フロントエンドだけが複数AZに分散していても、注文処理キュー、照合エンジン、セッション管理、リスクチェック、KYCや入出金連携の一部が単一AZに寄っていれば、利用者から見た可用性はそこで決まる。金融サービスではさらに、単に書き込み先を別AZへ切り替えるだけでは済まない。重複注文、約定順序、残高整合性、監査ログ、規制報告の整合性まで守る必要がある。
この点で、今回の障害はクラウド批判だけで片付けると読み違える。AWS側の責任範囲は、AZ内の冷却、電源、ハードウェア、クラウドサービスの復旧である。一方、Coinbaseのような顧客側には、特定AZが使えなくなっても業務上重要な機能をどう維持するかという設計責任がある。高可用性は、クラウド事業者が提供する部品と、利用者がその部品をどう組み合わせるかの掛け算で決まる。
特にUS-EAST-1は、AWSの中でも利用が集中しやすいとみられるリージョンだ。公式リージョン一覧では、US East (N. Virginia) は6つのAZを持ち、デフォルトで利用可能な主要リージョンの一つとして扱われている。歴史が長く、対応サービスが多く、米国東部のユーザーや企業システムに近いリージョンでは、一般に既存システムの依存が蓄積しやすく、移行も簡単ではない。
2025年10月のDynamoDB障害とは原因が違うが、露呈した構造は似ている
US-EAST-1をめぐっては、2025年10月にも大規模なAWS障害が発生している。AWSのポストイベントサマリーによれば、この障害はDynamoDBのDNS管理システムに潜んでいたrace conditionがきっかけだった。DynamoDBのリージョナルエンドポイントのDNS解決に失敗し、その後、EC2の新規インスタンス起動、Network Load Balancer、Lambda、ECS、EKS、Fargateなど複数サービスに段階的な影響が広がった。
2025年10月の障害と今回の冷却障害は、技術的な原因がまったく違う。前者はDNS管理自動化の論理的な欠陥であり、後者は温度上昇と電源影響を伴う物理インフラの問題である。それでも、利用者側から見た教訓は重なる。巨大なクラウドリージョンでは、物理的なAZ、論理的な制御プレーン、共通のデータサービス、顧客アプリケーションの依存関係が複雑に重なっている。どこか一つの境界で起きた障害が、想定以上に大きな業務影響として表に出ることがある。
この構造は、AI時代のデータセンター運用とも無関係ではない。Reutersは、AIやクラウドサーバーは大量の電力を消費し強い熱を出すため、データセンター各社が水冷や特殊冷媒などに頼る場面が増えていると指摘している。ただし、今回のAWS障害がAIワークロードの増加によって引き起こされたとは確認されていない。ここを飛躍して断定すると、記事としても技術的にも危うい。
今後AWSの正式なポストイベントサマリーが出るなら、見るべき論点は少なくとも4つある。第一に、温度上昇の直接原因が冷却設備、電源、運用手順、外部条件のどれだったのか。第二に、なぜ影響がEC2とEBSのどの範囲に及んだのか。第三に、影響AZからのトラフィック退避や追加冷却投入にどれだけ時間を要したのか。第四に、顧客側が即時復旧に必要なスナップショット復元や他AZ再作成を行える状態だったのかである。
次に問われるのは、マルチAZ構成の有無ではなく復旧手順の実効性だ
今回のCoinbase障害は、クラウドを使うべきか否かという単純な議論よりも、縮退運転の設計に踏み込んで見るべき事例である。マルチAZ、マルチリージョン、マルチクラウドという言葉は便利だが、金融市場サービスではそれぞれにコストと副作用がある。同期レプリケーションを強めれば遅延が増え、非同期にすればフェイルオーバー時の整合性判断が難しくなる。複数クラウドへ分散すれば、障害境界は広がるが、運用と監査の複雑性も増す。
それでも、24時間市場を支える取引所が「クラウド側の単一AZ障害だから仕方ない」と説明するだけでは足りない。利用者が必要とするのは、障害時に何ができ、何ができず、どの順番で復旧するのかという予測可能性である。注文取消だけは先に戻すのか、API利用者とWeb利用者を同じ扱いにするのか、入出金や残高表示を取引再開より優先するのか。こうした判断は、障害発生後ではなく、平時の設計と訓練で決まる。
AWS側にも、今回の正式な原因説明が求められる。AZは「独立した故障境界」として売られているからこそ、単一AZの物理障害がどこまでサービスレイヤーへ波及し、どの時点で顧客に他AZ利用を促したのかを明確にする意味がある。Coinbase側には、AWSの復旧を待つだけでなく、どの依存関係が取引停止に直結したのかを説明する責任がある。
北バージニアの一つの暖かすぎるデータセンターは、暗号資産市場全体を止めたわけではない。しかし、米国最大級の暗号資産取引所の一部機能を止めるには十分だった。クラウドの冗長化は、カタログ上のAZ数ではなく、障害時に利用者がどの操作を続けられるかで測られる。今回の事故が残した本当の宿題は、そこにある。
