NATゲートウェイか、インスタンスか：その「境界線」に潜むパケットの真実
クラウドインフラの設計において、プライベートサブネットから外部へのセキュアな出口を確保することは、単なる「疎通確認」以上の意味を持つ。パッチ適用、外部API連携、あるいはコンテナイメージのプル。これらの通信をどう制御するかは、システムの信頼性とコスト、そして何より「ネットワークの透明性」を左右する重大な意思決定だ。
今日は、AWSの NAT Gateway（マネージドサービス）と、古き良き NAT Instance（EC2）の深淵に触れつつ、パケットがトランスポート層で何を経験しているのか、その技術的内実を紐解いていきたい。
1. 内部挙動の解剖：マネージド vs インスタンス
NAT Gatewayのブラックボックス
AWSの NAT Gateway は、マネージドという名の「最適化されたブラックボックス」だ。内部的には、巨大な分散システムとして実装されており、パケットは透過的に処理される。しかし、ここには重要な制約がある。NAT Gateway は TCP のコネクションを追跡する stateful な設計だが、ポートの枯渇や TCP タイムアウトの挙動は、ブラックボックスゆえにチューニングの余地が少ない。
NAT Instanceの「生のLinux」
対して NAT Instance は、我々が iptables や nftables を駆使して制御できる「生のカーネル」だ。ここで重要なのは、netfilter の接続追跡（conntrack）テーブルのサイズである。
# conntrackテーブルの上限確認
sysctl net.netfilter.nf_conntrack_max
# 負荷が高い環境では、以下のようにチューニングする
# カーネルパラメータを調整して接続数を稼ぐ
sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=432000NAT Instance を採用する最大の利点は、TCP バッファの直接チューニングが可能である点だ。RTT（Round Trip Time）が長い環境では、TCP Window Scaling を適切に設定することで、スループットを劇的に改善できる。
2. トランスポートセキュリティとハンドシェイクの最適化
パケットがNATを通過する際、最もコストがかかるのは TLS ハンドシェイクだ。特にプライベートサブネットからの通信が頻発する場合、コネクションの再利用が死活問題となる。
TCP Fast Open (TFO) の活用
TCP Fast Open を利用すれば、ハンドシェイクの往復回数を減らし、TLS 1.3 と組み合わせることで、0-RTTの恩恵を最大限に享受できる。
# LinuxカーネルでTCP Fast Openを有効化
# 1: クライアント側, 2: サーバー側, 3: 両方
sysctl -w net.ipv4.tcp_fastopen=3NAT Gateway を使用する場合、これらの低レイヤー設定はAWS側に委ねられる。しかし、クライアント（プライベートサブネット上のEC2）側で tcp_tw_reuse などを適切に設定し、TIME_WAIT 状態のソケットを再利用可能にしておくことは、インフラエンジニアの嗜みだ。
3. 冗長化の設計と「切り戻し」の哲学
NAT Gateway はアベイラビリティーゾーン（AZ）ごとに構築する必要がある。高可用性を担保するには、AZまたぎのルーティングが必須だ。
一方、NAT Instance を冗長化する場合、Keepalived や VRRP を用いた浮動IPの制御が一般的だが、クラウド環境では Route Table の書き換えをAPI（replace-route）経由で行うアーキテクチャが最も堅牢だ。
PythonによるRouteテーブル自動切り替えの断片
import boto3
def failover_nat(route_table_id, instance_id):
ec2 = boto3.client('ec2')
# 特定の宛先（0.0.0.0/0）のターゲットを新しいNATインスタンスへ向ける
ec2.replace_route(
RouteTableId=route_table_id,
DestinationCidrBlock='0.0.0.0/0',
InstanceId=instance_id # 新しいNATへ切り替え
)
# これにより、パケットのフローが即座に切り替わる4. 現場の教訓：パケットが落ちる場所
筆者が現場で遭遇する最も厄介なトラブルは、MTU ミスマッチによるパケットロスだ。NAT Instance を自作する場合、ENI の MTU を 9001（ジャンボフレーム）に設定しつつ、インスタンス内部のインターフェースがそれに追従できていないケースが後を絶たない。
- MTU 1500の壁: 多くのパケットは標準で1500だが、オーバーレイネットワークや特定のトンネリングを使用する場合、ヘッダー分を計算に入れて
1450程度まで下げないと、断続的に通信が切れる「不可解なパケットロス」に見舞われる。
結論：どちらを選ぶべきか
- スケーラビリティと運用負荷を優先するなら
NAT Gateway一択。 - 運用コストを最小化し、AWSのバックボーンの恩恵を受ける。
- 極限のレイテンシチューニングや、セキュリティプロキシ（squid等）の透過的な挿入が必要なら
NAT Instance。 - ただし、これは「運用という名の茨の道」を歩む覚悟が必要だ。
ネットワークは「繋がって当たり前」の世界だが、その裏側で何億ものパケットがどうヘッダーを書き換えられ、どうルーティングされているのかを想像できるエンジニアだけが、真に堅牢なインフラを設計できる。
今日からあなたのネットワークスタックを sysctl で少しだけ覗いてみてほしい。そこには、OSが積み重ねてきた最適化の歴史が刻まれているはずだ。
コメント