Amazon Virtual Private Cloud (VPC) service provides connectivity options to connect your Virtual Private Cloud (VPC) to other networks like VPCs, the internet, and your on-premises network.
Using NAT devices, your AWS resources in the private subnet of VPC can connect to other VPCs, the internet, and on-premises network, and your resources can have the capabilities to communicate with services outside of your VPC but cannot receive unsolicited connection requests. During the process, the NAT device replaces the source IPv4 address of your resources with the address of the NAT device, and while responding to your resources, the NAT device translates the addresses back to the original source IPv4 addresses.
There are two NAT devices; the first is a NAT gateway offered and managed by AWS, and the second is a NAT instance in which you can create your own NAT device on an EC2 instance. It’s recommended to use a NAT gateway as it requires less administration and it provides better availability and bandwidth.
In this blog, I’ll share the information and use cases of NAT gateways with a Private connectivity type.
Private NAT gateway allows your resources in private subnets to communicate to other VPCs or your on-premises network. You can route traffic from the NAT gateway through a target such as a transit gateway, or a virtual private gateway, or a peering connection.
NAT gateway is an Availability Zone specific resource and has redundancy in that zone. Optionally, you can share one NAT gateway for your resources in multiple Availability Zones, but if the NAT gateway’s Availability Zone is down, your resources in the other Availability Zones lose the connectivity options through the NAT gateway. Thus it’s best practice to have an Availability Zone-independent architecture by creating a NAT gateway in each Availability Zone and proper routing to ensure that your resources use the NAT gateway in the same Availability Zone.
A private NAT gateway obtains an available private IP address from the subnet in which it is configured, and it remains persistent until you delete the private NAT gateway and you cannot assign an elastic IP address with a private NAT gateway.
Use the following steps to create a private NAT gateway:
- Open the Amazon VPC console.
- In the navigation pane, select NAT Gateways.
- Choose Create NAT Gateway
- (Optional) Specify a name for the NAT gateway.
- Select a subnet in which you want to create the NAT gateway.
- For Connectivity type, select Private to create a private NAT gateway.
- (Optional) For each tag, select Add new tag and enter the key name and value.
- Select Create a NAT Gateway.
Once the private NAT gateway status is Available, you can update your route tables as needed.
Following are two popular approaches where a private NAT gateway can be leveraged:
Access your network using allow-listed IP addresses
To allow communication from your VPC to your on-premises network using a pool of allow-listed IP addresses through a private NAT gateway instead of allowing wide IP ranges of running instances subnets. Furthermore, in a scenario where communication is required from your resources in private subnets to a vendor’s environment over a site-to-site VPN tunnel, and the vendor only allows a small range of IP addresses in their environment.
To access the resources in the corporate data center from the instances running in a VPC through allow-listed IP addresses of a private NAT gateway:
- Identify the CIDR range for private NAT gateway subnets in VPC. Here, the CIDR range 100.64.0.0/27 is identified and assigned to VPC.
- Create new private subnets with previously assigned CIDR range in VPC. Here, the AZ1 subnet with the CIDR range 100.64.0.0/28 & the AZ2 subnet with the CIDR range 100.64.0.16/28 are created.
- Create a private NAT gateway in each newly created subnets of VPC.
- Update the route table of the subnets where instances are running in VPC to send traffic destined for the corporate data center to the respective private NAT gateway in the same AZ. Update the route table of the newly created subnets with the private NAT gateways in VPC to send all traffic destined for the corporate data center to the virtual private gateway.
The instances running private subnets 10.0.0.0/23 (10.0.0.0/24 & 10.0.1.0/24) originate the traffic destined for the corporate data center (172.17.0.0/16) to the private NAT gateways in the private subnets 100.64.0.0/27 (100.64.0.0/28 & 100.64.0.16/28). The traffic is routed through the private NAT gateways to the corporate data center, and the corporate data center receives the traffic with the source IP addresses of the private NAT gateways.
Routing
The following is the route table for the private subnets 10.0.0.0/23 (10.0.0.0/24 & 10.0.1.0/24):
The following is the route table for the private subnets 100.64.0.0/27 (100.64.0.0/28 & 100.64.0.16/28):
Access networks with overlapping CIDR ranges
To allow communication between two networks having overlapping CIDR ranges through a private NAT gateway.
To access the resources in VPC B from the instances running in VPC A:
- Identify CIDR ranges for each VPC which does not overlap for routing. Here, the CIDR range 100.64.0.0/28 for VPC A and the CIDR range 100.64.0.16/28 for VPC B is identified and assigned to respective VPCs.
- Create a new private routable subnet with previously added CIDR ranges for each VPC.
- Create a private NAT gateway in the routable subnet in VPC A.
- Create an application load balancer in the routable subnet and register the instances in the non-routable subnet with the target group in VPC B.
- Create a transit gateway and ensure route propagation is disabled. Attach VPC A and VPC B to the transit gateway using a routable subnet.
- Create a transit gateway route table and create a static route with a routable subnet of each VPC with their respective transit gateway attachments.
- Update the route table of the non-routable subnet in VPC A to send traffic destined for the routable subnet 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 subnet 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 subnet of VPC A to the transit gateway.
The instances running in the non-routable subnet of VPC A originate the traffic destined for the routable subnet of VPC B to the private NAT gateway in the routable subnet of VPC A. The traffic is routed through the private NAT gateway to the routable subnet of the VPC B load balancer. The load balancer receives the traffic with the source IP addresses of the private NAT gateway and distributes the traffic across non-routable subnet instances of VPC B.
Routing
The following is the route table for the non-routable subnets 10.0.0.0/24 in VPC A:
The following is the route table for the routable subnets 100.64.0.0/28 in VPC A:
The following is the route table for the non-routable subnets 10.0.0.0/24 in VPC B:
The following is the route table for the routable subnets 100.64.0.16/28 in VPC B:
The following is the transit gateway route table:
In this blog, you have learned about the Private NAT gateways and their use cases with transit gateway or virtual private gateway to communicate privately with other VPCs or on-premises environments.
For more information, visit Connect to other networks using NAT devices, NAT gateways, and NAT gateway use cases.
