Azureサブネット設計の鉄則！将来の拡張を考慮したIPアドレス配分術を徹底解説
生徒
「Azure（アジュール）で仮想ネットワークを作ってみたのですが、サブネットの分け方がよくわかりません。適当に決めても大丈夫ですか？」
先生
「それは非常に重要なポイントですね。Azure仮想ネットワーク（VNet：ブイネット）におけるサブネット設計を失敗すると、後からIPアドレスが足りなくなったり、ネットワークの構成変更が難しくなったりするんです。」
生徒
「後から直すのは大変なんですね。将来を見越したIPアドレスの配分方法や、設計のコツを知りたいです！」
先生
「もちろんです。初心者の方でも迷わないように、Azureサブネット設計の鉄則を分かりやすく解説していきましょう！」
1. Azure仮想ネットワークとサブネットの基本
Azure仮想（かそう）ネットワーク（Virtual Network、略してVNet）は、クラウド上に自分専用のプライベートなネットワーク空間を作るサービスです。このVNetという大きな箱の中に、さらに小さな区切りを作るのがサブネット（Subnet）です。
サブネットを作る主な目的は、役割ごとにネットワークを分けることにあります。たとえば、外部に公開するウェブサーバー用、データを保存するデータベース用、といった具合にグループ分けをします。これにより、セキュリティの制御が行いやすくなり、通信の流れを整理整頓できるのです。例えるなら、VNetが「家全体」で、サブネットが「リビング」や「寝室」といった「部屋」のような関係です。
2. サブネット設計で絶対に知っておくべき予約済みアドレス
Azureでサブネットを設計する際、初心者が最も驚くのが「5つの予約済みIPアドレス」の存在です。例えば、256個のIPアドレスが使えるサイズでサブネットを作っても、実際には5個引いた251個しか使えません。この予約アドレスは、Azureシステムがネットワークを管理するために自動的に使用するものです。
具体的には、以下の5つが予約されています。
- x.x.x.0：ネットワークアドレス
- x.x.x.1：デフォルトゲートウェイ
- x.x.x.2、x.x.x.3：DNS（ディーエヌエス）サービス用
- x.x.x.255：ブロードキャストアドレス（VNet内では使用しませんが予約されています）
このため、非常に小さなサブネットを作ってしまうと、予約分だけでアドレスが使い切られてしまう可能性があるため注意が必要です。
3. 将来の拡張を考慮したCIDR表記とIPアドレス計算
IPアドレスの範囲を指定するときにはCIDR（サイダー）表記という書き方を使います。例えば「10.0.0.0/24」といった形式です。スラッシュの後の数字が小さいほど、使えるIPアドレスの数は多くなります。
初心者のうちは、ついつい現在のサーバー台数に合わせてギリギリのサイズを選びがちですが、これは危険です。将来、サーバーを増やしたり、Azureの新しい機能（負荷分散装置など）を追加したりするときに、IPアドレスが足りないとサブネットを作り直すことになります。余裕を持って設計することが鉄則です。
以下は、CIDRと利用可能なアドレス数の対応表です。
CIDR表記 | 合計アドレス数 | Azureで実際に使える数
---------+----------------+----------------------
/29 | 8 | 3
/28 | 16 | 11
/27 | 32 | 27
/26 | 64 | 59
/25 | 128 | 123
/24 | 256 | 251
4. 用途別のサブネット分割とセキュリティ設計
全てのサーバーを1つのサブネットに入れてしまうのは、セキュリティの観点から推奨されません。フロントエンド（Web）、ミドルウェア（App）、バックエンド（DB）のように、ティア（階層）ごとにサブネットを分けるのが一般的です。
サブネットを分けることで、ネットワークセキュリティグループ（NSG）という仮想のファイアウォールを使い、「WebサブネットからDBサブネットへの直接アクセスは禁止する」といった細かいルールを設定できるようになります。これにより、万が一Webサーバーが攻撃を受けても、DB（データベース）まで被害が及ぶリスクを低減できます。
/* サブネットごとのIP管理イメージをデータベースで表現 */
CREATE TABLE SubnetDesign (
id INT PRIMARY KEY,
SubnetName VARCHAR(50),
AddressPrefix VARCHAR(20),
Purpose VARCHAR(100)
);
INSERT INTO SubnetDesign VALUES (1, 'PublicWebSubnet', '10.0.1.0/24', '外部公開用Webサーバー');
INSERT INTO SubnetDesign VALUES (2, 'PrivateAppSubnet', '10.0.2.0/24', '内部処理用アプリケーション');
INSERT INTO SubnetDesign VALUES (3, 'DatabaseSubnet', '10.0.3.0/24', '重要データ蓄積用DB');
INSERT INTO SubnetDesign VALUES (4, 'GatewaySubnet', '10.0.0.0/27', 'VPN接続用特殊サブネット');
SELECT * FROM SubnetDesign;
id | SubnetName | AddressPrefix | Purpose
---+------------------+---------------+-------------------------
1 | PublicWebSubnet | 10.0.1.0/24 | 外部公開用Webサーバー
2 | PrivateAppSubnet | 10.0.2.0/24 | 内部処理用アプリケーション
3 | DatabaseSubnet | 10.0.3.0/24 | 重要データ蓄積用DB
4 | GatewaySubnet | 10.0.0.0/27 | VPN接続用特殊サブネット
5. 特殊な用途で使用する専用サブネットの注意点
Azureには、特定のサービスを利用するために「専用の名前」を付けなければならないサブネットがあります。その代表例がGatewaySubnet（ゲートウェイサブネット）です。これは、自分のPCや社内ネットワークとAzureをVPN（ブイピーエヌ）でつなぐ際に必要となります。
他にも、Azure Firewall（アジュールファイアウォール）用の「AzureFirewallSubnet」などがあります。これらの専用サブネットは、後から追加することが多いため、VNet全体のIPアドレス空間の最初に少し余白を残しておくのがコツです。最初からギチギチにサブネットを詰め込むと、専用サブネットを作る場所がなくなってしまいます。
# Azure CLIを使ってサブネット一覧を確認するイメージ
az network vnet subnet list --resource-group MyResourceGroup --vnet-name MyVNet -o table
Name AddressPrefix PrivEndpointNetworkPolicies PrivLinkServiceNetworkPolicies
---------------- --------------- ----------------------------- ------------------------------
PublicWebSubnet 10.0.1.0/24 Enabled Enabled
DatabaseSubnet 10.0.3.0/24 Enabled Enabled
GatewaySubnet 10.0.0.0/27 Enabled Enabled6. 開発環境と本番環境でのIPアドレス重複を避ける
多くの初心者が陥る罠が、開発環境（テスト用）と本番環境で同じIPアドレス範囲を使ってしまうことです。例えば、どちらも「10.0.0.0/16」で作成してしまうケースです。最初は独立しているので問題ありませんが、将来「開発環境から本番環境へデータをコピーしたい」となり、ネットワークを接続（VNetピアリング）しようとしたときに、IPアドレスが重複していると接続できません。
企業で利用する場合は、将来的に社内ネットワークや他のVNetと接続する可能性があることを前提に、世界で唯一の範囲を割り当てるように計画しましょう。これを「IPアドレス管理（IPAM：アイパム）」と呼びます。
7. サブネットのサイズ決定におけるベストプラクティス
具体的なサイズ選びの目安をお伝えします。一般的なWebシステムであれば、各サブネットに「/24（256アドレス）」を割り当てることが多いです。これは、将来的なサーバーの増設や、PaaS（パース）と呼ばれるAzureの便利な機能（App Service Environmentなど）をサブネット内に配置する場合、大量のIPアドレスを消費することがあるためです。
逆に、小さすぎるサイズ（/29など）は、運用の柔軟性を著しく損なうため、特別な理由がない限り避けるべきです。リソースに余裕があるクラウドだからこそ、アドレス空間は贅沢（ぜいたく）に、かつ計画的に使うのがプロの設計術です。
// C#でサブネットの利用可能アドレスを計算するシミュレーション
using System;
class SubnetCalculator
{
static void Main()
{
int cidr = 24;
double totalAddresses = Math.Pow(2, 32 - cidr);
int azureReserved = 5;
double usableAddresses = totalAddresses - azureReserved;
Console.WriteLine($"CIDR表記: /{cidr}");
Console.WriteLine($"合計アドレス数: {totalAddresses}");
Console.WriteLine($"Azure予約済み: {azureReserved}");
Console.WriteLine($"実際に使える数: {usableAddresses}");
}
}
CIDR表記: /24
合計アドレス数: 256
Azure予約済み: 5
実際に使える数: 251
8. ネットワーク構成の可視化とドキュメント作成
最後に大切なのが、設計した内容をしっかりと図に書き起こすことです。Azureポータル上ではリスト形式で表示されるため、全体のつながりが見えにくいことがあります。どのサブネットがどの役割を持ち、どのIP範囲を使っているのかを構成図として残しておきましょう。
設計書には、サブネット名、CIDR範囲、用途、接続を許可する通信プロトコル（HTTPやSSHなど）を明記します。これが、将来のトラブルシューティングや拡張作業において、もっとも頼りになる地図となります。初心者のうちから、コードや設定だけでなく「設計の意図」を記録する習慣をつけておくと、エンジニアとしてのスキルが飛躍的に向上します。
// JavaScriptでサブネット情報のリストを定義する例
const vnetSettings = {
vnetName: "ProductionVNet",
addressSpace: "10.0.0.0/16",
subnets: [
{ name: "Frontend", prefix: "10.0.1.0/24", security: "High" },
{ name: "Backend", prefix: "10.0.2.0/24", security: "Strict" },
{ name: "Management", prefix: "10.0.254.0/24", security: "AdminOnly" }
]
};
vnetSettings.subnets.forEach(subnet => {
console.log(`設定確認: ${subnet.name} サブネット (${subnet.prefix})`);
});
設定確認: Frontend サブネット (10.0.1.0/24)
設定確認: Backend サブネット (10.0.2.0/24)
設定確認: Management サブネット (10.0.254.0/24)
