NATゲートウェイの「AZ跨ぎ」という名の見えないコストと、その先にあるレイテンシの真実
クラウドアーキテクチャを設計する際、多くのエンジニアが直面する「NATゲートウェイ（NAT GW）をどう配置するか」という問い。これは単なるコスト計算の問題ではありません。パケットが物理的な距離をどう旅し、カーネルのスタックをどう通過するかという、ネットワークレイヤーの深淵に触れる意思決定なのです。
本稿では、コスト効率と可用性、そしてパフォーマンスのトライアングルをどう解くべきか、泥臭い現場の視点から掘り下げます。
—
1. 忌まわしき「AZ間データ転送コスト」の正体
AWS等のクラウドにおいて、NAT GWを単一のAZに集約し、他AZのプライベートサブネットからトラフィックを集中させる構成は、教科書的には「コスト削減」に見えます。しかし、実運用においては「AZ間データ転送コスト（Cross-AZ Data Transfer）」という名の隠れた税金が発生します。
パケットがAZ-AからAZ-BのNAT GWへ向かう際、クラウドプロバイダーのバックボーンネットワークを物理的に横断します。この転送単価は決して無視できる額ではありません。特に、マイクロサービスが外部APIと頻繁に通信する場合や、ログのストリーミング、大量のTLSハンドシェイクを繰り返すアーキテクチャでは、毎月の請求書に「AZ間転送」という項目が不気味な存在感を放つことになります。
—
2. パフォーマンスの死角：RTTとTCPバッファの罠
単一AZへの集約は、ネットワークレイテンシ（RTT）の増大を招きます。パケットがAZを跨ぐたびに発生するわずか数ミリ秒の遅延は、TLSハンドシェイクの往復回数によって累積され、アプリケーションのレスポンスタイムを確実に蝕みます。
パケットレベルでの最適化：TCPチューニングの勘所
もし集約構成を維持せざるを得ない場合、あるいは高負荷な通信を行うのであれば、Linuxカーネルのtcp_window_scalingや、初期ウィンドウサイズ（initcwnd）の調整が不可欠です。
# TCPウィンドウのスケーリングを有効にし、大量のデータを一度に流す準備をする
sysctl -w net.ipv4.tcp_window_scaling=1
# 初期CWND（Congestion Window）を拡大し、ハンドシェイク直後のバースト送信性能を向上させる
# ※ルートテーブルで設定する場合の例
ip route change default via 10.0.0.1 dev eth0 initcwnd 10また、TLS 1.3を採用している場合、0-RTT（Early Data）の利用を検討すべきです。これにより、RTTを1往復削減し、AZ間転送による遅延コストを実質的に相殺できる可能性があります。ただし、リプレイ攻撃のリスクには細心の注意が必要です。
—
3. 高可用性設計：各AZ配置か、共有か
可用性の観点から見れば、「各AZにNAT GWを配置する」のが黄金律です。しかし、これには管理コストとNAT GW自体の固定費がかかります。
- 共有型（単一AZ）: コスト低、可用性低（そのAZが落ちれば全滅）、AZ間転送コスト高。
- 分散型（各AZ）: コスト高、可用性高、AZ間転送コストゼロ、ローカルルーティングでRTT最適化。
現場のテックリードとして推奨するのは、「通信のライフサイクルに応じたハイブリッド戦略」です。
- トラフィックの定常的な出口: 全AZにNAT GWを配置し、
Route TableをAZローカルで完結させる。 - 管理用ネットワーク: 開発環境など、コスト優先の場合は共有型を許容する。
—
4. セキュリティとパケットヘッダーの深淵
NAT GWは単なるルーティングデバイスではなく、ステートフルなNATエンジンです。ここでのセキュリティの勘所は、「IPフラグメンテーション（断片化）」の回避です。
MTUサイズ（通常1500バイト）を超えたパケットがNAT GWで再構築される際、CPUリソースが消費され、これがボトルネックになることがあります。特にTLS 1.3のレコードサイズや、HTTP/2のヘッダー圧縮（HPACK）によってパケットサイズが微妙に変動する場合、Path MTU Discovery（PMTUD）が正しく動作していないと通信がブラックホール化します。
セキュリティ対策：MSSクランピング
VPNや複雑なトンネリングを行う場合、以下の設定を検討してください。
# iptablesでパケットサイズを制限し、NAT越え時のフラグメンテーションを回避する
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360この1360という値は、オーバーヘッドを考慮した安全な値です。これを設定することで、NAT GW越しの通信エラーを劇的に減らすことができます。
—
5. 結論：アーキテクトが取るべきスタンス
「AZ間転送コスト」を恐れて単一AZにNATを集約し、結果としてパフォーマンス劣化と可用性低下を招くのは、本末転倒なエンジニアリングです。
我々が目指すべきは、「ローカル・ファースト」の精神です。各AZで完結するトラフィックフローを設計し、NAT GWをそのAZの「玄関」として位置づける。もしコストが課題であれば、NAT GWではなく、VPC Endpoints (PrivateLink) を積極的に活用すべきです。S3やDynamoDBへの通信をNAT GW経由にしている時点で、コスト設計は既に破綻していると自覚してください。
ネットワークは生き物です。メトリクス（CloudWatch等）を眺めるだけでなく、tcpdumpを仕掛け、パケットがどのAZを経由しているのかを自分の目で確かめる。その泥臭い検証の積み重ねこそが、最高峰のインフラアーキテクトへの唯一の道なのです。
コメント