この記事では、AWSのVPC CIDRブロック選定から、マルチAZでのサブネット分割、セカンダリCIDRによる無停止拡張、VPCピアリング時のIP重複回避、AWS IPAMによる複数VPC管理まで、構成設計の実践パターンを解説します。
この記事のポイント
・VPCのCIDRブロックは作成後に変更不可。最初の設計が全てを決める
・複数VPCを計画するなら10.x.0.0/16形式の連番プランニングが基本
・マルチAZの3層サブネット設計は/24 x 9サブネットが現場の標準パターン
・セカンダリCIDRで既存VPCを無停止拡張でき、最大5ブロックまで追加できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜCIDR設計を最初にやらないと後悔するのか
VPCを作成する際、CIDRブロック（例: 10.0.0.0/16）を一度設定すると後から変更する手段はありません。変更したければVPCを削除して作り直すしかなく、その際はEC2インスタンス・RDS・ALBなど全リソースの再作成が必要になります。もう一つ見落とされがちな問題があります。VPCピアリングやAWS Transit Gateway、Direct ConnectでVPC間・オンプレ間を接続しようとしたとき、相手のCIDRと重複していると接続を作れません。よくある失敗が「どのVPCも10.0.0.0/16で作ってしまい、後でマルチアカウント構成に移行できなかった」というケースです。
設計を最初にきちんとやれば30分で済む話が、後から直すとなれば数日のダウンタイムリスクを伴う大規模作業になります。以下に「後から直す」コストのイメージを整理します。
| 影響を受けるリソース | やり直しの作業内容 |
|---|---|
| EC2インスタンス | 新VPCへの移行（AMI経由。IPアドレスが変わるためアプリ設定も変更） |
| RDS | スナップショットから新VPCに復元（接続文字列の変更が必要） |
| ALB / NLB | 新VPCで再作成・DNS変更（TTL待ちあり） |
| ElastiCache | サブネットグループの再作成・接続先変更 |
| VPCエンドポイント | 新VPCで再設定・ルートテーブル更新 |
VPCのCIDRブロックをどう選ぶか
AWSのVPCで使えるIPアドレスはRFC 1918で定められたプライベートアドレス範囲に限られます。・10.0.0.0/8：最も広いアドレス空間（約1,600万アドレス）。複数VPC・マルチアカウントにも対応できる
・172.16.0.0/12：約100万アドレス。中規模構成向け
・192.168.0.0/16：約65,000アドレス。家庭用ルーターがデフォルトで使う帯域と衝突しやすいため、VPNで自分のPCを接続する構成では避けた方が無難
実務では10.x.0.0/16形式が最も汎用的です。/16は65,534個のIPアドレスを含み、3層構成×3AZの9サブネットを/24で切ってもゆとりがあります。
1. 複数VPCを計画するときは連番でプランニングする
将来的に複数のVPCを使う可能性があるなら、最初から連番で確保しておくと後が楽です。# VPCのCIDRブロック割り当て例（マルチアカウント構成向け） 10.0.0.0/16 # 本番VPC（メインシステム） 10.1.0.0/16 # ステージングVPC 10.2.0.0/16 # 開発VPC 10.3.0.0/16 # セキュリティ監視VPC（将来用） 10.10.0.0/16 # 第2事業ドメイン用（将来の拡張） # オンプレミス側のネットワーク（Direct Connect・VPNで繋ぐ場合） 192.168.0.0/16 # オンプレ帯域（事前確認して衝突を回避すること）
2. 小さすぎるCIDRの罠
/24（254アドレス）でVPCを作ると、サブネットを切るたびにすぐ枯渇します。AWSはサブネット内で先頭4つと末尾1つの計5つを予約済みとして使用するため、/28サブネット（16アドレス）で使えるのは実質11アドレスしかありません。・テスト用VPC：最低/20（4,096アドレス）
・本番VPC：/16を推奨
・大規模マルチサービス構成：/16でも足りなくなる場合にセカンダリCIDRを追加（後述）
サブネットをマルチAZで3層に分割する設計パターン
現場でよく使われるのが「3層構成 × 3AZ」の9サブネット設計です。パブリックサブネット（ALBなどのインターネット向けリソース）・アプリケーションサブネット（EC2）・データサブネット（RDS・ElastiCache）を各AZに配置します。AWSでは通常3つのAZ（ap-northeast-1a / 1c / 1d など）を使います。以下に10.0.0.0/16 VPCでの具体的な分割例を示します。
| サブネット種別 | AZ-a (1a) | AZ-c (1c) | AZ-d (1d) |
|---|---|---|---|
| パブリック（ALB） | 10.0.0.0/24 | 10.0.1.0/24 | 10.0.2.0/24 |
| アプリケーション（EC2） | 10.0.10.0/24 | 10.0.11.0/24 | 10.0.12.0/24 |
| データ（RDS） | 10.0.20.0/24 | 10.0.21.0/24 | 10.0.22.0/24 |
10.0.0.0/24（パブリック）、10.0.10.0/24（アプリ）、10.0.20.0/24（データ）のように10番台・20番台でブロックを分けると、後で見たときに「どの層のサブネットか」がCIDRからすぐわかります。インフラが複雑になったときに助かる小さな工夫です。
AWSのVPC基礎からAmazon Linux実践操作まで体系的に学びたい方は、AWS・Amazon Linux入門ガイドでEC2とVPCの基本操作を確認するとスムーズです。
VPC間を接続するときのIPアドレス重複を回避する方法
VPCピアリング・AWS Transit Gateway・Direct Connect・Site-to-Site VPNを利用する場合、接続先のCIDRと自VPCのCIDRが重複すると接続を作れません。複数のVPCを接続する前に、既存VPCのCIDRを確認する習慣をつけましょう。# 全VPCのCIDRブロック一覧を取得する $ aws ec2 describe-vpcs --query 'Vpcs[*].{VpcId:VpcId,CIDR:CidrBlock,Name:Tags[?Key==`Name`]|[0].Value}' --output table ----------------------------------------------------- | DescribeVpcs | +----------------+-------------------+--------------+ | CIDR | Name | VpcId | +----------------+-------------------+--------------+ | 10.0.0.0/16 | prod-vpc | vpc-0a1b2c3d| | 10.1.0.0/16 | staging-vpc | vpc-1e2f3a4b| | 10.2.0.0/16 | dev-vpc | vpc-2c3d4e5f| +----------------+-------------------+--------------+
1. VPCピアリング作成前のCIDR重複チェック手順
# verify: check for cidr overlaps before peering # 自VPCのCIDRを確認する $ aws ec2 describe-vpcs --vpc-ids vpc-yyyyyyyyyyyyyyyyy --query 'Vpcs[0].CidrBlock' --output text 10.0.0.0/16 # 接続先VPCのCIDRを確認する（相手アカウントのVPC IDを指定） $ aws ec2 describe-vpcs --vpc-ids vpc-xxxxxxxxxxxxxxxxx --query 'Vpcs[0].CidrBlock' --output text 10.0.0.0/16 ← 同じ！ ピアリング作成が失敗する
Direct Connectでオンプレと接続する場合は、オンプレ側のIP帯域をインフラチームに確認してから設計に入るのがルールです。「AWSとオンプレで同じ172.16.0.0/16を使っていてDirect Connectが通らなかった」という事例は実際に起きています。
セカンダリCIDRブロックでVPCを無停止で拡張する
既存VPCのIPアドレスが逼迫してきたとき、セカンダリCIDRブロックを追加することでVPCを無停止で拡張できます。元のプライマリCIDRは変わらず、新しいIPアドレス空間を追加する形になります。# セカンダリCIDRブロックをVPCに追加する $ aws ec2 associate-vpc-cidr-block --vpc-id vpc-0a1b2c3d4e5f67890 --cidr-block 10.100.0.0/16 # 実行結果例 { "VpcId": "vpc-0a1b2c3d4e5f67890", "CidrBlockAssociation": { "AssociationId": "vpc-cidr-assoc-0abc123def456789", "CidrBlock": "10.100.0.0/16", "CidrBlockState": { "State": "associating" } } } # 追加後にVPCのCIDR一覧を確認する $ aws ec2 describe-vpcs --vpc-ids vpc-0a1b2c3d4e5f67890 --query 'Vpcs[0].CidrBlockAssociationSet[*].CidrBlock' [ "10.0.0.0/16", "10.100.0.0/16" ]
・制限1：1つのVPCに追加できるCIDRブロックは最大5つ（プライマリを含む）
・制限2：追加できるCIDRはプライマリCIDRと重複しない範囲のみ
・制限3：IPv6 CIDRは別カウント（最大5つのIPv4 + 1つのIPv6）
AWS IPAMで複数VPCのIPアドレスを一元管理する
VPCが5つを超えてくると、スプレッドシートでCIDRを管理するのが限界に近づきます。AWSが提供するVPC IP Address Manager（IPAM）を使うと、複数アカウント・複数リージョンのIPアドレス空間を一元管理できます。1. IPAMの基本概念（スコープとプール）
IPAMは「スコープ」と「プール」の2層構造で管理します。・スコープ：パブリック用とプライベート用を分ける最上位の区画。プライベートスコープはRFC 1918帯域向け
・プール：スコープ内に作る実際のIPアドレス帯域。親プールから子プールへと分割管理する（例: 10.0.0.0/8 親プール → 本番/ステージング/開発の子プール）
2. IPAMの有効化とプール確認（CLIで確認）
# IPAMを有効化する（Organizations連携で全アカウントに自動適用） $ aws ec2 create-ipam --operating-regions RegionName=ap-northeast-1 --region ap-northeast-1 # IPAMのプール一覧を表示する $ aws ec2 describe-ipam-pools --query 'IpamPools[*].{Name:IpamPoolName,CIDR:ProvisionedCidrs[0].Cidr}' --output table --------------------------------------------- | DescribeIpamPools | +--------------------------+----------------+ | CIDR | Name | +--------------------------+----------------+ | 10.0.0.0/8 | 親プール | | 10.0.0.0/16 | 本番 | | 10.1.0.0/16 | ステージング | +--------------------------+----------------+
3. IPAM統合でVPC作成時にCIDRを自動割り当てする
IPAMプールを指定してVPCを作成すると、プールから次の空きCIDRが自動的に割り当てられます。# IPAMプールからCIDRを自動割り当てしてVPCを作成する $ aws ec2 create-vpc --ipv4-ipam-pool-id ipam-pool-0a1b2c3d4e5f67890 --ipv4-netmask-length 16 --region ap-northeast-1 # 作成されたVPCのCIDRを確認する（プールから自動割り当てされた値） { "Vpc": { "CidrBlock": "10.2.0.0/16", "VpcId": "vpc-0a1b2c3d4e5f67890" } }
よくある失敗パターンとトラブルシュート
1. VPCピアリングを作成しようとしたらエラーになった
「InvalidVpc.Range」または「CidrConflict」エラーが出る場合、CIDRが重複しています。前述の describe-vpcs コマンドで両VPCのCIDRを確認してください。重複している場合、新しい方のVPCをCIDRを変えて作り直す必要があります。2. セカンダリCIDRを追加しようとしたら失敗した
以下のいずれかが原因です。・追加CIDRがプライマリCIDRと重複している → 重複しないCIDRに変更する
・VPCのCIDRブロック数が上限（5つ）に達している → 不要なCIDRブロックを解除する（aws ec2 disassociate-vpc-cidr-block）
・IPAMプールに空きがない → IPAMの割り当て状況を確認する
3. IPAMプールからVPCを作成したらCIDRが想定外の値になった
IPAMは空きCIDRを自動で選ぶため、特定のCIDRを使いたい場合は --cidr-block で明示的に指定する必要があります。IPAMプールの割り当て状況を確認してから手動指定してください。本記事のまとめ
VPCのCIDR設計は「とりあえず作った後で考えよう」が最も危険な判断です。作成後の変更は不可能で、後から直すコストは設計に費やす時間の数十倍になります。| 設計判断 | 推奨する設計 | アンチパターン |
|---|---|---|
| VPCのCIDRサイズ | 本番は/16、テストは最低/20 | /24以下（すぐに枯渇する） |
| 複数VPCの管理 | 10.x.0.0/16形式の連番で事前確保 | 全VPCに同じ10.0.0.0/16を使う |
| サブネット設計 | 3層×3AZの9サブネット（各/24） | 1AZだけ使う（単一障害点） |
| VPC拡張 | セカンダリCIDRブロックを追加（無停止） | VPCを削除・再作成する |
| 大規模管理 | AWS IPAMでプール管理・自動割り当て | スプレッドシートで手動管理 |
| 接続前確認 | describe-vpcsでCIDRを照合してから接続 | 重複チェックなしでピアリングを試みる |
AWSインフラの基礎からAmazon Linux実践操作まで体系的に学びたい方は、AWS・Amazon Linux入門ガイドもあわせてご覧ください。
VPC設計を「実務の型」として身につけませんか？
CIDRの選び方は調べれば分かります。でも「なぜマルチAZで3層構成にするのか」「複数VPCを将来つなぐために今何をしておくべきか」を設計前から語れますか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、「Linuxサーバー構築入門マニュアル（図解60P）」を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：AWS Step Functionsで非同期ワークフローを設計する方法｜ステートマシンでLambdaをオーケストレーションする実践パターン
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます