AWS NAT Gateway is an important topic to understand regardless of your experience with AWS or any cloud provider. Any basic architecture is likely to use at least one NAT gateway.
This article will cover everything you need about AWS NAT Gateway.
What is AWS NAT Gateway?
First, a NAT stands for Network Address Translation. It’s a service that provides outbound connectivity to the Internet on instances deployed in a Private Subnet.
💡 Also, NAT Gateway is one of the components of a VPC. To learn more about all VPC components, you can download our Mind Map in PDF format and learn everything about it.
However, one crucial information is that external connection from the Internet can’t be established with that instance which uses NAT Gateway. Because of that, it’s pretty secure. You will learn more details. Continue reading.
Why use AWS NAT Gateway?
The primary and traditional use case, it’s to allow the instances from a Private Subnet to be able to reach the internet to install applications, update OS or apply patches.
💡 For example, there is no reason to deploy a database server in a Public Subnet. So, it is usually deployed on Private Subnet, where only internal connection within a VPC is allowed. However, the database server must reach out to the Internet to install and update the Operation System.
AWS NAT Gateway: Connectivity Types
When you go through the AWS Console to create a NAT Gateway, you will notice that you must choose between different connectivity types: Public and Private.
However, how do you know which one you should use? I see a lot of people confused about this topic.
Public NAT Gateway
The public is the default option and most used. It’s one we mentioned before, providing outbound connectivity to the instances deployed on a Private Subnet.
Private NAT Gateway
Also, you can create NAT Gateway using the Private connectivity type, which is great for a hybrid network (between your AWS account and on-premises).
Why use a Private NAT Gateway?
For example, you can allow your instances from a Private Subnet to connect with other VPCs. Also, allow connecting your instance from AWS with your servers from your data center (on-premise).
What makes it possible to connect instances from a Private Subnet to on-premises servers?
The Route Table from your Subnet it’s the core for any NAT solution for your network. You can route the traffic using the Route Tables from a NAT Gateway to a Transit Gateway or alternatively through a Virtual Private Gateway.
Specific Use Cases
There are several use cases to analyze and understand when you should use the Private NAT Gateway. I would like to highlight one specifically very important.
You will learn now that Private NAT Gateway is not only used for on-premise solutions; it can resolve complex problems like the following:
Sometimes, you could have different AWS accounts where you have one VPC on each account. Later, you decide to create a VPC peering connection between them.
However, you found one issue: Both VPCs share the same IP Range!
How to create a peering connection between VPCs which their IPs are in conflict, in other words overlapping? Such a scenario is not supported by the VPC Peering connection.
The only way to make VPCs with an overlapping network is by creating a NAT Gateway and using Transit Gateway between the instances and NAT Gateway. Like the diagram below:
What are the differences between the Public and Private NAT Gateway?
Both solutions require a static IP. However, here are some differences.
- It uses Elastic IP (Public IP)
- All Traffic from a NAT Gateway is routed to an Internet Gateway. This is the main reason AWS calls “Public” because you need to deploy the NAT Gateway within the same Subnet from the Internet Gateway.
- You can’t use Elastic IP.
- One IP from the same Subnet is reserved for the NAT Gateway. It means that the IP will use the same IP range as the Subnet.
- You can’t route traffic from a Private Gateway to an Internet Gateway.
How does NAT Gateway Works?
The Private and Public have different use cases. However, the core concept of how they work is the same.
Regardless of the connectivity type (Public or Private), any server’s source IP address is replaced by a NAT Gateway’s IP address. So, in other words, as you learned the difference between Private and Public previously, the source IP for a server from a Private Subnet will be the Private IP, and the source IP from a server from a Public NAT Gateway will be the Elastic IP.
Because you have one single IP, it makes it easier to manage Security Groups for a fleet of instances that share the same NAT Gateway.
For example, if you have several back-end servers that need to connect to a single database, and if the servers share the same NAT Gateway, the database will see a unique source IP and won’t be aware if you have one or more servers behind that IP. So, it means that you can allow a single IP on your database Security Group.
Mapping NAT Gateway on Route Table
As you can see, the Route Table above is from a Private Subnet, and the IP Rage is 10.170.0.0/22.
Everything (0.0.0.0/0) outside from Subnet will be routed automatically to NAT Gateway.
How much cost a NAT Gateway?
Should I worry about the cost? Yes, especially if you have huge traffic. Why?
The pricing model for NAT Gateway it’s similar to most parts of AWS services. It depends on how much data you transfer out of the Availability Zone and on an hourly basis for NAT Gateway itself.
The cost is different between the regions.
For Example, in North Virginia (us-east-1), the hourly cost is $0.045 when the NAT Gateway is provisioned and available.
The cost related to the data transfer, for example, 1 GB of data from EC2 to S3 via NAT Gateway, will cost $0.045 in North Virginia.
How to save money
Remember that you don’t pay, for example, to transfer data from an EC2 instance to an S3 Bucket if they are in the same region.
So, to save money, you must avoid data transfer between different Availability Zones. But how can you do it?
Simple: Deploy one NAT Gateway on each Availability Zone where you have servers that need a NAT Gateway.
NAT Gateway – Best Practices
Deploying NAT Gateway on each Availability Zone is not a matter of just saving money on the transfer data fee. But also to ensure a High Availability of your servers and application.
By default, the NAT Gateway is already High Available in its zone. However, you should consider a specific scenario you should avoid: Share the same NAT Gateway across different Availability Zone.
Let’s suppose that the Availability Zone from the NAT Gateway is compromised. It means that all resources within that Zone will be unavailable.
Will this event affect the connectivity from other instances from another Availability Zone? Yes.
And all your High Availability architecture will be inefficient.
NAT Gateway alternatives
There are several AWS services that require Internet connectivity to interact with them. However, you don’t need to rely on the NAT Gateway to use some AWS services like S3, DynamoDB, API Gateway, or Secret Manager. (and many others)
It’s common for new AWS users to have issues connecting or using some AWS services from an instance within a Private Subnet. They make a wrong assumption that the fact of the instance is within the AWS cloud; it doesn’t need internet connectivity to reach those services. But, to the surprise of some new users, yes!
However, having one NAT Gateway to forward traffic, for example, to retrieve passwords or any raw data from Secret Manager, it looks like an over-designed solution. Besides, it could be dangerous to transfer sensitive data through the internet.
To resolve that issue, you can use VPC Endpoint. AWS reference those service as “Interface Endpoint” or “Gateway Endpoint”. Basically, those services use the AWS network backbone to route the traffic from the instances to those services without going through the Internet.
When you decide to use a NAT Gateway, you must be aware of some limitations to prevent issues. What are those limitations?
List of NAT Gateway Limitations:
- You can have up to 5 NAT Gateway by Availability Zone
- The Bandwidth is from 5 Gbps up to 100 Gbps.
- 55,000 concurrent connections for a unique destination. It means that beyond that limit, you will see some connection issues.
- You can’t change the IP address after creating a NAT Gateway. So, if you need a new IP, you must replace it with a new one.
- There is no way to assign a Security Group to a NAT Gateway. To control the Inbound and Outbound traffic, you need to manage the rules in EC2 Security Group.
Testing NAT Gateway
At this point, you already know everything about NAT Gateway. However, the most important: How do you make sure that NAT Gateway is working properly?
There are several easy ways to test by doing a simple connectivity test.
You can use Linux commands like traceroute or ping. Or even a simple curl command.
Example using curl to test connectivity:
curl -4 ifconfig.co
The command above will return your external IP (Elastic IP) from your NAT Gateway. So you can see if it matches.