タグ: high-availability

Microsoft Azureで大規模障害発生 ― Microsoft 365やXboxにも影響、原因は構成変更ミス

日本時間2025年10月30日午前1時頃からMicrosoft Azureで大規模な障害が発生しました。これにより、Microsoft Azure、Microsoft 365、Minecraft、XboxなどのMicrosoftが提供する製品やサービスだけでなく、Starbucks、costco、Krogerといった大手企業のシステムにも波及しました。

Microsoftの発表によると、「Azure Front Door（AFD）における誤った構成変更（inadvertent configuration change）」が原因とのことで、この設定変更が DNS ルーティングに影響を与え、Azure Portal や関連サービスにアクセス不能状態を引き起こしたものと見られています。

発生から対応までを時系列に並べると以下のようになります。

  1. 2025年10月30日 午前1時頃（日本時間）
    障害発生を確認
  2. 2025年10月30日 04:19（日本時間）
    「last known good configuration（直前の正常構成）」のデプロイが完了し、ノード復旧を開始し、「今後4時間以内に完全復旧を見込む」と告知
  3. 2025年10月30日 08:20（日本時間）
    Azure側が「recovery to happen by 23:20 UTC（＝8:20 JSTまでに復旧見込み）」と明記
  4. 2025年10月30日 09:40（日本時間）
    最終更新で「AFDサービスが98%以上の可用性を回復し、完全復旧を9:40 JSTに見込む」と発表

日本では、発生した時間自体は深夜ですが、回復に午前9時過ぎまでかかったため、朝一でメールを受信しようとしたらメールが受信できないなどの影響を受けた方もいたかと思います。

クラウド障害のインパクトの大きさ

先日のAWSの障害もDNSに起因するものでした。

AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

DNSで障害が起きるとネットワークを前提としたシステムは非常に脆いことがわかります。加えて、クラウドベンダーが提供して責任を持つ部分であるため、DNSで障害が起きると複数のサービスに影響がおよび、それらのサービスを使用している複数の企業が影響を受けます。

この点については、各企業ごとに対策することが難しい場合が多いです。クラウド上でシステムを運用しているならマルチクラウドという選択肢はあるにはあります。ただし、コストとトレードオフになるため、事業規模によっては選択肢できない場合もあります。

また、IaaSではなくPaaSサービスを利用している場合はそういった選択肢も難しい場合があります。例えば、Microsoft 365で障害が起きた場合、他のベンダーでメールサービスを継続するということは不可能です。インフラを管理しないことに対するトレードオフでもあるので、どうしても障害を起こしたくないのであればインフラを管理する必要がありますが、クラウドベンダー並の可用性を実現できる企業は数えるほどしかないでしょう。

もう一つはこれが誤設定によるものであるという点です。過去に発生した大規模障害においても、誤った設定を適用した場合や操作ミスといった単純ミスによるものであったことがありました。これはMicrosoft Azureに限ったものではなく、他のクラウドベンダーでも起きています。

具体的な内容については公表されていないので想像になりますが、本当にただの凡ミスだったかもしれません。もしかすると、想定していなかった挙動だったのかもしれません。いずれにせよ、本当のところはわからないので一方的に「テストをしていないのではないか」と断ずるのは総計です。実際、DNS周りは想定しない挙動をする場合があるので、本番同等の環境を用意するのは現実的ではないため、テスト環境では問題ないことを確認した上で適用したが、予想しない挙動を示していたのかもしれません。

おわりに

以前のAWSの障害、今回のAzureの障害から言えるのは、

  • 代替の選択肢を持つこと
  • バックアップを3-2-1ルール取得し、復元できることを定期的に確認しておくこと

が重要であるということです。

代替の選択肢を持つというのは、メールの例で言えばメールが唯一の連絡手段になってしまうとメールが使用できなくなったときに業務が完全にとまってしまうので、それ以外の手段を持っておくというです。メールの例でいえば、電話やチャットなど複数の手段があるのが普通だと思いますのでそれほど問題ありません。しかし、空港での搭乗手続きが完全に電子化され、手動での搭乗手続きの手段が失われていたらどうでしょうか？ゲート搭乗機に障害が発生すると運休せざるを得なくなってしまいます。そういった意味では電子化は優れた選択肢である一方でそこに障害が発生したときに、人間の手による代替ができるようになっていることが重要です。

前述の話は機能に障害が発生した場合ですが、データにアクセスできなくなる場合やロストする場合について対策が必要です。古典的な手段ではありますが、現代でも有効な3-2-1ルールに則って、3つのデータコピーを保持し、2種類の異なるメディアに保存し、そのうち1つをオフサイト（地理的に離れた場所）に保管することは非常に有効です。

ただし、いくらバックアップが無事だといってもそこから復元できなければ意味がありません。バックアップを用意していても、いざ復元しようとしたら戻せなかったということは今に始まった話ではなく昔からずっと起きている話です。古くはテープにバックアップしたけどそこから復元できなかったなどということはよくある話ですし、2020年にはバックアップに不備があり障害が起きたときにバックアップから復元できずに売買停止が起きたこともありました。

避難訓練と同じで、災害発生時のマニュアル確認のための訓練やバックアップから復元できるかのリハーサルは義務付けられているものを除くと行っていないケースが多いように思います。日常的にテスト環境を構築するのにバックアップを使っているという場合であればバックアップ自体は使用可能だt思いますが、高度に自動化されている場合は手動でもできるのかといった点や3-2-1ルールに則ってバックアップが完全に失われないかなどを見直すことも重要です。

