AWS VPCの深淵：IGWを通過するパケットの「素顔」とNATの最適化戦略
クラウドインフラの設計において、AWSの Internet Gateway (IGW) は単なる「出口」ではない。それは、AWSのSDN（Software Defined Networking）が作り出す広大な抽象化レイヤーにおける、最初の「境界線」だ。
今日は、パブリックサブネットに配置された Elastic IP (EIP) を持つインスタンスが、インターネットと通信する際、カーネルの奥底やVPCの内部で何が起きているのか。そして、そのパフォーマンスを極限まで引き出し、セキュリティを堅牢にするための「現場の知見」を共有しよう。
—
1. IGWにおけるNATの物理的・論理的振る舞い
多くのエンジニアは、IGWを「ルーター」と誤解している。しかし、AWSのIGWは、物理的なルーターではなく、VPCの端点に配置された「分散型NATゲートウェイ」だ。
パケットの変容：DNATとSNAT
インスタンスに EIP を割り当てた瞬間、AWSのコントロールプレーンは、そのインスタンスに対する「1対1の静的NAT」をIGWのハードウェア（あるいは高速な仮想スイッチ）にプログラミングする。
- インバウンド (DNAT): インターネットから
EIP宛てに届いたパケットは、IGWで宛先IPがインスタンスのプライベートIPに書き換えられる。この際、Checksumの再計算が行われるのは言うまでもない。 - アウトバウンド (SNAT): インスタンスから送信されたパケットは、IGWを通過する際、送信元IPがプライベートIPから
EIPに書き換えられる。
ここで重要なのは、この変換が「ステートレス」に見えて、実はIGWの内部では Connection Tracking (Conntrack) が高度に最適化されて機能している点だ。
—
2. パフォーマンスのボトルネック：TCPバッファとRTTの最適化
大規模なトラフィックを捌く際、デフォルトのLinuxカーネル設定ではIGWのポテンシャルを殺してしまうことが多い。特に TCP Window Scaling は必須の設定だ。
sysctl.confによるカーネルチューニング
高遅延・高帯域な環境では、以下のチューニングを適用し、TCPのフロー制御を最適化する。
# /etc/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
# TCPウィンドウサイズを自動調整
net.ipv4.tcp_window_scaling = 1
# パケットロス耐性を高めるための再送制御
net.ipv4.tcp_retries2 = 5これにより、RTT（Round Trip Time）が多少不安定な環境でも、スループットの急落を防ぐことができる。
—
3. セキュリティ：IGWを通過するパケットの脆弱性と防御
IGWは公開されているため、常にスキャンやDDoS攻撃の標的となる。ここで重要なのが Security Group (SG) と Network ACL の二段構えの防御だ。
なぜNetwork ACLは「エフェメラルポート」が重要なのか
Security Group がステートフルであるのに対し、Network ACL はステートレスだ。したがって、返信用のパケットを許可するために、必ず エフェメラルポート (1024-65535) を開けておく必要がある。
これを怠ると、インスタンスからインターネットへの通信は成功しても、戻りのパケットが破棄されるという「疎通不可」の泥沼に陥る。
# 推奨されるNACLインバウンド設定（返信パケットを通す）
# ルール番号 100: TCPカスタム (エフェメラルポート)
# ソース: 0.0.0.0/0
# ポート範囲: 1024-65535—
4. TLSハンドシェイクとヘッダー圧縮の現在地
現代の通信において、パケットのペイロードよりも「TLSのオーバーヘッド」がRTTに与える影響の方が大きい。
- TLS 1.3の活用: 1-RTTでのハンドシェイクを実現するTLS 1.3は、IGW越しの通信において劇的な改善をもたらす。
- HTTP/3 (QUIC) の導入: UDPベースのQUICを採用することで、TCPのHead-of-Line Blocking（先頭ブロック問題）を回避し、パケットロス時の影響を最小化できる。
もしAPIサーバーを運用しているのであれば、Nginx等のリバースプロキシで h2c や QUIC を有効化し、クライアントとの通信を可能な限り効率化することを強く推奨する。
# Nginx設定例：HTTP/3を有効化する最小構成
listen 443 quic reuseport;
listen 443 ssl http2;
# QUIC用ヘッダーの追加
add_header Alt-Svc 'h3=":443"; ma=86400';—
結びに代えて：ネットワークは「生き物」である
IGWを通じたNATは、AWSが提供する最も基本的な機能の一つだが、その背後には膨大なネットワークエンジニアリングの英知が詰まっている。
「とりあえず繋がった」で満足せず、パケットがどのインターフェースを通り、どのレイヤーで処理されているのかを常に想像すること。それが、トラブルが起きた時に「勘」ではなく「論理」で解決できる、真のエンジニアへの近道だ。
ネットワークは常に変化し続ける。だからこそ、我々SREは、その変化を観察し、最適化し、安全を守り続ける義務がある。次のデプロイでは、ぜひカーネルの統計値に目を向けてみてほしい。そこには、まだ見ぬボトルネックのヒントが隠されているはずだ。
コメント