仮想ネットワークとサブネットのAzure

Azure仮想ネットワーク (VNet) とサブネットは、すべてのAzure ネットワークの基本構成要素です。この記事では、VNet が分離を提供する方法、サブネットでリソースを整理する方法、運用環境のワークロード用にネットワークのサイズと構造を設定する方法について説明します。

この記事の内容

この記事では、VNet 分離境界、サブネットのサイズ設定と予約済みアドレス、Azure Firewallと Application Gateway などのサービス用の専用プラットフォームサブネット、VNet ピアリング、一般的なネットワークレイアウトパターンについて説明します。

この記事が必要なユーザー

次の場合は、この記事をお読みください。

最初のワークロードをAzureにデプロイしており、リソースを作成する前にネットワークのしくみを理解する必要があります。
マルチワークロード環境を計画しており、作成する VNet とサブネットの数を決定する必要があります。
オンプレミスのワークロードをAzureに移行しており、Azureネットワークと物理ネットワークの違いを理解する必要があります。
Azure Firewall、VPN Gateway、Azure Kubernetes Service (AKS)などのAzure プラットフォームサービスのサブネットのサイズを正しく設定する必要があります。
ワークロードを異なる VNet に分ける場合と、同じ VNet のままにする場合の使い分けを理解したい。

リフトアンドシフトの重点: オンプレミスのサブネット分割を Azure 上でもそのまま再現します。既存の VLAN とセキュリティゾーンをサブネットにマップし、チームが既に運用している範囲に合わせてアドレス空間を配置し、サブネットのサイズを大きくして、移行中にアドレスを変更する必要がないようにします。

フォーカスを最新化する: プラットフォームサービスと自動化に関するサブネットを設計します。 AKS、プライベートエンドポイント、専用プラットフォームサービスのサブネットのサイズを適切に設定し、多くの VNet に一貫性のある構成を適用するAzure Virtual Network Managerを計画します。

クラウド間のフォーカス:VNet を作成する前に、Azure、AWS、Google Cloud 間で重複しないアドレス空間を計画します。 NAT なしでクラウドをピアリングまたは VPN 接続できるように、既存の VPC と競合しない CIDR 範囲を予約します。

Azureサービスと機能

次のサービスと機能は、Azureの仮想ネットワーク基盤を構成します。

サービスまたは機能	提供される内容	いつ使用するか
Azure Virtual Network (VNet)	Azure内の分離されたプライベートネットワーク。すべてのAzureネットワークはここから始まります。同じ VNet 内のリソースは、既定で通信できます。異なる VNet 内のリソースは、明示的に接続しない限り通信できません。	常に:ネットワーク接続を必要とするすべてのワークロードには VNet が必要です。
Subnet	VNet アドレス空間のパーティション。サブネットは、ネットワークセキュリティグループ (NSG) とルートテーブルの関連付けのスコープです。	常に: 機能またはセキュリティの境界によって、ワークロードコンポーネントをサブネットに整理します。
仮想ネットワークピアリング	同じリージョン内またはリージョン間の 2 つの VNet 間の低待機時間のプライベート接続。トラフィックは Microsoft バックボーンに残ります。ピアリングは推移的ではありません。各ピアリングは直接リンクです。	個別の VNet 内のリソースが通信する必要がある場合。リージョン間ピアリングについては、「リージョン間接続」を参照してください。
サブネットピアリング (プレビュー)	VNet 全体ではなく、特定のサブネット間のピアリング。ピアリングリレーションシップに参加するサブネットをきめ細かく制御できます。	異なる VNet 内の特定のサブネット間できめ細かいピアリング制御が必要な場合。制約のセクションを参照してください。
ルートテーブル/ユーザー定義ルート (UDR)	Azureの既定のシステムルートをオーバーライドして、トラフィックの送信先を制御します。サブネットレベルで適用されます。	ファイアウォールまたはネットワーク仮想アプライアンス (NVA) を介してトラフィックを強制する必要がある場合。ハブアンドスポークのエグレス制御に必要です。 Azure Firewall設計とハブアンドスポークトポロジに関する説明を参照してください。
Azure Virtual Network Manager (AVNM)	サブスクリプション間でネットワーク構成を一元的に作成し、管理し、VNet に適用します。	複数のサブスクリプション間で多数の VNet を管理する場合。一元化されたネットワーク管理を参照してください。

選択する方法

仮想ネットワークとは

仮想ネットワーク (VNet) は、Azureのソフトウェア定義の分離されたネットワークです。 Azureのプライベートネットワークと考えてください。ケーブル、スイッチ、ルーターを使用する物理ネットワークとは異なり、VNet は完全にソフトウェアで定義されています。作成し、アドレス空間を割り当てて、リソースをデプロイします。

