Menu
Amazon Virtual Private Cloud
User Guide

NAT Gateways

You can use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the Internet or other AWS services, but prevent the Internet from initiating a connection with those instances. For more information about NAT, see NAT.

You are charged for creating and using a NAT gateway in your account. NAT gateway hourly usage and data processing rates apply. Amazon EC2 charges for data transfer also apply. For more information, see Amazon VPC Pricing.

NAT gateways are not supported for IPv6 traffic—use an egress-only Internet gateway instead. For more information, see Egress-Only Internet Gateways.

NAT Gateway Basics

To create a NAT gateway, you must specify the public subnet in which the NAT gateway will reside. For more information about public and private subnets, see Subnet Routing. You must also specify an Elastic IP address to associate with the NAT gateway when you create it. After you've created a NAT gateway, you must update the route table associated with one or more of your private subnets to point Internet-bound traffic to the NAT gateway. This enables instances in your private subnets to communicate with the Internet.

Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone. You have a limit on the number of NAT gateways you can create in an Availability Zone. For more information, see Amazon VPC Limits.

Note

If you have resources in multiple Availability Zones and they share one NAT gateway, in the event that the NAT gateway’s Availability Zone is down, resources in the other Availability Zones lose Internet access. To create an Availability Zone-independent architecture, create a NAT gateway in each Availability Zone and configure your routing to ensure that resources use the NAT gateway in the same Availability Zone.

If you no longer need a NAT gateway, you can delete it. Deleting a NAT gateway disassociates its Elastic IP address, but does not release the address from your account.

A NAT gateway has the following characteristics:

  • A NAT gateway supports bursts of up to 10 Gbps of bandwidth. If you require more than 10 Gbps bursts, you can distribute the workload by splitting your resources into multiple subnets, and creating a NAT gateway in each subnet.

  • You can associate exactly one Elastic IP address with a NAT gateway. You cannot disassociate an Elastic IP address from a NAT gateway after it's created. If you need to use a different Elastic IP address for your NAT gateway, you must create a new NAT gateway with the required address, update your route tables, and then delete the existing NAT gateway if it's no longer required.

  • A NAT gateway supports the following protocols: TCP, UDP, and ICMP.

  • You cannot associate a security group with a NAT gateway. You can use security groups for your instances in the private subnets to control the traffic to and from those instances.

  • You can use a network ACL to control the traffic to and from the subnet in which the NAT gateway is located. The network ACL applies to the NAT gateway's traffic. A NAT gateway uses ports 1024 - 65535. For more information, see Network ACLs.

  • When a NAT gateway is created, it receives a network interface that's automatically assigned a private IP address from the IP address range of your subnet. You can view the NAT gateway's network interface in the Amazon EC2 console. For more information, see Viewing Details about a Network Interface. You cannot modify the attributes of this network interface.

  • A NAT gateway cannot be accessed by a ClassicLink connection associated with your VPC.

The following diagram illustrates the architecture of a VPC with a NAT gateway. The main route table sends Internet traffic from the instances in the private subnet to the NAT gateway. The NAT gateway sends the traffic to the Internet gateway using the NAT gateway’s Elastic IP address as the source IP address.

A VPC with public and private subnets and a NAT gateway

Migrating From a NAT Instance

If you're already using a NAT instance, you can replace it with a NAT gateway. To do this, you can create a NAT gateway in the same subnet as your NAT instance, and then replace the existing route in your route table that points to the NAT instance with a route that points to the NAT gateway. If you want to use the same Elastic IP address for the NAT gateway that you currently use for your NAT instance, you must first also disassociate the Elastic IP address for your NAT instance and associate it with your NAT gateway when you create the gateway.

Note

If you change your routing from a NAT instance to a NAT gateway, or if you disassociate the Elastic IP address from your NAT instance, any current connections are dropped and have to be re-established. Ensure that you do not have any critical tasks (or any other tasks that operate through the NAT instance) running.

Using a NAT Gateway with VPC Endpoints, VPN, AWS Direct Connect, or VPC Peering

