AWS NAT Gateway Performance and Regional NAT Gateway Scaling
This post is translated from the original Japanese blog, published on December 25, 2025. https://qiita.com/tkazuaki0820/items/7bbfeedc72c9436b9cc5
This post is translated from the original Japanese blog, published on December 25, 2025.
Introduction
On November 19, 2025, AWS introduced Regional Mode for NAT Gateway. (Note: Existing NAT Gateways in use are classified as Zonal Mode.) https://aws.amazon.com/about-aws/whats-new/2025/11/aws-nat-gateway-regional-availability/
By using a Regional Mode NAT Gateway, AWS now manages the scaling of NAT Gateways within a region on your behalf.
This article summarizes Regional NAT Gateway scaling and NAT Gateway performance characteristics.
What Are Regional and Zonal Modes for AWS NAT Gateway?
Let's start with a brief explanation of Regional Mode and Zonal Mode for NAT Gateway.
With the traditional Zonal Mode NAT Gateway, you had to deploy a separate NAT Gateway in each Availability Zone, and a dedicated public subnet for each NAT Gateway was required.
With the newly released Regional Mode NAT Gateway, only a single Regional NAT Gateway needs to be created per region, and AWS manages the placement across AZs. Additionally, dedicated public subnets for the NAT Gateway are no longer required.
That covers the basic feature differences between Regional and Zonal Mode. (In practice there are various usage constraints, but this article focuses on performance differences.)
Regarding pricing differences between Regional and Zonal Mode, as stated on the official AWS site, the cost is essentially the same:
Regional-level NAT Gateway pricing When you create a NAT Gateway with region-level availability in a VPC, you are charged for each hour during which the NAT Gateway is provisioned in each Availability Zone. https://aws.amazon.com/vpc/pricing/
Switching to Regional Mode is a valid approach for reducing operational overhead, but it is not suitable as a means of reducing AWS costs.
AWS NAT Gateway Performance
① Network Throughput
A single NAT Gateway can handle between 5 Gbps and 100 Gbps of network traffic, with automatic scaling. If you need to handle large volumes of traffic, you must add more NAT Gateways.
② Concurrent Connections (TCP Connection Count)
The AWS documentation states that a NAT Gateway supports up to 55,000 simultaneous connections per destination IP address. Below is an explanation of the logic behind this limit, based on prior investigation. https://repost.aws/knowledge-center/vpc-resolve-port-allocation-errors
When extracting NAT Gateway-related logs from VPC Flow Logs, entries like the following appear:
| interface-id | srcaddr | dstaddr | srcport | dstport |
|---|---|---|---|---|
| eni-XXX | Amazon ECS Task IP | NAT Gateway IP | 32768 | 443 |
| eni-XXX | Amazon ECS Task IP | NAT Gateway IP | 32768 | 443 |
| … | … | … | … | … |
| eni-XXX | Amazon ECS Task IP | NAT Gateway IP | 60998 | 443 |
Per the IPv4 TCP specification, the number of available ports is limited for any given srcIP + dstIP pair. When dstport is fixed at 443, srcports can be exhausted, causing port exhaustion, which prevents normal communication:
1
2
AAA.AAA.AAA.AAA:srcport1 → XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcport2 → XXX.XXX.XXX.XXX:443Solution 1: Increase the number of source resources (e.g., more ECS Tasks) to diversify srcIPs and prevent port exhaustion:
1
2
3
4
AAA.AAA.AAA.AAA:srcport1 → XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcport2 → XXX.XXX.XXX.XXX:443
BBB.BBB.BBB.BBB:srcport1 → XXX.XXX.XXX.XXX:443
BBB.BBB.BBB.BBB:srcport2 → XXX.XXX.XXX.XXX:443Solution 2: Increase the number of NAT Gateways to diversify dstIPs:
1
2
3
4
AAA.AAA.AAA.AAA:srcport1 → XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcport2 → XXX.XXX.XXX.XXX:443
AAA.AAA.AAA.AAA:srcport1 → YYY.YYY.YYY.YYY:443
AAA.AAA.AAA.AAA:srcport2 → YYY.YYY.YYY.YYY:443Important note when calculating concurrent connections: When communicating from AWS to the external internet, the source IP is translated to an Elastic IP (EIP). Therefore, when calculating the concurrent connection count between a NAT Gateway and a single destination IP on the internet, you must factor in the number of EIPs assigned to the NAT Gateway.
As the number of client resources increases, the number of concurrent connections the NAT Gateway must handle also increases proportionally. You need to increase the number of EIPs assigned to your NAT Gateways in line with the total concurrent connection requirements of your system.
Regional NAT Gateway Scaling
✅ What It Can Do
① AZ Expansion The Regional NAT Gateway automatically detects ENIs (Elastic Network Interfaces) present in each AZ. When it detects an active workload in a new AZ, it automatically expands to cover it. However, expanding to a new AZ can take up to 60 minutes.
② Managed NAT Gateway Scaling Via a feature called
autoScalingIps, CloudWatch monitors the ErrorPortAllocation metric on the NAT Gateway, and AWS can automatically assign additional Elastic IPs within the same AZ. This allows the gateway to handle increased concurrent connections to the same destination when port exhaustion is detected.❌ What It Cannot Do (as of December 25, 2025)
① Traffic volume-based scaling is not supported. Scaling conditions for Regional NAT Gateway are based solely on concurrent TCP connections — not traffic volume. If your system requires high-throughput communication with a specific destination, you should use Zonal Mode instead of Regional Mode.
② Proactive scaling is not supported. Currently, Regional NAT Gateway scaling only triggers after AWS detects a communication error. It is not possible to pre-provision excess capacity to prevent errors from occurring in the first place. Regional Mode is therefore not suitable for systems where communication errors are unacceptable.
③ Scaling threshold tuning is not supported. While a NAT Gateway supports 55,000 simultaneous connections per destination IP, the actual number of concurrent connections your system can sustain varies depending on the port usage of the applications and OSS components in use. It is not possible to tune the Regional NAT Gateway's scaling thresholds to match those of your application.
For example, Nginx supports only approximately 14,000 simultaneous connections per destination IP. You cannot configure the NAT Gateway scaling threshold to match this Nginx limit. Therefore, Regional Mode is not suitable for systems that need to maintain a large number of TCP connections to a specific destination IP via the NAT Gateway.
(For details on port usage in Nginx, see: https://qiita.com/tkazuaki0820/items/2afa7ad253d4d65b4af1 )
Summary
Key takeaways on AWS NAT Gateway performance and Regional NAT Gateway scaling:
- NAT Gateway performance must be evaluated in terms of both throughput and concurrent connections (TCP connection count). The concurrent connection limit varies depending on port usage in your applications and OSS, and cannot be determined from AWS documentation alone — application-level design is required.
- Regional NAT Gateway is a valid choice when you simply want a multi-AZ NAT Gateway configuration with reduced operational overhead. However, it is not suitable (as of December 25, 2025) for systems that cannot tolerate communication errors or that require high-volume communication to a single destination. Also note that AWS costs are the same between Zonal Mode and Regional Mode.
Addendum
This article focused solely on NAT Gateway performance. In real-world operations, you must evaluate performance across the entire system, not just the NAT Gateway.
For every resource along the network path — on-premises servers, routers, Direct Connect, Direct Connect Gateways, Network Load Balancers, ECS, etc. — you need to understand their performance limits. The weakest link determines the system's overall capacity. Start by identifying the bottleneck relative to your system requirements and plan capacity expansion from there.
Reference: AWS Resource Quotas
| No. | AWS Resource | Throughput Limit | Reference |
|---|---|---|---|
| 1 | Direct Connect | No defined max concurrent TCP connections; bandwidth depends on contracted circuit | https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html |
| 2 | VPC | No defined max concurrent TCP connections | https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html |
| 3 | ECS Cluster | Requires design of ulimits - hardLimit parameter in task definition | — |
| 4 | Fargate | Requires design of ulimits - hardLimit parameter in task definition | — |
| 5 | NAT Gateway | 55,000 per destination IP (port usage design also required) | https://repost.aws/knowledge-center/vpc-resolve-port-allocation-errors |
| 6 | Firewall Endpoint | No defined max concurrent TCP connections; throughput limit is 100 Gbps | https://docs.aws.amazon.com/network-firewall/latest/developerguide/vpc-config.html |
| 7 | Internet Gateway | No defined max concurrent TCP connections | https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html |
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article