NATゲートウェイは「魔法の箱」ではない：マルチAZ設計とパケットの裏側で起きていること
クラウドアーキテクトとして多くの設計レビューに立ち会う中で、最も軽視されがちなのが「NATゲートウェイ（NAT GW）のアーキテクチャ」だ。AWSドキュメントには「可用性が高い」と書かれているが、そこには物理的な境界線とパケットの旅路という、泥臭い現実が存在する。
今日は、NAT GWの冗長化がもたらすトレードオフと、その裏側にあるカーネルレベルの挙動、そして極限のパフォーマンスを引き出すためのチューニングについて深掘りしていく。
—
1. NAT GWの冗長化：AZ間フェイルオーバーの「真実」
まず大前提として、NAT GWは「そのAZ（アベイラビリティゾーン）に閉じたリソース」である。これを理解していない設計は、障害時に致命的な脆弱性を露呈する。
マルチAZ構成を組む際、各プライベートサブネットのルートテーブルには、必ず「そのAZのNAT GW」を指定しなければならない。もしAZ AのNAT GWがダウンした場合、AWSのマネージドサービスとして自動復旧を待つか、ルートテーブルを動的に書き換える必要がある。
なぜ「クロスAZトラフィックコスト」を恐れるべきか
NAT GWを全AZに配置せず、単一AZに寄せてコストを削減しようとする設計者がいる。だが、これはネットワークパケットにとって「無駄な旅」を強いることになる。
- レイテンシの増大: パケットはAZを跨ぐたびに、物理的な距離とルーターのホップを経由する。ミリ秒単位のRTT（Round Trip Time）が積み重なれば、TCPのSlow Startフェーズでウィンドウサイズが拡大しきれず、スループットは頭打ちになる。
- データ転送料金: AZ間転送には明確な課金が発生する。高トラフィックなサービスでは、NAT GWの利用料以上に、この「見えない転送料金」が請求書を破壊する。
—
2. パケットレベルの深層：TCPバッファとNATの相性
NAT GWは、内部的に巨大な conntrack テーブル（接続追跡テーブル）を保持している。プライベートIPからパブリックIPへの変換時、5タプル（送信元IP/Port、宛先IP/Port、プロトコル）を維持するために、このテーブルがフル稼働する。
ここで重要なのが、クライアント側（EC2）のカーネルパラメータ設定だ。NAT GWを介する通信では、以下のTCPチューニングがパフォーマンスの分水嶺となる。
# /etc/sysctl.conf に記述すべき最適化パラメータ
# TCPウィンドウのスケーリングを有効化し、帯域幅を最大化する
net.ipv4.tcp_window_scaling = 1
# NAT GWでの接続滞留を防ぐため、FIN-WAIT状態のタイムアウトを短縮
net.ipv4.tcp_fin_timeout = 15
# 高負荷時にNATのコネクション追跡限界に達しないようバッファを拡張
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216これらの設定は、NAT GWという「中継点」において、パケットがバッファ溢れを起こして再送（Retransmission）が発生するのを防ぐための防衛策だ。特に高頻度なAPIコールを行うマイクロサービスでは、tcp_fin_timeout の短縮は必須の嗜みである。
—
3. TLSハンドシェイクの最適化とレイテンシ削減
NAT GWを通過するパケットの9割以上はTLS通信だろう。TLSハンドシェイクにおいて、NAT GWを跨ぐRTTは「致命的な遅延」となる。
- TCP Fast Open (TFO): 可能であればサーバー/クライアント間でTFOを有効化し、ハンドシェイクの往復回数を減らす。
- TLS 1.3の採用: TLS 1.3はハンドシェイクを1往復に短縮している。NAT GWを通る際、往復回数が減ることは、単なるスピード向上以上の意味を持つ（NATコンテキストの保持時間を減らせるため）。
—
4. セキュリティ専門家への警告：NATの脆弱性と対策
NAT GWを経由する通信において、最も見落とされがちなのが「ポート枯渇」によるDoSリスクだ。単一のNAT GWにトラフィックを集中させすぎると、接続が確立できなくなる。
推奨される監視メトリクス
AWS CloudWatchで以下のメトリクスを監視し、しきい値を超えたらアラートを飛ばす、あるいはNAT GWを増設するフローを構築せよ。
ErrorPortAllocation: ポート割り当て失敗数。これが0以外なら、そのNAT GWは既にキャパシティオーバーだ。ActiveConnectionCount: NAT GWのセッション数。
セキュリティの極意：Egressトラフィックの可視化
NAT GWはあくまで「出口」だ。ここを通る全通信を、VPC Flow Logsで監視することは当然として、可能であれば「AWS Network Firewall」をNAT GWのサブネットに配置し、FQDNベースでホワイトリスト制御を行うべきだ。IPベースのACLでは、現代の動的なクラウド環境は守りきれない。
—
結び：インフラは「静的な構築物」ではない
NAT GWの冗長化は、コストを払って「平穏な眠り」を買う行為である。AZを跨いだ通信が引き起こす隠れたコストやレイテンシを理解し、カーネルレベルのチューニングでそれを補う。これが、現場で戦うSREの矜持というものだ。
教科書的な設計図をそのまま適用するのではなく、パケットが今この瞬間、どのAZを通り、どのNAT GWで変換され、どれだけの時間がかかっているか。その感覚を研ぎ澄ませることが、堅牢なクラウドインフラを作り上げる唯一の道である。
コメント