2026年6月17日、Azure StandardV2 NAT GatewayのICMPサポートが一般提供（GA）になりました。既存・新規のStandardV2 NAT Gatewayで、IPv4とIPv6の送信ICMP Echo Request／Echo Reply、つまりpingによる疎通確認が追加設定なしで利用できます。 (Microsoft Azure)
既にStandardV2を利用している環境では、NAT Gatewayの再作成や再起動は不要です。一方、Standard SKUは今回の対象外です。ICMPを利用するためにStandardからStandardV2へ移行する場合は、インプレース更新ができず、パブリックIPの変更や通信断を伴う点に注意してください。
Azure NAT GatewayのICMPサポートGAで何が変わったのか
今回の変更により、StandardV2 NAT Gatewayを経由するワークロードから、インターネット上の宛先へpingを実行できるようになりました。
主な変更点は次のとおりです。
| 確認項目 | 変更前 | GA後 |
|---|---|---|
| 対象SKU | ICMP Echoは利用不可 | StandardV2で利用可能 |
| 対応プロトコル | TCP、UDP | TCP、UDP、ICMP Echo |
| IPバージョン | ICMP疎通確認は不可 | IPv4、IPv6の両方に対応 |
| 既存リソース | pingは失敗 | 既存のStandardV2でも利用可能 |
| 追加設定 | 該当なし | 原則不要 |
| 主な用途 | TCP・UDPベースの接続確認 | pingによる到達性の切り分け |
Azure公式情報では、既存と新規のStandardV2 NAT Gatewayの両方が対象であり、機能は既定で提供されると説明されています。 (Microsoft Azure)
ICMPのすべてがサポートされたわけではない
今回明示されている対象は、ICMP Echo RequestとEcho Replyです。
「ICMP対応」という表現だけを見て、Destination UnreachableやTime Exceededなど、すべてのICMPメッセージに対応したと判断しないようにしてください。tracerouteやPath MTU Discoveryなど、Echo以外のICMPメッセージに依存する診断については、別途実環境での確認が必要です。
外部からAzure VMへpingできる機能ではない
Azure NAT Gatewayは、引き続き送信専用のNATサービスです。
今回の変更は、Azure側のワークロードから開始したICMP Echo Requestと、その応答となるEcho Replyを通過させるものです。インターネット側からNAT GatewayのパブリックIPへ一方的にpingを送り、配下のVMへ到達できるようになるわけではありません。未要求の受信接続を許可しないというNAT Gatewayの基本動作は変わっていません。 (Microsoft Learn)
今回の変更で影響を受けるユーザー
StandardV2 NAT Gatewayを利用している管理者
既存のStandardV2環境では、リソースを作り直さなくてもpingを利用できます。
これまで「NAT GatewayではICMPが通らないため、ping失敗は正常」としていた監視ルールや運用手順がある場合は、内容を見直してください。pingが成功することを前提に、疎通確認の手順を簡略化できます。
ただし、pingだけでアプリケーションの正常性を判断するのは危険です。pingが成功していても、HTTPSの443番ポートやデータベースの接続ポートが利用できるとは限りません。
Standard NAT Gatewayを利用しているユーザー
Standard SKUに、今回の機能が自動追加されるわけではありません。
ICMP Echoを利用したい場合は、StandardV2への移行を検討します。ただし、pingだけを目的に本番環境を急いで移行する必要はありません。StandardV2にはゾーン冗長、IPv6、処理性能の向上、NAT Gatewayフローログなどの特徴もあるため、可用性や監視要件を含めて判断するのが現実的です。 (Microsoft Learn)
セキュリティ担当者
StandardV2ではICMP Echoが既定で利用可能になるため、ICMP送信を意図的に禁止している環境では出口制御を確認してください。
特に次の環境では、運用ポリシーとの整合性を確認する必要があります。
- NSGで送信プロトコルを厳格に制限している
- Azure FirewallやNVAを経由して外部通信を制御している
- マルウェア対策としてICMP通信を禁止している
- 外部監視や死活監視にpingを使用している
- 監視対象が多く、高頻度のpingを実行している
ICMPを許可したくない場合は、NSGやファイアウォールなど、既存の出口制御で明示的に拒否してください。
ICMPを使うための設定や更新は必要か
StandardV2 NAT Gatewayを利用中であれば、ICMP機能を有効にするためのスイッチや追加オプションはありません。NAT Gatewayの更新、VMの再起動、サブネットの再関連付けも原則不要です。 (Microsoft Learn)
ただし、pingが実際に成功するには、NAT Gateway以外の経路もICMPを通過できる必要があります。
| 確認場所 | 確認する内容 |
|---|---|
| NAT Gateway | SKUがStandardV2になっているか |
| パブリックIP | StandardV2のパブリックIPまたはプレフィックスが関連付いているか |
| サブネット | 対象のStandardV2 NAT Gatewayが関連付いているか |
| NSG | 送信ICMPを拒否する優先度の高い規則がないか |
| ルートテーブル | インターネット向け通信がNVAやVPN Gatewayへ強制転送されていないか |
| OSファイアウォール | VMやコンテナ側で送信ICMPを拒否していないか |
| 接続先 | 接続先がICMP Echo Replyを返す構成か |
StandardV2 NAT Gatewayでは、StandardV2のパブリックIPが必要です。Standard SKUのパブリックIPをそのまま関連付けることはできません。 (Microsoft Learn)
StandardV2とサブネットの関連付けを確認する手順
Azureポータルで確認する
Azureポータルでは、次の順番で確認します。
- Azureポータルで「NAT ゲートウェイ」を開く
- 対象のNAT Gatewayを選択する
- SKUが「StandardV2」であることを確認する
- 送信IPにStandardV2パブリックIPまたはプレフィックスが設定されていることを確認する
- ネットワーク設定から、対象サブネットとの関連付けを確認する
- サブネットに設定されたNSGとルートテーブルを確認する
Azure CLIでSKUを確認する
az network nat gateway show \
--resource-group <リソースグループ名> \
--name <NAT Gateway名> \
--query "sku.name" \
--output tsv結果が次のように表示されれば、今回のICMPサポート対象です。
StandardV2サブネットに関連付けられているNAT Gatewayは、次のコマンドで確認できます。
az network vnet subnet show \
--resource-group <リソースグループ名> \
--vnet-name <仮想ネットワーク名> \
--name <サブネット名> \
--query "natGateway.id" \
--output tsv何も表示されない場合は、そのサブネットにNAT Gatewayが関連付いていません。Azureポータル、Azure CLI、PowerShell、Bicep、Terraformのいずれかで関連付けを確認・更新できます。 (Microsoft Learn)
pingでICMP疎通を確認する方法
StandardV2 NAT Gatewayに接続されたサブネット内のVMやワークロードから、ICMP応答を許可している宛先へpingを実行します。
IPv4を確認する
ping -4 <ICMP応答を許可しているIPv4アドレスまたはFQDN>IPv6を確認する
ping -6 <ICMP応答を許可しているIPv6アドレスまたはFQDN>確認時は、最初にIPアドレスを指定し、次にFQDNを指定すると原因を切り分けやすくなります。
- IPアドレスでは成功し、FQDNでは失敗する場合はDNSを確認する
- IPv4だけ成功する場合はIPv6アドレス、ルート、NSGを確認する
- pingだけ失敗し、HTTPSは成功する場合は接続先や途中経路のICMP制限を疑う
- ping、HTTPS、DNSのすべてが失敗する場合はNAT Gatewayの関連付けやルートを確認する
アプリケーション通信も併せて確認してください。例えば、HTTPSの確認には次のような方法があります。
curl -I https://<接続先>Windowsでは、特定ポートへのTCP接続を次のように確認できます。
Test-NetConnection <接続先> -Port 443pingが失敗するときに確認するポイント
pingの失敗だけでは、StandardV2 NAT Gatewayの障害とは判断できません。接続先のサーバーやファイアウォールがICMPに応答しない構成は一般的です。
| 症状 | 考えられる原因 | 対応 |
|---|---|---|
| すべてのpingが失敗する | SKUがStandard、NSG拒否、経路の問題 | SKU、NSG、UDR、サブネット関連付けを確認 |
| pingは失敗するがHTTPSは成功する | 接続先がICMPを拒否 | ICMP応答が確認できる別の接続先で試す |
| IPv4は成功しIPv6は失敗する | IPv6パブリックIPやIPv6経路が未構成 | IPv6アドレス、プレフィックス、NSG、DNSを確認 |
| IP指定は成功しFQDNだけ失敗する | DNS障害 | DNSサーバーと名前解決設定を確認 |
| 一部の接続先だけ失敗する | 接続先側のICMP制限 | 複数の宛先で比較する |
| pingとTCP・UDPがすべて失敗する | NAT Gatewayまたはルーティングの問題 | パブリックIP、サブネット、UDR、NSGを確認 |
サブネットに0.0.0.0/0のユーザー定義ルートがあり、次ホップがNVA、VPN Gateway、ExpressRoute側になっている場合、通信はNAT Gatewayを経由しないことがあります。NAT Gatewayが関連付いていることだけでなく、実際の出口経路も確認してください。 (Microsoft Learn)
StandardからStandardV2へ移行する際の注意点
StandardからStandardV2へのインプレースアップグレードはできません。新しいStandardV2 NAT Gatewayを作成し、サブネットの関連付け先を切り替える必要があります。移行時には既存の送信接続が影響を受けるため、メンテナンス時間を確保してください。 (Microsoft Learn)
移行前に確認すること
移行を始める前に、次の項目を整理します。
- StandardV2が対象リージョンで利用できるか
- 新しいStandardV2パブリックIPを取得できるか
- 外部サービスの許可リストに送信元IPを登録していないか
- 移行対象となるサブネットはどれか
- 長時間接続やバッチ処理を停止できる時間帯はいつか
- Azure PolicyやIaCテンプレートがStandardV2を許可しているか
- Basic Load BalancerやBasicパブリックIPが同一構成に残っていないか
- 独自IPを持ち込むBYOIPを使用していないか
StandardV2では新しいStandardV2パブリックIPへのre-IPが必要です。外部のSaaS、API、データベースなどで送信元IPを許可リストに登録している場合は、切り替え前に新しいIPを追加してください。
推奨する移行手順
- 対象リージョンと構成のサポート状況を確認する
- StandardV2パブリックIPまたはパブリックIPプレフィックスを作成する
- StandardV2 NAT Gatewayを作成する
- 外部サービスの許可リストへ新しい送信元IPを追加する
- 別のテスト用サブネットで可能な範囲の動作確認を行う
- メンテナンス時間に対象サブネットをStandardV2へ切り替える
- ping、DNS、TCP、UDP、業務アプリケーションを確認する
- 監視期間を設けた後、不要になったStandard NAT Gatewayを削除する
1つのサブネットに同時に関連付けられるNAT Gatewayは1つだけです。そのため、本番サブネットでStandardとStandardV2を並行利用して徐々に切り替えることはできません。事前検証には、別サブネットや検証環境を利用してください。
料金は変わるのか
Microsoftの公式料金情報では、StandardとStandardV2のNAT Gatewayは同一料金とされています。今回のICMP機能について、専用の追加料金項目は示されていません。 (Microsoft Azure)
ただし、NAT Gatewayでは次の料金を確認する必要があります。
- NAT Gatewayリソースの稼働時間
- 送信データと、その応答として返されるデータの処理量
- Azureデータセンター外へ送信する帯域幅
- StandardV2 NAT Gatewayのフローログを有効にした場合のログ料金
- Log Analyticsやストレージへ保存する場合の料金
NAT Gatewayは、サブネットやパブリックIPを関連付けていなくても、リソースを作成した時点から時間料金が発生します。移行期間中にStandardとStandardV2を同時に保持すると、その期間は両方のリソース料金が発生する点にも注意してください。 (Microsoft Azure)
通常の疎通確認で発生するICMPデータ量は大きくありません。ただし、多数のVMから短い間隔で継続的にpingを送る設計では、不要な通信や監視アラートが増えます。死活監視では、監視間隔、タイムアウト、再試行回数を必要最小限に設定してください。
対応期限や強制移行はあるのか
2026年6月17日の発表はICMPサポートの一般提供開始であり、Standard NAT Gatewayの廃止や強制移行を告知するものではありません。今回の更新に関して、必須の対応期限や移行期限は示されていません。 (Microsoft Azure)
対応方針は、現在利用しているSKUによって異なります。
| 現在の構成 | 推奨する対応 |
|---|---|
| StandardV2を利用中 | SKUと経路を確認し、検証環境でpingを試す |
| Standardを利用中 | ICMP、IPv6、ゾーン冗長、フローログの必要性を評価する |
| ICMPを禁止したい | NSGやファイアウォールで明示的に制限する |
| ping監視を導入したい | TCPやHTTP監視と組み合わせて設計する |
| StandardV2へ移行したい | 新しい送信元IPと通信断を前提に移行計画を作る |
まとめ
Azure StandardV2 NAT Gatewayでは、2026年6月17日からIPv4とIPv6のICMP Echo Request／Echo Replyが一般提供されました。既存のStandardV2環境では追加設定や再デプロイは不要です。
まずAzureポータルまたはAzure CLIでSKUがStandardV2であることを確認し、検証環境からpingとTCP接続の両方をテストしてください。pingが失敗した場合は、NAT Gatewayだけでなく、NSG、UDR、OSファイアウォール、接続先のICMP制限を順番に切り分けます。
Standardから移行する場合は、インプレース更新ができません。新しいStandardV2パブリックIPへの変更、外部サービスの許可リスト更新、既存接続の切断を含むメンテナンス計画を作成してから実施することが重要です。
コメント