Azure の可用性ゾーン障害が発生したとき、「落ちた VM の NIC だけを別ゾーンの VM に付け替えて、IP アドレスを維持したままサービスを復旧させたい」というニーズはよくあります。本記事では、その可否と前提条件、実際の手順、PowerShell / Azure CLI による自動化のポイント、そしてより堅牢な可用性設計（ASR やゾーン冗長 Public IP など）までを、実務目線で詳しく解説します。
Azure 可用性ゾーン障害時に「NIC 付け替え」で復旧できるのか
前提となるシナリオを整理します。
- 同一リージョンの ゾーン 1 で障害発生
- ゾーン 1 上の VM：VM1 が停止・応答なし
- ゾーン 2 上に待機系 VM：VM2 が存在
- VM1 に付いている NIC（プライベート IP や Public IP）を VM2 に移したい
| 項目 | 内容 |
|---|---|
| リージョン | 同一リージョン内（例：Japan East） |
| ゾーン | VM1：ゾーン 1 / VM2：ゾーン 2 |
| 目的 | VM1 の NIC を VM2 に付け替えてサービスを復旧 |
| 必須要件 | IP アドレスや NSG 設定を極力引き継ぎたい |
結論から言えば、技術的には Azure VM 間で NIC の付け替えは可能です。ただし、いくつか重要な制約があります。
- 最後の 1 枚の NIC は VM から外せない
- NIC と VM は同一リージョンである必要がある
- 1 台の VM に複数 NIC を付ける場合は、すべて同一 VNet である必要がある
- VM サイズごとの NIC 上限数を超えてはいけない
- ゾーン障害中は、VM の停止（割り当て解除）や更新操作が失敗することがある
このため、「ゾーン障害時の標準的な対処方法」としては、NIC 付け替えよりも Azure Site Recovery（ASR）によるフェールオーバーや、ゾーン分散された VMSS + Load Balancer 構成などが推奨されます。ただ、どうしても IP アドレスを維持したい場合などには、NIC 付け替えは有効な選択肢になり得ます。
最後の 1 枚の NIC が VM から外せない理由と対処方法
Azure の VM は、少なくとも 1 つの NIC を持っていることが前提になっています。そのため、VM に 1 枚しか NIC が付いていない状態で、その NIC をデタッチすることはできません。この制約を回避するには、以下のようなパターンになります。
| パターン | VM1 の NIC 枚数 | NIC デタッチ方法 | 注意点 |
|---|---|---|---|
| 複数 NIC 構成 | 2 枚以上 | 対象の NIC を VM1 の NIC リストから削除して Update | Primary NIC を誤って外さないように注意 |
| 単一 NIC 構成 | 1 枚のみ | VM1 自体を削除すると NIC がデタッチ状態で残る | VM1 上の OS ディスクやデータディスクの扱いを事前に決めておく |
「VM1 を消したくない」という要件がある場合は、そもそも 平常時から複数 NIC 構成にしておくという設計も検討の余地があります。ただし、複数 NIC 構成はネットワーク設計や運用が複雑になるため、ASR や VMSS などの別解と比較してから選択するのが安全です。
NIC 付け替え時の主な制約条件
NIC を VM2 に付け替える際に確認すべき制約をまとめます。
| 制約項目 | 内容 | チェックポイント |
|---|---|---|
| リージョン | NIC と VM は同一リージョンに属している必要がある | Japan East → Japan East など、リージョンをまたいだ付け替えは不可 |
| サブスクリプション | 通常は同一サブスクリプション内で操作する | RG をまたいだ NIC 付け替えは可能だが、サブスクリプションは一致させるのが無難 |
| VNet | 1 台の VM に複数 NIC を付ける場合、全 NIC は同一 VNet に属する必要がある | サブネットは別でも可だが、VNet が異なる NIC を同一 VM に混在させることはできない |
| NIC 枚数上限 | VM サイズごとに最大 NIC 枚数が決まっている | D2s_v3 など、事前に公式ドキュメントの仕様を確認 |
| Accelerated Networking | NIC と VM サイズの双方が対応している必要がある | 非対応サイズへ付け替える場合は、Accelerated Networking を利用しない NIC を用意 |
| Public IP | NIC に割り当てられた Public IP は NIC と一緒に VM2 に移動 | zonal Public IP の場合はゾーン障害の影響を受ける。Zone-redundant を推奨 |
| NSG / UDR | NIC レベル NSG やサブネット NSG、UDR はそのまま適用される | VM2 側のトラフィック要件を満たすか事前確認が必要 |
ゾーン障害時に発生しがちな罠
可用性ゾーン障害時には、「操作が通るかどうか」そのものが大きな問題になります。ゾーン障害はデータプレーンだけでなく、場合によってはコントロールプレーンにも影響するため、以下のような現象が起こり得ます。
- VM の「停止（割り当て解除）」コマンドがタイムアウトまたは失敗する
- NIC を外すための VM 更新（Update）操作がエラーになる
- リソースのステータスがポータルや API 上で「Updating」のまま長時間遷移しない
つまり、最も NIC を付け替えたいタイミング（本番障害時）こそ、その操作が通らない可能性が高いというジレンマがあります。これが「NIC 付け替えを可用性設計のメイン手段にしない方がよい」と言われる理由です。
一方で、ゾーン障害が「部分的」であり、VM を停止できる程度にはコントロールプレーンが生きているケースでは、NIC 付け替えで迅速な復旧ができる可能性もあります。したがって、あくまで補助的な復旧手段として事前にスクリプトを用意しておくのが現実的な落としどころです。
NIC を別ゾーンの VM に付け替える具体的な手順
ここからは、実際に VM1 から NIC を切り離し、VM2 に取り付けるまでの代表的な手順を整理します。
事前確認（設計・構成条件のチェック）
- NIC と VM2 が 同一リージョンであるか
- VM2 の VM サイズが 追加 NIC を許容する枚数か
- VM2 に既に NIC が付いている場合、その NIC と付け替えたい NIC が同一 VNet に属しているか
- NIC にぶら下がる Public IP や NSG の設定が VM2 側の要件と整合しているか
- VM1 を削除する場合、OS ディスク・データディスクをどう扱うか（別 VM で再利用するか、スナップショットだけ取るかなど）
手順の全体像
代表的なフローを一覧にすると次の通りです。
| ステップ | 操作内容 | ポイント |
|---|---|---|
| 1 | VM1 を停止（割り当て解除） | 障害で失敗する場合もあるため、ログとステータスを確認 |
| 2 | VM1 から NIC を切り離す（または VM1 を削除） | 単一 NIC の場合は VM1 削除が必須 |
| 3 | デタッチ状態の NIC を VM2 に追加 | 複数 NIC 構成の場合、Primary 指定に注意 |
| 4 | VM2 を起動 | プライベート IP / Public IP / NSG の挙動を確認 |
PowerShell での操作例
以下は、シンプルな PowerShell による NIC 付け替えの例です。実運用では、エラーハンドリングやログ出力、条件分岐などを追加して使いやすくカスタマイズするとよいでしょう。
# 0) 変数定義
$rg1 = "RG1"
$rg2 = "RG2"
$vm1 = "VM1" # ゾーン1
$vm2 = "VM2" # ゾーン2
$nicName = "VM1-NIC" # 付け替え対象の NIC 名
# 1) VM1 を停止（割り当て解除）
Stop-AzVM -ResourceGroupName $rg1 -Name $vm1 -Force
# 2) NIC を VM1 から取得
$vm1Obj = Get-AzVM -ResourceGroupName $rg1 -Name $vm1
$nicObj = Get-AzNetworkInterface -ResourceGroupName $rg1 -Name $nicName
# 2') VM1 に NIC が 1 枚しかない場合は VM1 を削除して NIC をデタッチ
# Remove-AzVM -ResourceGroupName $rg1 -Name $vm1 -Force
# 2'') 複数 NIC 構成の例：対象 NIC を VM1 から取り外す
$vm1Obj = Remove-AzVMNetworkInterface -VM $vm1Obj -NetworkInterfaceIDs $nicObj.Id
Update-AzVM -ResourceGroupName $rg1 -VM $vm1Obj
# 3) VM2 に NIC を追加（Primary にしない例）
$vm2Obj = Get-AzVM -ResourceGroupName $rg2 -Name $vm2
$vm2Obj = Add-AzVMNetworkInterface -VM $vm2Obj -Id $nicObj.Id -Primary:$false
Update-AzVM -ResourceGroupName $rg2 -VM $vm2Obj
# 4) VM2 を起動
Start-AzVM -ResourceGroupName $rg2 -Name $vm2
ポイントは以下の通りです。
Remove-AzVMNetworkInterfaceで NIC を外せるのは、VM に複数 NIC がある場合のみ- Primary NIC を制御したい場合は、
-Primary:$true/-Primary:$falseを明示的に指定 - ゾーン障害時は
Stop-AzVMやUpdate-AzVMが失敗する可能性を考慮し、リトライロジックを入れておくと安心
Azure CLI での操作例
Azure CLI を使ったシェルスクリプトの例です。bash だけでなく、Azure Cloud Shell に貼り付けて使える形にしておくと、障害時にすぐ実行しやすくなります。
RG1=RG1
RG2=RG2
VM1=VM1
VM2=VM2
NIC=VM1-NIC
# 1) VM1 を停止（割り当て解除）
az vm deallocate -g $RG1 -n $VM1
# 2) NIC のリソース ID を取得
NIC_ID=$(az network nic show -g $RG1 -n $NIC --query id -o tsv)
# 2') VM1 に NIC が 1 枚しかない場合は VM1 を削除し NIC をデタッチ
# az vm delete -g $RG1 -n $VM1 --yes
# 2'') 複数 NIC 構成の例：VM1 から対象 NIC を外す
az vm nic remove -g $RG1 --vm-name $VM1 --nics $NIC_ID
# 3) VM2 に NIC を追加
az vm nic add -g $RG2 --vm-name $VM2 --nics $NIC_ID
# 4) VM2 を起動
az vm start -g $RG2 -n $VM2
CLI 版でも同様に、ゾーン障害中はコマンドがエラーになりやすいため、リトライやログ保存を仕込んだスクリプトにしておくと運用しやすくなります。
「NIC 付け替え」と「ASR / ゾーン冗長構成」の比較
可用性ゾーン障害を前提とした設計では、NIC 付け替えをメイン戦略にするのはリスクがあります。ここでは、代表的な 3 つのアプローチを比較します。
| アプローチ | 特徴 | メリット | デメリット |
|---|---|---|---|
| NIC 付け替え | 障害時に手動/スクリプトで NIC を別 VM へ移植 | IP や NIC 設定をそのまま引き継ぎやすい | 障害中に操作が通らないことがある。手順ミスのリスク |
| ASR フェールオーバー | Azure Site Recovery で別ゾーン/別リージョンへレプリカを保持 | リカバリプランで一連の復旧手順を自動化できる | IP が変わるケースもあるため、DNS 連携などの設計が必要 |
| VMSS + Load Balancer | 複数ゾーンに跨るスケールセットとロードバランサー構成 | ゾーン障害時も生存ゾーンの VM が自動でトラフィックを引き受ける | ステートフルなアプリやレガシー構成では適用が難しいことがある |
安定した BCP（事業継続計画）を実現したい場合は、ASR やゾーン分散構成を第一候補にし、NIC 付け替えは「IP を保持したい特定ケース向けのオプション」として位置付けるのが現実的です。
ASR（Azure Site Recovery）によるゾーン冗長構成のポイント
ASR を使うと、次のようなメリットがあります。
- VM のディスクを別ゾーン（または別リージョン）へ継続的にレプリケーション
- フェールオーバー時に実行するスクリプトや順序を「リカバリプラン」で定義
- テストフェールオーバー機能により、本番に影響を与えずに復旧手順を検証可能
特に、「障害対応をできるだけ自動化・標準化したい」「オペレーションの属人化を避けたい」という場合、ASR のリカバリプランに NIC 付け替えスクリプトを組み込むこともできます。例えば、フェールオーバー完了後に DNS 更新を行う PowerShell を実行する、といった使い方です。
Public IP とゾーン冗長性の設計
Public IP の種類によって、ゾーン障害への耐性が大きく変わります。
| Public IP の種類 | 特徴 | ゾーン障害時の挙動 | 利用シナリオ |
|---|---|---|---|
| Basic SKU | レガシーな SKU。機能が限定的 | 可用性ゾーンの概念がなく、冗長性設計が難しい | 新規設計では非推奨 |
| Standard SKU (Zonal) | 特定のゾーンに紐づく Public IP | 紐づくゾーンが落ちると影響を受ける | ゾーン指定が必要なワークロード |
| Standard SKU (Zone-redundant) | 複数ゾーンにまたがる冗長な Public IP | 単一ゾーン障害に対して高い耐性 | 高可用性を求めるインターネット公開サービス |
ゾーン障害に備えるなら、Standard SKU のゾーン冗長 Public IP を使いつつ、バックエンドに複数ゾーンに跨る VMSS か VM 群を配置する構成が王道です。NIC 付け替えは、この基本構成を補う「最後の手段」として位置づけるのが安全です。
IP アドレス維持要件が強い場合の代替パターン
「アプリケーションの接続先が IP 固定でしか設定できない」「多くのクライアント設定に IP 直書きしてしまっている」といった事情から、同じ IP を維持する必要が出ることがあります。こうした場合でも、NIC 付け替え一択ではなく、以下のような代替パターンも検討できます。
- DNS 名に収束させる：段階的にホスト名ベースの接続に移行する
- 内部 Load Balancer (ILB) を挟む：バックエンドの VM をラウンドロビンまたはフェールオーバー構成にする
- アプリ側の再接続戦略を改善：一時的な IP 変更でも再接続・再解決できるようにする
- 接続クライアントの設定自動化：構成管理ツール（Intune / GPO / Ansible など）で接続先変更を自動配布
どうしても IP を変えられない場合に限り、NIC 付け替えを検討しつつ、中長期的には「IP 固定依存からの脱却」もロードマップに載せておくことをおすすめします。
運用設計のベストプラクティス
NIC 付け替えを含む高可用性設計を検討する際は、次のポイントを押さえておくと、後から困りにくくなります。
1. NIC 付け替えを前提にしないアーキテクチャを優先する
- ゾーン分散された VMSS + Standard Load Balancer
- ASR による別ゾーン・別リージョンへのレプリケーション
- ゾーン冗長 Public IP + Application Gateway / Front Door / Traffic Manager 等
これらは、Azure が持つマネージドな可用性機能を最大限活用する設計です。NIC 付け替えは、これらの構成を補完する「手動フェールオーバー手段」として位置付けるとバランスが良くなります。
2. 付け替え手順を「Runbook」として標準化し、自動化する
- Azure PowerShell / Azure CLI / Azure Functions / Azure Automation でスクリプト化
- 引数として「元 VM 名」「先 VM 名」「NIC 名」を渡せる汎用スクリプトにする
- ログ出力や通知（メール / Teams Webhook など）を組み込み、トレーサビリティを確保
標準化された Runbook があれば、担当者による手順のブレを抑え、障害時の心理的ハードルも下げることができます。
3. 定期的に「模擬障害テスト」を実施する
- テスト環境で、実際に VM1 から VM2 へ NIC を付け替えてみる
- ASR のテストフェールオーバーを組み合わせて、復旧時間（RTO）を測定
- スクリプトのエラーケース（VM 停止失敗時など）を意図的に作り、挙動を確認
机上設計だけでなく、実際に手とスクリプトを動かして確認することで、「本番で本当に使える手順」へとブラッシュアップできます。
NIC 付け替え前に確認したいチェックリスト
最後に、実際に NIC を付け替える前に確認しておきたい項目をチェックリスト形式でまとめます。障害対応 Runbook の末尾にそのまま添付しておくのもおすすめです。
| カテゴリ | チェック項目 | 状態 |
|---|---|---|
| 構成 | NIC と VM2 が同一リージョンである | □ |
| 構成 | VM2 のサイズが NIC 枚数上限を超えない | □ |
| ネットワーク | VM2 に付いている他の NIC が同一 VNet に属している | □ |
| ネットワーク | NIC の NSG / UDR が VM2 の要件を満たす | □ |
| Public IP | zonal Public IP を使うリスクを把握している（必要に応じて Zone-redundant に移行計画あり） | □ |
| 運用 | PowerShell / CLI スクリプトが最新状態で保存されている | □ |
| 運用 | 模擬障害テストを直近で実施済み | □ |
| BCP | NIC 付け替えが失敗した場合の代替手段（ASR / DNS 切替など）が用意されている | □ |
まとめ：NIC 付け替えは「限定用途の有力カード」として準備する
本記事のポイントを整理します。
- Azure VM の NIC は、条件を満たせば別 VM に付け替え可能であり、プライベート IP や NIC レベル NSG、紐づいた Public IP も一緒に移動する
- ただし、最後の 1 枚の NIC は VM から外せないため、単一 NIC 構成では VM 自体を削除して NIC をデタッチする必要がある
- VM サイズごとの NIC 上限、同一リージョン / 同一 VNet ルール、Accelerated Networking 対応など、守るべき制約が多い
- ゾーン障害中は VM 停止や更新操作が失敗することがあり、最も必要なタイミングで NIC 付け替えが実行できないリスクもある
- 実運用での第一選択肢は、ASR やゾーン分散 VMSS、ゾーン冗長 Public IP などの冗長構成であり、NIC 付け替えは「IP 維持など限定的な要件向けの補助的手段」として位置付けるのが安全
- PowerShell / Azure CLI / Azure Automation 等でスクリプト化しておけば、NIC 付け替えが必要になったときに迅速に実行できる
Azure の可用性ゾーン障害を見据えた設計では、「どのレイヤーで冗長化するか」が重要です。ネットワーク（Public IP / LB）、コンピュート（VM / VMSS / ASR）、アプリケーション（再接続戦略 / DNS）など、複数レイヤーで対策を組み合わせ、その中に NIC 付け替えというカードを「最後の砦」として用意しておくと、より柔軟で堅牢なシステムを構築できます。
コメント