AWS VPC CIDR 設計 — 環境ごとに分けるべき理由と実践パターン

staging と production で同じ VPC CIDR（例: 10.0.0.0/16）を使っていると、普段は問題なくても将来的にハマるポイントがある。

同一 CIDR で起きる問題

• VPC Peering / Transit Gateway が張れない — AWS は重複 CIDR 同士の接続を拒否する
• VPN 接続時の混乱 — ローカルから両環境に同時接続すると 10.0.100.10 が stg か prod か区別できない
• SSH config で IP ワイルドカードが使えない — Host 10.0.100.* と書いても環境を分離できない

よくある CIDR 設計パターン

第2オクテットで環境を識別するのが一般的:

環境	VPC CIDR	IP 範囲
Production	10.0.0.0/16	10.0.x.x
Staging	10.1.0.0/16	10.1.x.x
Development	10.2.0.0/16	10.2.x.x
Shared Services	10.10.0.0/16	10.10.x.x

この設計なら、IP アドレスを見ただけでどの環境か判別できる。

SSH config での実感

bastion 経由で private subnet のサーバーに接続する場合、CIDR が分かれていれば:

# Staging（10.1.x.x）
Host bastion-stg
  HostName <STAGING_BASTION_EIP>
  User ec2-user
  IdentityFile ~/.ssh/staging-key.pem

Host 10.1.*
  User ec2-user
  IdentityFile ~/.ssh/staging-key.pem
  ProxyJump bastion-stg

# Production（10.0.x.x）
Host bastion-prod
  HostName <PRODUCTION_BASTION_EIP>
  User ec2-user
  IdentityFile ~/.ssh/prod-key.pem

Host 10.0.*
  User ec2-user
  IdentityFile ~/.ssh/prod-key.pem
  ProxyJump bastion-prod

IP ワイルドカードだけで環境が分離できるので、誤接続のリスクが減る。

既存環境を変えるべきか

CIDR 変更は VPC 再作成 + 全リソース移行になるため、コストが大きい。以下の条件に該当しなければ急ぐ必要はない:

• 環境間を Peering / TGW で接続する予定がある
• VPN で複数環境に同時接続したい
• IP アドレスベースで環境を判別する運用がある

該当しなければ「次に VPC を作り直す機会に分ける」で十分。