主な特性:

リージョンスコープ: 1 つの Azure リージョンに VNet が存在します。その VNet 内のすべてのリソースは、同じリージョンに存在する必要があります。 VNet は、そのリージョン内の可用性ゾーンにまたがります。
既定での分離: 接続 (ピアリングまたは VPN) を明示的に作成しない限り、ある VNet 内のリソースは別の VNet 内のリソースと通信できません。
既定の内部接続: 同じ VNet 内のリソースは、Azureが提供するシステムルートを介して、既定で相互に通信できます。

サブネットとは

サブネットは、VNet 内の IP アドレスの範囲です。サブネットを使用すると、次の手順を実行できます。

ワークロードコンポーネント (Web 層、アプリケーション層、データ層など) でネットワークをセグメント化します。
セキュリティ規則を適用します。 NSG は、トラフィックをフィルター処理するためにサブネットレベルでアタッチされます。
ルーティングの制御: ルートテーブルは、トラフィックを誘導するためにサブネットレベルでアタッチされます。

Azureは、すべてのサブネットに 5 つの IP アドレス (最初の 4 つのアドレスと最後のアドレス) を予約します。たとえば、/24 サブネット (256 アドレス) では、251 個しか使用できません。この予約をサイズ設定の計算に組み込む。

例: 3 層アプリケーション

一般的な 3 層 Web アプリケーションでは、3 つのサブネットを使用して懸念事項を分離し、個別のセキュリティ規則を適用します。

Subnet	CIDR 範囲	Purpose	リソースの例
`web-subnet`	10.0.1.0/24	インターネットまたは Application Gateway からの受信 HTTP/HTTPS トラフィックを受け入れるフロントエンド Web サーバー	Azure App Service Environment、NGINX を実行する Virtual Machine Scale Sets
`app-subnet`	10.0.2.0/24	中間層アプリケーションロジック。 Web サブネットからのトラフィックのみを受け入れます。	Azure Functions (VNet 統合)、ビジネスロジックを実行している VM
`data-subnet`	10.0.3.0/24	データストア。アプリサブネットからのトラフィックのみを受け入れます。インターネットに直接アクセスできない。	Azure SQL Managed Instance、Azure SQL Databaseまたは Cosmos DB のプライベートエンドポイント

このレイアウトを使用すると、各サブネットに NSG を適用して、その層が必要とするトラフィックのみにトラフィックを制限できます。 Web サブネットでは、受信 HTTPS (ポート 443) が許可されます。アプリサブネットでは、Web サブネットの IP 範囲からの受信トラフィックのみが許可されます。データサブネットでは、アプリサブネットの IP 範囲からの受信トラフィックのみが許可されます。

AKS ベースのモダン化パターンでは、Azure CNI Overlay をデプロイするときに、クラスターのノードプール向けに 10.0.4.0/24 などの aks-nodes サブネットを使用できます。このモデルでは、ノードのみがサブネットの VNet IP アドレスを使用します。ポッドは個別のオーバーレイ CIDR を使用します。これにより、ノードサブネットをフラットネットワーク AKS 設計よりも小さく保つことができます。

一般的なパターン

次のサブネットレイアウトは、最も一般的なAzureデプロイシナリオに対応しています。

パターン	サブネット	いつ使用するか
シンプルな Web アプリ	`web` + `data`	フロントエンドとデータベースを備えた 2 層アプリケーション。最小限の複雑さ。
3 層エンタープライズ	`web` + `app` + `data` + `management`	階層が異なり、管理用のジャンプボックスまたは Bastion サブネットを備えた従来のエンタープライズワークロード。
共有サービス付きAKS	`aks-nodes` + `aks-ingress` + `appgw` + `shared`	専用のイングレスコントローラーサブネットと WAF 用 Application Gateway を備えた Kubernetes ワークロード。
ハブアンドスポークエグレス	`AzureFirewallSubnet` + `GatewaySubnet` + `AzureBastionSubnet` + `management`	ハブアンドスポークトポロジ内のハブ VNet。スポーク VNet がトラフィックのルーティング先として使用する共有サービス。ハブアンドスポークトポロジを参照してください。
データワークロード	`compute` + `data` + `private-endpoints` + `management`	分析とデータプラットフォームのワークロード。ストレージとデータベースのプライベートエンドポイントには、IP 計画を明確にするために独自のサブネットが必要です。

VNet とサブネットの数

