この記事はJapan AWS Top Engineers Advent Calendar 2025 の最終日の記事になります。
https://qiita.com/advent-calendar/2025/aws-top-engineers
はじめに
2025/11/19にAWSのNATゲートウェイにリージョナルモードが実装されました。
※既存で利用していたNATゲートウェイはゾーナルモードになってます。
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-nat-gateway-regional-availability/
リージョナルモードのNATゲートウェイを利用することで、リージョン内のNATゲートウェイのスケーリングをAWS側で実施できるようになります。
この記事では、上記のリージョナルNATゲートウェイのスケーリングとNATゲートウェイの性能に関する纏め記事になります。
AWSのNATゲートウェイのリージョナル／ゾーナルモードとは？
最初にNATゲートウェイのリージョナルモード／ゾーナルモードとは何かを簡単に解説します。
今までのゾーナルモードのNATゲートウェイでは、NATゲートウェイを各AZ毎に個別に構築が必要かつ、NATゲートウェイ用のパブリックサブネットの構築が必要でした。
一方で新しくリリースされた、リージョナルモードのNATゲートウェイでは、
リージョンに一つのリージョナルNATゲートウェイの構築が必要となり、各AZへの配置はAWS側のマネージドになります。
また、NATゲートウェイ用のパブリックサブネットは不要になります。
NATゲートウェイのリージョナル／ゾーナルモードの機能の違いの簡単な説明は以上になります。
※実際には利用できるパターンの制約等が色々あるのですが、この記事では性能面での差分について触れていく予定です。
また、リージョナル／ゾーナルモードのAWS利用料金の違いですが、公式サイトに下記の記載があるように基本的には同じになります。
ーーー
https://aws.amazon.com/jp/vpc/pricing/
リージョンレベルの NAT ゲートウェイの料金
VPC でリージョンレベルでの可用性を備えた NAT ゲートウェイを作成する場合、各アベイラビリティーゾーンで NAT ゲートウェイが設定されている各時間について課金されます
ーーー
運用コストの効率化目的でのリージョナルモードへの切り替えは有効ですが、
AWS利用料の削減目的での切り替えは適してないです。
AWSのNATゲートウェイの性能について
①ネットワークトラフィック量
一つのNATゲートウェイで処理できるネットワークトラフィック量は5Gbps～100Gbpsとなり、自動スケーリングの方式となってます。
大量のトラフィックを処理する必要がある場合は、NATゲートウェイの増設を行っていく必要があります。
②同時接続数(TCPコネクション数)
AWS公式サイトにて、NATゲートウェイで宛先IPアドレス一つにつき、同時接続数55000の制限があると記載がありますが、こちらのロジックについて以前確認した結果を解説します。
https://repost.aws/ja/knowledge-center/vpc-resolve-port-allocation-errors
VPCフローログからNATゲートウェイ関連のログを抽出すると下記のようなログが出力されています。
| interface-id | srcaddr | dstaddr | srcport | dstport |
|---|---|---|---|---|
| eni-XXX | Amazon ECS TaskのIPアドレス | NAT ゲートウェイのIPアドレス | 32768 | 443 |
| eni-XXX | Amazon ECS TaskのIPアドレス | NAT ゲートウェイのIPアドレス | 32768 | 443 |
| ～ | ～ | ～ | ～ | ～ |
| eni-XXX | Amazon ECS TaskのIPアドレス | NAT ゲートウェイのIPアドレス | 60998 | 443 |
IPv4のTCP通信の仕様で、srcIPとdstIPの組み合わせ一つにつき使用できるポート数が限られており、
今回dstportが443で固定であると、srcportを使い切ってポート枯渇が発生してしまいます。ポート枯渇が発生すると正常な通信ができなくなります。
AAA.AAA.AAA.AAA:srcprt1 ⇒ XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcprt2 ⇒ XXX.XXX.XXX.XXX:443
こちらの問題の解決策として、NATゲートウェイの前段のリソース(例ではAmazon ECS Taskの数)を増やしてsrcIPを増やすことでポート枯渇を防ぐ必要があります。
AAA.AAA.AAA.AAA:srcprt1 ⇒ XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcprt2 ⇒ XXX.XXX.XXX.XXX:443
BBB.BBB.BBB.BBB:srcprt1 ⇒ XXX.XXX.XXX.XXX:443
BBB.BBB.BBB.BBB:srcprt2 ⇒ XXX.XXX.XXX.XXX:443
もしくはNATゲートウェイの数を増やして、dstIPを増やすことでポート枯渇を防ぐ必要があります。
AAA.AAA.AAA.AAA:srcprt1 ⇒ XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcprt2 ⇒ XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcprt1 ⇒ YYY.YYY.YYY.YYY:443
AAA.AAA.AAA.AAA:srcprt2 ⇒ YYY.YYY.YYY.YYY:443
また、同時接続数(TCPコネクション数)を算出する際は注意点があります。
AWSから外部のインターネットに接続する際のIPアドレスはElastic IP（EIP）へ変換されます。
NATゲートウェイとインターネット上の機器の接続先IPアドレス一つの同時接続数(TCPコネクション数)を算出する際は、
NATゲートウェイに付与されているElastic IP（EIP）の数で算出する必要があります。
クライアント機器の台数に比例して、NATゲートウェイで処理が必要な同時接続数(TCPコネクション数)も増えることになります。
システム全体で処理が必要な同時接続数(TCPコネクション数)に併せて、必要なNATゲートウェイに付与されているElastic IP（EIP）の数も増やしていく必要があります。
リージョナルNATゲートウェイのスケーリングについて
■できること
①使用するAZの拡張
AZに存在するENI（ネットワークインターフェース）をリージョナルNATゲートウェイにて自動的に検出を行う仕様になります。
リージョナルNATゲートウェイでアクティブなワークロードがあるAZを検出すると、自動で拡張する仕様となってます。
ただし、新しいAZへの拡張には最大60分かかる場合があるという制約もあります。
②マネージドなNATゲートウェイのスケーリング
autoScalingIpsという機能にて、CloudWatchでNATゲートウェイのErrorPortAllocationメトリクスを監視し、
AWS が同一AZ内で追加のElastic IP（EIP）を自動的に割り当てることができます。
NATゲートウェイで利用するポートが不足した場合、同一の宛先への同時接続数増加に対応することができるようになります。
■できないこと(2025/12/25時点)
現時点で、下記の3点はリージョナルNATゲートウェイでは実装できません。
①トラフィック量ベースでのNATゲートウェイのスケーリングができない。
リージョナルNATゲートウェイのスケーリング条件は同時接続(TCPコネクション数)のみが対象となっており、トラフィック量ベースではスケーリングができません。
特定の接続先と大量の通信を行うシステム要件がある場合はリージョナルモードではなくゾーナルモードのNATゲートウェイを利用する必要があります。
②プロアクティブなスケーリングができない。
現状のリージョナルNATゲートウェイのスケーリングはAWS側で通信エラーを検知してからスケーリングを実施する機能のみ提供しております。
予め余剰なリソースを用意しておいて、通信エラー自体を発生させないという実装にはできません。
要件として、通信エラー許容ができないシステムでのリージョナルモードの採用は適してません。
③スケーリング条件(閾値)のチューニングができない。
NATゲートウェイでは接続先IPアドレス一つにつき、55000同時接続(TCPコネクション数)をサポートしてますが、
システム内で動作してるアプリケーションやOSS側で利用するポート数によって、システム全体で担保できる同時接続(TCPコネクション数)の上限は変わっていきます。
この値に併せて、リージョナルNATゲートウェイのスケーリング条件をチューニングするということはできない仕様となってます。
例として、Nginx側で接続先IPアドレス一つにつき、約14000程度の同時接続(TCPコネクション数)しかサポートしてませんが、NATゲートウェイのスケーリングの閾値をNginxの値に併せて変更するということはできない仕様になってます。
そのため、特定の宛先IPアドレスに対してNATゲートウェイとの間で、大量のTCPコネクション接続を行う必要があるシステムでは、リージョナルモードの実装は適してません。
※Nginxで利用してるポート数の詳細については下記のブログで解説してます。
https://qiita.com/tkazuaki0820/items/2afa7ad253d4d65b4af1
まとめ
AWS NATゲートウェイの性能とリージョナルNATゲートウェイのスケーリングに関する纏めです。
・NATゲートウェイの性能はトラフィック量と同時接続数(TCPコネクション数)を考慮する必要がある。
同時接続数(TCPコネクション数)はアプリケーションやOSS側で利用するポート数によって、システム全体で担保できる同時接続(TCPコネクション数)の上限が変わるため、
AWS公式ドキュメントのみを参照して設計できるものではない。
・リージョナルNATゲートウェイはとりあえずマルチAZ構成のNATゲートウェイが欲しい際に運用コストを減らすという理由での採用は有効だが、
通信エラーが許容されない／同一の宛先に大量の通信を行う処理があるシステムへの導入は適さない(2025/12/25時点)
また、AWS利用料はゾーナルモードとリージョナルモードでは変わらない。
補足
今回は NATゲートウェイの性能の部分のみ解説しましたが、実運用では、NATゲートウェイのみに着目するのではなくシステム全体で処理できる性能を確認していく必要があります。
ネットワーク経路上に登場する全リソース(オンプレサーバ、ルーター、Direct Connect、Direct Connectゲートウェイ、Network Load Balancer、ECS等)で処理できる性能を確認し、一番最小の値になってる部分がシステム全体で処理できる性能となります。
システム要件と比較して性能のボトルネックになっているリソースから拡張を検討していくというアプローチが必要になってきます。
※参考 各AWSリソースのクォータ
| No | AWSリソース | 処理数上限 | 参考リンク |
|---|---|---|---|
| 1 | Direct Connect | 最大同時TCPコネクション数は上限なし。通信量の上限は契約する回線に依存 | https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/limits.html |
| 2 | VPC | 最大同時TCPコネクション数の上限の定義なし | https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/amazon-vpc-limits.html |
| 3 | ECS Cluster | タスク定義内の"ulimits - hardLimit"のパラメータ設計が必要 | - |
| 4 | Fargate | タスク定義内の"ulimits - hardLimit"のパラメータ設計が必要 | - |
| 5 | NATゲートウェイ | 接続先IPアドレス一つにつき55000｜TCPコネクションが必要(但しシステム内で利用するポート数の設計も考慮が必要) | https://repost.aws/ja/knowledge-center/vpc-resolve-port-allocation-errors |
| 6 | Firewall Endpoint | 最大同時TCPコネクション数は上限なし。通信量は100Gbpsが上限 | https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/vpc-config.html |
| 7 | Internetゲートウェイ | 最大同時TCPコネクション数の上限の定義なし | https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/amazon-vpc-limits.html |