Azure障害が連鎖した2日間：Managed IdentityとVM管理トラブルが依存サービスを巻き込んだ理由と対策

2026年2月上旬、Azureで「別々の障害」が短期間に発生し、結果として多くのPaaS／IaaS系サービスに影響が波及しました。ポイントは、単体のサービス停止というより「依存関係」と「リトライ（再試行）の増幅」で被害が広がったことです。自社のAzure運用を“止まりにくくする”ために、今回の事象から実務に落とせる学びを整理します。 Azure Service Health+1

• Azure障害が連鎖した2日間：Managed IdentityとVM管理トラブルが依存サービスを巻き込んだ理由と対策
  • 何が起きたのか（時系列で要点だけ）
    • 1）VMの管理操作が不安定化（2月2日〜3日）
    • 2）Managed Identityが過負荷で失敗（2月3日）
  • なぜ「連鎖」しやすいのか：依存関係の正体
    • Managed Identityは“認証の共通基盤”
    • VM拡張機能の配布は“地味だが重要な供給網”
  • 運用側が今日からできる実務対策（止まりにくい設計へ）
    • 1）“リトライの礼儀”を徹底する（最優先）
    • 2）Managed Identity障害を前提に“代替経路”を用意する
    • 3）拡張機能・起動時処理の“外部依存”を減らす
    • 4）Azure Service Healthアラートを“届く形”に整える
  • まとめ：クラウドは止まる、だから“波及を止める”

何が起きたのか（時系列で要点だけ）

1）VMの管理操作が不安定化（2月2日〜3日）

2月2日 19:46 UTCから2月3日 06:05 UTCにかけて、仮想マシンの作成・削除・更新・スケール・起動停止といった「管理操作」でエラーが増え、VMSSやAKSのノード作成、CI/CDなどにも影響が出ました。原因は、VM拡張機能パッケージを配布する一部のMicrosoft管理ストレージアカウントに対して、意図せず“公開読み取り”をブロックするポリシー変更が適用されたこととされています。 Azure Service Health

2）Managed Identityが過負荷で失敗（2月3日）

2月3日 00:10 UTC〜06:05 UTC、東西米国リージョンでManaged Identity（旧MSI）関連の作成・更新・削除やトークン取得が失敗し、Synapse、Databricks、Stream Analytics、AKS、Copilot Studio、Container Apps、PostgreSQL Flexible Serverなど多数の依存サービスに影響が及びました。背景として、前段の障害を抑えた後にトラフィックが急増し、さらに各コンポーネントが“攻撃的にリトライ”して雪だるま式に負荷が増えた、と説明されています。 Azure Service Health

なぜ「連鎖」しやすいのか：依存関係の正体

Managed Identityは“認証の共通基盤”

Managed Identityは、アプリがシークレットや証明書を自前で持たずにAzureリソースへ安全にアクセスするための仕組みです。便利な一方で、トークン取得が詰まると、データ基盤・コンテナ基盤・ワークフロー系が一斉に「認証できない」状態になり得ます。つまり、障害ドメインが大きい“共有基盤”です。 Azure Service Health+1

VM拡張機能の配布は“地味だが重要な供給網”

AKSノードのプロビジョニングやVMSSの構成適用、監視・セキュリティエージェントなどは、拡張機能パッケージの取得が前提になることがあります。配布元の読み取りが止まると「VMそのものはあるのに、必要な部品が入らない」ため、下流が広く詰まります。 Azure Service Health

運用側が今日からできる実務対策（止まりにくい設計へ）

1）“リトライの礼儀”を徹底する（最優先）

今回の説明でも、リトライが過負荷を増幅させた点が明示されています。

• 指数バックオフ＋ジッター（同時再試行の波を崩す）

• 最大試行回数／総待ち時間の上限（永遠に叩かない）

• 429/5xxでの挙動を分ける（即時再試行を避ける）

• サーキットブレーカー（一定割合失敗で遮断し回復を待つ）
  これだけで、同じ障害に遭っても“自社が被害を拡大させない”状態を作れます。 Azure Service Health

2）Managed Identity障害を前提に“代替経路”を用意する

理想はManaged Identity一本化ですが、業務クリティカルな処理は「短時間だけでも回る逃げ道」を設計しておくと強いです。例：

• 重要ジョブだけ、障害時は事前発行の短命トークン（保管・更新は厳格に）で継続

• 依存先がKey Vaultの場合、キャッシュ／フェイルクローズ方針を明確化

• トークン取得失敗時は、即死ではなく待機キューへ退避（後で再実行）

3）拡張機能・起動時処理の“外部依存”を減らす

VM/ノード初期化で外部取得が多いほど影響を受けます。

• 可能ならイメージに同梱（事前焼き込み）

• 取得元を複数にする／重要ファイルは自社管理ストレージにも置く

• “初回だけ必須”を減らし、後追い適用できるものは分離

4）Azure Service Healthアラートを“届く形”に整える

障害の把握が遅れると、復旧より前に現場が疲弊します。サービス正常性アラートを、メールだけでなくSMS・Webhook・運用チャットなどに流し、夜間も検知できる形にしておくのが現実的です。 Azure Service Health

まとめ：クラウドは止まる、だから“波及を止める”

今回の2日間は、VM管理（供給網）とManaged Identity（認証基盤）という“広く共有される土台”でつまずくと、依存サービスが一気に巻き込まれることを再確認させました。防御の要は、(1)リトライ制御、(2)障害時の逃げ道、(3)外部依存の削減、(4)検知と連絡網の整備です。
クラウド障害はゼロにできませんが、「自社の影響を最小化する設計」は今すぐ積み上げられます。 Azure Service Health+1