基本原則は簡単です。 アプリケーションごとに 1 つの仮想ネットワーク を使用し、コンポーネント (層) ごとに 1 つのサブネット を使用します。この既定値では、各ワークロードが分離され、層間のトラフィックがネットワークセキュリティグループで簡単に制御できるようになり、拡張の余地が残ります。共有サービス、分離要件、スケーリングに基づいてそこから調整します。

次の決定表を使用して、VNet とサブネットの戦略を決定します。

あなたの状況	推奨される方法
1 つのワークロード、単一のチーム、共有サービスは必要ありません	アプリケーションコンポーネント (Web、アプリケーションロジック、データ) ごとにサブネットを持つ 1 つの VNet。単一ワークロードトポロジを参照してください。
ゲートウェイまたはファイアウォールを共有する複数の独立したワークロード	共有サービス用のハブ VNet + ワークロードごとに 1 つのスポーク VNet。ハブアンドスポークトポロジを参照してください。
ワークロード間の厳密な分離 (ブラスト半径、コンプライアンス要件)	ワークロードごとに 1 つの VNet。それらの間にピアリングはありません。
サブスクリプションとリージョンが多数ある非常に大規模な環境	自動化されたハブ管理を使用したAzure Virtual WAN。 Virtual WAN トポロジを参照してください。

専用サブネットのサイズ設定のリファレンス

多くのAzure プラットフォームサービスには、特定の名前と最小サイズの専用サブネットが必要です。次の図は、専用プラットフォームサブネットの名前付け要件と最小サイズを示しています。

アドレス空間を計画するときは、次の表を使用します。

Azure サービス	最小サブネットサイズ	必要なサブネット名	メモ
Azure Firewall	/26 (59 個の使用可能な IP)	`AzureFirewallSubnet`	すべてのファイアウォール SKU に必要です。デザインAzure Firewall参照してください。
VPN Gateway	/27 (27 個の使用可能な IP)	`GatewaySubnet`	Microsoft は、スケール余裕を確保するために /27 以上を推奨しています。
Azure Bastion	/26 (59 個の使用可能な IP)	`AzureBastionSubnet`	2021 年 11 月以降に作成されたすべてのデプロイの最小値は /26 です。
Application Gateway v2	/24推奨 (使用可能な IP は 251 個)	必要な名前なし	自動スケールに対応するために、/24 を強くお勧めします。最小値は数式ベースです (インスタンス + 5 予約済み + 1 プライベートフロントエンド IP)。
App Service Environment	/24 (運用環境)、/23 (最大スケール)	必要な名前なし	スケーリングでは、サブネットからの IP が消費されます。 200 インスタンスの最大値に近いスケールを計画している場合は、/23 を使用します。
Azure Route Server	/26 (59 個の使用可能な IP)	`RouteServerSubnet`	NVA との BGP ルート交換に必要です。
Azure DNS Private Resolver	エンドポイントサブネットあたりの最小 /28	専用の受信サブネットと送信サブネット	受信エンドポイントと送信エンドポイントに個別のサブネットが必要です。他のリソースと共有することはできません。
AKS (Azure Kubernetes Service)	数式ベース (CNI に依存)	必要な名前なし	AKS のサイズ設定に関するガイダンスを参照してください。

Note

プライベートエンドポイントは、既存のサブネットの IP アドレスを使用します。専用サブネットは必要ありません。この IP 使用量をサブネットのサイズ設定に組み込みます。詳細な IP 計画については、 IP アドレスの計画を参照してください。

AKS サブネットのサイズ設定

AKS サブネットのサイズ設定は、コンテナーネットワークインターフェイス (CNI) プラグインの選択によって異なります。最小サイズは 1 つもありません。

Azure CNI オーバーレイ: ポッドは個別のプライベート CIDR (クラスレス Inter-Domain ルーティング) ブロックを使用するため、サブネットはノードのみを収容する必要があります。フラットネットワークと比較して、非常に小さいサブネットを使用できます。
Azure CNI (フラットネットワーク):サブネットは、ノードとポッドの両方に対応する必要があります。数式: (nodes + surge) × (max_pods + 1)。 /21 以上は、ノード数が 50 以上のクラスターでは一般的です。
Kubenet: ノードのみが VNet サブネット IP を使用します。ポッドはクラスター内部 IP アドレスを取得します。

CNI オプションごとのサイズ設定の数式については、「 AKS クラスターの IP アドレス指定を計画する」を参照してください。

サブネットピアリングの制約

サブネットピアリングは、アドレス空間全体ではなく、VNet 間で特定のサブネットを接続します。この方法では、ピアリングリレーションシップに参加するサブネットをきめ細かく制御できます。

Important

サブネットピアリングは現在プレビュー段階であり、次の制約があります。

(セルフサービス登録ではなく) 承認済みリストにサブスクリプションを追加する必要がある
CLI、ARM テンプレート、Terraform、または PowerShell のみ (ポータルのサポートなし)
以前の世代の SKU での既知のバグを回避するために、運用環境での使用には Intel ベースの V5 SKU (または AMD ジェノヴァ/コバルト 100 ベースの SKU) が必要です。現在のハードウェア要件に合わせてサブネットピアリングを構成するを参照してください
ピアリングリンクごとに各側で最大 200 個のサブネット
各 VNet のすべてのピアリングリンクにわたるサブネットの合計は最大 1,000 個です
サブネットは、重複しない一意のアドレス空間に属している必要があります

現在の制限事項と登録については、「サブネットピアリングの構成」を参照してください。

Note

Azure Virtual Network Manager (AVNM) では、サブネットピアリングと VNet ピアリングを区別できません。 AVNM を使用してピアリング構成を管理する場合は、サブネットレベルのピアリングリレーションシップが AVNM の標準 VNet ピアリングとして表示されていることに注意してください。

設計上の考慮事項

リフトアンドシフト時の VNet とサブネットの設計上の重点

オンプレミスのセグメント化を再作成します。各 VLAN またはセキュリティゾーンをサブネットにマップし、既存のファイアウォール境界と運用所有権を最小限の再設計で引き継ぎます。
余裕を持たせてサブネットのサイズを決めます。移行後の再アドレス指定は中断されるため、現在のホスト数よりも大きな CIDR 範囲を割り当てて、サブネットごとに増加とAzureの 5 つの予約済みアドレスを吸収する必要があります。
Azureアドレス空間は、可能な限りオンプレミスの範囲に合わせて維持し、ルーティングを簡略化し、VPN Gatewayまたは ExpressRoute 経由で接続するときに重複を回避します。
既定では、移行されたアプリケーションごとに 1 つの VNet に、層ごとにサブネットが設定されます。この設計は、一般的な 3 層のオンプレミスレイアウトを反映し、移動を予測可能に保ちます。

VNet とサブネットの設計フォーカスを最新化する

プラットフォームサービスに関するサブネットを最初に設計します。Azure Firewall、Application Gateway、Bastion の専用サブネットに加えて、CNI の選択に基づいて AKS 用の正しいサイズのサブネットを設計します。
ポッドは VNet アドレス空間ではなく別のオーバーレイ CIDR から描画されるため、AKS 用 Azure CNI オーバーレイを使用してノードサブネットを小さく保ちます。
Azure PaaS サービスの導入が進んでも IP 消費量を予測しやすく保てるように、プライベートエンドポイント専用のサブネットを予約します。
Azure Virtual Network Manager早期に導入して、VNet 数がサブスクリプション間で増加するにつれて、ネットワークグループ、接続、およびセキュリティ構成を一貫して適用します。

クラウド間 VNet とサブネットの設計に重点を置く

VNet を作成する前に、グローバルアドレス計画を確立します。既存の AWS VPC または Google Cloud VPC ネットワークと競合しないAzureに対して、重複しない CIDR ブロックを予約します。この予約は、ルーティングされた VPN または相互接続に必須です。
各クラウドのネットワークプリミティブをAzureにマップします。AWS VPC または Google Cloud VPC ネットワークは Azure VNet に対応し、セキュリティグループは NSG に対応します。
VPN GatewayのGatewaySubnetや、Azure Virtual WANで使用されるハブなど、クラウド間接続コンポーネントのサブネット領域を予約します。そのため、トランジットインフラストラクチャにはスケーリングの余地があります。
運用チームがマルチクラウドトラフィックのトラブルシューティングを行うときに同等のレベルを関連付けられるように、クラウド間でサブネットの名前付けとタグ付けを標準化します。

前提条件

仮想ネットワークとサブネットのレイアウトを設計する前に、次の機能があることを確認します。

Azure サブスクリプション: ネットワークリソースを作成するためのアクセス許可を持つアクティブなAzure サブスクリプション (ネットワーク共同作成者ロール以上)。
リソースグループ: VNet リソースを含むターゲットリージョン内のリソースグループ。
リージョンの決定: ユーザーへの近接性、コンプライアンス要件、サービスの可用性に基づいて、プライマリ Azure リージョンを選択します。
アドレス空間プラン: ピアリングするオンプレミスネットワークや他の VNet と重複しない IP アドレス範囲 (CIDR ブロック) を決定します。ガイダンスについては、IP アドレスの計画を参照してください。

セキュリティに関する考慮事項

