NATインスタンスの「死」を克服する：高可用性ルーティングの深淵とパケットの行方
AWSのマネージドサービスである NAT Gateway は確かに便利だ。しかし、コストの最適化や、ポート制限の回避、あるいは特定のプロトコル制御が必要な現場において、我々は依然として「NATインスタンス」という選択肢を捨てきれない。
だが、EC2ベースのNATインスタンスを採用するということは、同時に「そのインスタンスの死」をアーキテクチャとして許容せねばならないことを意味する。今回は、LambdaとCloudWatch Events（現EventBridge）を組み合わせた、泥臭くも極めて堅牢な「自動フェイルオーバー・ルーティング」の神髄を、パケットレベルの挙動まで掘り下げて解説する。
—
1. 瞬断の正体：ルーティング切り替えの物理
VPCのルートテーブルは、ある種の「分散型スイッチ」である。特定の Destination CIDR に対し、Target を書き換える行為は、AWSのコントロールプレーンを通じて各データプレーンへ伝搬される。
NATインスタンスAがダウンした際、Lambdaが ReplaceRoute APIを叩いてターゲットをインスタンスBに向ける。この時、最も注意すべきは 「TCPコネクションの生存」 だ。
NATインスタンスが変わるということは、送信元IPアドレス（NATのパブリックIP）が変化することを意味する。送信先サーバーから見れば、同じ Source IP で通信していたはずが、突然別の Source IP からパケットが届くことになる。これは TCP RST を誘発する。
パフォーマンスチューニングの極意
この瞬断を最小限に抑えるには、以下のカーネルパラメータをNATインスタンス上でチューニングしておくことが必須だ。
# /etc/sysctl.conf に追記して、NATのコネクション追跡を最適化
# 接続切断後のタイムアウトを早め、エフェメラルポートの枯渇を防ぐ
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.ip_local_port_range = 1024 65535
# パケットのドロップを減らすためのバックログ拡張
net.core.netdev_max_backlog = 5000—
2. Lambdaによるオートフェイルオーバー：その実装の作法
ヘルスチェックに CloudWatch の StatusCheckFailed を使うのは定石だが、実務では「疎通確認」をトリガーにすべきだ。NATインスタンスが起動していても、iptables が死んでいればパケットはブラックホールに消えるからだ。
以下は、ターゲットを切り替えるための最小限のPythonコード（Boto3）である。
import boto3
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
route_table_id = 'rtb-0123456789abcdef'
new_nat_instance_id = 'i-0987654321fedcba'
# ルートテーブルのターゲットを動的に書き換える
# 0.0.0.0/0 の宛先を、稼働中のインスタンスIDに差し替える
response = ec2.replace_route(
DestinationCidrBlock='0.0.0.0/0',
InstanceId=new_nat_instance_id,
RouteTableId=route_table_id
)
return {"status": "Route updated to " + new_nat_instance_id}このリカバリタイムは、概ね10秒から30秒程度。この「空白の時間」に発生するパケットをいかにケアするかが、プロのエンジニアの腕の見せ所だ。
—
3. パケットの行方：TLSハンドシェイクとヘッダー圧縮
NATインスタンスを通過する際、最もオーバーヘッドとなるのが TCP/IP の再構築と Connection Tracking (conntrack) のコストである。
MTUの最適化
AWSのネットワーク環境では、デフォルトの 1500 bytes のMTUを維持すると、トンネリングのオーバーヘッドによりパケットが断片化（フラグメンテーション）し、パフォーマンスが著しく低下する。
# インターフェースのMTUを適切に調整する
ip link set dev eth0 mtu 1400これを行うことで、TLSハンドシェイク時の ClientHello パケットがフラグメント化されず、SSL/TLSのネゴシエーションが劇的に高速化する。特にモバイル回線や不安定なバックボーンを通る通信では、この 100 bytes の余裕がレイテンシを数ミリ秒削り取る。
ヘッダー圧縮と脆弱性対策
NATインスタンスを経由する通信がHTTP/2やgRPC主体であれば、HPACK 圧縮が効いているはずだ。しかし、NATインスタンス自体がボトルネックにならないよう、conntrack のハッシュテーブルサイズを拡張しておくことが、重大な脆弱性（リソース枯渇によるDoS）への唯一の対抗策となる。
# /etc/modprobe.d/iptables.conf
# ハッシュテーブルを最大値まで引き上げる
options nf_conntrack hashsize=262144—
結論：高可用性とは「想定された失敗」の積み重ねである
NATインスタンスのAuto Scalingやフェイルオーバーは、単に「止まらない仕組み」を作ることではない。「止まったときに、どれだけ速く、かつ綺麗にパケットを再ルーティングできるか」 の勝負だ。
今回紹介したルートテーブル制御とカーネルチューニングは、クラウドアーキテクチャにおける基礎体力のようなものだ。このレイヤーを理解し、手足のように操れるようになることで、初めて我々は「マネージドの裏側にある真実」をコントロールできるようになる。
次回の記事では、このNATインスタンス群を eBPF を用いて監視し、さらにミリ秒単位で異常を検知する次世代のネットワーク・オブザーバビリティについて深掘りしようと思う。現場の熱量を、そのままコードに落とし込めるエンジニアであれ。
コメント