Azure ネットワーク入門：VNet からグローバルバックボーンまで
はじめに
Azure のネットワークを設計するときは、サービス名を覚えるよりも、「どの IP に届くのか」「通信を誰が許可するのか」「どの経路を通るのか」「名前を誰が解決するのか」を順に確認する方が、全体をつかみやすくなります。
この記事では、VNet を起点に NSG と UDR、ピアリング、PaaS の VNet 統合・インジェクション、Private Link と DNS、VPN と ExpressRoute、Microsoft のグローバルネットワークを整理します。特に、オンプレミスと Azure をつなぎ、PaaS の公開アクセスを閉じたい方を想定しています。「サービスと VNet の関係」と「VNet 同士の関係」を組み合わせ、何ができて何ができないかを表と 12 枚の図で確認します。
最初に押さえたいのは、プライベート IP を使うこと、通信を検査すること、暗号化することは、それぞれ別の設計事項だという点です。ExpressRoute を引くだけ、あるいはプライベートエンドポイントを作るだけでは、必要な制御がすべてそろうわけではありません。
記載内容は Microsoft Learn と Azure 公式ブログを出典とし、各章で根拠となるページへリンクしています。SKU・上限値・提供状況は変わるため、設計時は必ずリンク先の最新情報を確認してください。
2026年10月19日の改稿では、PaaS の接続方式と VNet 間の到達性、API Management の方式選択を公式資料で確認しました。図と表は設計上の整理であり、実環境での疎通・性能検証の結果ではありません。
全体像：レイヤーで捉える
Azure のネットワーク機能は、「どの層の課題を解くか」で分けると理解しやすくなります。内側ほど局所的で自分が細かく制御し、外側ほど広域で Microsoft が運用します。
各章はこの図の内側から外側へ順に進みます。ExpressRoute はピアリング拠点、Front Door はエッジ PoP が入口になります。一方、サイト間 VPN はインターネット上の IPsec トンネルを VPN Gateway で終端します。すべての通信が同じ入口・ゲートウェイを通るわけではありません。
| 層 | 解く課題 | 主な機能 | 章 |
|---|---|---|---|
| VNet 内 | IP 空間を切り、誰を通すか・どこへ送るかを決める | サブネット、NSG、UDR | 1・2 |
| VNet 間 | 複数の VNet をつなぎ、共有機能を集約する | ピアリング、ハブ & スポーク、AVNM | 3 |
| PaaS 接続 | サービスの入口・出口・配置を決める | Private Link、VNet 統合・インジェクション、Private DNS | 4・4-1 |
| 境界 | 入口・出口・ハイブリッド・運用の制御点を置く | 各種ゲートウェイ | 5 |
| ハイブリッド | オンプレとつなぐ | VPN、ExpressRoute | 6 |
| グローバル | リージョン・拠点・利用者を結ぶ | Microsoft バックボーン、Virtual WAN | 7・8 |
1. VNet の基本概念
VNet は「1 つのリージョン・1 つのサブスクリプションに属する、自分専用の IP 空間」です。リージョンをまたぐことはできませんが、同一リージョン内のすべての可用性ゾーン（AZ）にまたがります。リージョンを越えたい場合はピアリング等で VNet 同士をつなぎます（第 3 章）。
| 概念 | ポイント | 設計時の注意 |
|---|---|---|
| アドレス空間 | RFC 1918 のプライベート範囲が基本。RFC 6598（100.64.0.0/10）もプライベートとして扱われる | オンプレや他 VNet と重複させない。重複するとピアリングもルーティングもできない |
| サブネット | VNet のアドレス空間を区切った単位。NSG・ルートテーブル・NAT GW はサブネット単位で関連付ける | 後からの拡張は難しいため、将来のサービス追加分も見込んで余裕を持たせる |
| 予約 IP | 各サブネットで先頭 4 個と最後の 1 個、計 5 個は使えない（.0 ネットワーク、.1 既定 GW、.2-.3 Azure DNS 用、末尾ブロードキャスト） | /29 では実質 3 個しか使えない。小さいサブネットは要注意 |
| 専用サブネット | GatewaySubnet、AzureFirewallSubnet、AzureBastionSubnet、RouteServerSubnet など名前固定のサブネットがある | 名前と最小サイズが決まっている（第 5 章の表を参照） |
| サブネット委任 | App Service VNet 統合、SQL Managed Instance、Container Apps などが専用サブネットを要求する | 配置できるリソースは委任先サービスの要件に従う。異なるサービスの混在可否を確認する |
| Azure 提供 DNS / DHCP | VM は既定で Azure 管理の DNS（168.63.129.16）を使い、同一 VNet 内のホスト名を解決できる | 閉域でオンプレと名前解決を統合する場合は DNS 設計が必須（第 4 章） |
既定のアウトバウンドアクセスに頼らず、出口を明示する
かつては VM にパブリック IP がなくても、Azure が暗黙の IP でインターネットへ出られるようにしていました。これが「既定のアウトバウンドアクセス」です。2026 年 3 月 31 日以降にリリースされた API では、新規 VNet のサブネットが既定でプライベートサブネット（defaultOutboundAccess = false）になります。
- 既存の VNet・VM はそのまま動き続けますが、Microsoft は明示的な送信方法への移行を強く推奨しています（Tech Community）。
- 明示的な送信方法は NAT Gateway、Load Balancer のアウトバウンド規則、Azure Firewall / NVA への UDR、VM へのパブリック IP 直付けのいずれかです。
- 閉域設計ではむしろ好都合で、「意図しない出口がない」状態が既定になります。その代わり、OS 更新や外部 API など必要な出口は自分で用意する必要があります。
- 例外として、同一リージョンの Azure Storage にはプライベートサブネットからでも明示的な送信方法なしで到達できます。
2. VNet 内のトラフィック制御：NSG と UDR
VNet 内の通信は「誰を通すか」を NSG が、「どこへ送るか」をルートテーブルが決めます。両者は独立しており、閉域設計ではこの 2 つを組み合わせて出口を絞り込みます。
送信時は NIC の NSG → サブネットの NSG の順に評価され、通過したパケットの次ホップを経路表が決めます。
NSG（ネットワークセキュリティグループ）
- 送信元・宛先・ポート・プロトコルで許可 / 拒否を決めるステートフルなフィルタです。サブネットと NIC の両方に関連付けられます。
- 規則は優先度の数字が小さい順に評価され、最初に一致した規則で決まります。既定規則は「VNet 内は許可、Azure Load Balancer からは許可、それ以外は拒否」（受信）です。
- サービスタグ（例：Storage.JapanEast、AzureCloud）で Azure の IP 範囲をまとめて指定でき、IP 変更を自分で追う必要がありません。
- ASG（アプリケーションセキュリティグループ）で「Web 層」「DB 層」など論理グループ単位に規則を書けます。
- 注意：既定の受信規則「VirtualNetwork タグは許可」には、ピアリング先やオンプレから BGP で学習した範囲も含まれます。閉域でも VNet 内が全開になりやすいので、必要に応じて明示的な拒否を追加します。
ルートテーブル（システムルートと UDR）
- Azure は各サブネットにシステムルートを自動で作成します。VNet 内、ピアリング先、ゲートウェイ経由で学んだ経路、0.0.0.0/0 → Internet などが入ります。
- UDR（ユーザー定義ルート）でシステムルートを上書きできます。代表的な次ホップは VirtualAppliance（Firewall / NVA の IP を指定）、VirtualNetworkGateway、Internet、None（破棄）です。
- 経路選択の基本は最長プレフィックス一致、同じ長さなら UDR ＞ BGP ＞ システムルートの順です。ただし、VNet・ピアリング・サービスエンドポイントのシステムルートには優先される例外があります。サービスエンドポイントの経路は UDR で上書きできません。詳細はルーティングの公式説明で確認してください。
- 強制トンネリング：0.0.0.0/0 を Firewall やオンプレへ向けることで、インターネット向け通信をすべて検査できます。
- Azure Route Server を使うと、NVA と BGP で経路を交換でき、UDR を手で更新する必要が減ります。
よくある落とし穴
- プライベートエンドポイントにはサブネットのネットワークポリシー設定が関係します。NSG・UDR を適用する場合はポリシーを有効にし、UDR のプレフィックス条件も確認します（第 4 章）。
- UDR で Firewall を経由させると、行きと帰りで経路がずれる「非対称ルーティング」が起きやすく、ステートフルな Firewall で通信が落ちます。両方向の UDR をそろえるのが基本です。
- GatewaySubnet への UDR には制約があり、0.0.0.0/0 を設定してはいけません。
3. VNet 間接続：ピアリングとハブ & スポーク
VNet 同士はピアリングでつなぎ、共有機能をハブに集める「ハブ & スポーク」が Azure の標準構成です。ピアリングが非推移であることが、この構成を理解する鍵になります。
VNet ピアリング
- 同一リージョンの「VNet ピアリング」と、リージョンをまたぐ「グローバル VNet ピアリング」の 2 種類があります。
- どちらも通信はゲートウェイやインターネットを通らず、Microsoft バックボーン上をプライベート IP だけで流れます。
- 非推移：A–B、B–C をピアリングしても、A–C は通信できません。中継させるには B に Firewall / NVA を置き、UDR でそこを通します。
- ゲートウェイ転送：ハブの VPN / ExpressRoute ゲートウェイを、ピアリングしたスポークから共用できます。グローバルピアリングでも使えます。
- 注意：アドレス空間が重複する VNet 同士はピアリングできません。またゲートウェイ転送では、ハブと全スポークのアドレス空間が既定でオンプレへ広告されるため、広告経路数の上限に注意が必要です。
- グローバルピアリング越しでは Basic Load Balancer を使う一部サービスが動作しません。
図は、スポーク同士を直接接続していない構成例です。Firewall は中継先の一例で、NVA などでも実現できます。0.0.0.0/0 はインターネット向けの基本設定ですが、スポーク間の検査では宛先プレフィックスと有効なルートを確認し、必要な UDR と「転送されたトラフィックを許可」の設定を両方向でそろえます。
ハブにゲートウェイ、Firewall、Bastion、DNS を集め、各スポークはハブとだけピアリングします。スポーク間や外部への通信は UDR で Firewall を通り、検査・ログ取得を一箇所に集約できます。
VNet 同士をつなぐと、どこまで届くか
まず、通信先の VM・内部ロードバランサー・プライベートエンドポイントの IP まで、往復できる経路があるかを確認します。次の表の「条件付き」は、接続を作るだけでは足りず、経路と通信許可の設定が必要という意味です。
| VNet 間の関係 | 宛先のプライベート IP への通信 | 接続だけでは実現しないこと |
|---|---|---|
| 同じ VNet の別サブネット | 条件付きで可。NSG、UDR、宛先の待受を確認 | サブネットを分けるだけで通信を遮断すること |
| 直接ピアリングした VNet | 条件付きで可。同一・別リージョンとも対象 | 通信の強制検査、Private DNS ゾーンの共有 |
| A–ハブ、ハブ–B のピアリングのみ | A からハブ、B からハブへは可。A–B の中継は不可 | ピアリングの連鎖による推移的な到達性 |
| ハブの Firewall / NVA + スポークの UDR | 条件付きで A–B を中継可能 | 往復経路・転送許可・装置側の転送設定の自動構成 |
| ハブの VPN / ExpressRoute ゲートウェイを共有 | 条件付きでスポークからオンプレへ到達可能 | ゲートウェイ共有だけによるスポーク間の自動中継 |
| VPN Gateway の VNet 間接続 | 条件付きで接続先へ IPsec 通信が可能 | 接続していない別 VNet への自動中継 |
| Standard Virtual WAN の仮想ハブ経由 | ハブのルーターによる推移的接続が可能 | ルートの関連付け・伝播、分離方針、Firewall 検査の自動決定 |
| 同じテナント・同じサブスクリプションだけ | 接続を作らなければ不可 | 管理上の所属だけを根拠としたネットワーク到達性 |
ピアリングの経路・NVA による中継・ゲートウェイ共有の条件は仮想ネットワークピアリングの接続とサービスチェーン、Virtual WAN の推移的接続はStandard Virtual WAN の接続モデルに基づいています。アドレス空間の重複は、ここで示した通常のピアリングやルーティングでは解決しません（第 11 章）。
図の中央の構成では、両スポークからハブ内の同じプライベートエンドポイントへ接続できても、スポーク同士が通信できるとは限りません。「共有サービスに届く」と「ネットワーク全体が推移的につながる」を分けて判断します。
VNet が増えたときの一括管理：AVNM
VNet が数十〜数百に増えると、ピアリングや NSG を個別に管理するのは現実的ではありません。AVNM は管理グループやサブスクリプションをスコープに、接続・セキュリティ・ルーティングを一括で配布します。
- 接続構成：ハブ & スポーク、メッシュ、ハブ & スポーク + スポーク間直接接続を自動構成。メッシュは従来のピアリングではなく「接続グループ」という AVNM 独自の仕組みで実現され、グローバルメッシュでリージョンもまたげます（接続構成）。
- セキュリティ管理規則：NSG より先に評価される組織全体の規則。各チームが NSG を自由に設定しても、「絶対に開けてはいけないポート」を中央で強制できます。
- ルーティング構成と IPAM：UDR の一括配布と IP アドレス空間の割り当て管理。アドレス重複の防止に役立ちます。
ピアリングと VPN Gateway の VNet 間接続
VNet 同士は、VPN Gateway の「VNet 間（VNet-to-VNet）接続」でもつなげます。公式 FAQ では、VNet 間接続のトラフィックはインターネットではなく Microsoft Azure のバックボーンを通ると明記されています。経路はピアリングと同じくバックボーンで、違いは IPsec で暗号化されることとゲートウェイを経由することです。
| 観点 | VNet ピアリング | VPN Gateway の VNet 間接続 |
|---|---|---|
| 経路 | バックボーン上をプライベート IP のみで直接 | バックボーン上の IPsec トンネル |
| 暗号化（IPsec） | なし | あり |
| 帯域・遅延 | ゲートウェイを通らないため有利 | ゲートウェイ SKU が上限。拠点向けや P2S のトンネルと帯域を分け合う |
| 範囲 | リージョン内・リージョン間、別サブスクリプション・別テナント可 | 同左（Azure の同じクラウド内に限る） |
| 前提 | アドレス空間が重複しない | 両側にルートベースの VPN ゲートウェイ。アドレス空間が重複しない |
| 費用 | ピアリングのデータ転送料 | ゲートウェイ費用。同一リージョン内の転送は無料、リージョン間は送信元リージョンの転送料 |
- 通常はピアリングを選びます。Microsoft のブログでも、VPN Gateway は帯域に制限があっても暗号化が必要な場面向けと位置付けられています。
- VNet 間接続を選ぶのは、「VNet 間も IPsec で暗号化すること」が社内規程で求められる場合や、VPN ゲートウェイ側の BGP やトンネル単位で経路を制御したい場合です。
- データセンター間の物理リンクは Microsoft 側で自動的に暗号化されています（第 7 章）。暗号化だけのために VPN を張るかどうかは、規程の要求水準で判断します。
- 接続種別は「VNet-to-VNet」を選びます。「サイト間（S2S）」として相手の公開 IP を指定して組む構成もありますが、その場合の経路は公式に明記されていません。
4. PaaS と VNet の関係：接続方式を組み合わせて選ぶ
PaaS の接続方式は、サービスへの入口、サービスからの出口、サービスの配置先に分けて選びます。すべての PaaS が同じ方式に対応するわけではなく、同じ製品でも料金レベルや世代で選択肢が変わります。
| 方式 | VNet との関係 | できること | その設定だけではできないこと |
|---|---|---|---|
| Private Endpoint | VNet 内に、特定サービスへ接続する NIC とプライベート IP を作る | クライアントからサービスへの接続をプライベートにする | サービスの実行基盤をサブネットへ移すこと、サービスから VNet への新規接続 |
| VNet 統合 | VNet 外で動くサービスに、VNet を使う送信経路を持たせる | アプリから VNet 内・到達可能な接続先へリクエストを送る | アプリへの受信をプライベートにすること |
| VNet インジェクション | 対応するサービスの実行基盤を指定サブネットに配置する | そのサービスが対応する範囲で受信・送信を VNet に組み込む | 公開入口の自動無効化、管理系を含む全機能の一律な閉域化 |
| サービスエンドポイント | 送信元サブネットの身元を PaaS 側へ伝える | 対応 PaaS のパブリックエンドポイントへのアクセスをサブネット単位で制限する | 宛先のプライベート IP 化、オンプレからの同方式の利用 |
Private Endpoint はPrivate Link の接続開始方向、VNet 統合はApp Service の送信専用の統合機能、インジェクションはAPI Management の VNet 配置方式を代表例として整理しています。インジェクションでも運用は Azure が担当し、利用者が VM の OS を管理する形にはなりません。
VNet 統合に専用サブネットを使うことと、サービス全体がそのサブネットへ移ることは同じではありません。また、サブネット委任は、そのサブネットを指定サービスが使えるようにする設定です。委任そのものは受信・送信の接続方式を決めません。API Management v2 では統合とインジェクションの双方で委任しますが、委任先と機能が異なります（第 4-1 章）。
Storage などの入口を閉じる：Private Endpoint とサービスエンドポイント
Storage、SQL Database、Key Vault などへプライベートに接続する構成では、プライベートエンドポイント + パブリックアクセス無効化 + DNS 設計を組み合わせます。サービスエンドポイントはサブネット制限の別案ですが、宛先 IP はパブリックのままで、オンプレからはその方式を利用できません。サービスエンドポイントの仕組みと制限
| 観点 | サービスエンドポイント | プライベートエンドポイント |
|---|---|---|
| 仕組み | サブネットから PaaS のパブリック IP へ、バックボーン経由で VNet の身元を付けて届く | PaaS の特定リソースを、自分の VNet 内のプライベート IP（NIC）として見せる |
| 宛先 IP | パブリック IP のまま | VNet 内のプライベート IP |
| オンプレ / ピアリング先から | そのサブネットのサービスエンドポイントとしては使えない。利用元のサブネットごとに設定が必要 | VPN / ExpressRoute / ピアリング越しに使える |
| 情報漏えい対策 | サービス単位（別テナントの Storage にも出られる）。絞るにはサービスエンドポイントポリシーを併用 | リソース単位でマッピングされるため強い |
| DNS 変更 | 不要 | 必要（privatelink ゾーン） |
| コスト | 無料 | エンドポイント時間 + 処理データ量で課金 |
Private Link Service（自社サービスを公開する側）
自社が Standard Load Balancer の後ろで動かすサービスを、別の VNet・別テナントの利用者にプライベートエンドポイント経由で提供できます。IP 空間が重複していてもつなげられるため、SaaS 提供や部門間共有で使われます。
DNS が閉域設計の核心
プライベートエンドポイントを作っても、FQDN（例：mystorage.blob.core.windows.net）がパブリック IP に解決されれば通信は外へ出ようとして失敗します。パブリック DNS は privatelink サブドメインへの CNAME を返すので、その privatelink ゾーンを Private DNS ゾーンで抱えておくのが仕組みです（Private Endpoint の DNS 統合）。
オンプレの DNS は「privatelink.～」ではなく、推奨されるパブリック側のゾーン（例：blob.core.windows.net）を Resolver の受信エンドポイントへ条件付き転送します。
- Azure DNS（168.63.129.16）は VNet 内からしか引けません。オンプレからは DNS Private Resolver（または VNet 内の DNS フォワーダー VM）を経由させます。
- Private DNS ゾーンはハブに集約し、ハブ（と Resolver の VNet）にリンクします。同名ゾーンを複数作ると解決結果が場所ごとに変わり、障害の原因になります。
- エンドポイント作成時の A レコード登録は、DNS ゾーングループと Azure Policy で自動化するのが定石です。
- Resolver の送信エンドポイント + 転送ルールセットを使うと、逆に Azure からオンプレの社内ドメインを解決できます。
その他の注意点
- プライベートエンドポイントへの /32 経路は、通常の 0.0.0.0/0 より具体的です。Firewall を経由させるには、PE を置くサブネットで必要なネットワークポリシーを有効にし、PE の VNet アドレス空間と同じ長さ、またはそれより具体的なプレフィックスの UDR を設計します。0.0.0.0/0 の UDR だけでは PE の経路を上書きできません（ネットワークポリシーの公式説明）。
- PaaS 側の「パブリックネットワークアクセス」を無効にしないと、エンドポイントを作ってもインターネットからの入口が残ります。
- App Service から DB などへの接続は、送信元の VNet 統合と、宛先のプライベートエンドポイントを組み合わせられます。両者の IP 間で往復できる経路と名前解決を用意します。
4-1. 接続方式 × VNet 間接続で、できることを判断する
別の VNet にあるバックエンドへ届くか
次の表は、送信元サービスから見た到達性です。A と B はアドレス空間が重複しない VNet とし、宛先は B 内の VM・内部 API、または B に置いたプライベートエンドポイントを想定します。○ は「ネットワーク上の実現手段がある」という意味で、認証・認可まで成功する保証ではありません。
| 送信元の状態 | 同じ A 内の宛先 | B と直接ピアリング | A–ハブ–B のピアリングのみ | Firewall / NVA で中継、または Standard Virtual WAN |
|---|---|---|---|---|
| VNet 内の VM | ○ | ○ | × 中継されない | ○ 往復経路を構成 |
| VNet 統合済み PaaS（統合先 A） | ○ | ○ 対応製品・経路条件を確認 | × 統合は非推移性を変えない | △ 製品のルート対応と中継設定が必要 |
| VNet インジェクション済みサービス（配置先 A） | ○ 対応機能の範囲 | ○ 対応製品・経路条件を確認 | × 配置しても中継されない | △ 依存通信を含めた製品要件を確認 |
| 自分への Private Endpoint だけを A に持つ PaaS | × 送信用の機能ではない | × | × | × VNet 間経路だけでは解決しない |
| VNet 接続機能のない PaaS | × この構成では不可 | × | × | × サービスが使える送信手段を別途選ぶ |
VNet 統合の到達先はApp Service の対応範囲を例にしています。API Management の場合は、v2 の送信統合とPremium v2 のインジェクションの要件を確認します。表の ○ を、すべての PaaS に共通する製品保証として扱わないでください。
受信と送信を組み合わせる構成例
| 要件 | 組み合わせ | 残る確認事項 |
|---|---|---|
| 外部利用者へ公開し、バックエンドだけ非公開にする | 公開ゲートウェイ + VNet 統合 → 到達可能な内部 API | 公開入口の認証・保護、送信元サブネットの経路 |
| アプリの入口と DB 接続の両方を閉じる | 利用者 → アプリの Private Endpoint／アプリの VNet 統合 → DB の Private Endpoint | 入口・出口で別の接続設定とサブネットを用意し、双方の DNS を整える |
| API ゲートウェイを VNet 内のプライベート IP で受ける | 内部向けインジェクション → 同一・接続先 VNet の API | SKU、専用サブネット、受信 DNS、サービス依存先への通信 |
| オンプレからアプリの Private Endpoint へ接続する | VPN / ER + 必要ならゲートウェイ共有 + PE への経路 + DNS 転送 | オンプレへの戻り経路、接続先の公開アクセス無効化 |
| 接続していない VNet の特定サービスだけを使う | 利用側 A に Private Endpoint を作り、対応サービスへ Private Link 接続 | 接続承認、DNS、提供側の対応。提供側 VNet 全体へのルートは得られない |
| 中央の Private Endpoint を複数 VNet で共用する | 各利用 VNet から PE の IP へ到達する経路 + 共通 DNS 設計 | PE の配置先次第で中継が必要。DNS ゾーンのリンクだけでは通信不可 |
最後の 2 行は別の構成です。利用側に Private Endpoint を作る場合、接続先 PaaS のために提供側 VNet とピアリングする必要はありません。一方、別 VNet に作られた PE を使う場合は、その PE の IP まで到達する経路が必要です。Private Endpoint の配置・接続範囲
API Management では、料金レベルと入口の要件から選ぶ
API Management は方式の違いが分かりやすい具体例です。以下はマネージドゲートウェイについて、2026年10月19日に確認した整理です。ワークスペースゲートウェイやセルフホステッドゲートウェイは含めません。
| 構成 | 主な対象 | 利用者からの入口 | バックエンドへの出口 |
|---|---|---|---|
| 従来レベルの外部モードのインジェクション | Developer / Premium | 公開エンドポイント | 配置先 VNet と到達可能なネットワーク |
| 従来レベルの内部モードのインジェクション | Developer / Premium | VNet 内のプライベート IP | 配置先 VNet と到達可能なネットワーク |
| v2 の VNet 統合 | Standard v2 / Premium v2 | 統合だけでは公開のまま | 統合先 VNet 経由で非公開 API へ接続 |
| 受信 Private Endpoint + 送信 VNet 統合 | Standard v2 の代表的な構成 | PE を作成後、公開アクセスを無効化 | 統合先 VNet 経由で非公開 API へ接続 |
| Premium v2 のインジェクション | Premium v2 | ゲートウェイのプライベート IP | 配置先 VNet と到達可能なネットワーク |
この表はAPI Management のネットワーク方式比較に基づきます。Standard v2 で受信と送信を組み合わせる条件は受信プライベートエンドポイントの設定を参照してください。インジェクションは常に非公開の入口になる、とは限りません。 従来レベルの外部モードがその例です。
Premium v2 のインジェクションは、専用サブネットを Microsoft.Web/hostingEnvironments へ委任し、NSG と受信向け DNS を準備します。配置先 VNet はインスタンスと同じリージョン・サブスクリプションである必要があります。現行資料では作成時に選ぶ必要があり、既存インスタンスへの後付けや統合との切り替えはできません。ゲートウェイが対象であり、管理機能全体が自分の VNet に移るという意味ではありません。Premium v2 の配置要件と DNS
一方、v2 の送信統合では委任先は Microsoft.Web/serverFarms で、統合先 VNet にも同じリージョン・サブスクリプションの条件があります。統合サブネットの受信 NSG 規則で公開ゲートウェイへの受信を制御することはできません。送信先 API と Key Vault などの依存先への通信も確保します。v2 の統合サブネットと NSG の要件
接続方式を決めても残る 5 つの確認
- 機能と配置：SKU・リージョン・専用／委任サブネット・IP 数を確認する。PE と統合用サブネットを混在させられるとは限らない。
- 名前解決：送信元が実際に使う DNS で、期待するプライベート IP が返ることを確認する。VNet のピアリングと Private DNS ゾーンのリンクは別の設定。
- 往復経路：宛先 IP と戻り先 IP の有効なルートを確認する。中継装置、UDR、転送許可を含めて追う。
- 通信と権限：NSG・Firewall・公開アクセス設定に加え、サービスの認証・認可を確認する。プライベート IP に届くだけでは操作権限は得られない。
- 依存先と運用：管理・監視・証明書などの通信を確保し、経路や DNS を変更した後に再検証する。
4-2. DNS 詳説：参照範囲と伝播
Azure の名前解決は、問い合わせに使う DNS と、その DNS から見えるゾーン・転送ルールで決まります。誰がどの DNS に問い合わせるかは VNet / NIC の DNS 設定、何が見えるかは「リンク」、変更がいつ効くかは DHCP と TTL が決めます。ピアリングしても DNS の参照範囲は広がらない、という点が最大の落とし穴です。
4 つの名前解決手段とそのスコープ
Microsoft Learn は VNet 内の名前解決手段を 4 つに整理しており、Private DNS ゾーンを推奨しています。
| 手段 | 何を解決するか | 参照できる範囲 |
|---|---|---|
| Azure 提供の名前解決 | VM のホスト名（internal.cloudapp.net）とパブリック名 | その VNet の中だけ。他の VNet からは引けず、ピアリング先の逆引きも NXDOMAIN になる |
| Private DNS ゾーン | 任意のゾーン（privatelink を含む） | ゾーン自体はグローバル。仮想ネットワークリンクを張った VNet からだけ引ける（リージョンは問わない） |
| DNS Private Resolver | オンプレ→Azure（受信）、Azure→オンプレ（送信 + 転送ルール） | Resolver は同一リージョンの VNet 1 つに配置。転送ルールセットは同一リージョンの VNet（最大 500）にしかリンクできない |
| カスタム DNS（AD DC、フォワーダー VM） | 自由（社内ドメインなど） | そのサーバーに到達できる場所すべて。ただし 168.63.129.16 へ転送できるのは同じ VNet 内にある場合だけ |
問い合わせの流れ
VM が Azure DNS（168.63.129.16）を使う場合、まずその VNet にリンクされた Private DNS ゾーンを見て、一致しなければリンクされた転送ルールセットを評価し、どちらもなければ通常の再帰解決に進みます。
ゾーン名が一致した時点でそのゾーンが答えるため、通常はレコードがなければ NXDOMAIN で終わります。privatelink ゾーンで「インターネットへのフォールバック」を有効にした場合は例外です（この節の後半を参照）。
どこから何が引けるか
ハブ & スポークで、Private DNS ゾーンと Resolver をハブに置いた構成を前提にしています。「✕」は何もしないと引けないものです。
| 問い合わせ元 | 同じ VNet の VM 名（Azure 提供） | Private DNS ゾーン（privatelink など） | オンプレの社内ドメイン |
|---|---|---|---|
| ハブ VNet の VM | ○ | ○（ハブにリンク済み） | ○ ルールセットをハブにリンク |
| スポーク VNet の VM | ○（自 VNet 内のみ） | ✕ → スポークにもゾーンをリンクするか、スポークの DNS 設定を Resolver の受信エンドポイントにする | ✕ → ルールセットをスポークにリンク、または DNS 設定をハブに向ける |
| 別リージョンの VNet | ○（自 VNet 内のみ） | リンクすれば ○（ゾーンはグローバル） | ✕ → ルールセットはリージョンをまたげないため、そのリージョンにも Resolver を置く |
| オンプレミス | ✕ 168.63.129.16 に届かない | ○ 受信エンドポイントへ条件付き転送 | ○ 自前の DNS |
| App Service（VNet 統合） | ✕ 短いホスト名は不可、FQDN のみ | ○ 統合先 VNet にリンク、または Resolver 経由 | ○ Resolver のルールセット経由 |
実務では、「全 VNet の DNS 設定をハブの Resolver 受信エンドポイントに向け、ゾーンとルールセットはハブにだけリンクする」集中型か、「各スポークにゾーンとルールセットをリンクする」分散型のどちらかに揃えると、参照範囲が説明しやすくなります。混在させると障害時の切り分けが難しくなります。
伝播：変更はいつ・どこまで届くか
DNS の「伝播」には、設定が VM に届くこと、レコードが各所に見えること、キャッシュが入れ替わることの 3 層があります。
| 変更内容 | 反映のしかた | 注意点 |
|---|---|---|
| VNet / NIC の DNS サーバー設定 | DHCP で VM に配られる。既存 VM は DHCP リースを更新（Windows は ipconfig /renew）するか再起動するまで旧設定のまま | NIC の設定が VNet の設定より優先。OS 内で DNS を直接書き換えると、アダプター交換時などに消える |
| カスタム DNS への切り替え | 同上 | Azure 提供のサフィックス（internal.cloudapp.net）が配られなくなり、VM 名での解決が失われる。必要なら Private DNS ゾーンの自動登録で補う |
| Private DNS ゾーンのレコード追加・変更 | ゾーンは 1 つで、リンクしたすべての VNet が同じデータを参照する。ゾーン転送のような複製は不要 | クライアント、フォワーダー、オンプレ DNS が TTL の間キャッシュする。PE 作成前に引いたパブリック IP や NXDOMAIN が残ることがある |
| 仮想ネットワークリンクの追加・削除 | リンクの状態が完了になれば、その VNet から引ける・引けなくなる | ピアリングしてもリンクは伝わらない。VNet ごとに張るか、Resolver 経由にする |
| 自動登録（リンクの設定） | VM の A レコードが自動で作成・削除される | 自動登録を有効にできるのは 1 つの VNet につき 1 ゾーン。PTR は自動登録されない |
| 転送ルールセットのルール変更 | ルールセットをリンクした同一リージョンの VNet すべてに効く | 別リージョンには届かない。リージョンごとに同じルールを管理する |
PE を後から作る移行では、切り替え前に対象レコードの TTL を確認し、オンプレ DNS とフォワーダーのキャッシュクリアを手順に含めておくと安全です。
その他の注意点
- フォワーダーのタイムアウト：Windows DNS から Azure DNS へ転送する場合、転送タイムアウトを 4 秒より長くします。短いと、Private DNS ゾーンのレコードがパブリック IP で解決されることがあります。
- VPN Gateway とカスタム DNS の併用：VNet の DNS サーバー一覧に 168.63.129.16 も加えるよう求められています。
- フォールバックの扱い：privatelink ゾーンのリンクで「インターネットへのフォールバック」（NxDomainRedirect）を有効にすると、レコードがない場合にパブリック解決へ回せます。他テナントの PE が絡む環境では便利ですが、「閉域で解決できなければ失敗させる」方針とは相反するので、意図して使い分けます。
- 同名ゾーンの重複：1 つの VNet には同じ名前のゾーンを 1 つしかリンクできません。部署ごとに privatelink ゾーンを作ると、リンク先ごとに答えが変わるため、ゾーンは 1 か所に集約します。
- クエリ制限とキャッシュ：Azure DNS は VM ごとにクエリを制限します。制限に当たる場合は、Linux に dnsmasq などのキャッシュを入れることが推奨されています。
- 通信許可との関係：DNS 経路上の NSG・Firewall では UDP 53 と TCP 53 の両方を確認します。UDP 応答だけで完結しない問い合わせもあるためです。
5. 各種ゲートウェイの整理
名前に「Gateway」が付くサービスは多いですが、役割はまったく違います。「どの向きの通信を担うか」と「VNet の中に置くか、エッジで動くか」の 2 軸で整理すると混乱しません。
同じ「入口」でも、Front Door は世界中のエッジで受け、Application Gateway は特定リージョンの VNet 内で受けます。両者は競合ではなく、重ねて使うこともあります。
| サービス | 役割 | 層 | 必要なサブネット | 閉域での要点・注意点 |
|---|---|---|---|---|
| VPN Gateway | IPsec でオンプレ（S2S）や端末（P2S）と接続 | L3 | GatewaySubnet（/27 以上推奨、ER GW と共用） | 通信は暗号化されるが経路はインターネット。アクティブ/アクティブとゾーン冗長を推奨。ER のバックアップにも使う |
| ExpressRoute Gateway | ExpressRoute 回線を VNet につなぐ終端 | L3 | GatewaySubnet | ゲートウェイ SKU が帯域と経路数の上限を決める。GatewaySubnet に 0.0.0.0/0 の UDR は不可 |
| Azure Firewall | ステートフルなマネージド FW。FQDN フィルタ、DNAT、Premium は TLS 検査・IDPS | L3-L7 | AzureFirewallSubnet（/26）。強制トンネリング時は AzureFirewallManagementSubnet（/26）も | スポーク間・オンプレ間・インターネット向けの検査点。非対称ルーティングに注意 |
| NAT Gateway | サブネットの送信を固定パブリック IP で SNAT | L4 | 不要（サブネットに関連付け） | 受信はできない。既定アウトバウンド廃止後の「明示的な出口」の第一候補。Firewall の後段に置いて SNAT ポートを増やす構成もある |
| Application Gateway | リージョン内の L7 負荷分散 + WAF | L7 | 専用サブネット（名前は任意。/26 以上、v2 は /24 を強く推奨） | 内部向けにはプライベートフロントエンドを使う。オートスケール分の IP を確保しておく |
| Load Balancer | L4 負荷分散（内部 / 外部） | L4 | 不要 | Basic SKU は廃止済み。内部 LB は NVA の冗長化（HA ポート）にも使う |
| Azure Bastion | VM への RDP/SSH をブラウザ経由で提供 | — | AzureBastionSubnet（/26 以上） | VM にパブリック IP が不要になる。ハブに 1 つ置けばピアリング先の VM にも届く（Standard 以上） |
| Route Server | NVA と BGP で経路を交換し VNet に反映 | 制御面のみ | RouteServerSubnet | データは通らない。SD-WAN 装置と ExpressRoute の経路連携に使う |
| Front Door | グローバル L7 負荷分散・CDN・WAF | L7 | 不要（VNet 外） | Premium は Private Link で配信元にプライベート接続でき、配信元をインターネットに公開せずに済む |
専用サブネットは名前と最小サイズが決まっており、後から広げにくいため、ハブ VNet を作る時点でまとめて確保するのが安全です。サイズ要件は更新されることがあるので、各リンク先で最新値を確認してください。
6. ハイブリッド接続：VPN と ExpressRoute
オンプレと Azure をつなぐ手段は、インターネット上の IPsec（VPN Gateway）と、インターネットを通らない専用線（ExpressRoute）の 2 つです。本番の閉域接続は ExpressRoute、そのバックアップや小規模拠点に VPN、という組み合わせが典型です。
ExpressRoute はプロバイダー網を通ってピアリング拠点で Microsoft に入り、そこから先はバックボーンを通ります。VPN は同じ GatewaySubnet に置いて共存できます。
| 観点 | VPN Gateway（S2S） | ExpressRoute |
|---|---|---|
| 経路 | インターネット（IPsec で暗号化） | 接続プロバイダー経由の専用接続。インターネットを通らない |
| 暗号化 | あり | 既定ではなし。必要なら ExpressRoute 上の IPsec、または Direct の MACsec |
| 品質 | インターネット次第 | 帯域・遅延が安定、SLA あり |
| 導入リードタイム | 短い | 回線手配が必要で長い |
| 主な用途 | 小規模拠点、ER のバックアップ、P2S で個人端末 | 基幹系、大容量データ移行、安定した閉域接続 |
ExpressRoute の主要概念
- プライベートピアリング：VNet のプライベート IP へ到達する経路。閉域設計の主役です。PaaS もプライベートエンドポイント経由ならここを通ります。
- Microsoft ピアリング：Microsoft 365 や PaaS のパブリック IP へ専用線で到達する経路。公開 IP アドレスや NAT の設計が必要です。
- SKU：Local（同じ都市圈のリージョンのみ、データ転送料なし）、Standard（同一地政学的エリア内）、Premium（全世界のリージョン、経路数上限も拡大）。
- Global Reach：ER 回線同士をつなぎ、オンプレ拠点間も Microsoft バックボーンで結べます。地政学的エリアをまたぐ場合は Premium が必要です。
- FastPath：データ通信が ER ゲートウェイを迂回して VM へ直接届きます。ゲートウェイは経路交換のために引き続き必要です（Tech Community）。
- ExpressRoute Direct：ピアリング拠点で Microsoft のポート（10 / 100 Gbps）に直接接続する形態です。MACsec による暗号化が使えます。
冗長化の考え方
ExpressRoute のサイト冗長には Standard / High / Maximum の 3 段階があります。
- Standard：1 回線（回線内で 2 経路はあるが、ピアリング拠点は 1 か所）。
- High：ExpressRoute Metro で、同一都市圈の 2 つのピアリング拠点にまたがる。
- Maximum：異なるピアリング拠点に 2 本以上の回線（例：東京と大阪）。
あわせて、ER ゲートウェイのゾーン冗長 SKU、オンプレ側 CE ルーターの 2 台構成、VPN によるバックアップを検討します。VPN をバックアップにする場合、同じプレフィックスなら ER が優先されるので、経路広告の設計をそろえておきます。
7. Microsoft グローバルネットワーク（バックボーン）
ここまでの VNet、ピアリング、ExpressRoute は、すべて Microsoft が自社で持つ世界規模の WAN の上に乗っています。データセンター間や Microsoft のサービス間の通信は、すべてこのグローバルネットワーク内を流れ、パブリックインターネットは通りません。
構成要素
| 要素 | 役割 | 設計との関係 |
|---|---|---|
| リージョン | データセンター群の単位。VNet はこの単位で作る | リージョンごとにハブを置くのが基本（第 8・10 章） |
| 可用性ゾーン（AZ） | リージョン内で電源・冷却・ネットワークが独立した区画 | VNet とサブネットは全 AZ にまたがる。ゲートウェイや Firewall はゾーン冗長で配置する |
| エッジ PoP | 利用者の近くで Microsoft の網に入る入口 | Front Door や CDN はここで動く |
| ExpressRoute ピアリング拠点 | 専用線で Microsoft の網に入る入口 | リージョンとは別の場所。東京の拠点から東日本以外のリージョンにも届く |
| バックボーン（WAN） | リージョン・PoP・拠点を結ぶ自社所有または借用の光ファイバー網 | グローバルピアリングや Global Reach の通り道 |
Microsoft のブログでは、この網は 165,000 マイル超の光ファイバーと 180 以上のエッジ PoP を持ち、リージョン内・リージョン間のデータセンター間通信は物理層で自動的に暗号化されると説明されています（Azure ブログ、数値は公開時点のもの）。
コールドポテトとルーティング優先設定
既定では、インターネットとの通信もできるだけ長く Microsoft の網の中を通ります。これをコールドポテトルーティングと呼びます。パブリック IP ごとに「インターネット経由（ホットポテト）」を選ぶと、品質より転送コストを優先できます。
コールドポテトでは、例えばシンガポールの利用者の通信はシンガポールの PoP で Microsoft の網に入り、そのまま米国のリージョンまで運ばれます。
閉域設計にとっての意味
- プライベート IP 同士の通信（ピアリング、ER プライベートピアリング）は、拠点に入った後はバックボーンの中だけを通ります。「リージョン間のために自前の WAN を引く」必要はありません。
- パブリック IP 同士でも Azure 内ならバックボーンを通りますが、入口が公開されていることに変わりはなく、「閉域」とは別の話です。閉域の定義は「インターネットから到達できないこと」であり、第 4 章のパブリックアクセス無効化で実現します。
- ExpressRoute のピアリング拠点とリージョンは別物です。拠点を 2 か所に分ければ、拠点障害とリージョン障害を切り分けて備えられます。
8. Virtual WAN：マネージドなハブ
Virtual WAN は、第 3 章のハブ VNet を Microsoft が管理する「仮想ハブ」に置き換え、拠点・VNet・リージョン間の転送を自動化するサービスです。複数リージョンや多数拠点を持つ組織ほど効果が大きくなります。
- 仮想ハブ：リージョンごとに作る Microsoft 管理の VNet です。VPN / ExpressRoute / P2S のゲートウェイと、Azure Firewall や NVA を載せられます。
- ハブ間の自動接続：同じ Virtual WAN に属するハブ同士は自動でつながり、拠点⇔拠点、拠点⇔VNet、VNet⇔VNet の推移的な通信がバックボーン上で成立します。自前のハブ & スポークで必要だった UDR の作り込みが大幅に減ります。
- セキュアドハブとルーティングインテント：ハブに Firewall を置き、ルーティングインテントでプライベート通信とインターネット通信をそれぞれ Firewall や NVA に向けられます。プライベート用のポリシーを有効にすると、拠点間・拠点と VNet・ハブ間の通信がすべて検査対象になります。各ハブに設定できるのはインターネット用とプライベート用の各 1 つです。
- ルーティングインテントにより、リージョンをまたぐハブ間通信も検査できるようになりました（Azure ブログ）。
| 観点 | 自前のハブ & スポーク | Virtual WAN |
|---|---|---|
| ハブの管理 | 自分で VNet・ゲートウェイ・UDR を構築 | Microsoft 管理の仮想ハブ |
| 推移的ルーティング | Firewall / NVA と UDR で作り込む | 標準で提供 |
| 自由度 | 高い（任意の NVA や構成） | 制約あり（ハブ内に置けるものが限られる） |
| 向いているケース | 1～2 リージョン、細かい制御が必要 | 多リージョン・多拠点、運用負荷を下げたい |
どちらでも、サービスの入口・出口・配置、名前解決、検査する経路をそれぞれ設計します。Storage などへの接続は PE を使い、VNet に配置するサービスはインジェクションなどの要件に従います。Virtual WAN のハブには DNS Private Resolver などを直接置けないため、共有サービス用の VNet を別に用意してハブに接続します。推移的接続の説明は Standard Virtual WAN が対象で、Basic には VNet 間中継の機能がありません。
9. 閉域設計のチェックリスト
閉域の失敗は、多くが「IP 重複」「DNS」「意図しない出口」の 3 つに集約されます。設計レビュー時にそのまま使える形でまとめます。
IP アドレス設計
- [ ] オンプレ・全リージョンの VNet・将来の拡張分を含めて、アドレス空間が重複していない（AVNM の IPAM も活用）
- [ ] 専用サブネット（GatewaySubnet、AzureFirewallSubnet、AzureBastionSubnet、RouteServerSubnet、Application Gateway 用）を最初に確保した
- [ ] 委任や専用配置が必要なサブネット（App Service VNet 統合、SQL MI、利用方式に応じた AKS など）のスケール分の IP を見込んだ
入口を閉じる
- [ ] PaaS の対応方式を確認し、PE または内部向けインジェクションなどで必要な入口をプライベートにした
- [ ] PE を使う PaaS の「パブリックネットワークアクセス」を無効化し、管理系や別エンドポイントの公開範囲も確認した
- [ ] VM にパブリック IP を付けず、運用アクセスは Bastion（または ER / VPN 経由）に限定した
- [ ] 外部公開が必要なものは Front Door / Application Gateway + WAF に集約し、配信元はプライベートにした
出口を絞る
- [ ] 新規サブネットはプライベートサブネット（既定アウトバウンドなし）であることを確認した
- [ ] 0.0.0.0/0 を UDR で Firewall / NVA に向け、許可する FQDN だけを通している
- [ ] OS 更新・監視エージェント・ライセンス認証など、閉域でも必要な宛先を洗い出した（サービスタグや FQDN タグで許可）
DNS
- [ ] privatelink の Private DNS ゾーンをハブに集約し、同名ゾーンを重複作成していない
- [ ] オンプレ DNS からパブリック側ゾーン（例：blob.core.windows.net）を DNS Private Resolver に条件付き転送している
- [ ] Azure 側からオンプレの社内ドメインを引くための送信エンドポイントと転送ルールを設定した
ルーティングと可用性
- [ ] 送信元サービスの VNet 統合／配置先から、宛先の IP へ到達する経路を確認した（自分への PE を送信機能と取り違えていない）
- [ ] スポーク間に中継が必要な場合は、直接ピアリング・Firewall / NVA・Standard Virtual WAN のいずれかで構成した
- [ ] Firewall 経由の通信が往復とも同じ経路になる（非対称ルーティングがない）ことを確認した
- [ ] ゲートウェイ転送で広告される経路数が、ER / VPN の上限内に収まる
- [ ] ExpressRoute は異なるピアリング拠点で冗長化し、必要に応じて VPN をバックアップにした
- [ ] ゲートウェイ・Firewall・Application Gateway をゾーン冗長で配置した
検証
- [ ] Network Watcher（接続トラブルシューティング、有効なルート、IP フロー検証）で経路と NSG を確認した
- [ ] VNet フローログと Firewall のログを Log Analytics に集約した
10. グローバルレベルの全体図
これまでの概念を 1 枚に重ねると、「拠点からは ExpressRoute でバックボーンに入り、各リージョンのハブで検査・名前解決し、Storage などの PaaS にはプライベートエンドポイントで届く」という構成例になります。外部公開が必要なものだけを、エッジの Front Door Premium から Private Link で取り込みます。この図の PaaS は PE 型の例で、すべてのサービスを同じ方式で接続するという意味ではありません。
この構成では、ハブを各リージョンの検査・名前解決の拠点にします。検査対象の通信が Firewall を通るように経路を設計します。ExpressRoute と Azure 内のリージョン間接続は Microsoft バックボーンを利用しますが、VPN のバックアップ経路にはインターネット区間があり、Global Reach の拠点間通信が自動的にハブの Firewall を通るわけでもありません。
図の読み方
- 入口（上部）：インターネット利用者はエッジ PoP の Front Door で受け、WAF を通した上で配信元へ送ります。Private Link 接続には Premium が必要です。Application Gateway を配信元にする場合も、Private Link の構成と接続承認が必要で、プライベートフロントエンドを置くだけではつながりません（Front Door の Private Link）。
- リージョン（中央）：各リージョンに同じハブ構成を置きます。ハブ間はグローバルピアリング、もしくは Virtual WAN のハブ間接続でつなぎます。Private DNS ゾーンはグローバルなリソースなので、両ハブにリンクして共用できます。
- 拠点（下部）：異なるピアリング拠点に 2 回線を用意します。各回線を両リージョンの ER GW につなぐ「たすき掛け」にすると、拠点障害でもリージョン障害でも経路が残ります（図では省略）。Global Reach を使えば、本社 DC と DR サイトの通信もバックボーン経由にできます。
- 名前解決：社内 DNS は Azure サービスのゾーンをハブの DNS Private Resolver に転送し、プライベート IP を受け取ります。この仕組みがあってはじめて、拠点から PaaS への通信が ER を通ります。
この図に含めていないもの
全体を統一的に管理する層として、AVNM（接続・セキュリティ管理規則・IPAM）と Azure Policy（パブリックアクセス禁止や DNS レコード自動登録の強制）を重ねるのが一般的です。また、主に Microsoft 365 向けの ExpressRoute Microsoft ピアリングも省いています。
11. 特殊な要件への対応
Azure の VNet は L3 専用の SDN で、既定では「オンプレと同じアドレスを同時につなぐ」ことも「L2 に依存する仕組み」もそのままでは動きません。ただし多くは回避策があり、「標準でできる / 回避策でできる / 別の方式に置き換える」の 3 つに分けて判断します。
| 要件 | 可否 | 主な手段 | 節 |
|---|---|---|---|
| オンプレと同じプライベート IP で移行したい | 回避策で可 | 一括切替、サブネット延伸、NAT | 11-1 |
| IP が重複する相手とつなぎたい | 回避策で可 | Private Link Service、VPN NAT、NVA | 11-2 |
| 公開 IP をそのまま持ち込みたい | 標準で可 | BYOIP（Custom IP Prefix） | 11-3 |
| GARP・マルチキャスト・ブロードキャストに依存 | 不可 | Load Balancer、Route Server、アプリ側の変更 | 11-4 |
| 送信元のパブリック IP を固定したい | 標準で可 | NAT Gateway、Azure Firewall | 11-5 |
| ジャンボフレームを使いたい | 条件付きで可 | MTU 拡大（範囲限定） | 11-6 |
11-1. オンプレと同じ IP を Azure で使いたい
結論：VNet にオンプレと同じアドレス範囲を作ること自体は可能です。問題になるのは、同じ範囲が両側に同時に存在し、互いに通信する期間だけです。Azure は既定で、オンプレと重複するアドレスの接続を許していません。
一括切替できるなら A が最も単純です。サーバーを少しずつ移す必要があり、かつ IP を変えられないものだけが B、変換してもよければ C です。
| 方式 | 仕組み | 制約・注意点 |
|---|---|---|
| A. 一括切替 | オンプレ側のセグメントを停止して経路広告を取り下げ、同じ範囲のサブネットを VNet に作って ER / VPN で広告する | 切替はセグメント単位の一発勝負。経路広告の切替手順と切り戻し手順を用意する |
| B. サブネット延伸 | 両側に置いたアプライアンスがパケットをカプセル化し、ER / VPN 越しに運ぶ L3 オーバーレイ。Azure Extended Network は Windows Server のアプライアンス 2 台でこれを実現します | 延伸できるのは最大 250 IP。IP を変えられないマシンに限って使うよう推奨されている。アプライアンスが単一障害点と帯域のボトルネックになる |
| C. NAT | VPN Gateway の NAT ルールで、重複する拠点や VNet のアドレスを別の範囲に変換します。静的（1:1）と動的、受信側と送信側のルールがある | 相手からは変換後の IP に見えるため、IP を埋め込んだ設定は結局書き換えが必要。ExpressRoute ゲートウェイには同じ機能がないので、ER 経由は NVA などで変換する |
移行前に必ず確認する点：
- 予約 IP との衝突：Azure は各サブネットの先頭 4 個と末尾 1 個を予約します（第 1 章）。オンプレで .1～.3 や末尾のアドレスを使っているサーバーは、どの方式でもその IP を引き継げません。既定ゲートウェイも .1 になります。
- IP は NIC 側で固定する：Azure ではゲスト OS に静的 IP を書くのではなく、NIC の IP 構成で「静的」を指定し、OS は DHCP で受け取ります。
- 移行後の本筋：本来の解決策は、IP ではなく DNS 名で参照するように依存を整理し、再番号付けすることです。B や C を恒久構成にすると、運用と障害切り分けが複雑になります。
11-2. IP が重複する相手とつなぎたい
M&A、グループ会社、取引先との接続では、互いに 10.0.0.0/8 を使っていて重複することがよくあります。ピアリングは重複すると張れないため、次のどれかを使います。
- Private Link Service（第 4 章）：特定のサービスだけを相手の VNet 内の IP として見せます。片方向・サービス単位の公開に向き、アドレス重複を気にしなくて済みます。
- VPN Gateway の NAT：拠点単位の双方向通信に向きます。変換後の範囲同士も重複させられない点に注意します。
- NVA（Firewall など）での NAT：ExpressRoute 経由や、細かい変換ルールが必要な場合に使います。
11-3. 公開 IP をそのまま持ち込みたい
取引先の許可リストやメール送信の評判などで公開 IP を変えられない場合は、Custom IP Prefix（BYOIP）で自社のアドレスを Azure に持ち込めます。
- 範囲は自社所有で、ARIN や RIPE などのレジストリに登録済みである必要があり、Microsoft が所有を検証します。
- IPv4 は /21～/24、IPv6 は親プレフィックスが /48 です。そこから Public IP Prefix や Standard のパブリック IP を切り出して使います。
- オンプレと Azure で同じ範囲を同時にインターネットへ広告することはできないため、広告の切替日を決めて移行します。
11-4. L2 に依存する仕組み
VNet ではユニキャストのみが使え、マルチキャスト、ブロードキャスト、IP-in-IP、GRE はブロックされます。VLAN もありません。オンプレで当たり前の次の仕組みは置き換えが必要です。
| オンプレでの仕組み | Azure での置き換え |
|---|---|
| GARP で仮想 IP（VIP）を切り替えるクラスター | 内部 Load Balancer のフロントエンド IP を VIP にし、正常性プローブで稼働側を判定する |
| NVA の冗長化（VRRP など） | 内部 LB の HA ポート、または Route Server で BGP による経路切替 |
| マルチキャストを使うアプリ | ユニキャストへの設定変更を優先。できなければ製品側のオーバーレイ機能を検討する |
| 自前の DHCP サーバー | Azure の DHCP が IP を配るため不要。IP は NIC の構成で管理する |
11-5. 送信元のパブリック IP を固定したい
取引先の API が接続元 IP で許可している場合などは、サブネットに NAT Gateway を関連付け、パブリック IP または Public IP Prefix を割り当てます。強制トンネリングで Firewall を通す構成では、Firewall のパブリック IP（またはその後段の NAT Gateway）が送信元になります。11-3 の BYOIP と組み合わせれば、移行前と同じ送信元 IP も維持できます。
11-6. ジャンボフレーム（大きな MTU）
既定の MTU は 1,500 バイトです。Microsoft Azure Network Adapter（MANA）では 9,000 まで上げられますが、有効なのは同じ VNet 内と同一リージョンで直接ピアリングした VNet 内の通信だけです。ゲートウェイ、グローバルピアリング、インターネット向けは対象外で、オンプレとの通信では断片化して性能が落ちます。MTU の最適値は OS・ネットワーク・アプリケーションで変わるため、最大値にすればよいわけではありません。通信経路全体を検証し、段階的に適用します。
設計へ進む前に
まず「誰から、どのサービスの、どの機能へ接続するか」を一覧にし、サービスの入口・出口・配置方式を選びます。次に、アドレス空間と VNet 間接続を決めます。第 4-1 章の表で到達可能な組み合わせかを確認し、送信元での名前解決、IP の往復経路、NSG と Firewall、認証・認可の順に具体化します。最後に、公開アクセスの範囲、障害時の経路、ログによる検証をそろえます。
サービスを個別に選ぶときも、この順序に戻れば判断を整理できます。この記事の全体図は、その関係を確認するための構成例として使ってください。
参考資料
Microsoft Learn
- API Management の VNet 接続方式比較
- Premium v2 の VNet インジェクションと配置要件
- API Management v2 の送信 VNet 統合 / 受信 Private Endpoint
- App Service の VNet 統合と到達先
- Private Endpoint の概要・接続開始方向・配置
- サービスエンドポイントの概要と制限
- Standard Virtual WAN の推移的接続
- Azure の既定のアウトバウンドアクセス
- 仮想ネットワークのトラフィックルーティング（システムルートと UDR）
- VNet ピアリングの概要
- Azure Virtual Network Manager の概要 / 接続構成
- Private Endpoint の DNS 統合
- Application Gateway のインフラ構成（サブネット要件）
- ExpressRoute の信頼性（Well-Architected）
- Microsoft グローバルネットワーク
- ルーティング優先設定
- Virtual WAN のルーティングインテントとルーティングポリシー
- VNet の DNS 名前解決の構成
- Azure DNS Private Resolver の概要 / エンドポイントとルールセット
- Private DNS ゾーンのインターネットへのフォールバック
- サブネット延伸（Subnet extension） / Azure Extended Network
- VPN Gateway の NAT
- Custom IP アドレスプレフィックス（BYOIP）
- VNet の FAQ（マルチキャスト・ブロードキャスト等）
- VM の MTU 構成
- VPN Gateway FAQ：VNet 間接続
Azure ブログ / Tech Community