architecture
A
信頼度ランク
| S | 公式ソース確認済み |
| A | 成功実績多数・失敗例少数 |
| B | 賛否両論 |
| C | 動作未確認・セキュリティリスク高 |
| Z | 個人所感 |
VPC CIDRプランニング — プライマリ/セカンダリCIDR・ピアリングの制約・サブネット設計
AWSのVPC CIDRブロック設計、許可されるIPv4範囲、セカンダリCIDRの追加、VPCピアリング時の重複CIDR問題、サブネット設計のベストプラクティスを解説。
一言結論
VPCのCIDRは後から変更できず(セカンダリCIDR追加は可能)、CIDRが重複するとVPCピアリングが設定できないため、マルチアカウント環境では組織全体のCIDR割り当て計画を最初から設計することがネットワーク基盤の信頼性を左右する。
VPC CIDRの基本ルール
VPCのIPv4 CIDRブロックは以下のプライベートアドレス範囲から選択する必要がある。
RFC 1918 プライベートアドレス範囲:
10.0.0.0/8 → VPCでは /16 〜 /28 が指定可能
172.16.0.0/12 → VPCでは /16 〜 /28 が指定可能
192.168.0.0/16 → VPCでは /16 〜 /28 が指定可能
追加:
100.64.0.0/10(RFC 6598, CGNATアドレス)
→ AWSはこの範囲もVPCで使用可能
最小CIDRは /28(16IPアドレス)、最大は /16(65,536IPアドレス)だ。
AWSが予約するIPアドレス
各サブネットの最初の4つと最後の1つのIPアドレスはAWSが予約している。
例: 10.0.0.0/24(256アドレス)
10.0.0.0 ← ネットワークアドレス
10.0.0.1 ← VPCルーター
10.0.0.2 ← AWSのDNSサーバー
10.0.0.3 ← AWSが将来使用するために予約
10.0.0.255 ← ブロードキャストアドレス(AWSはブロードキャスト非対応)
→ 使えるIPは 10.0.0.4 〜 10.0.0.254 = 251アドレス
セカンダリCIDR(拡張)
VPC作成後にCIDRを拡張する必要が生じた場合、セカンダリCIDRを追加できる。
# セカンダリCIDRの追加
aws ec2 associate-vpc-cidr-block \
--vpc-id vpc-xxx \
--cidr-block 10.1.0.0/16
# 追加できるCIDR数: 最大5つ(プライマリ1 + セカンダリ4)
# ただし隣接するCIDRとの重複は不可
制約:
- 既存CIDRと重複できない
- 追加したCIDRと既存のピアリング先のCIDRが重複してはいけない
- セカンダリCIDRは削除可能(そのCIDRに属するリソースが使用されていない場合)
マルチアカウント・マルチVPC設計でのCIDRプランニング
複数アカウント・VPCを持つ場合、重複しないCIDRを計画的に割り当てることが重要だ。
例: 10.0.0.0/8 を組織全体で使う場合の割り当て計画
本番アカウント:
VPC-App: 10.0.0.0/16 (東京: 10.0.0.0〜10.0.255.255)
VPC-DB: 10.1.0.0/16 (東京: 10.1.0.0〜10.1.255.255)
開発アカウント:
VPC-Dev: 10.10.0.0/16 (東京)
VPC-Staging: 10.11.0.0/16
DR(大阪リージョン):
VPC-DR-App: 10.20.0.0/16
VPC-DR-DB: 10.21.0.0/16
オンプレミス:
192.168.0.0/16 (VPCと重複させない)
VPCピアリング時のCIDR重複問題
VPCピアリングではCIDRが重複するとピアリング設定はできない。
❌ 重複でピアリング不可:
VPC A: 10.0.0.0/16
VPC B: 10.0.0.0/16 → 同一CIDRなのでピアリング不可
❌ 一部重複でもピアリング不可:
VPC A: 10.0.0.0/16
VPC B: 10.0.1.0/24 → VPC AのCIDR内に含まれるのでピアリング不可
✅ 重複なしでピアリング可能:
VPC A: 10.0.0.0/16
VPC B: 10.1.0.0/16
サブネット設計のベストプラクティス
マルチAZ構成での一般的なサブネット設計:
VPC: 10.0.0.0/16
パブリックサブネット:
AZ-a: 10.0.0.0/24 (254ホスト)
AZ-c: 10.0.1.0/24
AZ-d: 10.0.2.0/24
プライベートサブネット(アプリ層):
AZ-a: 10.0.10.0/24
AZ-c: 10.0.11.0/24
AZ-d: 10.0.12.0/24
プライベートサブネット(DB層):
AZ-a: 10.0.20.0/24
AZ-c: 10.0.21.0/24
AZ-d: 10.0.22.0/24
AZ数×レイヤー数のサブネットを作成し、CIDRに余裕を持たせることで将来の拡張に対応する。
IPv6サポート
# VPCにAWSが割り当てるIPv6 CIDRを追加
aws ec2 associate-vpc-cidr-block \
--vpc-id vpc-xxx \
--amazon-provided-ipv6-cidr-block
# サブネットにIPv6 CIDRを割り当て
aws ec2 associate-subnet-cidr-block \
--subnet-id subnet-xxx \
--ipv6-cidr-block 2001:db8::/64
IPv6はAWS割り当ての /56 ブロックからサブネットに /64 を割り当てる。IPv6はすべてパブリックアドレスのため、インターネットへのアウトバウンドのみ許可する場合はEgress-Only IGWを使う。
試験頻出ポイント
| シナリオ | 回答 |
|---|---|
| /28サブネットで使えるIPの実際の数 | 16 - 5(AWS予約) = 11個 |
| ピアリングでCIDRが重複していた場合 | ピアリング設定できない |
| VPCのCIDR変更(既存VPC) | 変更不可(セカンダリCIDRの追加は可能) |
| セカンダリCIDRの最大数 | 4つ追加(プライマリと合わせて最大5つ) |
まとめ
CIDRプランニングは後から変更できないため設計段階での十分な計画が重要だ。マルチアカウント環境では組織全体のCIDR体系を設計し、重複が起きないよう管理することがVPCピアリングやTransit Gatewayを使う上での前提条件になる。