Azure VNet 完全設計ガイド｜CIDR / Subnet / NSG / Peering の実装ベストプラクティス

Azure Virtual Network (VNet) は、Azure 上の論理的に分離された仮想ネットワークで、Azure を活用するすべてのワークロードの土台となるコア技術です。 VNet の設計は『一度作ったら作り直しが極めて困難』な領域で、初期設計の質がその後のすべてのネットワーク・セキュリティ・運用に影響します。 本記事では、Azure VNet の実装ベストプラクティスを CIDR 設計・Subnet 分割・セキュリティ統合・運用ノウハウの観点から網羅的に整理します。

VNet の基本概念

Azure VNet は、オンプレ環境の VLAN や Subnet に相当する論理ネットワーク概念です。 1 つの VNet は1 つの Azure リージョンに紐付き、CIDR ブロック (例: 10.0.0.0/16) で IP アドレス空間を定義します。 VNet 内のリソース (VM・App Service Environment・Storage Account の Private Endpoint・AKS など) は同一ネットワークセグメントとして通信可能で、外部との通信は明示的に許可された経路 (Internet Gateway・NAT Gateway・VPN Gateway・ExpressRoute Gateway・Peering) のみ許可される、ゼロトラスト原則に近い設計思想です。

CIDR 設計

VNet の CIDR 設計は最重要です。一度設定した CIDR の縮小・変更は困難 (一部拡大は可能) で、変更が必要な場合は VNet 削除→再作成のリホストが発生します。

推奨 CIDR サイズ

• 環境別 VNet: /16 (65,536 アドレス) を Dev / Stage / Prod 各環境に 1 つずつ割り当て
• 小規模プロジェクト: /20 (4,096 アドレス) 単一 VNet
• 大規模エンタープライズ: /14 (262,144 アドレス) を Hub VNet に、/16 を Spoke VNet 各々に

CIDR 選定の原則

• RFC 1918 のプライベート IP 空間 (10.0.0.0/8・172.16.0.0/12・192.168.0.0/16) から選定
• 他 VNet との Peering を想定し、CIDR の重複を避ける (全社的な IP アドレス管理表が必須)
• オンプレネットワーク・他クラウド (AWS / GCP) との重複も避ける
• 将来の拡張余地を残し、最初から十分大きい (/16 推奨) アドレス空間を確保

Subnet 分割パターン

VNet を機能別の Subnet に分割するのが標準パターンです。 Azure の 3-tier アーキテクチャ標準パターン:

Azure 予約名 (GatewaySubnet・AzureFirewallSubnet・AzureBastionSubnet) は必ずその正確な名前で作成する必要があります。誤った名前で作成するとサービスデプロイ時にエラーになります。

Azure 予約 IP アドレス

Azure は各 Subnet で最初の 4 IP と最後の 1 IP の合計 5 IPを予約しています。 例: 10.0.0.0/24 の場合、以下が予約されます。

• 10.0.0.0: Network Address
• 10.0.0.1: Default Gateway
• 10.0.0.2: Azure DNS
• 10.0.0.3: Azure DNS
• 10.0.0.255: Broadcast

使用可能 IP は 10.0.0.4 ~ 10.0.0.254 の 251 個。/27 (32 IP) の場合は 27 IP のみ使用可能で、AKS Node や App Service Environment など IP 大量消費するリソースを配置する Subnet は大きめ (/22 以上) に確保することを推奨します。

VNet Peering

2 つの VNet を直接接続する仕組みが VNet Peering です。

• Regional Peering: 同一リージョン内の 2 つの VNet を接続。低レイテンシ・高帯域。
• Global Peering: 異リージョンの VNet を接続。Azure バックボーン経由、低レイテンシ。

Peering の料金はトラフィック量課金のみ (時間課金なし) で、Regional Peering は受信 / 送信 0.01 USD/GB、Global Peering は受信 / 送信 0.035-0.06 USD/GB (リージョンによる)。 3 つ以上の VNet を相互接続する場合は、すべての VNet を相互 Peering する Full Mesh 構成は管理が複雑になるため、Hub-Spoke or Virtual WAN への移行を検討するのが定石です。詳細は Hub-Spoke vs Virtual WAN 完全比較 を参照。

セキュリティレイヤ

VNet 内のトラフィックは多層防御で守ります。

基本パターンは NSG を常時適用 + 必要に応じて Azure Firewall を Hub に配置。両者は併用が標準で、相補的な役割を果たします。

DNS 設定

VNet の DNS 設定は『Azure 提供 DNS (Default)』『カスタム DNS (オンプレ DC IP)』『Private DNS Zone』の選択肢があります。

• Azure 提供 DNS (168.63.129.16): 標準設定、Azure リソース名前解決のみ可能。
• カスタム DNS:オンプレ AD DNS の IP を指定、ハイブリッド環境で AD 名前解決を統合。
• Private DNS Zone:VNet 内専用の DNS ゾーン、Private Endpoint の名前解決に必須。
• Azure DNS Private Resolver:ハイブリッド DNS 解決のマネージドサービス (2022 年 GA)。

VNet 設計の落とし穴

実務でよくある失敗パターン:

1. CIDR が小さすぎて IP 不足: /24 で始めると AKS 1 つで枯渇するケース多発。最低 /22 推奨。
2. Subnet 名を Azure 予約名と異なる名前で作成: GatewaySubnet・AzureFirewallSubnet・AzureBastionSubnet は正確な名前必須。
3. オンプレと CIDR 重複: VPN/ExpressRoute 接続時にルーティング不能。事前に IP アドレス管理表で全社一元管理。
4. Global Peering を多用してコスト爆発: 多拠点接続なら Virtual WAN を検討。
5. NSG なしで Public IP 付き VM を公開: セキュリティ事故の典型パターン。デフォルトで NSG を Subnet に適用。
6. Service Endpoint と Private Endpoint の使い分けを誤る: 詳細は Private Endpoint vs Service Endpoint 参照。
7. DNS 設定を Default のままにして Private DNS Zone が機能しない: Private Endpoint 配置時は Private DNS Zone を必ず構成。

関連認定試験

VNet 関連知識を体系的に学ぶには Microsoft 認定が最も効率的です。

• AZ-104 (Administrator): ドメイン 4 (Virtual networking 15-20%) で VNet 基礎。
• AZ-700 (Network Engineer Associate): 大規模 VNet 設計全般。
• AZ-305 (Solutions Architect Expert): ドメイン 4 でネットワーク設計判断。

詳細は Azure ネットワークエンジニア キャリアロードマップ を参照してください。

よくある質問

本記事の技術情報は Azure Virtual Network Documentation に基づいています。 本記事は Microsoft Corporation の公式商品ではなく、いかなる提携・後援関係もありません。 Microsoft、Azure は Microsoft group of companies の商標です。 情報は 2026 年 5 月 24 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。