クラウドのサブネットCIDRを「総数」ではなく実際の利用可能IP数で選ぶ

/26 のIPv4ブロックには64個のアドレスがあります。しかし、クラウド上のリソースへ64個すべてを割り当てられるわけではありません。一般的なサブネット計算で得られる「利用可能ホスト数62」さえ、クラウドでは過大になることがあります。

たとえば、現在50個のネットワークインターフェースにIPアドレスが必要な仮想シナリオを考えます。設計上の余裕を20%と決めると、目標は60個です。従来の計算なら /26 は62個使えるため足りそうですが、AWSとAzureでは5個が予約され、実際に割り当てられるのは59個です。わずか1個不足します。

ここでは、CIDRブロックの総数とクラウド上の割り当て可能数を分け、/26 と /25 のどちらを選ぶべきかを再計算します。なお、20%という値は一般的な推奨値ではなく、例を再現するための仮定です。

CIDRから分かる二つの基礎数値

IPv4は32ビットです。プレフィックス長を p とすると、ブロック内の総アドレス数は次の式で求められます。

総アドレス数 = 2^(32 - p)

RFC 4632 はCIDRの表記を定義し、/26 を64個、/25 を128個のブロックとして示しています。ただし、プレフィックスが表すのはブロックの大きさです。AWSやAzureなどの予約ルール、マネージドサービス固有の必要数までは含みません。

Calquio CIDR計算機 に 26 を入力すると、次の結果になります。

62という結果は、ネットワークアドレスとブロードキャストアドレスの2個を差し引く、従来のIPv4サブネットの基準です。クラウドの容量設計では、さらに次の計算が必要です。

事業者上の割り当て可能数 = 総アドレス数 - 事業者が予約するアドレス数

計算機は、入力したブロックがAWS VPCのサブネットなのか、Google Cloudのプライマリ範囲なのか、あるいは特定サービス専用なのかを判断しません。「利用可能ホスト数」はプロトコル上の基準値として使い、事業者固有の容量と同一視しないことが重要です。

クラウド事業者の予約分を差し引く

同じ /26 でも、各社の現行公式文書に基づく容量は異なります。

AWSは先頭4個と末尾1個を利用不可としています。Azureも先頭4個と末尾1個の計5個を予約します。Google CloudではプライマリIPv4範囲の先頭2個と末尾2個が利用不可です。

ただし、この表をすべての範囲へ機械的に適用してはいけません。Google Cloudの公式文書では、セカンダリIPv4範囲は全アドレスを利用できるとされています。AWSにもBYOIPの例外があります。また、ファイアウォール、ゲートウェイ、Kubernetesなどのサービスには、別の最小プレフィックスやスケール時の消費ルールがあり得ます。事業者名だけでなく、対象とする範囲とサービスの種類まで確認します。

50個の需要を60個の設計目標にする例

仮に、現在必要な50個の内訳を次のように置きます。

• アプリケーション用ネットワークインターフェース: 36個
• ワーカーまたはビルド用インターフェース: 8個
• 内部エンドポイント: 4個
• 運用用アドレス: 2個

これは推奨構成ではなく、計算手順を明示するための仮想例です。実際には、IPアドレスを受け取る要素を漏れなく、一度だけ数えます。

20%の余裕を加えると、設計目標は次のとおりです。

設計目標 = ceil(50 × 1.20) = 60

各プレフィックスを比較します。

AWSとAzureでは、64 - 5 = 59 なので /26 は不足します。/25 なら 128 - 5 = 123 となり、目標を満たします。

Google Cloudのプライマリ範囲では 64 - 4 = 60 のため、/26 でも数式上は一致します。ただし、設計上の余裕を目標到達時点ですべて使い切ります。ロードバランサーのインターフェース、ローリング更新中に一時併存する旧・新リソースなどを数え漏らしていれば、割り当てに失敗する可能性があります。上位のアドレス計画に余裕があるなら、/25 を選ぶ判断にも根拠があります。

一方、何も検討せず常に /24 にすると、予約前で256個を確保します。環境や層が増えればプライベートアドレス空間が細切れになり、将来のVPC接続、ピアリング、VPNで非重複範囲を確保しにくくなります。目標は「数式上ぎりぎり」でも「とりあえず大きめ」でもなく、根拠のある需要と余裕を満たす最小の有効ブロックです。

境界値を変えて感度を確かめる

必要数を変えると、どこでプレフィックスが切り替わるかが見えます。

必要数が60から61へ1個増えるだけで、Google Cloudのプライマリ範囲は /26 から /25 へ変わり、総ブロック数は64から128へ倍増します。CIDRは2の累乗で増えるため、これは丸め誤差ではありません。後から「なぜ大きいブロックを取ったのか」が分かるよう、余裕の根拠も設計記録へ残します。

平常時だけでなく、一時的なピークも数えます。ローリング更新では、旧リソースと新リソースが同時に存在する場合があります。オートスケール、プライベートエンドポイント、ロードバランサー、マネージドサービスの制御要素も、通常時とは異なるアドレスを消費し得ます。対象サービスの現行文書を確認し、それぞれを需要表の行へ落とし込みます。

実際に選ぶための確認リスト

サブネットを確保する前に、次を明文化します。

1. 範囲の種類: 事業者、IPv4の範囲種別、プライマリ・セカンダリ・BYOIP・専用サブネットの別。
2. 平常時の需要: インターフェース、エンドポイント、ノード、サービスが必要とするアドレス。
3. ピーク需要: 更新時の併存、障害切り替え、最大オートスケール数。
4. 設計上の余裕: パーセントまたは固定数と、その値を選んだ理由。
5. 事業者予約分: 総数から対象範囲に適用される予約数を差し引いた値。
6. サービス制約: 最小プレフィックスや専用サブネットなどの条件。
7. 全体アドレス計画: オンプレミス、他VPC/VNet、ピア、VPN接続先との重複。

最後にCIDR計算機で総数とサブネットマスクを再確認し、その横に事業者予約分を明記します。これにより、「62ホスト」という基準値が、いつの間にかAWSやAzureの容量保証として扱われるのを防げます。

この計算で扱えないこと

この手順はIPv4アドレス容量の計算です。ルーティング、セキュリティ境界、アベイラビリティゾーン構成、IPv6、Kubernetes Pod範囲まで設計するものではありません。サブネットを大きくしても、自動的に可用性や安全性が上がるわけではありません。

50個という内訳と20%の余裕は仮定です。実環境の観測値、サービスのスケール仕様、組織の復旧要件へ置き換えてください。予約ルールやサービス要件は変わり得るため、デプロイ前に対象事業者とサービスの最新公式文書を再確認する必要があります。

情報源

• RFC 4632: Classless Inter-domain Routing (CIDR) — IETF Best Current Practice、2006年8月。2026年7月29日参照。
• AWS: Subnet CIDR blocks — VPCの予約アドレスとサブネットサイズに関する現行文書。ページ上に改訂日の記載なし。2026年7月29日参照。
• Microsoft Azure: Virtual networks and subnets — 2026年6月22日更新。2026年7月29日参照。
• Google Cloud: Subnets — 2026年7月27日UTC更新。2026年7月29日参照。