導入
SAAでは「1つのVPCにCIDRを1つ割り当てる」だけで済みました。しかしSAPでは、数十のVPCを後からピアリングしたりTransit Gatewayでつないだりします。そのとき最初のCIDR設計が甘いと、あとで「アドレスが重複していてつなげない」という致命的な問題にぶつかります。
説明
VPCの CIDR（IPアドレス範囲） は、作成後に主要な範囲を変更できません（セカンダリCIDRの追加は可能）。そのため、組織全体でネットワークを設計する最初の一歩は「将来つながる可能性のあるVPC・オンプレ同士で、アドレスが絶対に重複しないように採番する」ことです。
| 設計原則 | 理由 |
|---|---|
| 事業部・環境ごとにCIDRブロックを事前予約 | 後から作るVPCが既存と重複しないようにする |
VPCは必要以上に大きく取らない（例 /22〜/24） | IPAM上限やルートテーブルの肥大化を避ける |
| サブネットはAZ数×用途数を見込んで区切る | 拡張時にサブネット追加で対応できる |
| オンプレのアドレス帯とも重複させない | VPN/Direct Connect接続時にルーティングが破綻する |
大規模組織でこの採番を手作業に頼るのは危険です。Amazon VPC IP Address Manager（IPAM） を使うと、複数アカウント・複数リージョンにまたがるCIDRの割り当てを一元管理し、重複を自動的に防げます。IPAMは組織のCIDRプールを階層化し（リージョン用プール→本番用プール→アカウント用プールのように）、各アカウントは決められたプールの中からしかCIDRを取得できないようにできます。
flowchart TD
IPAM["IPAM 全体プール<br/>10.0.0.0/8"] --> P1["本番用プール<br/>10.0.0.0/12"]
IPAM --> P2["開発用プール<br/>10.16.0.0/12"]
P1 --> V1["VPC A<br/>10.0.0.0/22"]
P1 --> V2["VPC B<br/>10.0.4.0/22"]
P2 --> V3["VPC C<br/>10.16.0.0/22"]
具体例
企業買収の現場でよく起きる失敗です。A社がB社を買収し、両社のAWS環境をつなごうとしました。ところが、両社とも“よくある”デフォルト帯 10.0.0.0/16 をVPCに使っていたため、アドレスが丸かぶり。ピアリングもTransit Gatewayも、CIDRが重複しているとルーティングが破綻してつなげません。VPCの主要CIDRは後から変更できないので、片方をVPCごと作り直す羽目に——大工事です。
これを未然に防ぐのがIPAMです。組織全体のアドレスを階層プールで管理し、
- 本番用プールは
10.0.0.0/12、開発用は10.16.0.0/12…と事前に区切る - 各アカウントは決められたプールの中からしかCIDRを取得できない
- 重複しそうな採番は自動で弾かれる
「将来つながる可能性のあるVPC・オンプレは、絶対にアドレスを重複させない」——これが大規模ネットワーク設計の第一歩。SAPで「複数VPCを将来接続する予定」と来たら、IPAMによる一元CIDR管理を思い出しましょう。
読んでみよう
「VPCピアリングやTransit Gatewayでつなごうとしたら、CIDRが重複していてルーティングできない」という失敗は、実務でもSAP試験でも頻出のシナリオです。問題文に「複数のVPCを将来接続する予定」とあれば、IPAMによる一元的なCIDR管理を選択肢として思い出せるようにしておきましょう。