# NAT gateways


A NAT gateway is a Network Address Translation (NAT) service. You can use a NAT gateway so that instances in a private subnet can connect to services outside your VPC but external services can't initiate a connection with those instances.

When you create a NAT gateway, you specify one of the following connectivity types:
+ **Public** – (Default) Instances in private subnets can connect to the internet through a public NAT gateway, but the instances can't receive unsolicited inbound connections from the internet. You create a public NAT gateway in a public subnet and must associate an Elastic IP address with the NAT gateway at creation. You route traffic from the NAT gateway to the internet gateway for the VPC. Alternatively, you can use a public NAT gateway to connect to other VPCs or your on-premises network. In this case, you route traffic from the NAT gateway through a transit gateway or a virtual private gateway.
+ **Private** – Instances in private subnets can connect to other VPCs or your on-premises network through a private NAT gateway, but the instances can't receive unsolicited inbound connections from the other VPCs or the on-premises network. You can route traffic from the NAT gateway through a transit gateway or a virtual private gateway. You can't associate an Elastic IP address with a private NAT gateway. You can attach an internet gateway to a VPC with a private NAT gateway, but if you route traffic from the private NAT gateway to the internet gateway, the internet gateway drops the traffic.

A NAT gateway is for use with IPv4 or IPv6 traffic (using [DNS64 and NAT64](nat-gateway-nat64-dns64.md)). Another option for enabling outbound-only internet communication over IPv6 is using an [egress-only internet gateway](egress-only-internet-gateway.md).

Both private and public NAT gateways map the source private IPv4 address of the instances to the private IPv4 address of the 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. 

**Considerations**
+ Connections must always be initiated from within the VPC containing the NAT gateway.
+ You can use either a public or private NAT gateway to route traffic to transit gateways and virtual private gateways.
+ If you use a private NAT gateway to connect to a transit gateway or virtual private gateway, traffic to the destination will come from the private IP address of the private NAT gateway.
+ If you use a public NAT gateway to connect to a transit gateway or virtual private gateway, traffic to the destination will come from the private IP address of the public NAT gateway. The public NAT gateway only uses its Elastic IP address as the source IP address when used in conjunction with an internet gateway in the same VPC.

**Topics**
+ [

# NAT gateway basics
](nat-gateway-basics.md)
+ [

# Work with NAT gateways
](nat-gateway-working-with.md)
+ [

# Regional NAT gateways for automatic multi-AZ expansion
](nat-gateways-regional.md)
+ [Use cases](nat-gateway-scenarios.md)
+ [DNS64 and NAT64](nat-gateway-nat64-dns64.md)
+ [

# Inspect traffic from NAT gateways
](nat-gateway-inspect-traffic.md)
+ [CloudWatch metrics](vpc-nat-gateway-cloudwatch.md)
+ [Troubleshooting](nat-gateway-troubleshooting.md)
+ [Pricing](nat-gateway-pricing.md)

# NAT gateway basics


Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone. There is a quota on the number of NAT gateways that you can create in each Availability Zone. For more information, see [Gateways](amazon-vpc-limits.md#vpc-limits-gateways).

If you have resources in multiple Availability Zones and they share one NAT gateway, and if the NAT gateway’s Availability Zone is down, resources in the other Availability Zones lose internet access. To improve resiliency, 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.

The following characteristics and rules apply to NAT gateways:
+ A NAT gateway supports the following protocols: TCP, UDP, and ICMP.
+ 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), your IPv6 workloads in a subnet in Amazon VPC can communicate with IPv4 resources. These IPv4 services may be present in the same VPC (in a separate subnet) or a different VPC, on your on-premises environment or on the internet.
+ A NAT gateway supports 5 Gbps of bandwidth and automatically scales up to 100 Gbps. If you require more bandwidth, you can split your resources into multiple subnets and create 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. To prevent packet loss, split your resources into multiple subnets and create a separate NAT gateway for each subnet.
+ Each IPv4 address can support up to 55,000 simultaneous connections to each unique destination. A unique destination is identified by a unique combination of destination IP address, the destination port, and protocol (TCP/UDP/ICMP). 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). You are limited to associating 2 Elastic IP addresses to your public NAT gateway by default. You can increase this limit by requesting a quota adjustment. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).
+ When you create a NAT gateway, you can select the primary private IPv4 address to assign to the NAT gateway. Otherwise, we select one on your behalf from the the IPv4 address range of the subnet. You can't change or remove the primary private IPv4 address. You can add secondary private IPv4 addresses as needed.
+ You can't associate a security group with a NAT gateway. You can associate security groups with your instances to control inbound and outbound traffic.
+ We create a requester-managed network interface for your NAT gateway. You can view this network interface using the Amazon EC2 console. Search for the ID of the NAT gateway in the description. You can add tags to the network interface, but you can't modify other properties of this network interface.
+ You can use a network ACL to control the traffic to and from the subnet for your NAT gateway. NAT gateways use ports 1024–65535. For more information, see [Network ACLs](vpc-network-acls.md).
+ You can't route traffic to a NAT gateway through a VPC peering connection. However, traffic from a NAT gateway through VPC peering to destinations in peered VPCs supports "Return to Sender" behavior - return traffic is automatically routed back to the originating NAT gateway even without return routes configured in the destination VPC. This behavior is specific to NAT gateways and does not apply to standard EC2 instances. To prevent this, use NACLs to block the return traffic.

  Not supported:

  ```
  Client → Peering → NAT → Internet
  ```

  Supported:

  ```
  Client → NAT → Peering → Destination
  ```
