【Azure VNet入門②】サブネットの設計と作成｜予約IP・特殊サブネットまで

Azure

前回のVNet概要で、VNetは「用途別のサブネットに区切って使う」と学びました。今回はいよいよ実際にVNetとサブネットを作成し、設計する手順に入ります。ポータル・Azure CLI・Terraformの3通りで作りながら、「知らないとハマる落とし穴」——Azureが勝手に予約するIPや、名前が固定された特殊サブネット——まで押さえます。

サブネットに /29 みたいな小さい範囲を切ったら「IPが足りません」って怒られた…なんで？

この記事では、次の5つを順番に整理します。読み終えたときに、これらを自分の言葉で説明でき、かつ実際に手を動かせるようになることをゴールにしています。

  • ポータル / Azure CLI / Terraform でVNetとサブネットを作成できる
  • 既存VNetにサブネットを追加・分割できる
  • オンプレ・他VNetとアドレス空間が重複しない設計ができる
  • 用途別サブネット設計（App / DB / PE / Bastion）ができる
  • 各サブネットでAzureが予約する5つのIPと特殊サブネットの命名規則を理解している

VNetとサブネットを作成する（ポータル / CLI / Terraform）

VNetの作成方法は主に3通りです。学習の最初はポータルで「目で見て」作り、慣れたらCLIやIaC（Terraform）でコード化していく、という流れがおすすめです。

① ポータルで作る（まず全体像を掴む）

ポータルでは「仮想ネットワークの作成」から、リージョン・アドレス空間（例: 10.0.0.0/16）・サブネット（例: 10.0.1.0/24）を画面で指定していくだけです。どの項目を入れているのかが視覚的に分かるので、最初の1回はポータルで作ると全体像がつかめます。

② Azure CLIで作る（再現性・自動化の入口）

# リソースグループ
az group create -n rg-network -l japaneast

# VNet ＋ 最初のサブネットを同時に作成
az network vnet create \
  -g rg-network -n myVnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name subnet-app \
  --subnet-prefix 10.0.1.0/24

# 既存VNetにサブネットを追加
az network vnet subnet create \
  -g rg-network --vnet-name myVnet \
  -n subnet-db --address-prefix 10.0.2.0/24

az network vnet create でVNetと1つ目のサブネットを同時に作り、以降は az network vnet subnet create でサブネットを足していく、という流れです。

③ Terraformで作る（IaCで再現性を担保）

実務では、VNetのような土台こそコード（IaC）で管理すると、同じ構成を何度でも再現でき、レビューもしやすくなります。Terraform（azurerm）ならこう書けます。

