AWS NAT
- AWS NAT – Network Address Translation devices, launched in the public subnet, enables instances in a private subnet to connect to the Internet but prevents the Internet from initiating connections with the instances.
- Instances in private subnets would need an internet connection for performing software updates or trying to access external services.
- NAT device performs the function of both address translation and port address translation (PAT)
- NAT instance prevents instances to be directly exposed to the Internet and having to be launched in a Public subnet and assigning of the Elastic IP address to all, which are limited.
- NAT device routes the traffic, from the private subnet to the Internet, by replacing the source IP address with its address and it translates the address back to the instances’ private IP addresses for the response traffic.
- AWS allows NAT configuration in 2 ways
- NAT Gateway, managed service by AWS (recommended)
- NAT Instance (legacy, not recommended)
NAT Gateway
- NAT gateway is an AWS managed NAT service that provides better availability, higher bandwidth, and requires less administrative effort.
- A NAT gateway supports 5 Gbps of bandwidth and automatically scales up to 100 Gbps. For higher bursts requirements, the workload can be distributed by splitting the resources into multiple subnets and creating a NAT gateway in each subnet.
- A NAT gateway can process one million packets per second and automatically scales up to ten million packets per second. Beyond this limit, a NAT gateway will drop packets.
- Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone (for zonal NAT gateways).
- A NAT gateway supports the TCP, UDP, and ICMP protocols.
- NAT gateways are supported for IPv4 or IPv6 traffic. For IPv6 traffic, NAT gateway performs NAT64. By using this in conjunction with DNS64 (available on Route 53 Resolver), IPv6 workloads in a subnet can communicate with IPv4 resources.
- NAT gateway cannot be associated with a security group. Security can be configured for the instances in the private subnets to control the traffic.
- Network ACL can be used to control the traffic to and from the subnet. NACL applies to the NAT gateway’s traffic, which uses ports 1024-65535
- NAT gateway when created receives an elastic network interface that’s automatically assigned a private IP address from the IP address range of the subnet. Attributes of this network interface cannot be modified.
- NAT gateway cannot send traffic over VPC endpoints, VPN connections, AWS Direct Connect, or VPC peering connections. The private subnet’s route table should be modified to route the traffic directly to these devices.
- NAT gateway can route traffic to Transit Gateways and virtual private gateways (for private NAT gateways) or through Transit Gateway for Site-to-Site VPN/Direct Connect traffic.
- NAT gateway times out the connection if it is idle for 350 seconds or more. To prevent the connection from being dropped, initiate more traffic over the connection or enable TCP keepalive on the instance with a value of less than 350 seconds.
- NAT gateways currently do not support the IPsec protocol.
- NAT gateways support traffic with a maximum transmission unit (MTU) of 8500 bytes.
- Each IPv4 address can support up to 55,000 simultaneous connections to each unique destination. You can increase this limit by associating up to 8 IPv4 addresses to your NAT gateways (1 primary IPv4 address and 7 secondary IPv4 addresses). By default, you can associate up to 2 Elastic IP addresses per public NAT gateway (quota increase available).
NAT Gateway Types
- Public NAT Gateway
- Enables instances in private subnets to connect to the internet
- Requires an Elastic IP address
- Must be created in a public subnet (for zonal mode)
- Supports up to 8 IPv4 addresses (1 primary + 7 secondary)
- Private NAT Gateway
- Enables instances in private subnets to connect to other VPCs or on-premises networks via Transit Gateway or virtual private gateway
- Does not require an Elastic IP address
- Uses private IP address for source NAT
- Cannot be used for internet connectivity
- Useful for communication between VPCs with overlapping CIDR ranges
Regional NAT Gateway (Announced November 2025)
- A regional NAT gateway automatically expands across Availability Zones based on workload presence, unlike standard zonal NAT gateways which operate in a single AZ.
- Does not require a public subnet – creates its own route table with a pre-configured route to the internet gateway.
- Provides automatic high availability without manual multi-AZ configuration.
- Simplifies setup – no need to create/delete NAT Gateways or edit route tables when workloads expand to new AZs.
- Supports up to 32 IP addresses per Availability Zone (compared to 8 for zonal NAT gateways).
- May take up to 60 minutes to expand to a new AZ after a resource is launched there.
- Supports two modes:
- Automatic mode – AWS manages IP addresses and AZ expansion (recommended)
- Manual mode – You manually manage IP addresses and control AZ expansion/contraction
- Supports AWS Transit Gateway as a valid route in the regional NAT gateway route table.
- Does not support private NAT connectivity (use zonal NAT gateways for private NAT use cases).
- Available in all commercial AWS Regions (except AWS GovCloud and China Regions).
Regional NAT Gateway vs Zonal NAT Gateway
- Zonal NAT Gateway (Traditional)
- Created in a specific Availability Zone
- Requires a public subnet in each AZ for high availability
- Requires manual creation of NAT Gateway in each AZ
- Requires route table updates for each AZ
- Supports up to 8 IP addresses
- Supports both public and private connectivity types
- Best for: Predictable, static workloads; private NAT use cases
- Regional NAT Gateway
- Automatically spans all AZs based on workload presence
- No public subnet required
- Single NAT Gateway resource to manage
- Automatic routing across AZs
- Supports up to 32 IP addresses per AZ
- Public connectivity only (no private NAT support)
- Best for: Dynamic workloads that scale across AZs, simplified management, new deployments

