AWSでのインフラ設計、特にVPC（Virtual Private Cloud）の初期サイジングは、後々の運用の運命を分ける極めて重要なフェーズです。
「とりあえず最大サイズの /16 を切っておけば安心だろ」
「足らなくなったらセカンダリCIDRを追加すればいいよね」
もしあなたがAWSの設計レビューでこんな言葉を発したとしたら、現場のシニアエンジニアから鋭いツッコミが飛ぶことでしょう。VPCのIPv4 CIDR設計は、KubernetesのPodネットワーク（CENI）や将来的な他リージョン・オンプレミスとのVPCピアリングを見据えた、極めて緻密なキャパシティプランニングが要求されます。
今回は、AWS VPCにおけるIPv4 CIDRブロックのサイジングの制約、そして禁断の「セカンダリCIDR追加」が現場のネットワークに何をもたらすのか、その深層を紐解いていきましょう。
—
1. VPC CIDRブロックの基本制約：なぜ /16 から /28 なのか
AWSのVPCを作成する際、我々は必ずIPv4のCIDRブロックを指定します。許可されているサイズは RFC 1918 に準拠したプライベートIPアドレス空間（またはパブリックIP空間）であり、プレフィックス長は /16（65,536個のIP）から /28（16個のIP）までです。
許容されるCIDRの境界と「使えないIP」
まず大前提として、AWSのVPC内では、各サブネットの先頭4つと末尾1つの計5個のIPアドレスがAWSによって予約されています。
ネットワークアドレス（先頭）AWS VPCルーター用（先頭から2番目）DNSサーバー用（先頭から3番目。VPCのネットワーク範囲のベースIP + 2）将来の予約用（先頭から4番目）ブロードキャストアドレス（末尾）
これらはユーザーがインスタンスのプライベートIPとして割り当てることはできません。つまり、一番小さな /28 サブネットを切った場合、利用できるのは実質 16 - 5 = 11個 のIPアドレスみとなります。ここにEKS（Amazon Elastic Kubernetes Service）のWorker Nodeをデプロイし、Pod用のアドレス空間を割り当てようものなら、一瞬で枯渇してノードが NotReady に陥る地獄絵図が完成します。
—
2. セカンダリCIDRブロックの罠：追加の仕様とルーティングの現実
「初期サイジングをミスった、あるいは想定以上の急成長でIPが足りない！」
そんなときに検討するのが、既存VPCへのセカンダリCIDRブロックの追加（AssociateVpcCidrBlock）です。
AWSでは、1つのVPCに対して最大5つのCIDRブロック（プライマリ1つ ＋ セカンダリ最大4つ）を関連付けることができます。しかし、ここには実務上見落としがちな強烈な制約と設計上のトラップが存在します。
セカンダリCIDRの主な制約事項
1. RFC 1918の重複禁止：追加できるのは 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 の範囲内ですが、すでにVPC内で使用されている範囲、あるいはAWSの内部予約IPと重複する範囲は追加できません。
2. ルーティングとセキュリティグループの挙動：セカンダリCIDRから切り出したサブネットは、既存のメインルートテーブルやセキュリティグループに対して明示的にルールを追加・調整する必要があります。「CIDRを追加したから勝手に通信できる」わけではありません。
3. VPCピアリング / Transit Gatewayの落とし穴：ここが一番のハマりどころです。他VPCやオンプレミスとVPCピアリングやAWS Transit Gatewayで接続している場合、新しく追加したセカンダリCIDR宛てのルートを、対向側のルートテーブルに手動で追加し忘れるトラブルが後を絶ちません。「一部の通信だけタイムアウトする」という深夜のインシデントの多くはこれが原因です。
—
3. 実務で役立つ：AWS CLIによるCIDRとサブネットの構築・検証フロー
口で言うのは簡単ですので、実際にIaC（TerraformやCloudFormation）やAWS CLIを叩く現場のエンジニア向けに、VPCのCIDR拡張とルートテーブルの整合性を確認・操作する実用的なスクリプトを共有します。
以下のPython（Boto3）スクリプトは、指定したVPCにセカンダリCIDRを追加し、既存のルートテーブルに適切なルートが存在するかを検証・追加する自動化スクリプトの断片です。
import boto3
from botocore.exceptions import ClientError
def add_secondary_cidr_and_route(vpc_id, secondary_cidr, route_table_id, gateway_id):
ec2 = boto3.client('ec2')
try:
# 1. セカンダリCIDRブロックをVPCに関連付け
print(f"VPC ({vpc_id}) にセカンダリCIDR ({secondary_cidr}) を追加しています...")
response = ec2.associate_vpc_cidr_block(
VpcId=vpc_id,
CidrBlock=secondary_cidr
)
association_id = response['CidrBlockAssociation']['AssociationId']
print(f"成功: Association ID -> {association_id}")
# 2. 指定したルートテーブルにセカンダリCIDR向けのルートを追加 (例: TGWやIGW向け)
print(f"ルートテーブル ({route_table_id}) に経路を追加しています...")
ec2.create_route(
RouteTableId=route_table_id,
DestinationCidrBlock=secondary_cidr,
GatewayId=gateway_id # または TransitGatewayId, VpcPeeringConnectionId など
)
print("ルートの追加が完了しました。")
except ClientError as e:
print(f"エラーが発生しました: {e}")
raise
# 実行例（※検証環境でお試しください）
if __name__ == "__main__":
# add_secondary_cidr_and_route(
# vpc_id="vpc-0123456789abcdef0",
# secondary_cidr="100.64.0.0/16", # 例としてCGNAT等で使われる範囲や追加のプライベート空間
# route_table_id="rtb-0123456789abcdef0",
# gateway_id="igw-0123456789abcdef0"
# )
passデバッグ時のTips：パケットの行方を見失ったら
もしセカンダリCIDR内のインスタンスからインターネットや他VPCへの通信が疎通しない場合、以下のコマンドや機能を上から順に確認してください。
1. VPCフローログ（VPC Flow Logs）の確認
REJECT ログが出ている場合、セキュリティグループ（SG）またはネットワークACL（NACL）が原因です。セカンダリCIDRからのトラフィックがSGのインバウンド/アウトバウンドルールに明示的に許可されているか確認します。
2. ルートテーブルの優先度（Longest Prefix Match）
より詳細なサブネットCIDR（例: /24）がセカンダリの大きなブロック（例: /20）に対して正しくルーティングされているか、AWS CLIで確認します。
# VPCのルートテーブル一覧と各ルートのステータスを確認
aws ec2 describe-route-tables \
--filters "Name=vpc-id,Values=vpc-0123456789abcdef0" \
--query "RouteTables[*].[RouteTableId, Routes]" \
--output json—
4. まとめ：SREが推奨するVPCサイジングの黄金律
VPCのIPv4 CIDR設計、およびセカンダリCIDRの追加について解説してきました。現場のシニアとして、後輩のエンジニアたちにいつも伝えている鉄則があります。
- 「最初から十分なサイズ（通常は
/16）を確保する」
クラウドネイティブなワークロードやK8s（Amazon VPC CNI）を導入する場合、IP消費量は設計者の想像の3倍のスピードで増加します。ケチらずに十分な広さを確保しましょう。
- 「セカンダリCIDRはあくまで『緊急避難的措置』と心得よ」
後からのCIDR追加は、ピアリング先の設定変更漏れやルーティングの複雑化を招き、障害時の切り分け難易度を跳ね上げます。セカンダリの追加が必要になった時点で、VPCのアーキテクチャそのものの分割（マルチVPC化やTransit Gatewayによるハブ＆スポーク構成への移行）を真剣に検討するタイミングです。
ネットワークの基盤は、家屋の「地盤」と同じです。地盤がしっかりしていれば、その上に乗るマイクロサービスやコンテナ群はどれだけ複雑であっても安定して稼働します。ぜひ、次回のアーキテクチャ設計では、IPアドレスの枯渇とルーティングの未来図まで見据えたサイジングを行ってください。
コメント