Transit GatewayによるNAT集約の「深淵」——スループットの物理的限界とパケットの旅路
クラウドアーキテクチャの設計において、「Egress（外向き通信）のコスト最適化」と「セキュリティの統合」を追求した結果、多くの現場がたどり着くのが AWS Transit Gateway (TGW) を用いた「NATゲートウェイ（NATGW）集約」という設計パターンです。
しかし、このアーキテクチャは一見エレガントに見えて、その裏側ではパケットが過酷な旅を強いられています。今回は、この構成におけるスループットの物理的上限と、パケットが陥る「非対称ルーティング」という呪い、そしてそれを打破するためのカーネルチューニングについて、SREの視点から深掘りします。
—
1. TGW集約の物理的制約：それは「ボトルネック」か「期待値」か
TGWを経由して集約NATGWへトラフィックを流すとき、多くのエンジニアが直面するのは「なぜかスループットが10Gbps（あるいはそれ以下）で頭打ちになる」という現象です。
これはAWS側の制限以上に、NATGWそのものの「ENIに対するスループット制限」と、TGWのパフォーマンスモードが複合的に影響しています。
パケットの過酷な旅
1. Source VPC から出たパケットは、TGWのAttachmentを通過し、TGW内の論理的なスイッチングファブリックを横断します。
2. Inspection VPC（NATGWがあるVPC） に到達し、NATGWのENIに届くまでに、パケットはカプセル化とデカプセル化のオーバーヘッドを経験します。
3. NATGW自体は、現時点で「1つのENIあたり最大10Gbps」という物理的な制約を抱えています。
もし、数百のインスタンスから一気にリクエストが飛べば、NATGWのポート枯渇（SNATのIP/ポート不足）と、この10Gbpsという帯域幅の壁が、TCPの再送制御を激しく誘発します。
—
2. 非対称ルーティングの呪いを解く
TGWを経由する際、最も恐ろしいのは戻りのパケットが意図しないルートを辿ることです。特に、戻りのトラフィックがTGWを介さずに直接VPCピアリングや別のルートへ戻ろうとした場合、ステートフルなファイアウォール（Security GroupやNACL）は、セッション開始のハンドシェイクを感知していないため、戻りのパケットをDropします。
回避策：静的ルートの強制
これを防ぐには、TGWのルートテーブルを「厳格な分離」と「強制ルーティング」で設計する必要があります。
- Inspection VPCのルートテーブル: デフォルトルートをTGWに向ける。
- 各VPCのルートテーブル: 外向きトラフィックはすべてTGWのIDへルーティングし、戻りトラフィックがTGW以外の経路を絶対に取らないように
0.0.0.0/0をピンポイントで制御する。
—
3. カーネルレベルの最適化：TCPスタックの極意
NATGWが集約されると、通信量は劇的に増大します。クライアント側でのTCP接続効率を最大化しなければ、NATGWのポート不足は避けられません。ここでSREが打つべき一手は、sysctl によるカーネルチューニングです。
以下のパラメーターは、大量のEgress通信を行うコンテナホスト（ノード）で適用を検討すべき設定値です。
# TCP接続の急増に備え、TIME_WAIT状態のソケットを再利用可能にする
# これを有効にしないと、NATGWのポートがすぐに枯渇する
sysctl -w net.ipv4.tcp_tw_reuse=1
# ローカルポートの範囲を拡大。最大値に近い65535まで開放する
sysctl -w net.ipv4.ip_local_port_range="1024 65535"
# TCPバッファを拡大し、RTTが大きい通信でもスループットを維持する
# 帯域幅遅延積（BDP）を考慮した値に設定する
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"TLSハンドシェイクの「重み」を消す
TLS 1.3が普及した現在、ハンドシェイクの往復回数は減りましたが、それでも「最初の1バイト」が届くまでの遅延は致命的です。NATGW集約構成では、HTTP/2 または HTTP/3 (QUIC) の利用を必須とすべきです。
特に HTTP/2 の多重化（Multiplexing）を活用することで、1つの接続で複数のリクエストを捌き、NATGWのSNATテーブルへの負荷を劇的に削減できます。
—
4. 脆弱性回避と監視の要諦
最後に、セキュリティの視点です。NATGWは「外に出る通信」のゲートウェイですが、同時に「侵入の踏み台」にもなり得ます。
- Flow Logsの分析: TGWの
Flow Logsを有効化し、REJECTされているパケットを可視化してください。非対称ルーティングが発生している場合、ここが真っ先に赤く染まります。 - ヘッダー圧縮とセキュリティ: HTTPヘッダー圧縮（HPACK）はリソースを節約しますが、悪意あるパケットによる「HPACK Bomb」攻撃に対しては、リバースプロキシ（Envoy等）側でバッファサイズの制限を設けるのが鉄則です。
アーキテクトへの提言
NATGW集約は「管理のシンプル化」と引き換えに、「ネットワークの集中」を生みます。もしあなたのサービスが、10Gbpsを恒常的に超えるようなトラフィックを抱えているなら、NATGWによる集約ではなく、VPC Endpoint (PrivateLink) の活用を第一選択肢にしてください。
NATGWはインターネットへの出口ですが、クラウドネイティブな構成において、外部APIとの通信は可能な限りVPC内（プライベートリンク経由）で完結させるべきです。それが、パケットの旅路を最短にし、我々SREの夜間対応を減らす唯一の道なのです。
—
*「ネットワークは正直だ。設計の歪みは、必ずパケットの遅延とドロップという形で現れる。」* — 本日の現場より。
コメント