A NAT Gateway is a managed service that allows instances in a private subnet to connect to the internet or other AWS services, but prevents the internet from initiating a connection with those instances.
Let’s see it in action. Imagine you have a web server in a private subnet that needs to download updates. Without NAT, it can’t reach the internet.
# On an EC2 instance in a private subnet, without NAT:
curl google.com
# curl: (6) Could not resolve host: google.com
Now, let’s set up a NAT Gateway. You first create an Elastic IP address, then a NAT Gateway in a public subnet, associating it with that EIP. Finally, you update the route table for your private subnet to point internet-bound traffic (0.0.0.0/0) to the NAT Gateway.
// Example NAT Gateway creation (AWS CLI)
aws ec2 create-nat-gateway --subnet-id subnet-0123456789abcdef0 --allocation-id eipalloc-abcdef0123456789
// Output will include the NAT Gateway ID: nat-0abcdef1234567890
// Example Route Table Update (AWS CLI)
aws ec2 create-route --route-table-id rtb-0fedcba9876543210 --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0abcdef1234567890
With the NAT Gateway in place:
# On the same EC2 instance in the private subnet:
curl google.com
# You'll get HTML output from Google.
The core problem NAT solves is providing outbound internet access to instances that reside in private subnets, which by definition, have no direct route to the internet. This is crucial for security, as it prevents unsolicited inbound connections. NAT Gateway achieves this by acting as a single point of exit. All traffic from your private instances destined for the internet is routed to the NAT Gateway. The NAT Gateway then translates the private IP addresses of your instances to its own public IP address (the Elastic IP) before sending the traffic to the internet. When responses come back, the NAT Gateway uses its Network Address Translation table to translate the public IP back to the correct private IP address of the originating instance.
The primary difference between a NAT Gateway and a NAT Instance boils down to management and scalability. A NAT Gateway is a fully managed AWS service. AWS handles its availability, patching, and scaling. You don’t need to provision or manage the underlying EC2 instance. It automatically scales its bandwidth up to 45 Gbps. A NAT Instance, on the other hand, is simply an EC2 instance that you configure to perform NAT. You are responsible for its uptime, security patching, and ensuring it has enough bandwidth for your traffic.
The cost structure is a significant differentiator. NAT Gateways incur an hourly charge for each NAT Gateway in use, plus a per-gigabyte charge for data processed through it. For example, a NAT Gateway might cost $0.045 per hour and $0.045 per GB of data processed. NAT Instances, conversely, only incur the cost of the EC2 instance itself (based on its type and runtime) and the Elastic IP address. If you have consistent, high-volume traffic, the per-GB charge of a NAT Gateway can add up quickly, potentially making a well-sized NAT Instance more cost-effective. However, the operational overhead and potential for misconfiguration with NAT Instances often outweigh the direct cost savings for many organizations.
Performance considerations are also key. NAT Gateways are designed for high availability and performance, automatically scaling to handle bursts of traffic up to 45 Gbps. They are deployed across multiple Availability Zones (AZs) within the region where they are created, providing inherent resilience. If you deploy a NAT Gateway in us-east-1a, it can serve traffic from private subnets in us-east-1a, us-east-1b, and us-east-1c. You’ll need a NAT Gateway in each AZ where you have private subnets that require outbound internet access if you want to avoid cross-AZ data transfer charges and maintain optimal latency. NAT Instances, being single EC2 instances, have performance limited by the instance type you choose and its EBS volumes. While you can choose powerful instance types, they don’t have the same built-in high availability or automatic scaling as NAT Gateways. If a NAT Instance fails, your private subnets lose internet connectivity until you can replace or repair it.
When choosing between them, consider your traffic volume, budget, and operational tolerance. For most use cases requiring high availability and minimal management, NAT Gateway is the preferred choice. If you have very predictable, lower traffic volumes and a strong desire to optimize costs by managing your own infrastructure, a NAT Instance might be suitable. However, remember that the "managed" aspect of NAT Gateway includes automatic failover and scaling, which can be invaluable for business-critical applications.
A common point of confusion is how NAT Gateways handle Availability Zones. While a NAT Gateway is deployed in a specific public subnet within an AZ, its routing capabilities extend to private subnets in any AZ within the same region. This means a single NAT Gateway in us-east-1a can route traffic for private subnets in us-east-1a, us-east-1b, and us-east-1c. However, traffic traversing between AZs incurs an inter-AZ data transfer charge. To avoid this and ensure optimal performance, it’s best practice to deploy a NAT Gateway in each AZ where you have private subnets requiring internet access.
The next challenge you’ll face is managing outbound connectivity for multiple VPCs.