境界を越えるパケットの矜持：VPCピアリングが隠す「非推移的」という制約と最適化の深淵
クラウドアーキテクトとして数多の障害現場に立ち会う中で、最も「なぜ繋がらないのか」という絶望的な問いを生むのが、このVPCピアリングだ。VPCピアリングは、クラウドの広大なネットワークにおいて、物理的な距離を超えて論理的な近接性を生み出す強力なツールだが、その本質を理解せずに設定を弄れば、瞬く間にパケットは迷宮入りする。
本稿では、教科書的な手順を超え、パケットがVPCの壁をどう突き抜けるのか、そしてなぜ我々が「非推移性」という足枷に苦しめられるのかを、SREの視点から紐解いていく。
—
1. パケットが辿る不可視の道：非推移的接続の物理的制約
VPCピアリングを語る上で避けて通れないのが「非推移的（Non-transitive）」という設計指針だ。VPC AとVPC Bを繋ぎ、VPC BとVPC Cを繋いでも、VPC AからVPC Cにはパケットは届かない。これは単なる仕様ではなく、クラウド基盤のデータプレーンにおけるルーティング・ループを物理的に回避するための防波堤である。
パケットがVPCピアリングを通過する際、ハイパーバイザーは送信元が許可されたCIDRブロックからのものか、そして宛先がピアリング接続を介して到達可能かを厳格に検証する。ここで、重複するCIDRブロックが存在すれば、ルーティングテーブルはどちらのインターフェースへパケットを投げるべきか判断できず、パケットは即座にドロップされる。
ピアリング確立時のルーティング更新要件
ピアリングは「接続を作っただけ」では不十分だ。両端のルートテーブルに、相手先ネットワークへの経路を明示的に記述しなければならない。
# AWS CLIによるルートテーブル更新の例
# VPC Aのルートテーブルに、VPC B（10.2.0.0/16）への経路を追加する
aws ec2 create-route \
--route-table-id rtb-12345678 \
--destination-cidr-block 10.2.0.0/16 \
--vpc-peering-connection-id pcx-0abcdef1234567890
# パケットはこのルート定義を基に、ピアリング接続という仮想的な「パイプ」へ射出される—
2. パフォーマンスの深淵：RTT削減とTCPウィンドウのチューニング
VPC間通信において、最も懸念すべきはレイテンシ（RTT）の増大とスループットの低下だ。特にマルチリージョンや高負荷な分散システムでは、TCPの3ウェイ・ハンドシェイクが大きなコストとなる。
TCPバッファの最適化
デフォルトのカーネルパラメータは、汎用的な通信には適していても、高速なVPC間通信には力不足だ。帯域幅遅延積（BDP = Bandwidth × Delay Product）を考慮し、送受信バッファを拡大する必要がある。
# /etc/sysctl.conf に記述すべきパフォーマンスチューニング
# 高帯域・長距離通信におけるウィンドウサイズを最大化する
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCPウィンドウのスケーリングを有効化（必須）
net.ipv4.tcp_window_scaling = 1これにより、ピアリング越しであっても、TCPの輻輳制御アルゴリズム（特にBBRなど）が帯域を最大限に活用できるようになる。
—
3. セキュリティの要諦：トランスポート層の硬化
ピアリングはあくまでプライベートネットワーク内の接続であるが、ゼロトラストの観点からは「ピアリング内は安全」という神話は捨て去るべきだ。VPC内部のトラフィックであっても、中間者攻撃や意図しないプロトコルによる通信を想定すべきである。
TLSハンドシェイクの最適化と強制
ピアリング接続上の通信であっても、アプリケーション層では必ず TLS 1.3 を強制し、0-RTT（Zero Round-Trip Time Resumption）を利用してハンドシェイクを短縮する設計を推奨する。
- ヘッダー圧縮の活用: HTTP/2またはHTTP/3 (QUIC) を採用することで、
HPACKやQPACKによるヘッダー圧縮を行い、ピアリング帯域の負荷を軽減する。 - 脆弱性回避: ピアリング越しにロードバランサーを介す際は、必ず
Security Groupで送信元・送信先のポートを443等の必要最小限に絞ること。広範なCIDRの許可は、内部ネットワークにおける「ラテラルムーブメント（横展開）」の格好の足場となる。
—
4. SREからの警告：死角を可視化せよ
最後に、運用上の注意点として「疎通確認の罠」を挙げたい。ping（ICMP）が通るからといって、アプリケーション通信が成功するとは限らない。
1. MTUの不一致: VPC間ではMTU 1500バイトが標準だが、VPNやオーバーレイネットワークを併用する場合、フラグメンテーションが発生し、パケットが消失することがある。Path MTU Discovery を正しく機能させる設定を忘れてはならない。
2. フローログによる追跡: トラブル時は必ず VPC Flow Logs を確認せよ。パケットが REJECT されているのか、それとも ACCEPT されているのにパケットが届いていないのか。この区別こそが、熟練のSREと初心者を分かつ境界線だ。
ネットワークは、構築した瞬間に完成するものではない。パケットの流れを想像し、ボトルネックを予測し、泥臭いログ解析を通じて初めて「信頼できる基盤」へと昇華される。VPCピアリングは、そのための最も基本的かつ奥深いキャンバスなのだ。
コメント