雲の上の論理回路：VPCの本質と、パケットを極限まで加速させるための深層設計
AWSのコンソールで「VPCを作成」ボタンを押すとき、多くのエンジニアは単なる「ネットワークの囲い」を作っていると錯覚しがちだ。しかし、それは大きな誤解だ。我々が対峙しているのは、物理的な制約から解き放たれ、SDN（Software Defined Networking）の抽象化レイヤーで制御される、極めて高度で動的な論理的隔離空間である。
今日は、教科書的な「サブネットの作り方」の話は飛ばそう。その先にある、パケットがVPCの境界をどう駆け抜け、レイテンシを削り出し、セキュリティを担保するのか。現場のSREとして避けては通れない「深層の設計論」を紐解いていく。
—
1. 論理的隔離の正体とCIDRの「静かなる設計」
VPCにおけるCIDRブロックの割り当ては、単なるIPアドレスの在庫管理ではない。それは、AWSのバックボーンネットワーク上における「ルーティングテーブルの集約効率」を決定づける行為だ。
設計の肝は、将来の拡張性と「ルート集約（Route Aggregation）」への配慮にある。VPC内のサブネットを 10.0.0.0/16 の中に収める際、最小限のCIDRで分割しようとする者がいるが、それは罠だ。可用性ゾーン（AZ）を跨いだトラフィックのルーティングコスト、そして何よりAWS Direct ConnectやVPNを経由したオンプレミスとの接続を考慮すると、CIDRの境界は「境界ルーターのルーティングテーブル」を汚さないよう、ビット境界で適切に揃えるのがプロの流儀だ。
2. パケットレベルの挙動：IGWとNATの背後にある暗黒大陸
パブリックサブネットにある Internet Gateway (IGW) を通るパケットは、単にルーティングされているわけではない。IGWは、VPC外との通信において、宛先IPがAWSパブリックIP空間にある場合にのみ反応する「論理的な変換ゲート」だ。
ここで注意すべきは、NAT Gateway を利用するプライベートサブネットの挙動だ。プライベートサブネットのインスタンスから外へ出るパケットは、一度NAT Gatewayのネットワークインターフェース（ENI）で SNAT され、送信元IPがNAT Gatewayのものに書き換えられる。
パフォーマンスチューニング：TCPバッファとRTTの最適化
高トラフィックな環境では、デフォルトのTCPスタック設定ではすぐにボトルネックが発生する。特にVPC内の通信では、カーネルのTCPウィンドウサイズを明示的にチューニングすることで、スループットを劇的に改善できる。
# /etc/sysctl.conf に以下のパラメータを適用し、大容量通信時のパケット廃棄を防ぐ
# TCPウィンドウサイズを拡張し、BDP（Bandwidth Delay Product）を最適化
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 = 5000RTT（Round Trip Time）の削減には、TCP Fast Open の有効化も検討すべきだ。ハンドシェイクの往復回数を減らすことで、TLSネゴシエーション開始までの時間を数ミリ秒単位で削り取れる。
3. セキュリティという名の「論理的フィルタリング」
セキュリティグループ（SG）とネットワークACL（NACL）の使い分けに迷う必要はない。NACLは「サブネットの入り口におけるステートレスな門番」であり、SGは「NICに直結したステートフルな盾」だ。
極限のパフォーマンスを追求するなら、NACLは最小限の許可ルールのみを記述し、複雑な制御はSGに集約させるべきだ。なぜなら、NACLはパケットをパースするたびにルールを上から順に評価するコストが発生するからだ。一方、SGは接続追跡（Conntrack）テーブルを参照するため、一旦確立された通信は、次のパケットから高速にパスされる。
セキュリティの深層：TLSハンドシェイクの最適化
ネットワーク層でパケットを最適化しても、TLSハンドシェイクが遅ければ意味がない。特にAWS内部のマイクロサービス間通信であれば、TLS 1.3 の採用は必須だ。0-RTT（Zero Round Trip Time）ハンドシェイクを有効にすることで、再接続時の遅延を限りなくゼロに近づけることができる。
また、もしVPCエンドポイント（AWS PrivateLink）を使用しているならば、トラフィックはVPCの境界を越えず、完全にAWSのプライベートネットワーク内で完結する。これはインターネットを経由しないというセキュリティ上の利点だけでなく、レイテンシのジッター（揺らぎ）を極限まで排除できるという強みがある。
4. 総括：クラウドインフラにおける「職人芸」
VPCの設計は、一度構築して終わりではない。トラフィックの特性（TCPかUDPか、短命なコネクションか長期間のストリーミングか）に応じて、カーネルパラメータを調整し、エンドポイントを最適配置し、ルーティングのパスを最短化する。
ネットワークは生き物だ。パケットの旅路を可視化し、VPCフローログの解析結果から「なぜそのパケットがそこでリトライしているのか」を読み解く能力こそが、現代のインフラアーキテクトに求められる真のスキルセットである。
次回は、これらの知見を踏まえ、Transit Gatewayを用いた大規模マルチVPC環境におけるルーティングの魔境と、その解決策について深掘りしていこうと思う。ネットワークの深淵を覗く準備はできているか？
コメント