VPCを作成するとき、CIDRブロックを深く考えず 10.0.0.0/16 を指定してしまっていないだろうか。単一VPCの検証環境ならそれで動くが、複数のVPCをTransit Gatewayで接続しようとした瞬間に問題が露呈する。CIDRが重複していると、Transit Gatewayのルーティングテーブルに追加できず、接続設定が完全に詰まってしまう。オンプレではVLANで論理的に重複を吸収できた場面も、AWSのルーティングベースの接続では許容されない。
この記事では、マルチアカウント環境を見越したCIDRブロックの計画方法、Transit Gateway接続に必要な設計方針、サブネット分割の実践パターンをオンプレ経験者向けに解説する。
なぜVPC CIDRは最初に正しく設計しなければならないのか
オンプレミスのIPアドレス設計との最大の違いは、VPCのプライマリCIDRブロックは作成後に変更できない点だ。セカンダリCIDRブロックを後から追加する方法はあるが（後述）、プライマリを変更したい場合はVPCを作り直すしかない。
VPCを作り直すということは、EC2インスタンス・RDS・ELB・ECSタスクなどすべてのリソースを再構築し、セキュリティグループやルートテーブルも設定し直すことを意味する。本番環境ではさらにDNS変更やダウンタイムの調整も伴う。
「とりあえず10.0.0.0/16にしておけば、あとでなんとかなる」という発想は、クラウドでは通用しない。プロジェクト初期の段階でCIDR設計を確定させることが、将来の大規模な手戻りを防ぐ最善策だ。
VPC CIDRの基礎とAWSの制約
1. 利用可能なプライベートアドレス範囲
AWSのVPC CIDRにはRFC 1918で定義されたプライベートアドレス範囲を使う。
| 範囲 | 総アドレス数 | 利用上の注意 |
|---|---|---|
| 10.0.0.0/8 | 約1,677万 | 大規模マルチアカウント設計の標準。組織全体でプール管理しやすい |
| 172.16.0.0/12 | 約104万 | DockerのデフォルトブリッジやオンプレVPNと競合しやすく要注意 |
| 192.168.0.0/16 | 約6.5万 | 小規模検証向け。マルチアカウント展開には不向き |
企業のマルチアカウント展開では、10.0.0.0/8の範囲を組織全体でプールとして管理し、アカウントごとに切り出して割り当てる設計が主流だ。172.16.0.0/12は、オンプレ環境のVPNルーターや仮想化基盤（VMware等）のデフォルト範囲と重複しやすいため、新規設計では避けたほうが無難だ。
2. VPCのCIDRサイズ（/16～/28）
AWSが許可するVPCのCIDRサイズは /16（65,536アドレス）から /28（16アドレス）まで。実際の設計では/16 か /20 を基本単位とするケースが多い。
| CIDRサイズ | IPアドレス数 | 用途の目安 |
|---|---|---|
| /16 | 65,536 | 大規模本番VPC。将来の大幅な拡張も見越したい場合 |
| /20 | 4,096 | 標準的なアカウント割り当て単位。中規模ワークロードに十分 |
| /24 | 256 | 単機能の専用VPC・小規模検証環境 |
3. AWSが予約する5つのIPアドレス
VPC内の各サブネットで先頭4つと末尾1つ、計5つのIPアドレスがAWSに予約されている。たとえば 10.0.1.0/24 のサブネットでは、実際に使えるIPは256 − 5 = 251個になる。
・x.x.x.0: ネットワークアドレス
・x.x.x.1: VPCルーター用
・x.x.x.2: AWSのDNSサーバー（VPC CIDRの先頭+2）
・x.x.x.3: 将来の利用のためにAWSが予約
・x.x.x.255: ネットワークブロードキャストアドレス（AWSのVPCでは使われないが予約済み）
/28（16アドレス）のサブネットだと実際に使えるのは11個しかない。Lambda関数やFargateタスクが使うENIは複数のIPを消費するため、プライベートサブネットは /24 以上を確保しておくのが安全だ。
Transit Gateway接続を見越したCIDR設計
1. CIDRが重複するとどうなるか
開発チームAが作ったVPC-A（10.0.0.0/16）と、別チームが独立して作ったVPC-B（10.0.0.0/16）を、Transit Gatewayで接続しようとする場面を想像してほしい。
Transit Gatewayのルーティングテーブルは、宛先CIDRをキーに次ホップを決定する。2つのVPCが同一CIDRを持っていると、ルーティングテーブルに両方のアタッチメントを登録できない。AWSのコンソールでは「The CIDR range conflicts with another attachment in this route table」のようなエラーが返り、接続設定が完全に詰まる。
VPC Peeringでも同様だ。重複したCIDRを持つVPC同士はピアリング接続の承認時点でエラーになる。
オンプレでは「ルーター側でNATを使えばいい」という回避策もあったが、Transit Gatewayは基本的にルーティングテーブルによる透過的な転送が前提のため、NATでの吸収は設計の複雑度と運用コストが跳ね上がり、現実的な解決策にならないことが多い。
Transit Gatewayの詳細な接続設定や使い方については、「AWS Transit Gateway入門｜マルチVPC・オンプレ接続をハブ&スポーク設計で統制する実践ガイド」を参照してほしい。
2. マルチアカウントでのCIDR割り当て戦略
AWS Organizationsとの連携を前提に、OU（組織単位）ごとにCIDRの塊を事前に確保し、各アカウントに一定サイズを切り出して割り当てるのが現場での標準設計だ。
以下は10.0.0.0/8全体をOU別に分割する設計例だ（一般的なパターンであり、実際の規模に合わせて調整すること）。
| OU / 環境 | 割り当てCIDR | 利用可能アドレス数 | 1アカウントの割り当て例 |
|---|---|---|---|
| 本番（Production） | 10.0.0.0/12 | 約104万 | /20（4,096IP）×最大256アカウント |
| ステージング（Staging） | 10.16.0.0/13 | 約52万 | /20（4,096IP）×最大128アカウント |
| 開発（Development） | 10.24.0.0/13 | 約52万 | /20（4,096IP）×最大128アカウント |
| 共有サービス（Shared Services） | 10.32.0.0/15 | 約13万 | Transit GatewayのHub VPC等を配置 |
| サンドボックス（Sandbox） | 10.34.0.0/15 | 約13万 | /22（1,024IP）単位で払い出し可 |
このように設計しておくと、どの環境・アカウントのVPCをTransit Gatewayに追加しても、ルーティングテーブルのCIDR競合が起きない。オンプレからの専用線接続（AWS Direct Connect等）を追加する際も、オンプレ側が使っているCIDRとの重複確認が容易になる。
AWS Organizationsを使ったマルチアカウント管理の基礎については「AWS Organizations入門｜マルチアカウント管理とSCPでガバナンスを統制する実践ガイド」を参照してほしい。Account Factoryによるアカウント自動払い出しを行う場合は「AWS Control Tower入門｜Landing Zoneで複数AWSアカウントを自動標準化するガバナンス設計と運用ガイド」も合わせて読んでほしい。
実践的なサブネット設計パターン
1. 3層構成（Public/Private/DB）とAZ分割の基本
VPCを3層（インターネット公開層・アプリ層・DB層）とAZ（アベイラビリティゾーン）3つで分割する場合のサブネット設計例を示す。VPC全体は10.0.0.0/16を想定している。
| 層 | AZ-a（ap-northeast-1a） | AZ-b（ap-northeast-1b） | AZ-c（ap-northeast-1c） |
|---|---|---|---|
| パブリック（ALB・NAT Gateway） | 10.0.0.0/24（251IP） | 10.0.1.0/24（251IP） | 10.0.2.0/24（251IP） |
| プライベート（EC2・ECS・Lambda ENI） | 10.0.16.0/20（4,091IP） | 10.0.32.0/20（4,091IP） | 10.0.48.0/20（4,091IP） |
| DB（RDS・ElastiCache） | 10.0.10.0/24（251IP） | 10.0.11.0/24（251IP） | 10.0.12.0/24（251IP） |
パブリックサブネットはALBとNAT Gateway用に最小限のサイズ（/24）に抑え、実際の計算インスタンスやコンテナはプライベートサブネットに置くのが基本だ。プライベートサブネットを /20 と大きめに確保するのは、FargateタスクやLambdaのENIが増加したときに追加のIPが必要になるためだ。
2. セカンダリCIDRによる拡張と限界
プライマリCIDRが枯渇しそうになった場合、VPCにセカンダリCIDRブロックを追加できる（最大5つまで）。ただしいくつかの制約がある。
・セカンダリCIDRはプライマリと重複できない
・100.64.0.0/10（CGNAT空間）のセカンダリCIDRを追加可能：通常インターネットから到達不能な範囲で、プライベートIPとして拡張用に使われるケースがある
・Transit GatewayやVPC Peeringで接続した相手のCIDRとも重複できない
セカンダリCIDRは緊急の拡張手段として有効だが、あくまで「後付け」であることに変わりはない。設計上の余裕は最初のプライマリCIDR設計で確保しておくのが原則だ。
AWS IPAMでCIDR管理を中央集権化する
アカウント数が増えてくると、スプレッドシートによる手動のCIDR管理では追いつかなくなる。そこで役立つのがAmazon VPC IP Address Manager（IPAM）だ。
IPAMを使うと、Organization全体のIPアドレス割り当てをコンソールから一元管理できる。既存VPCのCIDRを自動的に検出し、どのアカウント・どのリージョンに何のCIDRが割り当たっているかを可視化できる。CIDRプールを階層構造で定義し、アカウント作成時にIPAMプールから自動払い出しすることで、ヒューマンエラーによるCIDR重複を防止できる。
料金（2026年7月時点）: アクティブなIPアドレス1個あたり $0.00027/時間（東京リージョン）。10,000個のアクティブIPで月あたり約$20程度。
AWS CLIでIPAMプールを作成する例を示す。
# AWS CLIコマンド: IPAMプールを作成（本番OU向け） aws ec2 create-ipam-pool \ --ipam-scope-id ipam-scope-0abc1234def56789 \ --address-family ipv4 \ --cidr 10.0.0.0/12 \ --allocation-min-netmask-length 20 \ --allocation-max-netmask-length 20 \ --description "Production OU CIDR Pool" \ --region ap-northeast-1
パブリックIPv4課金とIPv6デュアルスタックの検討
2024年2月から、AWSはパブリックIPv4アドレス（Elastic IPを含むすべての種類）に対して $0.005/時間（2026年7月時点・東京リージョン） の課金を開始した。月あたりIPv4アドレス1つで約$3.6、10個保有していれば月$36かかる計算だ。
この課金が始まってから、不要なElastic IPの解放やALBへの集約が現場で急速に進んだ。VPC設計においても、不必要にパブリックサブネットにEC2インスタンスを置かず、NAT Gateway経由でインターネットへアクセスするプライベートサブネット配置を徹底することがコスト削減の第一歩になる。
IPv6については、AWSはIPv6の利用に対して追加料金を設けていない（データ転送料金は別途かかる）。新規のVPCではデュアルスタック（IPv4+IPv6の並存）を検討する価値がある。ただし、アプリケーション側のIPv6対応確認が必要なため、既存システムへの適用は慎重な評価を要する。
よくある設計ミスと対処法
・すべてのVPCに10.0.0.0/16を使う: 最も多いミス。Transit Gateway接続やVPC Peeringを追加しようとした時点で詰まる。アカウント払い出し時にCIDRを一意に割り当てるルールを事前に定めること。
・サブネットを/28や/29で切りすぎる: Lambda・Fargate・ECSが使うENIは複数のIPを消費する。サービス側のENI数上限を確認し、プライベートサブネットは /24 以上を確保するのが安全だ。
・172.16.0.0/12を選ぶ: DockerのデフォルトブリッジやオンプレVPNと競合しやすい。特別な事情がない限り10.0.0.0/8を選択することを推奨する。
・後から何でも追加できると過信する: セカンダリCIDRで拡張はできるが、既存のピアリング先やTGW接続との重複チェックが必要になり、追加コストと調整工数がかかる。
・オンプレのIPアドレス範囲との重複チェックを怠る: Direct ConnectやSite-to-Site VPNでオンプレと接続する場合、オンプレ側が使っているCIDRとVPCのCIDRが重複していると接続できない。オンプレのIPAM台帳と突合してから設計を確定すること。
本記事のまとめ
VPC CIDRの設計は、後から変更できないプライマリブロックの性質上、プロジェクト初期に確定させる必要がある。特にマルチアカウント・Transit Gateway接続を前提とした環境では、OU別のCIDR割り当て方針を組織全体で決めておくことが、将来の拡張時の手戻りを防ぐ最善策だ。
| 設計ポイント | 推奨アクション |
|---|---|
| CIDR重複の防止 | OU別にCIDR範囲を事前割り当て。10.0.0.0/8を組織プールとして管理する |
| VPCのCIDRサイズ | 本番は /16 または /20 を基本単位とし、プライベートサブネットは大きめに確保する |
| CIDR管理の自動化 | アカウント数が増えたらAWS IPAMの導入を検討する |
| パブリックIPコスト削減 | インスタンスはプライベートサブネットに置き、ALB・NAT Gatewayで集約する |
| オンプレとの接続前確認 | Direct Connect・VPN追加前にオンプレCIDRとの重複チェックを必ず実施する |
PR
AWSの設計パターンをアーキテクチャ視点で体系的に解説した一冊。VPC設計・セキュリティ・コスト最適化まで現場目線でカバーしており、CIDR設計を含む基盤設計の判断材料として手元に置きたい書籍です。
