Azure の「既定アウトバウンドアクセス（暗黙のインターネット送信）」廃止に関する通知を受け取り、どこまで対応すべきか悩んでいる方向けに、最新の公式ドキュメントに基づく正しい影響範囲と、具体的な実装パターン／運用手順をまとめました。結論から言うと、既存の仮想ネットワーク（VNet）上の既存 VM は直ちに停止しません。ただし、今後の再構築や拡張では“明示的なアウトバウンド経路”が標準になります。Windows Update だけ必要なサーバーの最小構成も含め、実践的に解説します。
まず押さえるべき前提（最新の公式情報）
「既定アウトバウンドアクセス」は、VNet のサブネットに明示的な送信経路（NAT Gateway、Standard Load Balancer のアウトバウンド規則、NIC に割り当てた Public IP、Firewall/NVA など）が無い場合に、Azure が自動で割り当てる“暗黙の送信用パブリック IP”です。予告なく IP が変わり、ゼロトラストにも反するため、本番用途に非推奨です。
2026年3月31日以降、新しく作成する 新規 VNet は既定で Private サブネット（= 既定アウトバウンドを使わない）として作成され、パブリック到達が必要なら明示的な送信経路を構成するのが標準挙動になります。
一方で、既存の VNet はこの既定挙動変更の対象外です。既存 VNet 上では、既存 VM だけでなく、その VNet に新規作成した VM でも、サブネットを Private に変更しない限り既定アウトバウンドが引き続き割り当てられます（= 直ちに送信が止まるわけではありません）。
| 対象 | 作成／変更時期 | 既定挙動 | 備考 |
|---|---|---|---|
| 既存 VNet 上の既存 VM | ～現在 | 既定アウトバウンド継続 | サブネットを Private にしない限り継続。 |
| 既存 VNet 上の新規 VM | ～現在 | 既定アウトバウンド割当の可能性あり | 同上。Private 化しない限り割り当て継続。 |
| 新規 VNet（API 既定変更） | 2026-03-31 以降 | Private サブネットが既定 | 明示的な送信経路が必須。 |
補足：Private サブネットでは、Windows の ライセンス認証／Windows Update のような OS 基盤通信にも明示的な送信経路が必要になります。また、UDR の next hop type Internet は動作しません（NVA 経由の 0.0.0.0/0 ルート等に置換）。
ユーザーからの質問に対する結論
1) 「該当 3 台は Windows Update 以外の外向き通信は不要。設定変更は必要？」
今すぐの強制変更は不要です。理由は上記の通り、既存 VNet は既定挙動変更の対象外であり、既定アウトバウンドが引き続き機能するためです。ただし、セキュア・バイ・デフォルトの観点と将来の再構築／新規 VNet での仕様（Private 既定）を踏まえ、計画的に“明示的アウトバウンド経路”へ移行しておくことを強く推奨します。特に「Windows Update だけ許可したい」ケースは、Azure Firewall の FQDN タグ WindowsUpdate を使うと安全に最小化できます（NAT Gateway 単体では URL/FQDN による絞り込みは不可）。
なお、かつて NSG で Windows Update を許可するのに使えた AzureUpdateDelivery サービスタグは非推奨（deprecated）です。新規構成の依存は避け、Firewall のアプリケーション規則（FQDN タグ）または WSUS/Update Manager へ移行してください。
2) 「今後どのような対策を取ればよいか？」
推奨は次の 4 パターンのいずれかです（後述の選定指針と設計チェックリストを参照）。
| 方式 | 概要 | 得意領域 | 注意点 |
|---|---|---|---|
| NAT Gateway | サブネット単位に一括 SNAT。1 IP あたり 64,512 SNAT ポート、最大 16 IP で約 100 万ポート超に拡張可能。 IP を固定でき、ホワイトリストが容易。 | 高スループット、IP 固定、SNAT 枯渇対策 | レイヤ 7 制御は不可（URL/FQDN 制御は Firewall 併用）。ゾーン設計に配慮。 |
| Standard Load Balancer（SLB）のアウトバウンド規則 | 小規模〜中規模の送信を低コストで実現。フロント IP ごとに 64K 近い SNAT ポートを利用。 | コスト重視の小規模送信 | 大量接続だと SNAT ポート消費が課題。既知の制限事項にも注意。 |
| NIC への Public IP 直付け | 最も単純。個別サーバー単位で外部到達。 | 検証環境・一時用途 | セキュリティ・運用負荷が高くなりがち。NSG/上位 FW で厳格に制御を。 |
| Azure Firewall / NVA | アプリケーション規則（FQDN タグ）や集中ログで強力に制御。Windows Update の FQDN タグを利用可。 | L7 フィルタ、監査、ゼロトラスト | スループットと SNAT 口数の設計は要検討（大規模は NAT Gateway 併用が有効）。 |
「Windows Update だけ許可したい」最小構成ガイド
Windows Update／ライセンス認証は Private サブネットでは明示的な送信経路が無いと動作しません。最も扱いやすいのは Firewall（アプリケーション規則）＋ UDR です。
- 送信経路：サーバーの属するサブネットに
0.0.0.0/0を 次ホップ＝Firewall とする UDR を設定。Firewall から外部へは NAT（Firewall SNAT もしくは背後の NAT Gateway）で送信。 - 通信許可：Azure Firewall のアプリケーション規則で FQDN タグ「WindowsUpdate」 を Allow。その他は Deny。
- NSG：VM の NIC/サブネットに対して、外向きは 80/443 に限定（OS や運用要件に合わせて最小化）。
- 代替案：WSUS を VNet 内に置く、あるいは Azure Update Manager で集中更新（Arc 経由でハイブリッドも可）。インターネット露出を最小化できます。
- 非推奨の手法：NSG の AzureUpdateDelivery サービスタグは既に 非推奨。将来の互換性を担保できません。
大量更新による接続急増や DO 配信で SNAT ポートが逼迫しやすい環境では、Firewall の外側に NAT Gateway を併用し、SNAT 口数を確保する設計が堅実です（1 IP = 64,512 ポート、最大 16 IP で ~100 万ポート）。
3 台の既存 VM に対する具体的アクションプラン
| フェーズ | 目的 | 作業内容（例） |
|---|---|---|
| 可視化 | 既定アウトバウンド依存の洗い出し | Azure Advisor → 運用上の優秀性 →「Add explicit outbound method to disable default outbound」を確認。対象 NIC/VM をリストアップ。 |
| 設計 | Windows Update 最小構成を決定 | Firewall（FQDN タグ）＋ UDR を基本。コスト・性能要件次第で NAT Gateway を併用。 |
| 実装 | 明示的アウトバウンド経路の導入 | サブネットに NAT Gateway をアタッチ、もしくは Firewall/NVA を配置し 0.0.0.0/0 を迂回。SLB 既設なら小規模はアウトバウンド規則でも可。 |
| 検証 | Windows Update 動作・SNAT 健全性 | WSUS/Update Manager 経由の更新や OS 認証を確認。SNAT 枯渇兆候がないか監視。 |
| 最適化 | 将来の再構築に備えた準備 | 新規 VNet は Private 既定（2026-03-31～）に合わせ、テンプレートや IaC の標準化を実施。 |
実装の要点（設計パターン別の深掘り）
NAT Gateway を使う場合
- スケール：1 Public IP あたり 64,512 SNAT ポート。最大 16 IP で約 1,032,192 ポート。大量同時接続でも枯渇しにくい。
- ゾーン設計：NAT Gateway 自体はゾーナル・リソース。可用性ゾーン障害に対する設計では「ゾーンごとにサブネット＋NAT Gateway」を構成し、ゾーン独立性を確保するのが推奨。
- SNAT 最適化：特定宛先へのセッション集中で 1 宛先あたりの同時接続上限に当たる場合は、Public IP の追加／サブネット分割で分散。
Standard Load Balancer（アウトバウンド）を使う場合
- SNAT ポート：フロント IP ごとに 64K 近い SNAT ポート。負荷分散／Inbound NAT ルールでポートが消費される点に留意。
- 既知の落とし穴：IP アドレス指定のバックエンドプール構成では既定アウトバウンドに依存する既知の問題があり、NAT Gateway 併用が無難。
Azure Firewall / NVA を使う場合
- FQDN タグ：「WindowsUpdate」タグで更新サイトのみ許可。セキュリティと運用性のバランスがよい。
- 大規模構成：SNAT 口数は Firewall だけだと不足しがち。NAT Gateway を背後に統合し、レイヤ 7 制御と大量 SNAT を両立するのが定石。
監査と可視化：どの VM が既定アウトバウンドに依存しているか
Azure Advisor の推奨事項「Add explicit outbound method to disable default outbound」を確認するのが最も簡単です。ここで NIC 単位の対象が一覧できます。
より踏み込む場合は、NIC のプロパティ properties.defaultOutboundConnectivityEnabled を基に Azure Resource Graph で網羅的に抽出できます（ARG 例）。
Resources
| where type =~ 'microsoft.network/networkinterfaces'
| project id, name, resourceGroup, location,
vmId = tostring(properties.virtualMachine.id),
defaultOutbound = tobool(properties.defaultOutboundConnectivityEnabled)
| where defaultOutbound == true
また、サブネットが Private かどうかは Microsoft.Network/virtualNetworks/subnets の properties.defaultOutboundAccess を確認します。Private 化後、VM に残る既定アウトバウンドのフラグを正しく消すには、サブネットを Private にした上で VM を停止（割り当て解除）→ 起動が必要です。
移行・運用のチェックリスト
- ① 影響調査：Advisor と ARG で既定アウトバウンド依存の NIC/VM を洗い出し。
- ② 方式選定：スループット・可用性・セキュリティ要件から NAT Gateway／SLB／Firewall/NVA を組み合わせ決定。
- ③ Windows Update 方針：Firewall の WindowsUpdate タグで最小許可、もしくは WSUS／Azure Update Manager で集中管理。
- ④ ゾーン設計：NAT Gateway はゾーナル。VM の配置と同一ゾーンでスタックを組むか、複数サブネットでゾーン分離。
- ⑤ SNAT 設計：大量同時接続や Delivery Optimization を考慮し、Public IP の本数や宛先分散を設計。
- ⑥ 検証：Windows 認証／更新、アプリ外向き通信、ログ取得、障害時フェイル動作を確認。Private 化後の UDR（
Internetnext hop の排除）も忘れずに。 - ⑦ IaC 標準化：2026-03-31 以降の Private 既定に合わせ、Bicep/ARM/CLI/Terraform のテンプレート既定値を整備。
トラブル回避の知見（SNAT と可用性）
- SNAT 枯渇：同一宛先への大量短時間接続は枯渇を招きやすい。NAT Gateway なら IP 追加で SNAT プールを水平拡張できる。
- 可用性ゾーン障害：単一ゾーンに置いた NAT Gateway をゾーンを跨る VM 群で共有すると、障害時に全面停止する恐れ。ゾーン整合のサブネット設計が有効。
- VMSS（Flexible）：Flexible オーケストレーションの VMSS は既定アウトバウンドが付与されないため、明示的な送信経路が必須。
サンプル実装（コマンド断片）
NAT Gateway の作成とサブネット関連付け（Azure CLI）
# 1) パブリック IP を作成（必要に応じて複数）
az network public-ip create -g rg -n nat-pip-01 --sku Standard --allocation-method static
# 2) NAT Gateway を作成
az network nat gateway create -g rg -n ngw-01 --public-ip-addresses nat-pip-01
# 3) サブネットに関連付け
az network vnet subnet update -g rg --vnet-name vnet01 -n snet-app --nat-gateway ngw-01 Private サブネット化（既定アウトバウンドを無効化）
# 既存サブネットを Private 化
az network vnet subnet update -g rg --vnet-name vnet01 -n snet-app --default-outbound false
# 変更を NIC に反映させるには、該当 VM を停止・割り当て解除してから起動
# （defaultOutboundConnectivityEnabled のフラグが更新される）
停止・割当解除を伴う理由は、NIC 側の既定アウトバウンド割り当てフラグ更新に必要だからです。
関連の“近い将来”イベントも踏まえておく
同時期に Basic SKU Public IP / Basic Load Balancer の退役も進んでおり、Standard SKU への統一を前提に設計しておくと移行が滑らかです（ゾーン冗長 IP の活用も可能）。
まとめ：いま取るべき一手
- 既存 3 台は直ちに停止しないが、将来の再構築や新規 VNet 作成では明示的アウトバウンド経路が必須になる。
- Windows Update だけ必要なら、Firewall（WindowsUpdate FQDN タグ）＋ UDR が安全・簡潔。大規模は NAT Gateway を背後に。
- Advisor と ARG で依存状況を可視化し、段階的に Private サブネット化＋明示的送信へ移行するブループリントを固める。
- IaC の既定値を 2026-03-31 以降の挙動（Private 既定）に合わせて更新しておく。
付録：方式選定の意思決定マトリクス
| 要件 | 最有力候補 | 補足 |
|---|---|---|
| 固定アウトバウンド IP が欲しい／第三者ホワイトリストに提出 | NAT Gateway | IP 固定と SNAT スケールに優れる。 |
| 更新サイトのみ許可したい（最小権限） | Firewall（FQDN タグ） | WindowsUpdate タグで簡潔に許可。 |
| 小規模・低コストで足りる | SLB アウトバウンド | SNAT ポート数と既知の制限を確認。 |
| ゼロトラスト／監査の厳密化 | Firewall + NAT Gateway | L7 制御と大規模 SNAT を両立。 |
付録：よくある誤解と正しい理解
- 誤解：「2025-09-30 で既存 VM の送信が止まる」
正解：最新の公式情報では、既存 VNet は対象外。新規 VNet が 2026-03-31 以降 Private 既定へと変わるのが主眼。既存 VNet 上の VM はサブネットを Private にしない限り既定アウトバウンドが続く。 - 誤解：「NSG の AzureUpdateDelivery を使えば良い」
正解：当該サービスタグは 非推奨。Firewall の WindowsUpdate FQDN タグや WSUS/Update Manager へ移行を。 - 誤解：「UDR の next hop=Internet で一部だけバイパスできる」
正解：Private サブネットではInternetnext hop は使えない。明示的経路を構成する。
参考：Windows Update をオフライン寄りにしたいとき
VNet 内の WSUS に集約すれば、各 VM はインターネットに直接出さずに更新可能です。ハイブリッド環境では Azure Arc と Azure Update Manager を組み合わせ、メンテナンスウィンドウや再起動管理を一元化すると運用の手間が減ります。
本記事の要点：既存 3 台に即時の停止リスクはありません。しかし、2026-03-31 以降に新規 VNet を作ると Private 既定になります。今のうちに NAT Gateway / Firewall 等の“明示的アウトバウンド経路”を標準化し、Windows Update のみを許可する最小権限設計へ移行しておくのが、コスト・運用・監査のすべてで長期的に有利です。
コメント