resource "azurerm_virtual_network" "main" {
  name                = "myVnet"
  location            = "japaneast"
  resource_group_name = azurerm_resource_group.net.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "app" {
  name                 = "subnet-app"
  resource_group_name  = azurerm_resource_group.net.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.1.0/24"]
}

resource "azurerm_subnet" "db" {
  name                 = "subnet-db"
  resource_group_name  = azurerm_resource_group.net.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.2.0/24"]
}

VNetの address_space（親の範囲）と、各サブネットの address_prefixes（子の範囲）が親子関係になっているのが読み取れます。terraform plan で差分を確認してから apply する運用にすれば、ネットワークの変更事故も防ぎやすくなります。

【ここが説明できればOK①】
「ポータル / CLI（az network vnet create）/ Terraform でVNetとサブネットを作成でき、以降はサブネットを追加していける」——これを言えれば、1つ目のチェックはクリアです。

アドレス空間の重複を避ける設計（オンプレ・他VNetとの整合）

VNet設計で後から一番ハマるのがCIDRの重複です。なぜなら、いざVNet同士やオンプレと繋ごうとした瞬間に、アドレス範囲が被っていると接続できないからです。

たとえば、東日本のVNetも西日本のVNetも、どちらも安易に 10.0.0.0/16 で作ってしまうと——

【NG】重複していて繋げない
  VNet-East   10.0.0.0/16  ┐
  VNet-West   10.0.0.0/16  ┘ ← 同じ範囲！ピアリング不可

【OK】範囲を割り当てておく
  VNet-East   10.0.0.0/16     （10.0.x.x を東で使う）
  VNet-West   10.1.0.0/16     （10.1.x.x を西で使う）
  オンプレ     192.168.0.0/16  （社内は別レンジ）

ポイントは、最初に「全社のアドレス計画（IPアドレス設計）」を立ててから各VNetを作ることです。「このVNetには 10.1.0.0/16、あのVNetには 10.2.0.0/16、オンプレは 192.168.0.0/16」というように、将来つなぐ可能性のあるネットワーク全体で範囲がぶつからないよう先に割り当てておきます。これは後から直そうとすると全リソースの作り直しになりかねない、「最初にやっておくべき設計」の代表格です。

【ここが説明できればOK②】
「オンプレや他VNetと接続する可能性を見越して、最初にアドレス計画を立て、CIDRが重複しないよう各VNetに範囲を割り当てる」——これを説明できれば、2つ目のチェックはクリアです。

用途別にサブネットを分ける（App / DB / PE / Bastion）

サブネットは、「役割ごとに分ける」のが基本設計です。1つのサブネットに何でも詰め込むのではなく、通信の性質が違うものを分けておくことで、あとからNSG（通信ルール）を用途別にきれいに当てられるようになります。

VNet: myVnet (10.0.0.0/16)
│
├─ subnet-app      10.0.1.0/24   アプリ層（Webサーバー等）
├─ subnet-db       10.0.2.0/24   データ層（DBは外部非公開に）
├─ subnet-pe       10.0.3.0/24   Private Endpoint 専用
└─ AzureBastionSubnet 10.0.4.0/26  Bastion 専用（名前固定）

この分け方には明確な意図があります。たとえばDB層は「アプリ層からの通信だけ許可し、インターネットからは完全に遮断」したい。App層とDB層が同じサブネットだと、この「層ごとに違うルール」を当てるのが難しくなります。分けておけば、「app→dbは許可、外→dbは拒否」といったルールを素直に表現できます。Private Endpoint専用サブネットやBastion専用サブネットを分けるのも同じ理由（＋後述の要件）です。

「サブネットを分ける＝通信ルールを分けて当てられるようにする」。これが用途別分割の本当の狙いだよ！

【ここが説明できればOK③】
「App / DB / PE / Bastion など用途別にサブネットを分けるのは、層ごとに違う通信ルール（NSG）を当てられるようにするためだ」——これを説明できれば、3つ目のチェックはクリアです。

各サブネットでAzureが予約する5つのIP

冒頭の「小さいサブネットを切ったらIPが足りないと怒られた」の正体がこれです。Azureは各サブネットで、必ず5つのIPアドレスを内部用に予約します。だから、サブネットで実際に使えるIP数は「見た目の数 − 5」になります。

例）サブネット 10.0.1.0/24（見かけ256個）の予約
  10.0.1.0   → ネットワークアドレス
  10.0.1.1   → 既定ゲートウェイ（Azure予約）
  10.0.1.2   → Azure DNS マッピング用
  10.0.1.3   → Azure DNS マッピング用（将来利用）
  10.0.1.255 → ブロードキャストアドレス

  → 実際に使えるのは 256 - 5 = 251 個

予約されるのは「先頭の3つ（.0 .1 .2 .3 のうち先頭アドレス＋3つ）と末尾の1つ」で合計5つです。ここから2つの実務的な注意が導けます。

  • サブネットを小さく切りすぎない：/29（8個）だと使えるのは3個だけ。/28（16個→11個）でもかなり少ない。用途に対して余裕を持たせる。
  • 「あと少しIPが足りない」が起きやすい：ちょうど256台入ると思って /24 にすると、実際は251台。ギリギリ設計は避ける。

【ここが説明できればOK④】
「各サブネットでは先頭側と末尾を合わせて5つのIPがAzureに予約されるため、使えるIPは『全体数 − 5』になる」——これを説明できれば、4つ目のチェックはクリアです。

特殊サブネットの命名規則（GatewaySubnet / AzureBastionSubnet など）

最後に、初見で必ず戸惑う「名前が固定されたサブネット」を押さえます。一部のAzureサービスは、専用サブネットの名前が完全に決められており、その名前でないと機能しません。

GatewaySubnet          … VPN Gateway / ExpressRoute 用
                         （名前は必ず "GatewaySubnet"。/27以上推奨）

AzureBastionSubnet     … Azure Bastion 用
                         （名前は必ず "AzureBastionSubnet"。/26以上）

AzureFirewallSubnet    … Azure Firewall 用
                         （名前固定・専用）

これらは「好きな名前を付けてはいけない」サブネットです。たとえばBastionを使いたいのに subnet-bastion という名前で作ってしまうと、Bastionが認識してくれません。必ず AzureBastionSubnet という決められた名前で、かつ指定サイズ以上（Bastionなら /26 以上）で作る必要があります。「名前とサイズに要件があるサブネットが存在する」と知っておくだけで、この手のエラーで悩む時間がゼロになります。

【ここが説明できればOK⑤】
「GatewaySubnet / AzureBastionSubnet など、名前とサイズが固定された特殊サブネットがあり、その名前でないと対象サービスが動かない」——これを説明できれば、5つ目のチェックはクリアです。

まとめ

  • VNet・サブネットはポータル / CLI / Terraformで作成できる（実務はIaC推奨）
  • 接続を見越してアドレス計画を先に立て、CIDRの重複を避ける
  • サブネットは用途別（App / DB / PE / Bastion）に分け、ルールを当てやすくする
  • 各サブネットは5つのIPが予約される（使えるのは全体 − 5）。小さく切りすぎない
  • GatewaySubnet / AzureBastionSubnet など名前固定の特殊サブネットに注意

サブネットを用途別に切れたら、次はその各サブネットに「通信の許可・拒否ルール」を当てるNSG（ネットワークセキュリティグループ）です。「DBサブネットはアプリからだけ許可」といった制御を、次の記事で具体的に作っていきます。

あわせて読みたい

タイトルとURLをコピーしました