Imagine that you have a contract to move an auto repair shop's servers on to AWS. They have a public web server, a private SQL server, and a private Node.js server that orders parts. The web server is easy enough to move, but how do you configure the private servers?
The problem is that you'll potentially want to run updates on the SQL server, and you'll need to allow the Node.js server to access API endpoints for your suppliers. How can you do this without opening up the server to the internet?
You'll need some sort of middleman to talk to the internet on behalf of your private servers. This middleman is called a NAT device.
A NAT device is a server that relays packets between devices on a private subnet and the internet. It relays responses back to the server that sent the original request. Since it only sends response packets to the private subnet, it keeps your private subnet secure.
The NAT works by replacing the source address of incoming packets with its own address and forwarding them to their destination on the internet. Similarly when the NAT receives an incoming packet, it replaces the destination address with the address of the server on the private subnet that sent the initial request.
The most common use case for a NAT device in AWS is to download updates on instances in a private subnet, but the NAT can be used any time you want to keep a subnet private and still allow it to talk to the internet.
You can use two different types of NAT devices in your VPC. The oldest of the two is called a NAT Instance, and the newer one is called a NAT Gateway.
A NAT Instance is really just an EC2 instance running a service in a public subnet.
Amazon currently provides a NAT AMI. You can find them by searching for
amzn-ami-vpc-nat in the name. You may, however, need to build your own NAT images in the future since Amazon built the NAT AMIs on a version of Amazon Linux that is EOL, and they don't plan on updating the NAT images.
Based on the AWS shared responsibility model, you will need to manage updating and scaling your NAT instance. As a tradeoff, you get more control over traffic routing, and you can run software on the instance beyond just a NAT service.
Performance of your NAT Instance will be up to you, since it can vary based on the instance type that you choose. For example, a
t3.micro instance can have up to 5 Gbps, but a
m5n.12xlarge can get 50 Gbps of bandwidth.
AWS NAT Gateway is the new, managed solution to setting up a NAT device in your VPC. Since it's a managed device, you can set it up once and forget about it. AWS will take care of automatically scaling and updating it as needed.
The NAT Gateway can scale to allow up to 45 Gbps through it. If you need more bandwidth, you can always create another one and send different subnet traffic through different gateways.
The cost of a NAT instance is just like any other EC2 instance. It’s determined by the type of instance and the amount of data transferred out to the internet.
When you use a NAT Gateway, you're charged for two things: a flat rate for every hour that it's running, and a fee for every GB that passes through it.
You can use the AWS Pricing Calculator to estimate the costs of VPC configurations. Using the example of the auto repair shop from the introduction, you can calculate some example costs. We'll assume that you'll be transferring 100 GB every month.
You can use the
m5n.12xlarge instance types from earlier to get an idea of the range of instance costs. Assuming that you want to run the instance all the time and use an EC2 Instance Savings Plan, you will get the following values:
If you follow AWS best practices in your VPC, you'll need to set up redundancy across multiple availability zones to ensure your application is highly available. This means you'll need to create a NAT Instance or Gateway for each availability zone (AZ). Depending on your availability requirements, this means you'll need to multiply each of the costs in the table by 2 at minimum.
Now that you know how much a NAT device is going to cost, you may be wondering if there's a way to reduce your AWS bill. Read on to learn a few of my favorite methods.
You can see from the comparison table above that the prices of NAT Instances can vary greatly. If you need bandwidth close to 45 Gbps, then you should definitely use the NAT Gateway. In the example above, you would save $1,278.92 and offload maintenance work onto Amazon.
On the other hand, if you need to run a bastion server and 5 Gbps is enough bandwidth, the
t3.micro is plenty. This would save $29.60 every month. While it's not as big of savings as switching from an
m5n instance to the NAT Gateway, you do gain the option of using it as a bastion server, too.
Another consideration is maintenance time and costs. If you’re at a smaller company where everyone has multiple roles, offloading maintenance time to AWS can provide a substantial productivity boost.
In the maintenance shop example, you need to keep the NAT device running all the time if the service places orders for parts throughout the day. If you change the service to place vendor orders at a specific time every day, you could turn on a NAT instance on a schedule.
If you want to use a NAT Gateway on a schedule, you certainly could do that. It'd be a bit more complicated though, since you would need to create and destroy the gateway on a schedule. You could set up a CloudWatch event that triggers a lambda that updates your VPC infrastructure.
The easiest way to save some money is to take advantage of AWS's always free resources. You can run a single
t3.micro for 750 hours a month for free. So if you don't have a lot of traffic (less than 5 Gbps), throw up a free NAT instance and use that money on something else.
A NAT device acts as a secure bridge between your private subnet and the internet. AWS provides two NAT device types: a NAT instance that you manage yourself, and a NAT gateway. Since there are some tradeoffs on performance, cost, maintenance, and configurability, you'll need to evaluate both options for your project.