NAT Instance
⚠️ NAT Instance – Legacy (Not Recommended)
The NAT AMI is built on the last version of Amazon Linux AMI, 2018.03, which reached end of standard support on December 31, 2020 and end of maintenance support on December 31, 2023.
AWS recommends migrating to a NAT Gateway for better availability, higher bandwidth, and less administrative effort.
If NAT instances are required for your use case (e.g., cost optimization for non-production environments), you can create your own NAT AMI from a current version of Amazon Linux.
NAT Gateway vs NAT Instance

AWS Certification Exam Practice Questions
- Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
- AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
- AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
- Open to further feedback, discussion and correction.
- After launching an instance that you intend to serve as a NAT (Network Address Translation) device in a public subnet you modify your route tables to have the NAT device be the target of internet bound traffic of your private subnet. When you try and make an outbound connection to the Internet from an instance in the private subnet, you are not successful. Which of the following steps could resolve the issue?
- Attaching a second Elastic Network interface (ENI) to the NAT instance, and placing it in the private subnet
- Attaching an Elastic IP address to the instance in the private subnet
- Attaching a second Elastic Network Interface (ENI) to the instance in the private subnet, and placing it in the public subnet
- Disabling the Source/Destination Check attribute on the NAT instance
- You manually launch a NAT AMI in a public subnet. The network is properly configured. Security groups and network access control lists are property configured. Instances in a private subnet can access the NAT. The NAT can access the Internet. However, private instances cannot access the Internet. What additional step is required to allow access from the private instances?
- Enable Source/Destination Check on the private Instances.
- Enable Source/Destination Check on the NAT instance.
- Disable Source/Destination Check on the private instances
- Disable Source/Destination Check on the NAT instance
- A user has created a VPC with public and private subnets. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.1.0/24 and the public subnet uses CIDR 20.0.0.0/24. The user is planning to host a web server in the public subnet (port 80. and a DB server in the private subnet (port 3306.. The user is configuring a security group of the NAT instance. Which of the below mentioned entries is not required for the NAT security group?
- For Inbound allow Source: 20.0.1.0/24 on port 80
- For Outbound allow Destination: 0.0.0.0/0 on port 80
- For Inbound allow Source: 20.0.0.0/24 on port 80 (Refer NAT Instance Documentation)
- For Outbound allow Destination: 0.0.0.0/0 on port 443
- A web company is looking to implement an external payment service into their highly available application deployed in a VPC. Their application EC2 instances are behind a public facing ELB. Auto scaling is used to add additional instances as traffic increases. Under normal load the application runs 2 instances in the Auto Scaling group but at peak it can scale 3x in size. The application instances need to communicate with the payment service over the Internet, which requires whitelisting of all public IP addresses used to communicate with it. A maximum of 4 whitelisting IP addresses are allowed at a time and can be added through an API. How should they architect their solution?
- Route payment requests through two NAT instances setup for High Availability and whitelist the Elastic IP addresses attached to the NAT instances
- Whitelist the VPC Internet Gateway Public IP and route payment requests through the Internet Gateway. (Internet gateway is only to route traffic)
- Whitelist the ELB IP addresses and route payment requests from the Application servers through the ELB. (ELB does not have a fixed IP address)
- Automatically assign public IP addresses to the application instances in the Auto Scaling group and run a script on boot that adds each instances public IP address to the payment validation whitelist API. (would exceed the allowed 4 IP addresses)
- A company needs to provide internet access to instances in private subnets across multiple Availability Zones with automatic high availability and simplified management. Which NAT Gateway option should they use?
- Create a public NAT Gateway in each Availability Zone
- Create a Regional NAT Gateway that automatically spans all Availability Zones
- Create a private NAT Gateway in each Availability Zone
- Use NAT instances with Auto Scaling
- An organization has two VPCs with overlapping CIDR ranges that need to communicate with each other through a Transit Gateway. Which NAT Gateway type should be used to enable this communication?
- Public NAT Gateway with Elastic IP addresses
- Regional NAT Gateway in automatic mode
- Private NAT Gateway connected to a Transit Gateway
- NAT Instance with Source/Destination Check disabled
- A company’s NAT Gateway is experiencing port exhaustion when communicating with a popular third-party API endpoint. What is the most effective solution to increase the number of simultaneous connections?
- Create multiple NAT Gateways in the same subnet
- Associate secondary IPv4 addresses with the NAT Gateway to increase the connection limit
- Increase the NAT Gateway bandwidth allocation
- Replace the NAT Gateway with a NAT Instance using a larger instance type