「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、こういった他社の事例からもしっかりと教訓を得ることは重要です。

参考文献

AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

2025年10月20日（日本時間）、Amazon Web Services（AWS）において大規模なサービス障害が発生しました。障害は主に米国東部リージョン（US-EAST-1）で発生し、世界中の多くのオンラインサービスやアプリケーションが一時的に停止しました。

本稿では、今回の障害の概要と影響範囲、マルチAZ構成を採用していても防げなかった理由、そして今後の設計指針について整理します。

障害の概要

AWS公式ステータスによれば、障害はUS-EAST-1リージョンにおける複数サービス（DynamoDB、Lambda、API Gateway、STSなど）で発生し、エラー率の急上昇およびレイテンシの増大が確認されました。

この影響により、Snapchat、Fortnite、Signal、Perplexity、Alexaなど、多数の世界的サービスが同時にダウンしました。AWSはその後「主要な根本原因を特定し、主要機能は緩和された（fully mitigated）」と発表していますが、一部では依然として遅延やキュー残りが発生していると報じられています。

マルチAZ構成でも防げなかった理由

AWSが推奨するマルチAZ構成は、高可用性を実現するための基本的な冗長化手法です。しかし今回の障害では、マルチAZ構成を採用していても影響を受けたケースが確認されました。その理由は、障害のレイヤーが「AZ内」ではなく「リージョン全体」に及んでいたためです。

制御プレーン障害が発生

今回の障害は、個別のデータセンターやハードウェア障害ではなく、AWSの制御プレーン（サービス間のAPI、認証、ルーティングなど）に影響したとみられています。

その結果、各AZの物理的な可用性は保たれていても、API呼び出しやリソース管理を行う中核部分が機能しなくなり、アプリケーションレベルでの可用性が確保できなくなりました。

マルチAZ構成の限界

マルチAZ構成は、AZ単位の停電・ネットワーク断などに対しては効果的ですが、制御プレーンや内部ネットワーク層に障害が発生した場合には対応できません。

このため、同一リージョン内の冗長化では「論理的単一障害点（Single Point of Failure）」が残るという設計上の限界が明確に浮き彫りになりました。

今後の対策と設計指針

今回の障害を踏まえると、ランニングコストと求める耐障害性のバランスをどう考えるかが構成設計の分岐点となります。冗長化を強化するほど可用性は向上しますが、運用コストや構成の複雑さも増大します。以下では、代表的な構成パターンと考慮点を整理します。

マルチAZ構成＋別リージョンでのコールドスタンバイ構成

平常時は単一リージョンで稼働させ、障害時にのみ別リージョンの環境を立ち上げる方式です。コストを抑えつつ大規模障害に備えられますが、復旧までに数時間単位のダウンタイムが発生します。

  • メリット：低コストで広域障害への備えが可能
  • デメリット：RTO（復旧時間目標）が長く、人的操作が必要

マルチAZ構成＋別リージョンでのウォーム／ホットスタンバイ構成

別リージョンにも一定のリソースを常時稼働させておき、障害時に迅速に切り替える構成です。ウォームは部分稼働、ホットは完全稼働を指します。コストと可用性のバランスを柔軟に調整できます。

  • メリット：自動フェイルオーバーが可能でRTOを短縮できる
  • デメリット：維持コスト・設計複雑度が上昇

マルチリージョン構成

複数リージョンで同時稼働させるアクティブ／アクティブ構成です。トラフィック分散や地理的冗長化に優れ、リージョン全体の障害にも耐えられますが、最も高コストかつ複雑です。

  • メリット：最高水準の可用性と応答性能を確保
  • デメリット：整合性維持とコストが大きな課題

マルチクラウド構成

AWS単独ではなく、GCPやAzureなど複数のクラウドを併用する構成です。ベンダー依存リスクを分散できますが、各クラウドのAPI差異・運用統合コストが課題になります。

  • メリット：クラウド全体の障害に対する強靭性を確保
  • デメリット：開発・運用の複雑化、スキル要求の増大

災害対策設計（DR: Disaster Recovery）の最低要件

いずれの構成を採る場合でも、最低限、別リージョンでサービスを再開できるDR設計を持つことが不可欠です。データバックアップ、DNSフェイルオーバー、クロスリージョンレプリケーションなど、迅速に代替リージョンへ切り替える仕組みを整備しておくべきです。

おわりに

今回のAWS障害は、クラウド基盤における高可用性設計の限界を改めて浮き彫りにしました。マルチAZ構成は依然として有効な手法であるものの、それだけで「クラウドは止まらない」と断言することはできません。過去にはAzureやGoogle Cloud Platform（GCP）でも大規模な障害が発生しており、大手クラウドベンダーであっても絶対的な安心・安全が保証されるわけではありません。

また、ランサムウェア被害の事例では、バックアップ自体が無事であったにもかかわらず、復旧がうまくいかなかったケースも報告されています。したがって、単にバックアップを取得するだけでなく、少なくとも年に一度はバックアップからの復旧訓練を実施し、実際に復元できることを検証することが重要です。

今回の事象は、制御プレーンやサービス間依存を含むリージョン単位の障害リスクを前提とした設計、およびバックアップ運用の実効性確保の重要性を改めて認識させるものとなりました。

参考文献

モバイルバージョンを終了