本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第3章　複雑な組織のネットワーク設計　·　レッスン12

VPC設計とCIDR計画 ― 大規模での重複回避・アドレス設計・拡張性

導入

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"]

読んでみよう

「VPCピアリングやTransit Gatewayでつなごうとしたら、CIDRが重複していてルーティングできない」という失敗は、実務でもSAP試験でも頻出のシナリオです。問題文に「複数のVPCを将来接続する予定」とあれば、IPAMによる一元的なCIDR管理を選択肢として思い出せるようにしておきましょう。