+ You can't route traffic to a NAT gateway from Site-to-Site VPN or Direct Connect using a virtual private gateway. You can route traffic to a NAT gateway from Site-to-Site VPN or Direct Connect if you use a transit gateway instead of a virtual private gateway.
+ NAT gateways support traffic with a maximum transmission unit (MTU) of 8500, but it's important to note the following: 
  + The MTU of a network connection is the size, in bytes, of the largest permissible packet that can be passed over the connection. The larger the MTU of a connection, the more data that can be passed in a single packet.
  + Packets larger than 8500 bytes that arrive at the NAT gateway are dropped (or fragmented, if applicable).
  + To prevent potential packet loss when communicating with resources over the internet using a public NAT gateway, the MTU setting for your EC2 instances should not exceed 1500 bytes. For more information about checking and setting the MTU on an instance, see [Network MTU for your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#set_mtu) in the *Amazon EC2 User Guide*.
  + NAT gateways support Path MTU Discovery (PMTUD) via FRAG\$1NEEDED ICMPv4 packets and Packet Too Big (PTB) ICMPv6 packets. 
  + NAT gateways enforce Maximum Segment Size (MSS) clamping for all packets. For more information, see [RFC879](https://datatracker.ietf.org/doc/html/rfc879). 

# Work with NAT gateways


You can use the Amazon VPC console to create and manage your NAT gateways.

**Topics**
+ [

## Control the use of NAT gateways
](#nat-gateway-iam)
+ [

## Create a NAT gateway
](#nat-gateway-creating)
+ [

## Edit secondary IP address associations
](#nat-gateway-edit-secondary)
+ [

## Tag a NAT gateway
](#nat-gateway-tagging)
+ [

## Delete a NAT gateway
](#nat-gateway-deleting)
+ [

## Command line overview
](#nat-gateway-api-cli)

## Control the use of NAT gateways


By default, users do not have permission to work with NAT gateways. You can create an IAM role with a policy attached that grants users permissions to create, describe, and delete NAT gateways. For more information, see [Identity and access management for Amazon VPC](security-iam.md).

## Create a NAT gateway


Use the following procedure to create a NAT gateway.

**Related quotas**
+ You won't be able to create a public NAT gateway if you've exhausted the number of Elastic IP addresses allocated to your account. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).
+ You can assign up to 8 private IPv4 addresses to your private NAT gateway. This limit is not adjustable.
+ You are limited to associating 2 Elastic IP addresses to your public NAT gateway by default. You can increase this limit by requesting a quota adjustment. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).

**To create a NAT gateway**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **NAT gateways**.

1. Choose **Create NAT gateway**.

1. (Optional) Specify a name for the NAT gateway. This creates a tag where the key is **Name** and the value is the name that you specify.

1. Select the subnet in which to create the NAT gateway.

1. For **Connectivity type**, leave the default **Public** selection to create a public NAT gateway or choose **Private** to create a private NAT gateway. For more information about the difference between a public and private NAT gateway, see [NAT gateways](vpc-nat-gateway.md).

1. If you chose **Public**, do the following; otherwise, skip to step 8:

   1. Choose an **Elastic IP allocation ID** to assign an Elastic IP address to the NAT gateway or choose **Allocate Elastic IP** to automatically allocate one for the public NAT gateway. You are limited to associating 2 Elastic IP addresses to your public NAT gateway by default. You can increase this limit by requesting a quota adjustment. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).
**Important**  
When you assign an Elastic IP address to a public NAT gateway, the network border group of the EIP must match the network border group of the Availability Zone (AZ) that you're launching the public NAT gateway into. If it's not the same, the NAT gateway will fail to launch. You can see the network border group for the subnet's AZ by viewing the details of the subnet. Similarly, you can view the network border group of an EIP by viewing the details of the EIP address. For more information, see [1. Allocate an Elastic IP address](WorkWithEIPs.md#allocate-eip). 

   1. (Optional) Choose **Additional settings** and, under **Private IP address - optional**, enter a private IPv4 address for the NAT gateway. If you don't enter an address, AWS will automatically assign a private IPv4 address to your NAT gateway at random from the subnet that your NAT gateway is in.

   1. Skip to step 11.

1. If you chose **Private**, for **Additional settings**, **Private IPv4 address assigning method**, choose one of the following:
   + **Auto-assign**: AWS chooses the primary private IPv4 address for the NAT gateway. For **Number of auto-assigned private IPv4 addresses**, you can optionally specify the number of secondary private IPv4 addresses for the NAT gateway. AWS chooses these IP addresses at random from the subnet for your NAT gateway.
   + **Custom**: For **Primary private IPv4 address**, choose the primary private IPv4 address for the NAT gateway. For **Secondary private IPv4 addresses**, you can optionally specify up to 7 secondary private IPv4 addresses for the NAT gateway.

1. If you chose **Custom** in Step 8, skip this step. If you chose **Auto-assign**, under **Number of auto-assigned private IP addresses**, choose the number of secondary IPv4 addresses that you want AWS assign to this private NAT gateway. You can choose up to 7 IPv4 addresses.
**Note**  
Secondary IPv4 addresses are optional and should be assigned or allocated when your workloads that use a NAT gateway exceed 55,000 concurrent connections to a single destination (the same destination IP, destination port, and protocol). Secondary IPv4 addresses increase the number of available ports, and therefore they increase the limit on the number of concurrent connections that your workloads can establish using a NAT gateway.

1. If you chose **Auto-assign** in Step 9, skip this step. If you chose **Custom**, do the following:

   1. Under **Primary private IPv4 address**, enter a private IPv4 address.

   1. Under **Secondary private IPv4 address**, enter up to 7 secondary private IPv4 addresses.

1. (Optional) To add a tag to the NAT gateway, choose **Add new tag** and enter the key name and value. You can add up to 50 tags.

1. Choose **Create a NAT gateway**.

1. The initial status of the NAT gateway is `Pending`. After the status changes to `Available`, the NAT gateway is ready for you to use. Be sure to update your route tables as needed. For examples, see [NAT gateway use cases](nat-gateway-scenarios.md).

If the status of the NAT gateway changes to `Failed`, there was an error during creation. For more information, see [NAT gateway creation fails](nat-gateway-troubleshooting.md#nat-gateway-troubleshooting-failed).

## Edit secondary IP address associations


Each IPv4 address can support up to 55,000 simultaneous connections to each unique destination. A unique destination is identified by a unique combination of destination IP address, the destination port, and protocol (TCP/UDP/ICMP). 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). You are limited to associating 2 Elastic IP addresses to your public NAT gateway by default. You can increase this limit by requesting a quota adjustment. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).

You can use the [NAT gateway CloudWatch metrics](metrics-dimensions-nat-gateway.md) *ErrorPortAllocation* and *PacketsDropCount* to determine if your NAT gateway is generating port allocation errors or dropping packets. To resolve this issue, add secondary IPv4 addresses to your NAT gateway.

**Considerations**
+ You can add secondary private IPv4 addresses when you create a private NAT gateway or after you create the NAT gateway using the procedure in this section. You can add Elastic IP addresses to public NAT gateways only after you create the NAT gateway by using the procedure in this section. 
+ Your NAT gateway can have up to 8 IPv4 addresses associated with it (1 primary IPv4 address and 7 secondary IPv4 addresses). You can assign up to 8 private IPv4 addresses to your private NAT gateway. You are limited to associating 2 Elastic IP addresses to your public NAT gateway by default. You can increase this limit by requesting a quota adjustment. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).

**To edit secondary IPv4 address associations**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **NAT gateways**.

1. Select the NAT gateway whose secondary IPv4 address associations you want to edit.

1. Choose **Actions**, and then choose **Edit secondary IP address associations**.

1. If you are editing the secondary IPv4 address associations of a private NAT gateway, under **Action**, choose **Assign new IPv4 addresses** or **Unassign existing IPv4 addresses**. If you are editing the secondary IPv4 address associations of a public NAT gateway, under **Action**, choose **Associate new IPv4 addresses** or **Disassociate existing IPv4 addresses**.

1. Do one of the following:
   + If you chose to assign or associate new IPv4 addresses, do the following:

     1. This step is required. You must select a private IPv4 address. Choose the **Private IPv4 address assigning method**:
        + **Auto-assign**: AWS automatically chooses a primary private IPv4 address and you choose if you want AWS to assign up to 7 secondary private IPv4 addresses to assign to the NAT gateway. AWS automatically chooses and assigns them for you at random from the subnet that your NAT gateway is in.
        + **Custom**: Choose the primary private IPv4 address and up to 7 secondary private IPv4 addresses to assign to the NAT gateway.

     1. Under **Elastic IP allocation ID**, choose an Elastic IP address to add with a secondary IPv4 address. This step is required. You must select an Elastic IP address along with a private IPv4 address. If you chose **Custom** for the **Private IP address assigning method**, you also must enter a private IPv4 address for each Elastic IP address that you add.
**Important**  
When you assign a secondary EIP to a public NAT gateway, the network border group of the EIP must match the network border group of the Availability Zone (AZ) that the public NAT gateway is in. If it's not the same, the EIP will fail to assign. You can see the network border group for the subnet's AZ by viewing the details of the subnet. Similarly, you can view the network border group of an EIP by viewing the details of the EIP address. For more information, see [1. Allocate an Elastic IP address](WorkWithEIPs.md#allocate-eip). 

     Your NAT gateway can have up to 8 IP addresses associated with it. If this is a public NAT gateway, there is a default quota limit for Elastic IP addresses per Region. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).
   + If you chose to unassign or disassociate new IPv4 addresses, complete the following:

     1. Under **Existing secondary IP address to unassign**, select the secondary IP addresses that you want to unassign.

     1. (optional) Under **Connection drain duration**, enter the maximum amount of time to wait (in seconds) before forcibly releasing the IP addresses if connections are still in progress. If you don't enter a value, the default value is 350 seconds.

1. Choose **Save changes**.

If the status of the NAT gateway changes to `Failed`, there was an error during creation. For more information, see [NAT gateway creation fails](nat-gateway-troubleshooting.md#nat-gateway-troubleshooting-failed).

## Tag a NAT gateway


You can tag your NAT gateway to help you identify it or categorize it according to your organization's needs. For information about working with tags, see [Tagging your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

Cost allocation tags are supported for NAT gateways. Therefore, you can also use tags to organize your AWS bill and reflect your own cost structure. For more information, see [Using cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) in the *AWS Billing User Guide*. For more information about setting up a cost allocation report with tags, see [Monthly cost allocation report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html) in *About AWS Account Billing*. 

**To tag a NAT gateway**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **NAT gateways**.

1. Select the NAT gateway that you want to tag and choose **Actions**. Then choose **Manage tags**.

1. Choose **Add new tag**, and define a **Key** and **Value** for the tag. You can add up to 50 tags.

1. Choose **Save**.

## Delete a NAT gateway


If you no longer need a NAT gateway, you can delete it. After you delete a NAT gateway, its entry remains visible in the Amazon VPC console for about an hour, after which it's automatically removed. You can't remove this entry yourself.

Deleting a NAT gateway disassociates its Elastic IP address, but does not release the address from your account. If you delete a NAT gateway, the NAT gateway routes remain in a `blackhole` status until you delete or update the routes.

**To delete a NAT gateway**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **NAT gateways**.

1. Select the radio button for the NAT gateway, and then choose **Actions**, **Delete NAT gateway**.

1. When prompted for confirmation, enter **delete** and then choose **Delete**.

1. If you no longer need the Elastic IP address that was associated with a public NAT gateway, we recommend that you release it. For more information, see [5. Release an Elastic IP address](WorkWithEIPs.md#release-eip).

## Command line overview


You can perform the tasks described on this page using the command line.

**Assign a private IPv4 address to a private NAT gateway**
+ [assign-private-nat-gateway-address](https://docs.aws.amazon.com/cli/latest/reference/ec2/assign-private-nat-gateway-address.html) (AWS CLI)
+ [Register-EC2PrivateNatGatewayAddress](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2PrivateNatGatewayAddress.html) (AWS Tools for Windows PowerShell)

**Associate Elastic IP addresses and private IPv4 addresses with a public NAT gateway**
+ [associate-nat-gateway-address](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-nat-gateway-address.html) (AWS CLI)
+ [Register-EC2NatGatewayAddress](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2NatGatewayAddress.html) (AWS Tools for Windows PowerShell)

**Create a NAT gateway**
+ [create-nat-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-nat-gateway.html) (AWS CLI)
+ [New-EC2NatGateway](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2NatGateway.html) (AWS Tools for Windows PowerShell)

**Delete a NAT gateway**
+ [delete-nat-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-nat-gateway.html) (AWS CLI)
+ [Remove-EC2NatGateway](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2NatGateway.html) (AWS Tools for Windows PowerShell)

**Describe a NAT gateway**
+ [describe-nat-gateways](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-nat-gateways.html) (AWS CLI)
+ [Get-EC2NatGateway](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2NatGateway.html) (AWS Tools for Windows PowerShell)

**Disassociate secondary Elastic IP addresses from a public NAT gateway**
+ [disassociate-nat-gateway-address](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-nat-gateway-address.html) (AWS CLI)
+ [Unregister-EC2NatGatewayAddress](https://docs.aws.amazon.com/powershell/latest/reference/items/Unregister-EC2NatGatewayAddress.html) (AWS Tools for Windows PowerShell)

**Tag a NAT gateway**
+ [create-tags](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-tags.html) (AWS CLI)
+ [New-EC2Tag](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Tag.html) (AWS Tools for Windows PowerShell)

**Unassign secondary IPv4 addresses from a private NAT gateway**
+ [unassign-private-nat-gateway-address](https://docs.aws.amazon.com/cli/latest/reference/ec2/unassign-private-nat-gateway-address.html) (AWS CLI)
+ [Unregister-EC2PrivateNatGatewayAddress](https://docs.aws.amazon.com/powershell/latest/reference/items/Unregister-EC2PrivateNatGatewayAddress.html) (AWS Tools for Windows PowerShell)

# Regional NAT gateways for automatic multi-AZ expansion


Use regional NAT gateways when you want to simplify your network architecture, improve your security posture, and configure high availability by default. A regional NAT gateway automatically expands across Availability Zones based on your workload presence. Unlike standard NAT gateways (referred to as zonal NAT gateways), which operate in a single Availability Zone, regional NAT gateways follow your workloads to provide automatic high availability.

![\[alt text not found\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/rnat.drawio.png)


Diagram A on the left represents the current setup with zonal NAT Gateway. You first create zonal NAT Gateways per Availability Zone and host your NATs in public subnets. You then configure separate routes per Availability Zone from your private subnets to the NAT in that Availability Zone. You repeat this step every time your workloads expand to a new Availability Zone, for high availability. Additionally, you need to add routes for the internet gateway in the route table of your NAT subnet per Availability Zone.

On the other hand, with a regional NAT Gateway, you don't need to create a public subnet to host it. You also don't have to create and delete NAT Gateways and edit your route tables every time your workloads expand to new Availability Zones. Instead, you simply create a NAT Gateway with regional mode, choose your VPC, and it automatically expands and contracts across all AZs based on your workload's presence to offer high availability. As shown in diagram B, you can route traffic from your resources in a private subnet across all AZs to this single regional NAT Gateway ID, or use the same route table across subnets in your AZ to perform network address translation. Once you create your regional NAT Gateway, AWS automatically creates a route table for it, which comes with a pre-configured route to the internet gateway. You can use this route table to add return routes to your middleboxes.



## Benefits


Regional NAT gateways provide the following benefits:
+ **Simplified setup** – Use a single NAT ID across all Availability Zones that have network interfaces, so you can use the same route entry for subnets across different Availability Zones.
+ **Enhanced security** – No public subnets required. A regional NAT Gateway is a standalone resource with its own route table and you do not need a public subnet in your VPC to host a regional NAT Gateway, which reduces chances of misconfiguring private resources in subnets with public connectivity.
+ **Automatic high availability** – Automatically expands and contracts with your workload footprint to maintain zonal affinity which provides high availability by default.
+ **Higher port and IP limits** – Your regional NAT Gateways support up to 32 IP addresses per Availability Zone (compared to 8 for zonal NAT gateways). Each IP address increases the limit on concurrent connections to a popular destination (identified by unique combination of destination IP, destination port and protocol) by 55,000.

## When to use regional NAT gateways


Consider using Regional NAT Gateways for all use cases except those that require private connectivity. Regional NAT Gateways do not offer private connectivity and we recommend using your NAT Gateways in zonal availability mode for private NAT use cases.

## How regional NAT gateways work


When you launch resources in a new Availability Zone, the regional NAT gateway detects the presence of an network interface(ENI) in that Availability Zone and automatically expands to that zone. Similarly, the NAT Gateway contracts from the Availability Zone that has no active workloads.

It may take your regional NAT Gateway up to 60 minutes to expand to a new Availability Zone after a resource is instantiated there. Until this expansion is complete, the relevant traffic from this resource is processed across zones by your regional NAT Gateway in one of the existing Availability Zones.

Regional NAT gateways support two modes:
+ **Automatic mode** – In this mode, AWS automatically manages IP addresses and Availability Zone expansion (recommended). If you want to use your own IP addresses in this mode and you use Amazon VPC IPAM, see [Define public IPv4 allocation strategy with IPAM policies](https://docs.aws.amazon.com/ipam/define-public-ipv4-allocation-strategy-with-ipam-policies.xml) in the *Amazon VPC IPAM User Guide*.
+ **Manual mode** – In this mode, you manually manage IP addresses and control network address translation for each Availability Zone. In manual mode, you are responsible for expanding and contracting your NAT gateway across Availability Zones.

**Important**  
Regional NAT gateways support AWS Transit Gateway as a valid route in the regional NAT gateway route table. Regional NAT gateways do not support private NAT. If you need private NAT, use zonal NAT gateways instead.

## Pricing


For pricing information, see [Amazon VPC Pricing](https://aws.amazon.com/vpc/pricing/).

## Create a regional NAT gateway


### Using the console


1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **NAT gateways**.

1. Choose **Create NAT gateway**.

1. For **Availability mode**, choose **Regional**. You do not need to specify any subnets when you choose regional availability

1. Choose a VPC.

1. Complete the remaining configuration and choose **Create NAT gateway**.

### Using the AWS CLI


Create a regional NAT gateway

```
aws ec2 create-nat-gateway --vpc-id vpc-12345678 --availability-mode regional
```

View NAT gateway details

```
aws ec2 describe-nat-gateways --nat-gateway-ids nat-12345678
```

Add IP addresses (manual mode)

```
aws ec2 associate-nat-gateway-address --nat-gateway-id nat-12345678 --availability-zone us-east-1b --allocation-ids eipalloc-12345678
```

Remove IP addresses

```
aws ec2 disassociate-nat-gateway-address --nat-gateway-id nat-12345678 --association-ids eipassoc-12345678
```

Delete a regional NAT gateway

```
aws ec2 delete-nat-gateway --nat-gateway-id nat-12345678
```

## Convert from zonal to regional NAT gateways


**Important**  
This will reset your existing connections. We recommend that you complete these steps in your maintenance window.

You can convert existing zonal NAT gateways to a regional NAT gateway using one of two approaches:

**If you are okay with using regional NAT Gateways with new IP addresses:**

1. Create a new regional NAT gateway

1. Update route tables to point to the regional NAT gateway

1. Delete the old zonal NAT gateways

This approach uses new IP addresses and resets existing connections when routes are updated.

**If you want to reuse existing IP addresses with regional NAT Gateways:**

1. Delete existing zonal NAT gateways to release their IP addresses

1. Create a regional NAT gateway using the released IP addresses

1. Update route tables to point to the regional NAT gateway

This approach preserves IP addresses but requires a maintenance window as traffic is interrupted during the transition.

# NAT gateway use cases
Use cases

The following are example use cases for public and private NAT gateways.

**Topics**
+ [

## Access the internet from a private subnet
](#public-nat-internet-access)
+ [

## Access your network using allow-listed IP addresses
](#private-nat-allowed-range)
+ [

## Enable communication between overlapping networks
](#private-nat-overlapping-networks)

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

**Topics**
+ [

### Overview
](#public-nat-gateway-overview)
+ [

### Routing
](#public-nat-gateway-routing)
+ [

### Test the public NAT gateway
](#public-nat-gateway-testing)

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

![\[A VPC with public and private subnets, a NAT gateway, and an internet gateway.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/public-nat-gateway-diagram.png)


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](vpc-example-private-subnets-nat.md).

### 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](WorkWithRouteTables.md).

### 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](#nat-gateway-testing-example).

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 `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 (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](nat-gateway-troubleshooting.md).

#### Test the internet connection


The following example demonstrates how to test whether an instance in a private subnet can connect to the internet.

1. 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/0` for both inbound and outbound SSH traffic for this test).

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

1. 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](#ssh-forwarding-linux) or [To configure SSH agent forwarding for Windows](#ssh-forwarding-windows).

1. 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](#test-internet-connection).<a name="ssh-forwarding-linux"></a>

**To configure SSH agent forwarding for Linux or macOS**

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 macOS, use the following command.

   ```
   ssh-add -K mykeypair.pem
   ```

1. Connect to your instance in the public subnet using the `-A` option 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
   ```<a name="ssh-forwarding-windows"></a>

**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).

------
#### [ OpenSSH ]

Install OpenSSH for Windows as described in this article: [Getting started with OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse). Then add your key to the authentication agent. For more information, see [Key-based authentication in OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement).

------
#### [ PuTTY ]

1. Download and install Pageant from the [PuTTY download page](https://www.chiark.greenend.org.uk/~sgtatham/putty/), if not already installed.

1. Convert your private key to .ppk format. For more information, see [Convert your private key using PuTTYgen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html#putty-private-key) in the *Amazon EC2 User Guide*.

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

1. Start a PuTTY session and connect to your instance in the public subnet using its public IP address. For more information, see [Connect to your Linux instance using PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-from-windows.html). In the **Auth** category, ensure that you select the **Allow agent forwarding** option, and leave the **Private key file for authentication** box blank.

------<a name="test-internet-connection"></a>

**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 as shown in the following example.

   ```
   ssh ec2-user@10.0.1.123
   ```

1. From your private instance, test that you can connect to the internet by running the `ping` command for a website that has ICMP enabled.

   ```
   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\$1C** on your keyboard to cancel the `ping` command. If the `ping` command fails, see [Instances cannot access the internet](nat-gateway-troubleshooting.md#nat-gateway-troubleshooting-no-internet-connection).

1. (Optional) If you no longer require your instances, terminate them. For more information, see [Terminate your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) 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 IP address range, you can route traffic from the subnet that is destined for the on-premises network through a private NAT gateway with an IP address from the allow-listed IP address range.

**Topics**
+ [

### Overview
](#private-nat-allowed-range-overview)
+ [

### Resources
](#private-nat-allowed-range-resources)
+ [

### Routing
](#private-nat-allowed-range-routing)

### Overview


The following diagram shows how instances can access on-premises resources through Site-to-Site VPN. Traffic from the instances is routed to a virtual private gateway, over the VPN connection, to the customer gateway, and then to the destination in the on-premises network. However, suppose that the destination allows traffic only from a specific IP address range, such as 100.64.1.0/28. This would prevent traffic from these instances from reaching the on-premises network.

![\[Access to an on-premises network using an Site-to-Site VPN connection.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/allowed-range.png)


The following diagram shows the key components of the configuration for this scenario. The VPC has its original IP address range plus the allowed IP address range. The VPC has a subnet from the allowed IP address range with a private NAT gateway. Traffic from the instances that is destined for the on-premises network is sent to the NAT gateway before being routed to the VPN connection. The on-premises network receives the traffic from the instances with the source IP address of the NAT gateway, which is from the allowed IP address range.

![\[VPC subnet traffic routed through private NAT gateway\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/private-nat-allowed-range.png)


### Resources


Create or update resources as follows:
+ Associate the allowed IP address range with the VPC.
+ Create a subnet in the VPC from the allowed IP address range.
+ Create a private NAT gateway in the new subnet.
+ Update the route table for the subnet with the instances to send traffic destined for the on-premises network to the NAT gateway. Add a route to the route table for the subnet with the private NAT gateway that sends traffic destined for the on-premises network to the virtual private gateway.

### Routing


The following is the route table associated with the first subnet. There is a local route for each VPC CIDR. Local routes enable resources in the subnet to communicate with other resources in the VPC using private IP addresses. The third entry sends traffic destined for the on-premises network to the private NAT gateway.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | local | 
| 100.64.1.0/24 | local | 
| 192.168.0.0/16 | nat-gateway-id | 

The following is the route table associated with the second subnet. There is a local route for each VPC CIDR. Local routes enable resources in the subnet to communicate with other resources in the VPC using private IP addresses. The third entry sends traffic destined for the on-premises network to the virtual private gateway.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | local | 
| 100.64.1.0/24 | local | 
| 192.168.0.0/16 | vgw-id | 

## Enable communication between overlapping networks


You can use a private NAT gateway to enable communication between networks even if they have overlapping CIDR ranges. For example, suppose that the instances in VPC A need to access the services provided by the instances in VPC B.

![\[Two VPCs with overlapping CIDR ranges.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/overlapping-networks.png)


**Topics**
+ [

### Overview
](#private-nat-overlapping-networks-overview)
+ [

### Resources
](#private-nat-overlapping-networks-resources)
+ [

### Routing
](#private-nat-overlapping-networks-routing)

### Overview


The following diagram shows the key components of the configuration for this scenario. First, your IP management team determines which address ranges can overlap (non-routable address ranges) and which can't (routable address ranges). The IP management team allocates address ranges from the pool of routable address ranges to projects on request.

Each VPC has its original IP address range, which is non-routable, plus the routable IP address range assigned to it by the IP management team. VPC A has a subnet from its routable range with a private NAT gateway. The private NAT gateway gets its IP address from its subnet. VPC B has a subnet from its routable range with an Application Load Balancer. The Application Load Balancer gets its IP addresses from its subnets.

Traffic from an instance in the non-routable subnet of VPC A that is destined for the instances in the non-routable subnet of VPC B is sent through the private NAT gateway and then routed to the transit gateway. The transit gateway sends the traffic to the Application Load Balancer, which routes the traffic to one of the target instances in the non-routable subnet of VPC B. The traffic from the transit gateway to the Application Load Balancer has the source IP address of the private NAT gateway. Therefore, response traffic from the load balancer uses the address of the private NAT gateway as its destination. The response traffic is sent to the transit gateway and then routed to the private NAT gateway, which translates the destination to the instance in the non-routable subnet of VPC A.

![\[VPC with private NAT gateway and transit gateway for inter-VPC communication with overlapping CIDR\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/private-nat-overlapping-networks.png)


### Resources


Create or update resources as follows:
+ Associate the assigned routable IP address ranges with their respective VPCs.
+ Create a subnet in VPC A from its routable IP address range, and create a private NAT gateway in this new subnet.
+ Create a subnet in VPC B from its routable IP address range, and create an Application Load Balancer in this new subnet. Register the instances in the non-routable subnet with the target group for the load balancer.
+ Create a transit gateway to connect the VPCs. Be sure to disable route propagation. When you attach each VPC to the transit gateway, use the routable address range of the VPC.
+ Update the route table of the non-routable subnet in VPC A to send all traffic destined for the routable address range of VPC B to the private NAT gateway. Update the route table of the routable subnet in VPC A to send all traffic destined for the routable address range of VPC B to the transit gateway.
+ Update the route table of the routable subnet in VPC B to send all traffic destined for the routable address range of VPC A to the transit gateway.

### Routing


The following is the route table for the non-routable subnet in VPC A.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | local | 
| 100.64.1.0/24 | local | 
| 100.64.2.0/24 | nat-gateway-id | 

The following is the route table for the routable subnet in VPC A.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | local | 
| 100.64.1.0/24 | local | 
| 100.64.2.0/24 | transit-gateway-id | 

The following is the route table for the non-routable subnet in VPC B.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | local | 
| 100.64.2.0/24 | local | 

The following is the route table for the routable subnet in VPC B.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | local | 
| 100.64.2.0/24 | local | 
| 100.64.1.0/24 | transit-gateway-id | 

The following is the transit gateway route table.


| CIDR | Attachment | Route type | 
| --- | --- | --- | 
| 100.64.1.0/24 | Attachment for VPC A | Static | 
| 100.64.2.0/24 | Attachment for VPC B | Static | 

# DNS64 and NAT64
DNS64 and NAT64

A NAT gateway supports network address translation from IPv6 to IPv4, popularly known as NAT64. NAT64 helps your IPv6 AWS resources communicate with IPv4 resources in the same VPC or a different VPC, in your on-premises network or over the internet. You can use NAT64 with DNS64 on Amazon Route 53 Resolver or use your own DNS64 server.

**Topics**
+ [

## What is DNS64?
](#nat-gateway-dns64-what-is)
+ [

## What is NAT64?
](#nat-gateway-nat64-what-is)
+ [

## Configure DNS64 and NAT64
](#nat-gateway-nat64-dns64-walkthrough)

## What is DNS64?


Your IPv6-only workloads running in VPCs can only send and receive IPv6 network packets. Without DNS64, a DNS query for an IPv4-only service will yield an IPv4 destination address in response and your IPv6-only service can't communicate with it. To bridge this communication gap, you can enable DNS64 for a subnet and it applies to all the AWS resources within that subnet. With DNS64, the Amazon Route 53 Resolver looks up the DNS record for the service you queried for and does one of the following:
+ If the record contains an IPv6 address, it returns the original record and the connection is established without any translation over IPv6.
+ If there is no IPv6 address associated with the destination in the DNS record, the Route 53 Resolver synthesizes one by prepending the well-known `/96` prefix, defined in RFC6052 (`64:ff9b::/96`), to the IPv4 address in the record. Your IPv6-only service sends network packets to the synthesized IPv6 address. You will then need to route this traffic through the NAT gateway, which performs the necessary translation on the traffic to allow IPv6 services in your subnet to access IPv4 services outside that subnet.

You can enable or disable DNS64 on a subnet using the [modify-subnet-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-subnet-attribute.html) using the AWS CLI or with the VPC console by selecting a subnet and choosing **Actions** > **Edit subnet settings**.

## What is NAT64?


NAT64 enables your IPv6-only services in Amazon VPCs to communicate with IPv4-only services within the same VPC (in different subnets) or connected VPCs, in your on-premises networks, or over the internet.

NAT64 is automatically available on your existing NAT gateways or on any new NAT gateways you create. It's not a feature you enable or disable. The subnet that the NAT gateway is in does not need to be a dual-stack subnet for NAT64 to work.

After you enable DNS64, if your IPv6-only service sends network packets to a synthesized IPv6 address through the NAT gateway, the following happens:
+ From the `64:ff9b::/96` prefix, the NAT gateway recognizes that the original destination is IPv4 and translates the IPv6 packets to IPv4 by replacing:
  + Source IPv6 with its own private IP which is translated to Elastic IP address by the internet gateway.
  + Destination IPv6 to IPv4 by truncating the `64:ff9b::/96` prefix.
+ The NAT gateway sends the translated IPv4 packets to the destination through the internet gateway, virtual private gateway, or transit gateway and initiates a connection.
+ The IPv4-only host sends back IPv4 response packets. After a connection is established, NAT gateway accepts the response IPv4 packets from the external hosts.
+ The response IPv4 packets are destined for NAT gateway, which receives the packets and de-NATs them by replacing its IP (destination IP) with the host’s IPv6 address and prepending back `64:ff9b::/96` to the source IPv4 address. The packet then flows to the host following the local route.

In this way, the NAT gateway enables your IPv6-only workloads in a subnet to communicate with IPv4-only services outside the subnet.

## Configure DNS64 and NAT64


Follow the steps in this section to configure DNS64 and NAT64 to enable communication with IPv4-only services.

**Topics**
+ [

### Enable communication with IPv4-only services on the internet with the AWS CLI
](#nat-gateway-nat64-dns64-walkthrough-internet)
+ [

### Enable communication with IPv4-only services in your on-premises environment
](#nat-gateway-nat64-dns64-walkthrough-on-prem)

### Enable communication with IPv4-only services on the internet with the AWS CLI


If you have a subnet with IPv6-only workloads that needs to communicate with IPv4-only services outside the subnet, this example shows you how to enable these IPv6-only services to communicate with IPv4-only services on the internet.

You should first configure a NAT gateway in a public subnet (separate from the subnet containing the IPv6-only workloads). For example, the subnet containing the NAT gateway should have a `0.0.0.0/0` route pointing to the internet gateway.

Complete these steps to enable these IPv6-only services to connect with IPv4-only services on the internet:

1. Add the following three routes to the route table of the subnet containing the IPv6-only workloads:
   + IPv4 route (if any) pointing to the NAT gateway.
   + `64:ff9b::/96` route pointing to the NAT gateway. This will allow traffic from your IPv6-only workloads destined for IPv4-only services to be routed through the NAT gateway.
   + IPv6 `::/0` route pointing to the egress-only internet gateway (or the internet gateway).

   Note that pointing `::/0` to the internet gateway will allow external IPv6 hosts (outside the VPC) to initiate connection over IPv6.

   

   ```
   aws ec2 create-route --route-table-id rtb-34056078 --destination-cidr-block
   0.0.0.0/0 --nat-gateway-id nat-05dba92075d71c408
   ```

   

   ```
   aws ec2 create-route --route-table-id rtb-34056078 --destination-ipv6-cidr-block
   64:ff9b::/96 --nat-gateway-id nat-05dba92075d71c408
   ```

   

   ```
   aws ec2 create-route --route-table-id rtb-34056078 --destination-ipv6-cidr-block
   ::/0 --egress-only-internet-gateway-id eigw-c0a643a9
   ```

1. Enable DNS64 capability in the subnet containing the IPv6-only workloads.

   ```
   aws ec2 modify-subnet-attribute --subnet-id subnet-1a2b3c4d --enable-dns64
   ```

Now, resources in your private subnet can establish stateful connections with both IPv4 and IPv6 services on the internet. Configure your security group and NACLs appropriately to allow egress and ingress traffic to `64:ff9b::/96` traffic.

### Enable communication with IPv4-only services in your on-premises environment


Amazon Route 53 Resolver enables you to forward DNS queries from your VPC to an on-premises network and vice versa. You can do this by doing the following:
+ You create a Route 53 Resolver outbound endpoint in a VPC and assign it the IPv4 addresses that you want Route 53 Resolver to forward queries from. For your on-premises DNS resolver, these are the IP addresses that the DNS queries originate from and, therefore, should be IPv4 addresses.
+ You create one or more rules which specify the domain names of the DNS queries that you want Route 53 Resolver to forward to your on-premises resolvers. You also specify the IPv4 addresses of the on-premises resolvers.
+ Now that you have set up a Route 53 Resolver outbound endpoint, you need to enable DNS64 on the subnet containing your IPv6-only workloads and route any data destined for your on-premises network through a NAT gateway.

How DNS64 works for IPv4-only destinations in on-premises networks:

1. You assign an IPv4 address to the Route 53 Resolver outbound endpoint in your VPC.

1. The DNS query from your IPv6 service goes to Route 53 Resolver over IPv6. Route 53 Resolver matches the query against the forwarding rule and gets an IPv4 address for your on-premises resolver.

1. Route 53 Resolver converts the query packet from IPv6 into IPv4 and forwards it to the outbound endpoint. Each IP address of the endpoint represents one ENI that forwards the request to the on-premises IPv4 address of your DNS resolver.

1. The on-premises resolver sends the response packet over IPv4 back through the outbound endpoint to Route 53 Resolver.

1. Assuming the query was made from a DNS64-enabled subnet, Route 53 Resolver does two things:

   1. Checks the content of the response packet. If there’s an IPv6 address in the record, it keeps the content as is, but if it contains only an IPv4 record. It synthesizes an IPv6 record as well by prepending `64:ff9b::/96` to the IPv4 address.

   1. Repackages the content and sends it to the service in your VPC over IPv6.

# Inspect traffic from NAT gateways


You can attach Network Firewall Proxy to your NAT Gateway to inspect and filter traffic on your NAT Gateway. This security control allows you to prevent data leaks outside your trusted perimeter and blocks any undesired inbound response.

## How it works


When creating a Network Firewall Proxy, you're required to select an existing NAT Gateway to attach the Proxy on. Once created, the Proxy:
+ The Proxy comes with a fully qualified domain name and you need to set set your applications to send http and https connect requests to the Proxy. The proxy first filters the domain name in the connect request based on the rules entered by the customer. If allowed by the customer, the proxy then makes a DNS query to get the IP address of the domain. It then established TCP connection with the end destination. Based on whether TLS decryption is enabled, the proxy then filters the TLS connection on the IP address and header attributes and only established a TLS connection with the destination if the IP and header attributes (including the header action and the url path) are allowed by the policies.
+ The appliance inspects and filters the traffic.
+ Allowed traffic continues to the destination (in the internet or on-prem environment or another VPC).

## Attaching appliances


Appliances are attached to NAT Gateways through AWS Network Firewall. For steps on creating and attaching appliances, see the [Network Firewall Proxy Developer Guide](https://docs.aws.amazon.com/network-firewall/latest/developerguide/network-firewall-proxy-developer-guide.html).

## Viewing attached appliances


To view appliances attached to your NAT Gateway, use the [describe-nat-gateways](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-nat-gateways.html) command:

```
aws ec2 describe-nat-gateways --nat-gateway-ids nat-1234567890abcdef0
```

The response includes an `AttachedAppliances` field showing:
+ **Type** – The appliance type (e.g., `network-firewall-proxy`)
+ **ApplianceArn** – The ARN of the attached appliance
+ **AttachmentState** – Current attachment status (`attached`, `detaching`, `detached`, `attach_failed`, `detach_failed`)
+ **ModificationState** – Current modification status (`modifying`, `completed`, `failed`)
+ **VpcEndpointId** – The VPC endpoint ID used to route traffic from application VPCs to the proxy for inspection and filtering
+ **FailureCode** – The failure code if the appliance attachment or modification operation failed
+ **FailureMessage** – A descriptive message explaining the failure if the appliance attachment or modification operation failed

# Monitor NAT gateways with Amazon CloudWatch
CloudWatch metrics

You can monitor your NAT gateway using CloudWatch, which collects information from your NAT gateway and creates readable, near real-time metrics. You can use this information to monitor and troubleshoot your NAT gateway. These metrics give you visibility into the health and performance of your NAT gateway, enabling you to closely monitor its operation and quickly troubleshoot any issues.

The NAT gateway metrics collected by CloudWatch include data points such as bytes processed, packet counts, connection counts, and error rates. This enables you to thoroughly understand the traffic flowing through your NAT gateway and identify any anomalies or bottlenecks. CloudWatch delivers this metric data at 1-minute intervals, giving you a granular, up-to-the-minute view of your NAT gateway's behavior.

Additionally, CloudWatch retains this NAT gateway metric data for an extended period of 15 months, enabling you to analyze trends and patterns over time. You can use this historical data for capacity planning, performance optimization, and understanding the long-term evolution of your NAT gateway usage.

To leverage these powerful monitoring capabilities, you can create custom CloudWatch dashboards and alarms tailored to your specific needs. For example, you could set up alerts to notify you whenever your NAT gateway's outbound data transfer exceeds a certain threshold, allowing you to proactively address potential bandwidth constraints.

For more information about pricing, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).

**Topics**
+ [

# NAT gateway metrics and dimensions
](metrics-dimensions-nat-gateway.md)
+ [

# View NAT gateway CloudWatch metrics
](viewing-metrics.md)
+ [

# Create CloudWatch alarms to monitor a NAT gateway
](creating-alarms-nat-gateway.md)

# NAT gateway metrics and dimensions


The following metrics are available for your NAT gateways. The description column includes a description of each metrics as well as the [units](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit) and [statistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Statistics-definitions.html).


| Metric | Description | 
| --- | --- | 
| ActiveConnectionCount |  The total number of concurrent active TCP connections through the NAT gateway. A value of zero indicates that there are no active connections through the NAT gateway. Units: Count Statistics: The most useful statistic is `Max`.  | 
| BytesInFromDestination |  The number of bytes received by the NAT gateway from the destination. If the value for `BytesOutToSource` is less than the value for `BytesInFromDestination`, there might be data loss during NAT gateway processing, or traffic being actively blocked by the NAT gateway. Units: Bytes Statistics: The most useful statistic is `Sum`.  | 
| BytesInFromSource |  The number of bytes received by the NAT gateway from clients in your VPC. If the value for `BytesOutToDestination` is less than the value for `BytesInFromSource`, there might be data loss during NAT gateway processing. Units: Bytes Statistics: The most useful statistic is `Sum`.  | 
| BytesOutToDestination |  The number of bytes sent out through the NAT gateway to the destination. A value greater than zero indicates that there is traffic going to the internet from clients that are behind the NAT gateway. If the value for `BytesOutToDestination` is less than the value for `BytesInFromSource`, there might be data loss during NAT gateway processing. Unit: Bytes Statistics: The most useful statistic is `Sum`.  | 
| BytesOutToSource |  The number of bytes sent through the NAT gateway to the clients in your VPC. A value greater than zero indicates that there is traffic coming from the internet to clients that are behind the NAT gateway. If the value for `BytesOutToSource` is less than the value for `BytesInFromDestination`, there might be data loss during NAT gateway processing, or traffic being actively blocked by the NAT gateway. Units: Bytes Statistics: The most useful statistic is `Sum`.  | 
| ConnectionAttemptCount |  The number of connection attempts made through the NAT gateway. This includes only the initial SYN. In some cases, `ConnectionAttemptCount` may be lower than `ConnectionEstablishedCount` due to SYN retransmission. If the value for `ConnectionEstablishedCount` is less than the value for `ConnectionAttemptCount`, this indicates that clients behind the NAT gateway attempted to establish new connections for which there was no response. Unit: Count Statistics: The most useful statistic is `Sum`.  | 
| ConnectionEstablishedCount |  The number of connections established through the NAT gateway. This includes SYN and SYN retransmissions. If the value for `ConnectionEstablishedCount` is less than the value for `ConnectionAttemptCount`, this indicates that clients behind the NAT gateway attempted to establish new connections for which there was no response. Unit: Count Statistics: The most useful statistic is `Sum`.  | 
| ErrorPortAllocation |  The number of times the NAT gateway could not allocate a source port.  A value greater than zero indicates that too many concurrent connections are open through the NAT gateway. Units: Count Statistics: The most useful statistic is `Sum`.  | 
| IdleTimeoutCount |  The number of connections that transitioned from the active state to the idle state. An active connection transitions to idle if it was not closed gracefully and there was no activity for the last 350 seconds. A value greater than zero indicates that there are connections that have been moved to an idle state. If the value for `IdleTimeoutCount` increases, it might indicate that clients behind the NAT gateway are re-using stale connections.  Unit: Count Statistics: The most useful statistic is `Sum`.  | 
| PacketsDropCount |  The number of packets dropped by the NAT gateway.  To calculate the number of dropped packets as a percentage of the overall packet traffic, use this formula: `PacketsDropCount/(PacketsInFromSource+PacketsInFromDestination)*100`. If this value exceeds 0.01 percent of the total traffic on the NAT gateway, there may be an issue with Amazon VPC service. Use the [AWS service health dashboard](http://status.aws.amazon.com/) to identify any issues with the service that may be causing NAT gateways to drop packets.  Units: Count Statistics: The most useful statistic is `Sum`.  | 
| PacketsInFromDestination |  The number of packets received by the NAT gateway from the destination. If the value for `PacketsOutToSource` is less than the value for `PacketsInFromDestination`, there might be data loss during NAT gateway processing, or traffic being actively blocked by the NAT gateway. Unit: Count Statistics: The most useful statistic is `Sum`.  | 
| PacketsInFromSource |  The number of packets received by the NAT gateway from clients in your VPC. If the value for `PacketsOutToDestination` is less than the value for `PacketsInFromSource`, there might be data loss during NAT gateway processing. Unit: Count Statistics: The most useful statistic is `Sum`.  | 
| PacketsOutToDestination |  The number of packets sent out through the NAT gateway to the destination. A value greater than zero indicates that there is traffic going to the internet from clients that are behind the NAT gateway. If the value for `PacketsOutToDestination` is less than the value for `PacketsInFromSource`, there might be data loss during NAT gateway processing. Unit: Count Statistics: The most useful statistic is `Sum`.  | 
| PacketsOutToSource |  The number of packets sent through the NAT gateway to the clients in your VPC. A value greater than zero indicates that there is traffic coming from the internet to clients that are behind the NAT gateway. If the value for `PacketsOutToSource` is less than the value for `PacketsInFromDestination`, there might be data loss during NAT gateway processing, or traffic being actively blocked by the NAT gateway. Unit: Count Statistics: The most useful statistic is `Sum`.  | 
| PeakBytesPerSecond |  This metric reports the highest 10-second bytes per second average in a given minute. Units: Count Statistics: The most useful statistic is `Maximum`.  | 
| PeakPacketsPerSecond |  This metric calculates the average packet rate (packets processed per second) every 10 seconds for 60 seconds and then reports the maximum of the six rates (the highest average packet rate). Units: Count Statistics: The most useful statistic is `Maximum`.  | 

To filter the metric data, use the following dimension.


| Dimension | Description | 
| --- | --- | 
| NatGatewayId | Filter the metric data by the NAT gateway ID. | 

# View NAT gateway CloudWatch metrics


NAT gateway metrics are sent to CloudWatch at 1-minute intervals. Metrics are grouped first by the service namespace, and then by the possible combinations of dimensions within each namespace. You can view the metrics for your NAT gateways as follows.

**To view metrics using the CloudWatch console**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. In the navigation pane, choose **Metrics**, **All metrics**.

1. Choose the **NATGateway** metric namespace.

1. Choose a metric dimension.

**To view metrics using the AWS CLI**  
At a command prompt, use the following command to list the metrics that are available for the NAT gateway service.

```
aws cloudwatch list-metrics --namespace "AWS/NATGateway"
```

# Create CloudWatch alarms to monitor a NAT gateway


You can create a CloudWatch alarm that sends an Amazon SNS message when the alarm changes state. An alarm watches a single metric over a time period that you specify. It sends a notification to an Amazon SNS topic based on the value of the metric relative to a given threshold over a number of time periods. 

For example, you can create an alarm that monitors the amount of traffic coming in or leaving the NAT gateway. The following alarm monitors the amount of outbound traffic from clients in your VPC through the NAT gateway to the internet. It sends a notification when the number of bytes reaches a threshold of 5,000,000 during a 15-minute period.

**To create an alarm for outbound traffic through the NAT gateway**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. In the navigation pane, choose **Alarms**, **All alarms**.

1. Choose **Create alarm**.

1. Choose **Select metric**.

1. Choose the **NATGateway** metric namespace and then choose a metric dimension. When you get to the metrics, select the check box next to the **BytesOutToDestination** metric for the NAT gateway, and then choose **Select metric**.

1. Configure the alarm as follows, and then choose **Next**:
   + For **Statistic**, choose **Sum**.
   + For **Period**, choose **15 minutes**.
   + For **Whenever**, choose **Greater/Equal** and enter `5000000` for the threshold.

1. For **Notification**, select an existing SNS topic or choose **Create new topic** to create a new one. Choose **Next**.

1. Enter a name and description for the alarm and choose **Next**.

1. When you done configuring the alarm, choose **Create alarm**.

As another example, you can create an alarm that monitors port allocation errors and sends a notification when the value is greater than zero (0) for three consecutive 5-minute periods.

**To create an alarm to monitor port allocation errors**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. In the navigation pane, choose **Alarms**, **All alarms**.

1. Choose **Create alarm**.

1. Choose **Select metric**.

1. Choose the **NATGateway** metric namespace and then choose a metric dimension. When you get to the metrics, select the check box next to the **ErrorPortAllocation** metric for the NAT gateway, and then choose **Select metric**.

1. Configure the alarm as follows, and then choose **Next**:
   + For **Statistic**, choose **Maximum**.
   + For **Period**, choose **5 minutes**.
   + For **Whenever**, choose **Greater** and enter 0 for the threshold.
   + For **Additional configuration**, **Datapoints to alarm**, enter 3.

1. For **Notification**, select an existing SNS topic or choose **Create new topic** to create a new one. Choose **Next**.

1. Enter a name and description for the alarm and choose **Next**.

1. When you are done configuring the alarm, choose **Create alarm**.

For more information, see [Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) in the *Amazon CloudWatch User Guide*.

# Troubleshoot NAT gateways
Troubleshooting

The following topics help you to troubleshoot common issues that you might encounter when creating or using a NAT gateway.

**Topics**
+ [

## NAT gateway creation fails
](#nat-gateway-troubleshooting-failed)
+ [

## NAT gateway quota
](#nat-gateway-troubleshooting-quota)
+ [

## Elastic IP address quota
](#nat-gateway-troubleshooting-limits)
+ [

## Availability Zone is unsupported
](#nat-gateway-troubleshooting-unsupported-az)
+ [

## NAT gateway is no longer visible
](#nat-gateway-troubleshooting-gateway-removed)
+ [

## NAT gateway doesn't respond to a ping command
](#nat-gateway-troubleshooting-ping)
+ [

## Instances cannot access the internet
](#nat-gateway-troubleshooting-no-internet-connection)
+ [

## TCP connection to a destination fails
](#nat-gateway-troubleshooting-tcp-issues)
+ [

## Traceroute output does not display NAT gateway private IP address
](#nat-gateway-troubleshooting-traceroute)
+ [

## Internet connection drops after 350 seconds
](#nat-gateway-troubleshooting-timeout)
+ [

## IPsec connection cannot be established
](#nat-gateway-troubleshooting-ipsec)
+ [

## Cannot initiate more connections
](#nat-gateway-troubleshooting-simultaneous-connections)

## NAT gateway creation fails


**Problem**  
You create a NAT gateway and it goes to a state of `Failed`.

**Note**  
A failed NAT gateway is automatically deleted, usually in about an hour.

**Cause**  
There was an error when the NAT gateway was created. The returned state message provides the reason for the error.

**Solution**  
To view the error message, open the Amazon VPC console, and then choose **NAT Gateways**. Select the radio button for your NAT gateway, and then find **State message** on the **Details** tab.

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 error | Cause | Solution | 
| --- | --- | --- | 
| Subnet has insufficient free addresses to create this NAT gateway | The subnet that 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.  | Check how many IP addresses are available in your subnet by going to the Subnets page in the Amazon VPC console. You can view the Available IPs 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 attached | A 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 [Add internet access to a subnet](working-with-igw.md). | 
| Elastic IP address eipalloc-xxxxxxxx is already associated | The Elastic IP address that you specified is already associated with another resource, and cannot be associated with the NAT gateway. | Check which resource is associated with the Elastic IP address. Go to the Elastic IPs page in the Amazon VPC console, and view 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 [Start using Elastic IP addresses](WorkWithEIPs.md). | 

## NAT gateway quota


When you try to create a NAT gateway, you get the following error.

```
Performing this operation would exceed the limit of 5 NAT gateways
```

**Cause**  
You've reached the quota for the number of NAT gateways for that Availability Zone.

**Solution**

If you've reached this NAT gateway quota for your account, you can do one of the following:
+ Request an increase in the [NAT gateways per Availability Zone quota](https://console.aws.amazon.com/servicequotas/home/services/vpc/quotas/L-FE5A380F) using the Service Quotas console.
+ Check the status of your NAT gateway. A status of `Pending`, `Available`, or `Deleting` counts against your quota. 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 quota. 

For more information, see [Amazon VPC quotas](amazon-vpc-limits.md).

## Elastic IP address quota


**Problem**  
When you try to allocate an Elastic IP address for your public NAT gateway, you get the following error.

```
The maximum number of addresses has been reached.
```

**Cause**  
You've reached the quota for the number of Elastic IP addresses for your account for that Region.

**Solution**  
If you've reached your Elastic IP address quota, you can disassociate an Elastic IP address from another resource. Alternatively, you can request an increase in the [Elastic IPs quota](https://console.aws.amazon.com/servicequotas/home/services/ec2/quotas/L-0263D0A3) using the Service Quotas console.

## Availability Zone is unsupported


**Problem**  
When you try to create a NAT gateway, you get the following error: `NotAvailableInZone`.

**Cause**  
You might be trying to create the NAT gateway in a constrained Availability Zone — a zone in which our ability to expand is constrained. 

**Solution**  
We cannot support NAT gateways in these Availability Zones. You can create a NAT gateway in a different 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 zone.

## NAT gateway is no longer visible


**Problem**  
You created a NAT gateway but it's no longer visible in the Amazon VPC console.

**Cause**  
There might have been an error during the creation of your NAT gateway, and creation failed. A NAT gateway with a status of `Failed` is visible in the Amazon VPC console for about an hour). After an hour, it's automatically deleted.

**Solution**  
Review the information in [NAT gateway creation fails](#nat-gateway-troubleshooting-failed), and try creating a new NAT gateway.

## NAT gateway doesn't respond to a ping command


**Problem**  
When 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 an instance in your VPC, you do not get a response. 

**Cause**  
A NAT gateway only passes traffic from an instance in a private subnet to the internet.

**Solution**  
To test that your NAT gateway is working, see [Test the public NAT gateway](nat-gateway-scenarios.md#public-nat-gateway-testing).

## Instances cannot access the internet


**Problem**  
You created a public NAT gateway and followed the steps to test it, but the `ping` command fails, or your instances in the private subnet cannot access the internet.

**Causes**  
The cause of this problem might be one of the following: 
+ The NAT gateway is not ready to serve traffic.
+ Your route tables are not configured correctly.
+ Your security groups or network ACLs are blocking inbound or outbound traffic.
+ You're using an unsupported protocol.

**Solution**  
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 creation fails](#nat-gateway-troubleshooting-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.
  + Your instance must be in a private subnet with a route table that routes internet traffic to the NAT gateway.
  + 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.

   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.

  You can enable flow logs to help you diagnose dropped connections because of network ACL or security group rules. For more information, see [Logging IP traffic using VPC Flow Logs](flow-logs.md).
+ If you are using the `ping` command, ensure that you are pinging a host that has ICMP enabled. If ICMP is not enabled, 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 destination fails


**Problem**  
Some of your TCP connections from instances in a private subnet to a specific destination through a NAT gateway are successful, but some are failing or timing out.

**Causes**  
The cause of this problem might be one of the following:
+ The destination endpoint is responding with fragmented TCP packets. NAT gateways do not support IP fragmentation for TCP or ICMP. For more information, see [Compare NAT gateways and NAT instances](vpc-nat-comparison.md).
+ The `tcp_tw_recycle` option is enabled on the remote server, which is known to cause issues when there are multiple connections from behind a NAT device.

**Solutions**  
Verify whether the endpoint to which you're trying to connect is responding with fragmented TCP packets by doing the following:

1. Use an instance in a public subnet with a public IP address to trigger a response large enough to cause fragmentation from the specific endpoint.

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

   Diagnostic tools that send or receive large ICMP packets will report packet loss. For example, the command `ping -s 10000 example.com` does not work behind a NAT gateway.

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

If you have access to the remote server, you can verify whether the `tcp_tw_recycle` option is enabled by doing the following:

1. From the server, run the following command.

   ```
   cat /proc/sys/net/ipv4/tcp_tw_recycle
   ```

   If the output is `1`, then the `tcp_tw_recycle` option is enabled.

1. If `tcp_tw_recycle` is enabled, we recommend disabling it. If you need to reuse connections, `tcp_tw_reuse` is a safer option.

If you don't have access to the remote server, you can test by temporarily disabling the `tcp_timestamps` option on an instance in the private subnet. Then connect to the remote server again. If the connection is successful, the cause of the previous failure is likely because `tcp_tw_recycle` is enabled on the remote server. If possible, contact the owner of the remote server to verify if this option is enabled and request for it to be disabled.

## Traceroute output does not display NAT gateway private IP address


**Problem**  
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. 

**Cause**  
Your instance is accessing the internet using a different gateway, such as an internet gateway.

**Solution**  
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 350 seconds


**Problem**  
Your instances can access the internet, but the connection drops after 350 seconds.

**Cause**  
If a connection that's using a NAT gateway is idle for 350 seconds or more, the connection times out.

When a connection times out, a NAT gateway returns an RST packet to any resources behind the NAT gateway that attempt to continue the connection (it does not send a FIN packet). 

**Solution**  
To prevent the connection from being dropped, you can initiate more traffic over the connection. Alternatively, you can enable TCP keepalive on the instance with a value less than 350 seconds.

## IPsec connection cannot be established


**Problem**  
You cannot establish an IPsec connection to a destination.

**Cause**  
NAT gateways currently do not support the IPsec protocol.

**Solution**  
You can use NAT-Traversal (NAT-T) to encapsulate IPsec traffic in UDP, which is a supported protocol for NAT gateways. Ensure that you test your NAT-T and IPsec configuration to verify that your IPsec traffic is not dropped.

## Cannot initiate more connections


**Problem**  
You have existing connections to a destination through a NAT gateway, but you cannot establish more connections.

**Cause**  
You might have reached the limit for simultaneous connections for a single NAT gateway. For more information, see [NAT gateway basics](nat-gateway-basics.md). If your instances in the private subnet create a large number of connections, you might reach this limit. 

**Solution**  
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.
+ Use the [`IdleTimeoutCount`](vpc-nat-gateway-cloudwatch.md) metric in CloudWatch to monitor for increases in idle connections. Close idle connections to release capacity.
+ Create a NAT gateway with multiple IP addresses or add secondary IP addresses to an existing NAT gateway. Each new IPv4 address can support up to 55,000 concurrent connections. For more information, see [Create a NAT gateway](nat-gateway-working-with.md#nat-gateway-creating) or [Edit secondary IP address associations](nat-gateway-working-with.md#nat-gateway-edit-secondary).

# Pricing for NAT gateways
Pricing

When you provision a NAT gateway, you are charged for each hour that your NAT gateway is available and each gigabyte of data that it processes. For more information, see [Amazon VPC Pricing](https://aws.amazon.com/vpc/pricing/).

The following strategies can help you reduce the data transfer charges for your NAT gateway:
+ If your AWS resources send or receive a significant volume of traffic across Availability Zones, ensure that the resources are in the same Availability Zone as the NAT gateway. Alternatively, create a NAT gateway in each Availability Zone with resources.
+ If most traffic through your NAT gateway is to AWS services that support interface endpoints or gateway endpoints, consider creating an interface endpoint or gateway endpoint for these services. For more information about the potential cost savings, see [AWS PrivateLink pricing](https://aws.amazon.com/privatelink/pricing/).