仮想ネットワークとサブネットは、ネットワークセグメント化の最初のレイヤーです。次のセキュリティプラクティスを適用します。

ネットワークセキュリティグループ (NSG): NSG をすべてのサブネットに関連付けて、受信トラフィックと送信トラフィックをフィルター処理します。各サブネットのロールに固有の許可ルールを定義し、既定で他のすべてを拒否します。詳細なガイダンスについては、ネットワークセキュリティグループとアプリケーションセキュリティグループに関する記事を参照してください。
UDR を使用した強制トンネリング: コンプライアンス要件で、すべてのインターネットにバインドされたトラフィックがオンプレミスの検査デバイスまたはクラウドファイアウォールを通過することが義務付けられている場合は、ユーザー定義ルートを含むルートテーブルを使用して、既定のインターネットルーティングをオーバーライドします。送信接続とエグレス接続を参照してください。
サブネットの分離: 異なる信頼レベルのリソースを別々のサブネットに配置します。たとえば、アプリケーション層サブネットからの受信トラフィックのみを許可するサブネットにデータベースを保持します。この分離により、攻撃者が 1 つのコンポーネントを侵害した場合の横移動が制限されます。
プラットフォームサービス用の専用サブネット: 多くのAzure プラットフォームサービス (Azure Firewall、Application Gateway、Bastion) が専用サブネットにデプロイされます。この分離により、プラットフォームサービスのルーティングとセキュリティ規則がワークロードサブネットに干渉しないようにします。

NSG とサブネットの相互作用

NSG をサブネットに関連付けると、そのサブネット内のすべてのリソースに NSG ルールが適用されます。これらの相互作用の動作を理解します。

累積的な評価: VM の NIC にも NSG がある場合、Azureはサブネットレベルの NSG と NIC レベルの NSG の両方を評価します。受信トラフィックの場合、Azureは最初にサブネット NSG、次に NIC NSG を評価します。送信トラフィックの場合、Azureは最初に NIC NSG、次にサブネット NSG を評価します。
既定の拒否: Azureには、VNet 内トラフィックと送信インターネットアクセスを許可する既定の規則が含まれています。カスタム拒否規則を追加した後、正当なトラフィック (IP アドレス 168.63.129.16 の正常性プローブAzure Load Balancerなど) が誤ってブロックされていないことを確認します。
サービスタグと ASG: 生の IP アドレスではなく、NSG ルールでサービスタグ ( AzureLoadBalancer、 Internet、 VirtualNetworkなど) とアプリケーションセキュリティグループ (ASG) を使用します。このアプローチにより、ルール管理が簡素化され、Azure の IP 範囲の変更に応じて自動的に適応します。
可視性のためのフローログ: すべてのサブネットレベルの NSG で NSG フローログを有効にして、承認済みおよび拒否されたトラフィックをキャプチャします。フローログは、セキュリティ規則が意図したとおりに動作することを確認し、コンプライアンス監査の証拠を提供するのに役立ちます。セットアップ手順については、NSG フローログを参照してください。

Azure ネットワーク設計ガイドの次の記事では、関連するトピックについて説明します。

IP アドレス計画: アドレス空間を設計し、重複を回避し、拡張を計画します。
ネットワークセキュリティグループとアプリケーションセキュリティグループ: サブネットと NIC レベルでトラフィックフィルター規則を定義します。
単一ワークロードトポロジ: 共有サービスのない 1 つのワークロード用に単純なネットワークを設計します。
ハブアンドスポークトポロジ: 共有サービスハブを介して複数のワークロード VNet を接続します。
Virtual WAN トポロジ: 自動化されたハブルーティングを使用して大規模な接続を管理します。
リージョン間接続: グローバルピアリングまたはVirtual WANを使用して、Azure リージョン間で VNet を接続します。
一元化されたネットワーク管理: Azure Virtual Network Managerを使用して、サブスクリプション全体の VNet 構成を管理します。

詳細情報

Azure仮想ネットワークの詳細については、次のリソースを参照してください。

次のステップ

Tip

あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。

リフトアンドシフト体験の次の手順:

IP アドレス空間を計画する: オンプレミスのアドレス範囲との重複を回避する /16 CIDR プールを割り当てます。

次に、最新化の取り組みを行います。

IP アドレス空間を計画する: アクティブ/アクティブピアリング用に重複しない範囲を持つデュアルリージョン IP プールを割り当てます。

マルチクラウドへの移行における次のステップ:

IP アドレス空間を計画する: Azure、アマゾンウェブサービス (AWS)、Google Cloud 全体で重複しないアドレス指定を設計します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-01