Azure IaaS の built-in resiliency が気になるなら、結論は明快です。Azure は仮想マシン、ストレージ、ネットワークの各層に、可用性・継続性・復旧のための機能をあらかじめ持っています。ですが、それは「単一VMでも自動で無停止」という意味ではありません。Microsoft が 2026年4月1日に公開した公式ブログでも、Azure IaaS は availability・continuity・recovery の土台を提供する一方、最終的なレジリエンシーは利用者側の設計と構成に左右されると明示しています。Azure IaaS の built-in resiliency を評価するときは、機能名の多さではなく、「どの障害まで吸収できる設計を組めるか」で見るのが正解です。 (マイクロソフト アジュール)
この記事では、Azure IaaS の built-in resiliency で何が built-in なのか、Azure IaaS はどこまで止まりにくくできるのか、そして Azure を選ぶ理由をどう再整理すべきかを、実務で判断しやすい形で整理します。 (マイクロソフト アジュール)
Azure IaaS はどこまで止まりにくいのか
Azure IaaS は、ホスト障害やラック障害のような局所的なトラブルから、ゾーン障害、さらに構成次第ではリージョン障害まで見据えた設計ができます。ただし守れる範囲は、「Azure 上に置いたかどうか」ではなく、「何台をどう分散し、データをどう複製し、トラフィックをどう切り替え、監視と訓練をどこまで回しているか」で決まります。単一VMのままでは built-in resiliency の恩恵は限定的で、multi-zone や multi-region に進むほど止まりにくさは上がる一方、複雑さと運用負荷も増えます。 (マイクロソフト アジュール)
4月1日の公式記事が前面に出したメッセージ
4月1日の公式記事「Azure IaaS: Keep critical applications running with built-in resiliency at scale」が強く訴えたのは、レジリエンシーを“後付けのオプション”ではなく、IaaS の基盤設計として考えるべきだという点です。Microsoft は、Azure IaaS の built-in capabilities を compute、storage、networking にまたがる isolation・redundancy・failover・recovery の土台として位置づけています。 (マイクロソフト アジュール)
同時に、公式はかなり重要な線引きもしています。Azure 側が提供するのは「レジリエントな土台」であり、どのワークロードをどのレベルまで守るか、どこで切り替えるか、どの程度のデータ損失を許容するかは利用者側が決める、という shared responsibility です。ここを読み違えると、「Azure に載せたのだから止まりにくいはず」という危険な期待値になります。 (マイクロソフト アジュール)
- Azure 側で built-in と言いやすいものは、可用性ゾーンや VM Scale Sets、ストレージ冗長、Load Balancer / Application Gateway / Traffic Manager / Front Door、Azure Backup、Azure Site Recovery など、障害分離・冗長化・切り替え・復旧のための部品です。 (マイクロソフト アジュール)
- 利用者側で設計が必要なものは、VM の台数と配置、アプリやデータの複製方式、トラフィックのルーティング、通知設計、テストフェールオーバー、運用runbookです。 (Microsoft Learn)
Azure IaaS の built-in resiliency で実際に使う要素
Compute は「どこに置くか」でかなり変わる
Compute 側での built-in resiliency は、まず 配置と分離 にあります。Availability Zones は同一リージョン内の物理的に分離されたデータセンター群で、各ゾーンは独立した電源・冷却・ネットワークを持ちます。さらに可用性ゾーンは、ゾーン全体の障害だけでなく、ラックやクラスター単位のより小さな障害に対しても有効です。VM Scale Sets は、インスタンスを可用性ゾーンや障害ドメインに分散しながら管理できるため、フロントエンドやアプリ層のように「台数で粘る」設計と相性がよい機能です。 (マイクロソフト アジュール)
ただし、ここで誤解しやすい点があります。単一の zonal VM は、単体ではゾーン障害に強くありません。 公式ドキュメントでも、ゾーン障害に耐えたいなら複数VMを別ゾーンに配置するか、VM Scale Sets で複数ゾーンに分散するよう案内されています。逆に、非ゾーン指定の regional VM はどこかのゾーンに置かれる可能性があるため、ゾーン障害の影響を受けることがあります。加えて、ゾーン間のトラフィック制御やデータ複製は Azure が自動で全部やってくれるわけではなく、利用者側の責任です。 (Microsoft Learn)
可用性ゾーンだけが答えではありません。Availability Set は、VM を fault domain と update domain に分けて配置する仕組みで、物理ハードウェア障害や計画メンテナンスの影響を一度に受けにくくします。同一リージョン内で VM 間レイテンシを抑えたい場面では、Availability Zone より Availability Set が向くケースもあります。一方で、Availability Set はデータセンター障害やリージョン障害までは守れません。 (Microsoft Learn)
Storage は「冗長方式の選び方」がレジリエンシーそのもの
ストレージ側では、built-in resiliency は 冗長オプションの選択肢 として現れます。LRS は単一データセンター内で複製する最小構成、ZRS はプライマリリージョン内の 3 つ以上の可用性ゾーンに同期複製する構成です。さらに GRS と GZRS はセカンダリリージョンにも複製し、RA-GRS / RA-GZRS を使えばセカンダリからの読み取りも可能になります。実務では、ZRS はゾーン障害向け、GZRS はゾーン障害に加えて地域障害まで見たいときの有力候補 と考えると整理しやすいです。 (マイクロソフト アジュール)
大事なのは、geo 冗長だからゼロデータロスではない ことです。GRS/GZRS のセカンダリリージョンへの複製は非同期なので、プライマリリージョンが回復不能になった場合、直近の書き込みが失われる可能性があります。これは RPO の話であり、ストレージの冗長方式は単なる容量や価格の話ではなく、どこまでデータ損失を許容するかの設計判断です。 (Microsoft Learn)
VM ベースのワークロードでは、ストレージ冗長だけでなく、スナップショット、Azure Backup、Azure Site Recovery まで含めて初めて復旧設計になります。公式ブログも、これらは単なるバックアップ機能ではなく、「どれだけデータを失い得るか」「どれだけ早く戻せるか」を決める要素だと整理しています。 (マイクロソフト アジュール)
Network は「到達性」を止めないための built-in
どれだけ compute と storage が健全でも、ユーザーや依存サービスが到達できなければ、そのアプリは実質的に停止です。Azure のネットワーク側の built-in resiliency は、この 到達性を落とさない ための機能群です。Load Balancer は L4 で低遅延の分散を行い、health probes で正常なインスタンスにのみ送ります。Application Gateway は URL パスやホストヘッダーなど HTTP 特性に基づいて L7 ルーティングを行い、異常なバックエンドには自動で送らなくなります。Traffic Manager は DNS ベースで複数リージョンのエンドポイントを監視し、自動フェールオーバーを提供します。Front Door はグローバルな L7 配信で、fast failover、TLS 終端、キャッシュ、WAF が必要な Web ワークロードに向きます。 (マイクロソフト アジュール)
以下は、Azure IaaS の可用性設計で迷いやすいネットワーク機能の使い分けを、実務向けに整理した目安です。 (Microsoft Learn)
| シナリオ | 第一候補 | 使い分けの目安 |
|---|---|---|
| 同一リージョン内の TCP/UDP 分散 | Azure Load Balancer | L4で低遅延。VMやゾーンをまたいで分散しやすい |
| 同一リージョン内の Web アプリ | Application Gateway | URL/Host ベースの L7 ルーティングや WAF を使いたい |
| 複数リージョンのシンプルな切り替え | Traffic Manager | DNS ベースで複数エンドポイントを監視し自動フェールオーバーしたい |
| グローバル Web 配信と高速切り替え | Front Door | グローバル L7、TLS 終端、キャッシュ、WAF をまとめて使いたい |
実務で特に重要なのは、Traffic Manager と Front Door は似て非なるもの だという点です。Traffic Manager は DNS ベースなので、DNS キャッシュや TTL の影響で Front Door ほど速く切り替わらない場合があります。Microsoft も多くのケースでは Front Door か Traffic Manager のどちらか一方を使うことを勧めており、両方を重ねるのは高度な高可用性が必要な特殊ケースと考えた方が安全です。なお Traffic Manager は Azure 外の公開エンドポイントも扱えるため、ハイブリッド環境や段階移行の切り替えにも向いています。 (Microsoft Learn)
可用性設計の基本は「どの障害単位まで守るか」を先に決めること
公式ブログが繰り返し強調している通り、すべてのワークロードが同じレジリエンシーを必要とするわけではありません。Stateless なアプリ層ならオートスケール、ゾーン分散、迅速なインスタンス置き換えが効きやすく、Stateful なワークロードではバックアップ、複製、フェールオーバー計画の重要度が一気に上がります。レジリエンシーは“最高設定を入れること”ではなく、業務影響に応じて設計の深さを変えること です。 (マイクロソフト アジュール)
以下は、公式機能を前提にした実務上の目安です。 (Microsoft Learn)
| 求める継続性 | 構成の目安 | 向くケース | 注意点 |
|---|---|---|---|
| まずは単一点障害を減らしたい | 2台以上のVM、Availability Set または複数ゾーン、Load Balancer、バックアップ | 社内システム、停止許容が比較的大きい業務 | 単一VMのままでは built-in を活かし切れない |
| ゾーン障害まで吸収したい | 複数ゾーンの VM / VMSS、zone-redundant な負荷分散、ZRS/GZRS、アプリ/DB複製 | 対外Web、API、24×7運用 | データ複製とトラフィック制御は利用者責任 |
| リージョン障害まで想定する | 別リージョンDRまたは active-active、Site Recovery、Traffic Manager / Front Door、運用 runbook | EC、決済、顧客向け基幹 | 切り替え試験と運用コストが必須 |
見落とされがちですが、ストレージの geo 冗長と VM の DR は同じ話ではありません。 ストレージアカウントのセカンダリリージョンはプライマリリージョンに基づいて決まり、変更できません。一方で VM の DR は、Site Recovery を使えばセカンダリとしてほぼ任意の Azure リージョンを選べます。つまり、「VM の待避先」と「データの複製先」は同じルールで決まるわけではないので、compute と data の復旧先を一体で設計する必要があります。 (Microsoft Learn)
失敗しやすいポイント
- 単一VMを可用性ゾーンに置いたから安心だと思う。 単一の zonal VM は、単体ではゾーン障害に強くありません。ゾーン障害に備えるなら、複数ゾーンにまたがる複数VMや VMSS、そしてトラフィック切り替えが前提です。 (Microsoft Learn)
- GRS や GZRS を選んだからゼロデータロスだと思う。 セカンダリリージョンへの複製は非同期なので、プライマリ障害時には直近データが失われる可能性があります。RPO を許容できるかを先に決めるべきです。 (Microsoft Learn)
- ロードバランサーを置けば自動で全部切り替わると思う。 Load Balancer のフロントエンドを zone-redundant にしても、バックエンドのVMが同一ゾーンに固まっていれば単一障害点は消えません。Application Gateway や Load Balancer の health probe は有効ですが、バックエンド冗長は別問題です。 (Microsoft Learn)
- 障害通知は Microsoft が自動で全部知らせてくれると思う。 VM の可用性ゾーン障害については、Microsoft が自動通知する前提ではなく、Resource Health や Service Health の監視・アラート設計が必要です。 (Microsoft Learn)
- 可用性ゾーンはどのリージョン・どのサービスでも同じように使えると思う。 実際には、サービスやリージョン、SKU、構成条件によって対応状況は異なります。VM サイズによっては特定リージョンや特定ゾーンでしか使えないこともあります。 (Microsoft Learn)
- 既存の単一VMも後から簡単にゾーン化できると思う。 既存の regional VM を zonal VM に移す場合、新しい VM を対象ゾーンに作成する形になり、停止を伴います。あとから対策するほど手戻りが大きくなりやすい部分です。 (Microsoft Learn)
- DR は作ったら終わりだと思う。 Site Recovery には、本番や継続レプリケーションに影響を与えずに実施できる test failover があり、VM 側では Chaos Studio を使った障害シミュレーションも可能です。止まりにくさは、設計図より訓練で差が出ます。 (Microsoft Learn)
Azure を選ぶ理由を built-in resiliency の観点で再整理する
Azure を選ぶ理由を改めて一言でいえば、レジリエンシーの部品が compute・storage・networking で分断されず、同じプラットフォーム上で組み合わせられること です。可用性ゾーン、ストレージ冗長、負荷分散、グローバルルーティング、バックアップ、DR までを Azure の中で一貫して設計しやすい点は、IaaS の採用判断で効いてきます。 (マイクロソフト アジュール)
もう一つの強みは、要件に応じて段階的に伸ばせること です。公式ブログも、同じ Azure IaaS 基盤であっても、ワークロードの重要度、運用要件、コスト、複雑さ、回復速度のトレードオフに応じて異なるパターンを取れると説明しています。最初から全システムを multi-region active-active にするのではなく、重要度の高い系だけを multi-zone / multi-region に寄せる設計がしやすいわけです。 (マイクロソフト アジュール)
さらに、移行タイミングがレジリエンシー改善の好機になりやすい点も見逃せません。公式は、クラウド移行を単なるリフト＆シフトで終わらせず、単一障害点を洗い直し、IaC と CI/CD で構成を標準化し、復旧を再現しやすくするべきだと示しています。Azure を選ぶ理由は「VM を上げられること」ではなく、「止まりにくい構成へ作り替えやすいこと」にあります。 (マイクロソフト アジュール)
まずやること
- 重要アプリを棚卸しし、許容停止時間と許容データ損失を決める。
先に RTO / RPO を決めないと、Availability Set、Availability Zones、multi-region のどれを選ぶべきかが定まりません。 - 単一VMのまま残っている業務を洗い出す。
built-in resiliency は複数インスタンスや分離配置を前提に効いてくるため、単一VMのままでは Azure の強みを活かしにくいです。 - トラフィック制御と通知をセットで入れる。
Load Balancer や Application Gateway の health probes、Traffic Manager / Front Door の監視に加えて、Resource Health と Service Health のアラートを必ず構成しておくべきです。 (Microsoft Learn) - DR を一度は実際に試す。
Site Recovery の test failover や、必要に応じた障害シミュレーションを回し、runbook を更新して初めて“使えるレジリエンシー”になります。 (Microsoft Learn) - 構成を IaC で固定する。
レジリエンシーは一度作っても、設定ドリフトで簡単に弱くなります。Terraform や Bicep、パイプラインを使って、再現できる構成にしておく方が安全です。 (マイクロソフト アジュール)
Azure IaaS の built-in resiliency を正しく読むコツは、機能一覧で終わらせず、障害単位、RTO/RPO、切り替え、監視、訓練 までを一つの設計として見ることです。まずは重要アプリを「単一リージョンでよいか」「ゾーン障害まで吸収するか」「リージョン障害まで見るか」で仕分けしてください。そのうえで VM 配置、ストレージ冗長、トラフィック制御、DR テストを埋めていけば、Azure IaaS は“単に動く基盤”ではなく、“止まりにくい基盤”として使えるようになります。 (マイクロソフト アジュール)
コメント