A NAT gateway cannot send traffic over VPC endpoints, VPN connections, AWS Direct Connect, or VPC peering connections. If your instances in the private subnet need to access resources over a VPC endpoint, a VPN connection, or AWS Direct Connect, use the private subnet’s route table to route the traffic directly to these devices.

For example, your private subnet’s route table has the following routes: Internet-bound traffic (0.0.0.0/0) is routed to a NAT gateway, Amazon S3 traffic (pl-xxxxxxxx; a specific IP address range for Amazon S3) is routed to a VPC endpoint, and 10.25.0.0/16 traffic is routed to a VPC peering connection. The pl-xxxxxxxx and 10.25.0.0/16 IP address ranges are more specific than 0.0.0.0/0; when your instances send traffic to Amazon S3 or the peered VPC, the traffic is sent to the VPC endpoint or the VPC peering connection. When your instances send traffic to the Internet (other than the Amazon S3 IP addresses), the traffic is sent to the NAT gateway.

You cannot route traffic to a NAT gateway through a VPC peering connection, a VPN connection, or AWS Direct Connect. A NAT gateway cannot be used by resources on the other side of these connections.

Working with NAT Gateways

You can use the Amazon VPC console to create, view, and delete a NAT gateway. You can also use the Amazon VPC wizard to create a VPC with a public subnet, a private subnet, and a NAT gateway. For more information, see Scenario 2: VPC with Public and Private Subnets (NAT).

Creating a NAT Gateway

To create a NAT gateway, you must specify a subnet and an Elastic IP address. Ensure that the Elastic IP address is currently not associated with an instance or a network interface. If you are migrating from a NAT instance to a NAT gateway and you want to reuse the NAT instance's Elastic IP address, you must first disassociate the address from your NAT instance.

To create a NAT gateway

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose NAT Gateways, Create NAT Gateway.

  3. In the dialog box, specify the subnet in which to create the NAT gateway, and select an Elastic IP address to associate with the NAT gateway. When you're done, choose Create a NAT Gateway.

  4. The NAT gateway displays in the console. After a few moments, its status changes to Available, after which it's ready for you to use.

If the NAT gateway goes to a status of Failed, there was an error during creation. For more information, see NAT Gateway Goes to a Status of Failed.

Updating Your Route Table

After you've created your NAT gateway, you must update your route tables for your private subnets to point Internet traffic to the NAT gateway. We use the most specific route that matches the traffic to determine how to route the traffic (longest prefix match). For more information, see Route Priority.

To create a route for a NAT gateway

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose Route Tables.

  3. Select the route table associated with your private subnet and choose Routes, Edit.

  4. Choose Add another route. For Destination, enter 0.0.0.0/0. For Target, select the ID of your NAT gateway.

    Note

    If you're migrating from using a NAT instance, you can replace the current route that points to the NAT instance with a route to the NAT gateway.

  5. Choose Save.

To ensure that your NAT gateway can access the Internet, the route table associated with the subnet in which your NAT gateway resides must include a route that points Internet traffic to an Internet gateway. For more information, see Creating a Custom Route Table. If you delete a NAT gateway, the NAT gateway routes remain in a blackhole status until you delete or update the routes. For more information, see Adding and Removing Routes from a Route Table.

Deleting a NAT Gateway

You can delete a NAT gateway using the Amazon VPC console. After you've deleted a NAT gateway, its entry remains visible in the Amazon VPC console for a short while (usually an hour), after which it's automatically removed. You cannot remove this entry yourself.

To delete a NAT gateway

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose NAT Gateways.

  3. Select the NAT gateway, and then choose Delete NAT Gateway.

  4. In the confirmation dialog box, choose Delete NAT Gateway.

Testing a NAT Gateway

After you've created your NAT gateway and updated your route tables, you can ping the Internet from an instance in your private subnet to test that it can connect to the Internet. For an example of how to do this, see Testing the Internet Connection.

