「なぜか繋がらない？」を解決！AWS NATゲートウェイのSNATポート枯渇問題を優しく紐解く
AWSでシステムを構築していると、一度は遭遇する「謎の接続エラー」。特に、プライベートサブネットからインターネットへ通信しようとすると、突如として Connection Timed Out が頻発する現象……。
「設定は間違っていないはずなのに、なぜ？」。その犯人の多くは、NATゲートウェイの「SNATポート枯渇」という現象です。
今回は、ネットワークの専門家が、この厄介な現象を「郵便配達」に例えて、直感的に、そして深く解説します。これを読み終える頃には、あなたのシステムはもう突然の「繋がらない」に怯えることはありませんよ！
—
1. NATゲートウェイは「街の郵便局」である
まず、NATゲートウェイの役割を理解しましょう。プライベートサブネットにあるインスタンスたちは、自分専用の「外向きの住所（パブリックIPアドレス）」を持っていません。だから、外の世界（インターネット）と手紙（パケット）をやり取りするときは、必ず街の郵便局である「NATゲートウェイ」に手紙を預ける必要があります。
NATゲートウェイは、あなたの手紙を預かると、「自分自身の住所」で宛先を書き換え（これがSNAT）、外へ発送します。
ここで発生する「ポート」という名の制限
郵便局には「同時に処理できる受け付け窓口」の数に限りがあります。これが、よく耳にする「55,000ポート」という数字の正体です。
- 送信元IPアドレス（NATゲートウェイのIP）
- 送信元ポート（窓口番号）
- 宛先IPアドレス
- 宛先ポート
この4つの組み合わせで、NATゲートウェイは「どのインスタンスからの手紙か」を識別しています。宛先IPと宛先ポートが同じ場合、NATゲートウェイが使える窓口は最大55,000個しかない、というのがこの問題の核心です。
—
2. なぜ「ポート枯渇」は起きるのか？
想像してみてください。あなたの会社のインスタンスが、短時間に同じ外部APIサーバー（宛先IPが固定）に対して、何万回もリクエストを送るとしたら？
郵便局の窓口（ポート）は、一度使われると「後片付け（セッションの終了確認）」が終わるまで次の手紙に使えません。リクエストのスピードが早すぎると、窓口の整理が終わる前に「次の窓口、空いてない？」と行列ができてしまい、最後には「窓口が全部埋まってます！」と通信が拒絶されるのです。これが Connection Timed Out の正体です。
—
3. トラブルを未然に防ぐ「3つの打ち手」
では、どうすればこの行列を解消できるのでしょうか？
対策1：コネクションを「使い回す（Keep-Alive）」
一番の基本は、毎回新しい手紙を書く（新しいTCP接続を確立する）のではなく、一度繋いだ窓口を維持し続けることです。HTTPクライアントの設定で Keep-Alive を有効にしましょう。
Pythonの requests ライブラリを使うなら、Session オブジェクトを使い回すのが鉄則です。
import requests
# セッションを使い回すことで、何度も接続を確立するコストを削減する
session = requests.Session()
# このセッションを使えば、一度開いたコネクションが維持され、
# NATゲートウェイのポート消費を劇的に抑えられます
response = session.get('https://api.example.com/data')対策2：NATゲートウェイを分散させる
「一つの郵便局が混むなら、郵便局を増やせばいいじゃない！」という考え方です。
サブネットごとにNATゲートウェイを配置することで、負荷を分散させることができます。特に高負荷なマイクロサービス環境では、この設計が非常に有効です。
対策3：AWSの最新機能「NATゲートウェイの複数IP対応」を活用する
2021年にリリースされた機能ですが、NATゲートウェイに複数のパブリックIPアドレスを割り当てることが可能になりました。
これまでは1つのIPにつき55,000ポートが上限でしたが、最大8個のIPアドレスを割り当てられるようになり、理論上は1つのNATゲートウェイで約440,000ポートまで拡張可能です。
# AWS CLIでNATゲートウェイにセカンダリIPを割り当てる例
aws ec2 associate-nat-gateway-address \
--nat-gateway-id nat-0123456789abcdef0 \
--allocation-ids eipalloc-0abcdef1234567890—
4. 最後に：インフラエンジニアの心得
「ポートが枯渇しているか」を調べるには、AWS CloudWatchのメトリクスにある ErrorPortAllocation を監視するのが一番の近道です。この値が「0」以外を記録し始めたら、それはシステムからの「限界だよ！」という悲鳴です。
ネットワークのトラブルは、一見すると魔法のように不可解に見えますが、こうして「郵便配達」のように現実の仕組みに置き換えてみると、どこで渋滞が起きているかが見えてくるはずです。
皆さんのシステムが、今日もスムーズに世界と繋がりますように！また次回の深掘り記事でお会いしましょう。
コメント