There are workloads that you want to expose to the internet. And there are workloads you don't. It could be your backend for your web application. Or it could be an internal application not accessible to the public at all.

When this happens, you usually still need to access the internet from the virtual machines in the private subnet. In theory, you could put them in a public subnet, assign public IPv4 addresses, and block incoming traffic with security groups. But this would then get too complex as soon as you want to introduce load balancing into your application.

It's best to place public applications in public subnets and private applications in private subnets. The normal way you would give internet access to applications in private subnets is with NAT Gateways. But as with all things in life, those NAT Gateways cost money. If you want to run highly available applications over three availability zones, the NAT Gateways cost around $109/month. This is even more expensive than the servers in some cases.

But there is a workaround which can save you money: using NAT Instances instead of NAT Gateways.

In principle, NAT Instances work the same way as NAT Gateways. They route traffic to and from your instances in private subnets. This makes updates and backups, for example, possible even without public IP addresses. The difference is that a NAT Instance is an EC2 Instance that you configure and maintain. A NAT Gateway is an AWS-managed service that provides built-in redundancy within its availability zone and can be set up with a single click.

The downside of NAT Instances is that they require considerable effort to set up. You generally want to automate this process. The best way to do it is by building your own Amazon Machine Images (AMIs) with an automation tool, like HashiCorp Packer or AWS EC2 Image Builder.

After you created the AMIs with Packer, you can use them in your Terraform templates to spin up your NAT Instances. This saves you a lot of time you would otherwise spend on configuration. As with NAT Gateways, NAT Instances provide a single point of failure. This means you need to deploy them across availability zones. Automating these steps is key to becoming a DevOps engineer.

This brings me to the reason I am actually writing this article. Enterprise environments generally do not use NAT Instances. They use NAT Gateways. Their cloud bills are already so large that a few dollars extra does not bug them. And because they don't want the extra complexity of setting up NAT Instances, they usually don't use them. NAT Gateways are less complex to set up, and don't cost a lot of money on a large scale.

But here’s the point. They still need golden images for their virtual machines.

The reason you engineer AMIs with HashiCorp Packer to create your own NAT Instances is not to learn how to save money for enterprises. It is to learn how to use the tools that will eventually save money for enterprises. In this case the relevant areas are automation and networking.

To put it as plainly as possible. NAT Instances do not save money. But the knowledge you need to set them up does.

To conclude this post, the cost for three NAT Instances on EC2 instances will be around $22. This saves you $87 per month compared to NAT Gateways.