Skip to content

MS_AzureSubnetting

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Azureのサブネッティング

概要

VNETにサブネッティングを施す。

詳細

補足（この赤字が本ページの結論）: 「FLSM でアドレッシングすると
ネットワーク分割ができない」という指摘は、
後掲の例 2 と例 3 の対比で具体的に示されている。

要は、

【FLSM（クラスの境界どおり）】
  192.168.0.0/16 を VNET に割り当てる
    → クラス C のプライベート空間（192.168.0.0/16）を丸ごと使い切る
    → 2 つ目の VNET に割り当てる空きが無い

【VLSM / CIDR（自由な境界）】
  192.168.0.0/20 を VNET1 に
  192.168.16.0/20 を VNET2 に … と分割できる

という話である。
VNET のアドレス空間は後から縮小できない（拡張は可能だが
既存サブネットとの整合が要る）ため、
最初に大きく取り過ぎると将来の VNET を作れなくなる。

実務では、

指針 内容
全社の IP 割り当て計画を先に作る オンプレとの重複を避ける（VPN / ExpressRoute で繋ぐと重複は致命的）
VNET には必要十分なサイズを /16 を安易に取らない。/20〜/22 程度から検討
将来の拡張分を空けておく 連続した空きがあると VNET のアドレス空間を追加しやすい
ピアリングを前提に 重複していると VNET ピアリングができない（Azureの仮想ネットワーク ピアリング）

最後の点が特に重要で、
アドレスが重複した VNET 同士はピアリングできない。
後から統合しようとして初めて発覚することが多い。

例

サブネッティングの例

  • DMZ の構築
  • サブネットの分割

例1

クラス A のプライベート IP アドレス（10.0.0.0/8）

仮想ネットワーク

  • Address space : 10.0.0.0/16
  • 上位 2 バイト（16 ビット）が、仮想ネットワークの（ネットワーク）アドレス部

サブネット

  • Address Range : 10.0.0.0/24
    • 上位 3 バイト（24 ビット）が、サブネットの（ネットワーク）アドレス部
    • 下位 1 バイト（8 ビット）が、各ホストの IP アドレス
  • サブ・ネッティング
    • Subnet1
      • Name : Public
      • Prefix : 10.0.0.0/24
    • Subnet2
      • Name : Private
      • Prefix : 10.0.1.0/24

例2

クラス C のプライベート IP アドレス（192.168.0.0/16）

仮想ネットワーク

  • Address space : 192.168.0.0/16
  • 上位 2 バイト（16 ビット）が、仮想ネットワークの（ネットワーク）アドレス部

※ このケースでは、仮想ネットワーク分割ができない。

サブネット

  • Address Range : 192.168.0.0/24
    • 上位 3 バイト（24 ビット）が、サブネットの（ネットワーク）アドレス部
    • 下位 1 バイト（8 ビット）が、各ホストの IP アドレス
  • サブ・ネッティング
    • Subnet1
      • Name : FrontEnd
      • Prefix : 192.168.1.0/24
    • Subnet2
      • Name : GatewaySubnet
      • Prefix : 192.168.200.0/24

例3

クラス C のプライベート IP アドレス（192.168.16.0）

※ 例2で、クラス C で仮想ネットワークを分割できるようにした例。

仮想ネットワーク

  • Address space : 192.168.0.0/20
  • 上位 2.5 バイト（20 ビット）が、仮想ネットワークの（ネットワーク）アドレス部

サブネット

  • Address Range : 192.168.0.0/24
    • 上位 3 バイト（24 ビット）が、サブネットの（ネットワーク）アドレス部
    • 下位 1 バイト（8 ビット）が、各ホストの IP アドレス
  • Subnet1
    • Name : FrontEnd
    • Prefix : 192.168.16.0/24
  • Subnet2
    • Name : GatewaySubnet
    • Prefix : 192.168.31.0/24

移行メモ（正誤）: 例 3 の見出しにあるリンクは
原典では 192.168.16.0/16 を指していたが、
/16 は 192.168.0.0 が基点になるため表記として整合しない
（本文の Address space も 192.168.0.0/20 である）。
誤記と判断し、リンクを外して記載した。

補足（Azure のサブネットで押さえるべき制約）: 上記の例では触れられていないが、
Azure のサブネットにはオンプレミスと異なる制約がある。

制約 内容
各サブネットで 5 個の IP が予約される ネットワーク アドレス、既定 GW、DNS × 2、ブロードキャスト。/29（8 個）なら使えるのは 3 個
最小サイズ /29（実質 /28 以上を推奨）
特定用途の名前が固定 GatewaySubnet（VPN/ER GW）、AzureBastionSubnet、AzureFirewallSubnet はこの名前でなければならない
特定用途の最小サイズ GatewaySubnet は /27 以上推奨、AzureBastionSubnet は /26 以上、AzureFirewallSubnet は /26
サブネットは AZ に固定されない AWS と異なる（Azureの仮想マシン）

例 2・例 3 に GatewaySubnet が出てくるのは
この名前が予約語だからであり、任意の名前は付けられない。

また、5 個予約される点は小さなサブネットを切る際に効いてくる。
「/29 で 8 個あるから 6 台置ける」と考えると足りなくなる。

なお、サブネットの分割方針としては、

  • 層（ティア）ごとに切る（Web / AP / DB）
    → NSG を層単位で書けるため管理しやすい
    （Azureの仮想マシンの「AZ をミニリージョンとして使用しない」）、
  • 専用サブネットが必要なサービス（Bastion、Firewall、GW、
    App Service の VNET 統合、Managed Instance）の分を先に確保する

のが定石である。

参考

Tags: 移行, インフラストラクチャ, クラウド, Azure, 通信技術

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally