Microsoftは2026年6月11日、Azure Virtual Machine Scale Sets（VMSS）向けの「Inbound NAT Pools」を廃止すると案内しました。2026年11月15日以降は新しいInbound NAT Poolsを作成できなくなり、2027年9月30日に機能が廃止されます。既存構成は廃止日まで動作しますが、それまでにInbound NAT rule V2への移行が必要です。(Microsoft Azure)
注意したいのは、すべてのInbound NAT rule V1が対象ではない点です。今回の対象はVMSS専用機能であるInbound NAT Poolsです。単一VMに設定したInbound NAT rule V1は引き続きサポートされ、今回の移行対象には含まれません。(Microsoft Learn)
Microsoft developer platformで何が変わるのか
今回のMicrosoft developer platform関連の変更は、Azure Load Balancerを使ってVMSSの各インスタンスへRDPやSSHなどの通信を転送している環境に影響します。
| 確認項目 | 内容 |
|---|---|
| 対象機能 | Azure Load BalancerのInbound NAT Pools |
| 対象リソース | Azure Virtual Machine Scale Sets |
| 新規作成停止 | 2026年11月15日 |
| 機能廃止 | 2027年9月30日 |
| 移行先 | Inbound NAT rule V2 |
| 既存構成 | 廃止日までは継続して動作 |
| 対象外 | 単一VM向けInbound NAT rule V1 |
2026年11月15日に既存のNATプールが直ちに停止するわけではありません。ただし、新規作成や古い構成の再デプロイができなくなるため、ARMテンプレート、Bicep、Terraform、Azure CLI、PowerShellなどの自動構築処理も事前に見直す必要があります。(Microsoft Learn)
Inbound NAT Poolsとは
Inbound NAT ruleは、Azure Load BalancerのフロントエンドIPアドレスとポートで受信した通信を、バックエンドの特定インスタンスへ転送する機能です。
例えば、次のようにVMSS内の各サーバーへ異なるフロントエンドポートを割り当てられます。
| 接続先 | フロントエンド | バックエンド |
|---|---|---|
| VMSSインスタンス1 | 203.0.113.10:50001 | インスタンス1:22 |
| VMSSインスタンス2 | 203.0.113.10:50002 | インスタンス2:22 |
| VMSSインスタンス3 | 203.0.113.10:50003 | インスタンス3:22 |
従来のInbound NAT Poolsでは、VMSSがスケールアウト・スケールインすると、インスタンスごとのNAT規則が自動的に作成または削除されていました。
Inbound NAT rule V1とV2の違い
| 項目 | Inbound NAT Pools・V1 | Inbound NAT rule V2 |
|---|---|---|
| 主な対象 | VMSS | VMSS、複数VM |
| 規則の関連付け先 | VMSSのNIC構成 | Load Balancerのバックエンドプール |
| 更新対象 | Load BalancerとVMSS側 | 主にLoad Balancer側 |
| ポート対応の確認 | NICとの照合が必要 | Load Balancer構成から取得可能 |
| 今後の扱い | 2027年9月30日に廃止 | 移行先として推奨 |
V2では、NAT規則がVMSSのNICではなくLoad Balancerのバックエンドプールを参照します。そのため、規則を変更する際にLoad Balancerと各VMのNICを個別に更新する必要がなくなり、構成管理が簡素化されます。
また、バックエンドインスタンスと割り当てポートの対応をLoad Balancer側から確認しやすくなる点もV2の利点です。(Microsoft Learn)
影響を受ける環境
次の条件に該当する環境は確認が必要です。
- Azure Load BalancerのバックエンドにVMSSを登録している
- VMSSの各インスタンスへ、Load Balancer経由でRDPやSSH接続している
- Load Balancerの構成に
inboundNatPoolsが存在する - VMSSのネットワーク構成に
loadBalancerInboundNatPoolsが存在する - ARM、Bicep、TerraformなどでInbound NAT Poolsを作成している
一方、次の環境は今回の廃止対象ではありません。
- 単一VM向けのInbound NAT rule V1だけを利用している
- 負荷分散規則だけを利用し、Inbound NAT Poolsを設定していない
- アウトバウンド規則だけを利用している
- すでにバックエンドプールを対象とするInbound NAT rule V2へ移行している
一般ユーザーが設定を変更する必要はありません。ただし、管理者が移行しなかった場合は、将来的にRDP、SSH、管理ポートなどを利用した接続に影響が出る可能性があります。
Inbound NAT Poolsを使用しているか確認する方法
Azure portalで確認する
- Azure portalで「ロード バランサー」を開きます。
- 対象のLoad Balancerを選択します。
- 「設定」から「インバウンド NAT 規則」を開きます。
- VMSS向けのNATプールや、対象がバックエンドプールではない古い構成が存在しないか確認します。
V2では、規則の対象としてバックエンドプールが設定されます。単一VMを対象とするV1規則が表示されても、それだけで今回の移行対象とは判断できません。(Microsoft Learn)
Azure CLIで確認する
az network lb inbound-nat-pool list \
--resource-group <リソースグループ名> \
--lb-name <ロードバランサー名>空の配列ではなくNATプールの情報が返された場合、そのLoad BalancerはInbound NAT Poolsを使用しています。
PowerShellで確認する
$lb = Get-AzLoadBalancer `
-Name "<ロードバランサー名>" `
-ResourceGroupName "<リソースグループ名>"
$lb.InboundNatPools結果が返る場合は移行対象です。ARMリソースのJSONを確認できる場合は、Load Balancerのproperties.inboundNatPoolsが空になっているかも確認してください。(Microsoft Learn)
Inbound NAT rule V2への移行手順
公式手順の基本的な流れは次のとおりです。
| 手順 | 作業 |
|---|---|
| 1 | 現在のNATプール、ポート範囲、バックエンドポートを記録する |
| 2 | V2で利用するバックエンドプールとポート範囲を設計する |
| 3 | Inbound NAT PoolsをLoad Balancerから削除する |
| 4 | VMSSからloadBalancerInboundNatPoolsの参照を削除する |
| 5 | VMSSの全インスタンスへモデル変更を反映する |
| 6 | バックエンドプールを対象とするInbound NAT rule V2を作成する |
| 7 | 接続、ポート割り当て、スケールアウトをテストする |
移行中は、Inbound NAT規則を通過している既存トラフィックに停止時間が発生します。一方、通常の負荷分散規則やアウトバウンド規則を通る通信は、公式手順上は移行の影響を受けません。メンテナンス時間を確保し、管理接続が切断されても復旧できる経路を準備してから作業してください。(Microsoft Learn)
Azure CLIによる移行例
# 1. 既存のInbound NAT Poolを削除
az network lb inbound-nat-pool delete \
--resource-group <リソースグループ名> \
--lb-name <ロードバランサー名> \
--name <NATプール名>
# 2. VMSSモデルからNAT Poolの関連付けを削除
az vmss update \
--resource-group <リソースグループ名> \
--name <VMSS名> \
--remove virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].ipConfigurations[0].loadBalancerInboundNatPools
# 3. 全インスタンスへ変更を反映
az vmss update-instances \
--resource-group <リソースグループ名> \
--name <VMSS名> \
--instance-ids "*"
# 4. バックエンドプールを対象とするV2規則を作成
az network lb inbound-nat-rule create \
--resource-group <リソースグループ名> \
--lb-name <ロードバランサー名> \
--name <新しい規則名> \
--protocol Tcp \
--frontend-port-range-start 50001 \
--frontend-port-range-end 50100 \
--backend-port 22 \
--backend-address-pool <バックエンドプール名>この例のNICとIP構成は、配列の0番目を対象としています。複数のNICやIP構成を持つVMSSでは、実際のJSON構造を確認してインデックスを変更してください。
また、公式のCLI例はVMSSのアップグレードモードがManualであることを前提としています。自動移行用のPowerShellモジュールを使用する場合、Load BalancerはStandard SKUである必要があります。VMSSのアップグレードポリシーはManualまたはAutomaticが対象で、Rollingはサポートされていません。(Microsoft Learn)
移行前に確認すべき設定
フロントエンドポートの数
V2では、バックエンドプール内のインスタンスへ割り当てるフロントエンドポートを事前に確保します。
例えば、最大100台までスケールアウトするVMSSでは、1つのNAT規則につき少なくとも100個のフロントエンドポートが必要です。ポート範囲が不足すると、新しいインスタンスのポートマッピングを作成できず、バックエンドプールのスケールアウトがブロックされる可能性があります。(Microsoft Learn)
ポートの重複
次の構成は避ける必要があります。
- 複数のInbound NAT規則でフロントエンドポート範囲が重複している
- 複数のInbound NAT規則で同じバックエンドポートを使用している
- Inbound NAT規則と負荷分散規則が同じバックエンドポートを使用している
現在の規則だけでなく、将来追加する管理ポートやVMSSの最大台数も含めてポート範囲を設計してください。(Microsoft Learn)
NSGと接続元制限
V2へ移行しても、Network Security Groupの許可規則は自動的に最適化されません。RDPの3389番やSSHの22番をインターネット全体へ公開する構成は避け、接続元IPアドレスを管理拠点やVPNに限定します。
Azure BastionやVPN経由の管理に切り替えられる場合は、Inbound NAT規則自体を廃止できないかも検討してください。
Infrastructure as Code
Azure portalだけを変更しても、古いテンプレートを再実行するとInbound NAT Poolsが再作成される恐れがあります。
次の箇所を併せて更新します。
- ARMまたはBicepの
inboundNatPools - VMSS側の
loadBalancerInboundNatPools - TerraformのLoad BalancerおよびVMSSネットワーク設定
- Azure CLIやPowerShellのデプロイスクリプト
- 構成ドリフトを修正するCI/CDパイプライン
- 障害復旧用の再デプロイ手順
遅くとも2026年11月15日までに、新規環境がV2で作成される状態へ変更しておくことが重要です。
料金は変わるのか
Azure Load Balancerの料金表では、Inbound NAT規則自体は無料です。また、Inbound NAT規則はLoad Balancerの課金対象となる規則数には含まれません。そのため、V1からV2へ移行したことだけを理由に、NAT規則単位の料金が追加されるわけではありません。(Microsoft Azure)
ただし、次の費用は別途確認が必要です。
- Standard Load Balancerの利用料金
- Load Balancerが処理するデータ量
- Azure外への帯域料金
- Public IPアドレス
- Azure BastionやVPNなど、代替管理経路の料金
- SKUやネットワーク構成を同時に変更する場合の差額
実際の金額はリージョンや契約によって異なるため、移行前後の構成をAzure料金計算ツールで比較してください。
移行で失敗しやすいポイント
| 失敗例 | 対策 |
|---|---|
| V1規則をすべて削除してしまう | 単一VM向けV1とVMSS向けInbound NAT Poolsを区別する |
| 停止時間を考慮していない | 管理接続が切れる前提でメンテナンス時間を確保する |
| ポート範囲が狭い | VMSSの最大インスタンス数を基準に確保する |
| VMSSモデルだけ変更した | update-instancesなどで全インスタンスへ反映する |
| IaCが古いまま残っている | テンプレートとCI/CDも同時にV2へ更新する |
| 本番環境で直接実行した | 検証環境で削除・再作成・スケールアウトを試す |
| 管理サービスのリソースを直接変更した | サービス固有の移行案内やサポート方針を確認する |
よくある疑問
2026年11月15日に既存のInbound NAT Poolsは停止しますか
停止しません。2026年11月15日以降に制限されるのは新規作成です。既存構成は2027年9月30日の廃止日まで継続して動作すると案内されています。(Microsoft Azure)
単一のAzure VMで使用しているV1規則も移行が必要ですか
今回の案内では不要です。対象はVMSS固有のInbound NAT Poolsであり、単一VM向けInbound NAT rule V1は廃止対象に含まれていません。(Microsoft Learn)
V2へ自動的に移行されますか
自動移行を前提にせず、管理者が手動または公式の移行用PowerShellモジュールを使って対応する必要があります。まず利用状況を確認し、停止時間を含む移行計画を作成してください。(Microsoft Learn)
最初に何をすべきですか
対象のLoad Balancerで次のコマンドを実行してください。
az network lb inbound-nat-pool list \
--resource-group <リソースグループ名> \
--lb-name <ロードバランサー名>結果が返った環境を一覧化し、ポート範囲、接続用途、VMSSの最大台数、構築テンプレートの所有者を記録します。その後、検証環境でV2への移行を行い、本番のメンテナンス日を決めるのが安全です。
今回の対応では、2026年11月15日までに新規構築をV2へ切り替え、2027年9月30日より十分前に既存環境を移行することが重要です。期限直前ではなく、ポート設計、VMSS更新、IaC修正、接続試験を含めて早めに着手してください。
コメント