VPCのCIDR設計は「運命」を決める：枯渇と拡張の境界線を歩くエンジニアへ
VPCを作成する際、多くのエンジニアが「とりあえず /16 で切っておけば将来的に困らないだろう」という安易な選択に走ります。しかし、大規模な分散システムやマイクロサービスを運用する現場において、その「とりあえず」は後に地獄のような負債となって跳ね返ってきます。
今日は、AWSのVPC設計におけるCIDRサイジングの哲学と、セカンダリCIDRが抱える「パケットレベルの影」について、深層まで掘り下げていきましょう。
—
1. CIDRサイジングの美学：なぜ /16 は「広すぎる」のか
多くのAWSユーザーがデフォルトで選ぶ /16 (65,536アドレス) は、確かに余裕があります。しかし、インフラアーキテクトとして意識すべきは、「ルーティングテーブルの複雑性とセキュリティグループの管理コスト」です。
広すぎるアドレス空間は、セキュリティ境界（サブネット）を曖昧にします。例えば、一つのVPC内で開発環境と本番環境をCIDR範囲で論理的に分割し、NACL（ネットワークACL）で制御しようとした際、CIDRが広すぎるとCIDRブロックベースのルールが複雑化し、ヒューマンエラーによる設定ミスを誘発します。
パフォーマンスとMTUの最適化
ネットワーク設計で忘れられがちなのが、MTU とパケット断片化の関係です。VPC内部で巨大なCIDRを確保し、その上でオーバーレイネットワーク（KubernetesのPodネットワークなど）を走らせる場合、VXLAN等のカプセル化によってオーバーヘッドが生じます。
# インスタンス内でMTUを確認し、必要に応じて調整する
# パケットが断片化すると、TCPハンドシェイクの遅延だけでなく、
# CPUの割り込み処理負荷が増大し、スループットが低下する
ip link show eth0 | grep mtu
# 1500から1400へ下げ、カプセル化の余地を確保する例
sudo ip link set dev eth0 mtu 1400—
2. セカンダリCIDRの「甘い誘惑」と禁断の果実
「IPが足りなくなった。セカンダリCIDRを追加しよう」。この決断には慎重を期す必要があります。AWSにおいてセカンダリCIDRは、メインのプライマリCIDRと並列で存在しますが、いくつかの重大な制約があります。
セカンダリCIDRの落とし穴
1. セキュリティグループの制約: 一部の機能（特に古いインスタンスタイプや特定のプロトコル）で、プライマリCIDRとセカンダリCIDRの間の通信が期待通りにフィルタリングされないケースが稀にあります。
2. ルート伝播の複雑化: Direct ConnectやTransit Gatewayを使用している場合、セカンダリCIDRの経路情報が適切に広告されないと、オンプレミスとの通信がブラックホール化します。
3. セキュリティグループの「最大数」: 1つのネットワークインターフェース（ENI）に割り当てられるIP数には上限があります。セカンダリCIDRを追加しても、ENIごとの制約は解消されません。
—
3. TCPバッファとRTT削減：極限のチューニング
大規模な通信をさばく場合、ネットワーク層の設計だけでなく、OSカーネルレベルのチューニングも不可欠です。VPC内での通信は高速ですが、広域ネットワークを跨ぐ場合、TCP Window Scaling がボトルネックになります。
パケットがネットワークを駆け巡る際、帯域幅遅延積（BDP）を考慮したバッファ設定がパフォーマンスの鍵を握ります。
# sysctl.confによるTCPバッファの最適化
# 高速なネットワーク環境下でのスループットを最大化する
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 送信キューの長さを調整し、バーストトラフィックに備える
net.core.netdev_max_backlog = 5000また、セキュリティの観点から TLS 1.3 への強制移行を推奨します。TLS 1.3 はハンドシェイクのラウンドトリップを1回に短縮し、RTTが重要なクラウドインフラにおいて劇的なレイテンシ改善をもたらします。
—
4. 現場の知見：設計時に守るべき「3つの鉄則」
最後に、私が多くのプロジェクトを救済する中で確信している「設計の鉄則」を共有します。
1. CIDRは「疎」に設計せよ: 将来的なVPCピアリングやTransit Gateway接続を想定し、CIDRブロックが重複しないよう、社内全体でIPアドレス管理表を厳格に運用すること。
2. サブネットは小さく、明確に: 運用しやすい「機能単位（Public/App/DB）」でサブネットを分け、それぞれに最小限のCIDRを割り当てる。これにより、NACLによる防御が強固になります。
3. ログの可視化を怠るな: VPC Flow Logs を必ず有効化し、特に拒否されたパケット（REJECT）を監視してください。これは、CIDR設計ミスによる疎通障害を即座に検知する唯一の手段です。
最後に
ネットワーク設計は、一度デプロイしてしまえば修正に莫大なコストがかかります。パケットが IGW を抜け、ENI に到達し、カーネルのスタックで処理されるまでのフローを常に頭に描きながら、静かに、しかし大胆に設計してください。
インフラは、目に見えない部分にこそ魂が宿るのです。
コメント