NAT gateway use cases
The following are example use cases for public and private NAT gateways.
Scenarios
Access the internet from a private subnet
You can use a public NAT gateway to enable instances in a private subnet to send outbound traffic to the internet, while preventing the internet from establishing connections to the instances.
Overview
The following diagram illustrates this use case. There are two Availability Zones, with two subnets in each Availability Zone. The route table for each subnet determines how traffic is routed. In Availability Zone A, the instances in the public subnet can reach the internet through a route to the internet gateway, while the instances in the private subnet have no route to the internet. In Availability Zone B, the public subnet contains a NAT gateway, and the instances in the private subnet can reach the internet through a route to the NAT gateway in the public subnet.
Both private and public NAT gateways map the source private IPv4 address of the instances to the private IPv4 address of the private NAT gateway, but in the case of a public NAT gateway, the internet gateway then maps the private IPv4 address of the public NAT gateway to the Elastic IP address associated with the NAT gateway. When sending response traffic to the instances, whether it's a public or private NAT gateway, the NAT gateway translates the address back to the original source IP address.
Note that if the instances in the private subnet in Availability Zone A also need to reach the internet, you can create a route from this subnet to the NAT gateway in Availability Zone B. Alternatively, you can improve resiliency by creating a NAT gateway in each Availability Zone that contains resources that require internet access. For an example diagram, see Example: VPC with servers in private subnets and NAT.
Routing
The following is the route table associated with the public subnet in Availability Zone A. The first entry is the local route; it enables the instances in the subnet to communicate with other instances in the VPC using private IP addresses. The second entry sends all other subnet traffic to the internet gateway, which enables the instances in the subnet to access the internet.
| Destination | Target |
|---|---|
VPC CIDR |
local |
| 0.0.0.0/0 | internet-gateway-id |
The following is the route table associated with the private subnet in Availability Zone A. The entry is the local route, which enables the instances in the subnet to communicate with other instances in the VPC using private IP addresses. The instances in this subnet have no access to the internet.
| Destination | Target |
|---|---|
VPC CIDR |
local |
The following is the route table associated with the public subnet in Availability Zone B. The first entry is the local route, which enables the instances in the subnet to communicate with other instances in the VPC using private IP addresses. The second entry sends all other subnet traffic to the internet gateway, which enables the NAT gateway in the subnet to access the internet.
| Destination | Target |
|---|---|
VPC CIDR |
local |
| 0.0.0.0/0 | internet-gateway-id |
The following is the route table associated with the private subnet in Availability Zone B. The first entry is the local route; it enables the instances in the subnet to communicate with other instances in the VPC using private IP addresses. The second entry sends all other subnet traffic to the NAT gateway.
| Destination | Target |
|---|---|
VPC CIDR |
local |
| 0.0.0.0/0 | nat-gateway-id |
For more information, see Manage subnet route tables.
Test the public NAT gateway
After you've created your NAT gateway and updated your route tables, you can ping remote addresses on the internet from an instance in your private subnet to test whether it can connect to the internet. For an example of how to do this, see Test the internet connection.
If you can connect to the internet, you can also test whether internet traffic is routed through the NAT gateway:
-
Trace the route of traffic from an instance in your private subnet. To do this, run the
traceroutecommand from a Linux instance in your private subnet. In the output, you should see the private IP address of the NAT gateway in one of the hops (usually the first hop). -
Use a third-party website or tool that displays the source IP address when you connect to it from an instance in your private subnet. The source IP address should be the Elastic IP address of the NAT gateway.
If these tests fail, see Troubleshoot NAT gateways.
Test the internet connection
The following example demonstrates how to test whether an instance in a private subnet can connect to the internet.
-
Launch an instance in your public subnet (use this as a bastion host). In the launch wizard, ensure that you select an Amazon Linux AMI, and assign a public IP address to your instance.
Ensure that your security group rules allow inbound SSH traffic from the range of IP addresses for your local network, and outbound SSH traffic to the IP address range of your private subnet. You can also use
0.0.0.0/0for both inbound and outbound SSH traffic for this test. -
Launch an instance in your private subnet. In the launch wizard, ensure that you select an Amazon Linux AMI. Do not assign a public IP address to your instance. Ensure that your security group rules allow inbound SSH traffic from the private IP address of your instance that you launched in the public subnet, and all outbound ICMP traffic. You must choose the same key pair that you used to launch your instance in the public subnet.
-
Configure SSH agent forwarding on your local computer, and connect to your bastion host in the public subnet. For more information, see To configure SSH agent forwarding for Linux or macOS or To configure SSH agent forwarding for Windows.
-
From your bastion host, connect to your instance in the private subnet, and then test the internet connection from your instance in the private subnet. For more information, see To test the internet connection.
To configure SSH agent forwarding for Linux or macOS
From your local machine, add your private key to the authentication agent.
For Linux, use the following command.
ssh-add -c mykeypair.pemFor macOS, use the following command.
ssh-add -K mykeypair.pemConnect to your instance in the public subnet using the
-Aoption to enable SSH agent forwarding, and use the instance's public address, as shown in the following example.ssh -A ec2-user@54.0.0.123
To configure SSH agent forwarding for Windows
You can use the OpenSSH client available in Windows, or install your preferred SSH client (for example, PuTTY).
To test the internet connection
From your instance in the public subnet, connect to your instance in your private subnet by using its private IP address as shown in the following example.
ssh ec2-user@10.0.1.123From your private instance, test that you can connect to the internet by running the
pingcommand for a website that has ICMP enabled.ping ietf.orgPING ietf.org (4.31.198.44) 56(84) bytes of data. 64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=1 ttl=47 time=86.0 ms 64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=2 ttl=47 time=75.6 ms ...Press Ctrl+C on your keyboard to cancel the
pingcommand. If thepingcommand fails, see Instances cannot access the internet.(Optional) If you no longer require your instances, terminate them. For more information, see Terminate your instance in the Amazon EC2 User Guide.
Access your network using allow-listed IP addresses
You can use a private NAT gateway to enable communication from your VPCs to your on-premises network using a pool of allow-listed addresses.
Instead of assigning each instance a separate IP address from the allow-listed range, you can route traffic from the subnet through a private NAT gateway with an IP address from the allow-listed range.