【入門編】ポート枯渇（Port Exhaustion）エラーの発生メカニズムとCloudWatch/Azure Monitorでのメトリクス監視 – クラウド＆コンテナネットワーク実践ガイド

なぜ突然、通信が繋がらなくなるのか？「NATゲートウェイのポート枯渇」という見えない壁

クラウドインフラの現場で、ある日突然「特定のAPIが叩けない」「外部通信がタイムアウトする」という相談を受けることがあります。調べてみると、アプリケーション側には異常がなく、ネットワーク機器も正常……。

実はこれ、NATゲートウェイの「ポート枯渇（Port Exhaustion）」という、インフラエンジニアなら一度は頭を抱える「見えない壁」にぶつかっている可能性が高いのです。

今日は、この厄介な現象を、郵便配達の仕組みに例えながら、初心者の方にもわかるように紐解いていきましょう。

—

1. NATゲートウェイは「街の郵便局」である

まずは、NATゲートウェイの役割をイメージしてみましょう。

インターネットに直接繋がっていないプライベートサブネットのサーバー（PC）たちが、外部のWebサイトと通信したいとします。しかし、彼らは外の世界に直接住所（パブリックIPアドレス）を持っていません。

そこで登場するのがNATゲートウェイです。これは、プライベートなサーバーたちの手紙を一度預かり、自分の住所に書き換えてから外へ送る「街の郵便局」のような存在です。

プライベートサーバー： 住所がないので、外に直接送れない。
NATゲートウェイ： 自分の住所を使い、サーバーの代わりに通信してくれる。

これなら安全ですよね。でも、ここには一つ大きな制約があります。

「受付窓口」は64,000個しかない

郵便局には「同時に処理できる受付窓口（ポート）」に限りがあります。NATゲートウェイという一つの郵便局が、外の世界と通信できる窓口は、実は約64,000個と決まっています。

もし、あなたの会社のサーバーが同時に何万通もの手紙を外に送ろうとすると、窓口がすべて埋まってしまい、それ以降の通信は「ただいま窓口が満員です」と突き返されてしまいます。これが「ポート枯渇」の正体です。

—

2. なぜ64,000個もあれば足りないのか？

「6万個もあれば十分じゃないの？」と思われるかもしれません。しかし、ここが落とし穴です。

実は、通信が終わった後も、NATゲートウェイは「もし相手から返事が来たら困るから」という理由で、一定時間（これをタイムアウトと呼びます）その窓口を占有し続けます。

つまり、サーバーが高速で通信を繰り返すと、新しい通信をしようとしても「まだ前の通信の窓口を片付け中だよ！」という状態になり、あっという間に窓口が足りなくなるのです。

—

3. 「ポート枯渇」のサインをどう見つけるか？

パニックになる前に、まずは「本当に窓口が足りていないのか」をメトリクスで確認しましょう。AWSのCloudWatchを例に挙げます。

監視すべき重要メトリクス

NATゲートウェイの監視画面で、以下の項目をチェックしてください。

ErrorPortAllocation：これが「0」以外になっていたら、まさに「窓口が足りなくてパケットを捨てている」証拠です。
ActiveConnectionCount：現在の接続数を確認します。

もし、これらのメトリクスが急上昇していたら、インフラ側での対策が必要です。

—

4. 現場で使える！ポート枯渇を防ぐ3つの鉄則

もしポート枯渇が起きてしまったら、あるいは未然に防ぐにはどうすればよいでしょうか。

① コネクションを使い回す（コネクションプーリング）

アプリケーション側で毎回通信のたびに「接続→切断」を繰り返すのではなく、確立した接続を使い回すように設定します。
例えば、データベースへの接続やHTTPリクエストを送る際、ライブラリ側で「接続を維持（Keep-Alive）」する設定を有効にしましょう。

② 接続先を最適化する

もし同じ宛先（例えば特定の外部API）に頻繁に通信しているなら、Keep-Aliveを有効にして、一つの窓口をずっと使い続けるようにします。

③ NATゲートウェイを分割・増設する

それでも足りない場合、AWSではNATゲートウェイをサブネットごとに配置するなどのアーキテクチャ見直しが必要です。

—

5. アラート設計のヒント

最後に、実務で役立つ「気付き」のアラート設定例を紹介します。

CloudWatchアラーム設定の推奨値:

メトリクス： ErrorPortAllocation
閾値： 1 以上（1つでも発生したら即座に通知）
統計： 合計（Sum）
期間： 1分

# AWS CLIでアラームを作成する際のイメージです
aws cloudwatch put-metric-alarm \
    --alarm-name "NATGatewayPortExhaustionAlert" \
    --metric-name "ErrorPortAllocation" \
    --namespace "AWS/NATGateway" \
    --statistic "Sum" \
    --period 60 \
    --threshold 1 \
    --comparison-operator "GreaterThanOrEqualToThreshold" \
    --evaluation-periods 1 \
    --alarm-actions <あなたのSNSトピックARN>
    # 1分間に1回でもポート割り当てエラーが発生したら通知する設定です

—

まとめ：ネットワークは「流れ」で見よう

ポート枯渇は、プログラムのバグではなく、インフラの「交通渋滞」です。
「パケットという郵便物が、NATゲートウェイという郵便局を通り抜けるとき、窓口が足りなくなっているんだな」とイメージできれば、解決の糸口は必ず見つかります。

最初は難しく感じるネットワークの世界も、こうして身近な仕組みに置き換えて考えてみると、少しだけ親しみやすくなりませんか？

次のトラブルシューティングでは、ぜひこの「郵便局の窓口」を思い出してみてくださいね。それでは、素敵なクラウドライフを！