If you're able to connect to the Internet, you can also perform the following tests to determine if the Internet traffic is being routed through the NAT gateway:

  • You can trace the route of traffic from an instance in your private subnet. To do this, run the traceroute command 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 (it's 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 your NAT gateway. You can get the Elastic IP address and private IP address of your NAT gateway by viewing its information on the NAT Gateways page in the Amazon VPC console.

If the above tests fail, see Troubleshooting NAT Gateways.

Testing the Internet Connection

The following example demonstrates how to test if your instance in a private subnet can connect to the Internet.

  1. Launch an instance in your public subnet (you'll use this as a bastion server). For more information, see Launching an Instance into Your Subnet. 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 (you can also use 0.0.0.0/0 for this test), and outbound SSH traffic to the IP address range of your private subnet.

  2. 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.

  3. Configure SSH agent forwarding on your local computer, and connect to your bastion server in the public subnet. For more information, see To configure SSH agent forwarding for Linux or OS X or To configure SSH agent forwarding for Windows (PuTTY).

  4. From your bastion server, 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 OS X

  1. From your local machine, add your private key to the authentication agent.

    For Linux, use the following command:

    ssh-add -c mykeypair.pem

    For OS X, use the following command:

    ssh-add -K mykeypair.pem
  2. Connect to your instance in the public subnet using the -A option to enable SSH agent forwarding, and use the instance's public address; for example:

    ssh -A ec2-user@54.0.0.123

To configure SSH agent forwarding for Windows (PuTTY)

  1. Download and install Pageant from the PuTTY download page, if not already installed.

  2. Convert your private key to .ppk format. For more information, see Converting Your Private Key Using PuTTYgen in the Amazon EC2 User Guide for Linux Instances.

  3. Start Pageant, right-click the Pageant icon on the taskbar (it may be hidden), and choose Add Key. Select the .ppk file you created, enter the passphrase if required, and choose Open.

  4. Start a PuTTY session and connect to your instance in the public subnet using its public IP address. For more information, see Starting a PuTTY Session. In the Auth category, ensure that you select the Allow agent forwarding option, and leave the Private key file for authentication field blank.

To test the Internet connection

  1. From your instance in the public subnet, connect to your instance in your private subnet by using its private IP address, for example:

    ssh ec2-user@10.0.1.123
  2. From your private instance, test that you can connect to the Internet by running the ping command for a website that has ICMP enabled, for example:

    ping ietf.org
    
    PING 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 ping command. If the ping command fails, see Instances in Private Subnet Cannot Access Internet.

  3. (Optional) Terminate your instances if you no longer require them. For more information, see Terminate Your Instance in the Amazon EC2 User Guide for Linux Instances.

Troubleshooting NAT Gateways

The following topics can help you to troubleshoot common problems you may encounter when creating or using a NAT gateway.

NAT Gateway Goes to a Status of Failed

If you create a NAT gateway and it goes to a status of Failed, there was an error when it was created. To view the error message, go to the Amazon VPC console, choose NAT Gateways, select your NAT gateway, and then view the error message in the Status field in the details pane.

Note

A failed NAT gateway is automatically deleted after a short period; usually about an hour.

The following table lists the possible causes of the failure as indicated in the Amazon VPC console. After you've applied any of the remedial steps indicated, you can try to create a NAT gateway again.

Displayed errorReasonRemedial steps
Subnet has insufficient free addresses to create this NAT gatewayThe subnet you specified does not have any free private IP addresses. The NAT gateway requires a network interface with a private IP address allocated from the subnet's range. You can check how many IP addresses are available in your subnet by going to the Subnets page in the Amazon VPC console, and viewing the Available IPs field in the details pane for your subnet. To create free IP addresses in your subnet, you can delete unused network interfaces, or terminate instances that you do not require.
Network vpc-xxxxxxxx has no Internet gateway attachedA NAT gateway must be created in a VPC with an Internet gateway.Create and attach an Internet gateway to your VPC. For more information, see Attaching an Internet Gateway.
Elastic IP address eipalloc-xxxxxxxx could not be associated with this NAT gatewayThe Elastic IP address that you specified does not exist or could not be found. Check the allocation ID of the Elastic IP address to ensure that you entered it correctly. Ensure that you have specified an Elastic IP address that's in the same region in which you're creating the NAT gateway.
Elastic IP address eipalloc-xxxxxxxx is already associatedThe Elastic IP address that you specified is already associated with another resource, and cannot be associated with the NAT gateway.You can check which resource is associated with the Elastic IP address by going to the Elastic IPs page in the Amazon VPC console, and viewing the values specified for the instance ID or network interface ID. If you do not require the Elastic IP address for that resource, you can disassociate it. Alternatively, allocate a new Elastic IP address to your account. For more information, see Working with Elastic IP Addresses.
Network interface eni-xxxxxxxx, created and used internally by this NAT gateway is in an invalid state. Please try again.There was a problem creating or using the network interface for the NAT gateway.You cannot fix this error. Try creating a NAT gateway again.

You've Reached Your Elastic IP Address or NAT Gateway Limit

If you've reached your Elastic IP address limit, you can disassociate an Elastic IP from another resource, or you can request a limit increase using the Amazon VPC Limits form.

If you've reached your NAT gateway limit, you can do one of the following:

  • Request a limit increase using the Amazon VPC Limits form. The NAT gateway limit is enforced per Availability Zone.

  • Check the status of your NAT gateway. A status of Pending, Available, or Deleting counts against your limit. If you've recently deleted a NAT gateway, wait a few minutes for the status to go from Deleting to Deleted, then try creating a new NAT gateway.

  • If you do not need your NAT gateway in a specific Availability Zone, try creating a NAT gateway in an Availability Zone where you haven't reached your limit.

For more information about limits, see Amazon VPC Limits.

The Availability Zone is Unsupported (NotAvailableInZone)

In some cases, you may be trying to create the NAT gateway in a constrained Availability Zone — a zone in which our ability to expand is constrained. We cannot support NAT gateways in these zones. You can create a NAT gateway in another Availability Zone and use it for private subnets in the constrained zone. You can also move your resources to an unconstrained Availability Zone so that your resources and your NAT gateway are in the same Availability Zone.

You Created a NAT Gateway and It's No Longer Visible

There may have been an error when your NAT gateway was being created, and it failed. A NAT gateway with a status of failed is visible in the VPC console for a short while (usually an hour), after which it's automatically deleted. Review the information in NAT Gateway Goes to a Status of Failed, and try creating a new NAT gateway.

NAT Gateway Doesn't Respond to a Ping Command

If you try to ping a NAT gateway's Elastic IP address or private IP address from the Internet (for example, from your home computer) or from any instance in your VPC, you will not get a response. A NAT gateway only passes traffic from an instance in a private subnet to the Internet.

To test that your NAT gateway is working, see Testing a NAT Gateway.

Instances in Private Subnet Cannot Access Internet

If you followed the steps to test your NAT gateway above and the ping command fails, or your instances cannot access the Internet, check the following information:

  • Check that the NAT gateway is in the Available state. In the Amazon VPC console, go to the NAT Gateways page and view the status information in the details pane. If the NAT gateway is in a failed state, there may have been an error when it was created. For more information, see NAT Gateway Goes to a Status of Failed.

  • Check that you've configured your route tables correctly:

    • The NAT gateway must be in a public subnet with a route table that routes Internet traffic to an Internet gateway. For more information, see Creating a Custom Route Table.

    • Your instance must be in a private subnet with a route table that routes Internet traffic to the NAT gateway. For more information, see Updating Your Route Table.

    • Check that there are no other route table entries that route all or part of the Internet traffic to another device instead of the NAT gateway.

  • Ensure that your security group rules for your private instance allow outbound Internet traffic. For the ping command to work, the rules must also allow outbound ICMP traffic.

    Note

    The NAT gateway itself allows all outbound traffic and traffic received in response to an outbound request (it is therefore stateful).

  • Ensure that the network ACLs that are associated with the private subnet and public subnets do not have rules that block inbound or outbound Internet traffic. For the ping command to work, the rules must also allow inbound and outbound ICMP traffic.

    Note

    You can enable flow logs to help you diagnose dropped connections because of network ACL or security group rules. For more information, see VPC Flow Logs.

  • If you are using the ping command, ensure that you are pinging a website that has ICMP enabled. If not, you will not receive reply packets. To test this, perform the same ping command from the command line terminal on your own computer.

  • Check that your instance is able to ping other resources, for example, other instances in the private subnet (assuming that security group rules allow this).

  • Ensure that your connection is using a TCP, UDP, or ICMP protocol only.

TCP Connection to a Specific Endpoint Fails

If a TCP connection to a specific endpoint or host is failing even though TCP connections to other endpoints are working normally, verify whether the endpoint you are trying to connect to is responding with fragmented TCP packets. A NAT gateway currently does not support IP fragmentation for TCP. For more information, see Comparison of NAT Instances and NAT Gateways.

To check if the endpoint is sending fragmented TCP packets, use an instance in a public subnet with a public IP address to do the following:

  • Trigger a response large enough to cause fragmentation from the specific endpoint.

  • Use the tcpdump utility to verify that the endpoint is sending fragmented packets.

Important

You must use an instance in a public subnet to perform these checks; you cannot use the instance from which the original connection was failing, or an instance in a private subnet behind a NAT gateway or a NAT instance.

If the endpoint is sending fragmented TCP packets, you can use a NAT instance instead of a NAT gateway.

Note

A NAT gateway also doesn't support IP fragmentation for the ICMP protocol. Diagnostic tools that send or receive large ICMP packets will report packet loss. For example, the command ping -s 10000 example.com will not work behind a NAT gateway.

Traceroute Output Does Not Display NAT Gateway Private IP Address

Your instance can access the Internet, but when you perform the traceroute command, the output does not display the private IP address of the NAT gateway. In this case, your instance is accessing the Internet using a different device, such as an Internet gateway. In the route table of the subnet in which your instance is located, check the following information:

  • Ensure that there is a route that sends Internet traffic to the NAT gateway.

  • Ensure that there isn't a more specific route that's sending Internet traffic to other devices, such as a virtual private gateway or an Internet gateway.

Internet Connection Drops After 5 Minutes

If a connection that's using a NAT gateway is idle for 5 minutes or more, the connection times out. You can initiate more traffic over the connection or use a TCP keepalive to prevent the connection from being dropped.

IPSec Connection Cannot be Established

NAT gateways currently do not support the IPSec protocol.

Cannot Initiate More Connections to a Destination

You may have reached the limit for simultaneous connections. A NAT gateway can support up to 65 000 simultaneous connections to each unique destination. If your instances in the private subnet create a large amount of connections, you may reach this limit. You can do one of the following:

  • Create a NAT gateway per Availability Zone and spread your clients across those zones.

  • Create additional NAT gateways in the public subnet and split your clients into multiple private subnets, each with a route to a different NAT gateway.

  • Limit the number of connections your clients can create to the destination.

  • Close idle connections to release the capacity.

Note

If the destination IP address, the destination port, or the protocol (TCP/UDP/ICMP) changes, you can create an additional 65,000 connections.

Controlling the Use of NAT Gateways

By default, IAM users do not have permission to work with NAT gateways. You can create an IAM user policy that grants users permission to create, describe, and delete NAT gateways. We currently do not support resource-level permissions for any of the ec2:*NatGateway* API operations. For more information about IAM policies for Amazon VPC, see Controlling Access to Amazon VPC Resources.

API and CLI Overview

You can perform the tasks described on this page using the command line or API. For more information about the command line interfaces and a list of available API operations, see Accessing Amazon VPC.

Create a NAT gateway

Describe a NAT gateway

Delete a NAT gateway