NAT Gateways: Advantages and Disadvantages

Network and cloud development teams know they have to secure certain workloads from hackers or other threat actors. In cloud service provider (CSP) consoles, turning up infrastructure typically starts with choosing whether you want a public or private subnet. A public one means that your endpoints will be exposed to the internet, which in some cases, is the most convenient option because most workloads need some level of inbound and outbound communication ability with applications external to your company. 

Private subnets are often the default option in how-to guides to set up cloud services. One, private subnets are less vulnerable to attacks. Two, there are limits to how many public IPs you can get on an account. 

Once you choose to have a private subnet, you’ll have to decide whether you want to NAT your traffic in order for your virtual machines (VMs) to communicate with external applications over the public internet. You want to be able to protect your internal endpoints, but you also want your applications to poll third-party APIs and run software updates. 

One of the easiest ways to NAT your traffic is to use the CSP’s NAT gateway. In this blog, we’ll break down the advantages and disadvantages of using this fully managed service so you can decide whether a NAT gateway is appropriate for your use cases.   



Cloud NAT gateways don’t use proxy devices, which can end up being a choke point for traffic. In the case of Google Cloud NAT, for example, each virtual instance is given a unique pool of NAT IP addresses and port ranges, enabling greater scalability and giving each instance as much bandwidth as those on a public subnet. For AWS NAT gateway, they require Elastic IPs (EIPs), which are static and public IPv4 addresses, to enable NAT.

Cuts operational labor

If you had to set up NAT yourself with your own devices, here are just a few things you’d have to do:

  • Reserve a pool of static IP address
  • Create compute instance groups
  • Set up health checks to monitor those instances
  • Create default routes
  • Set up and maintain a NAT proxy appliance over time.

With a fully managed NAT gateway, many of those tasks are taken care of for you.

Configurability via Software-Defined Networking

When you use a NAT gateway, it’s configurable via a software-defined network interface. In Google Cloud, you can set up Cloud NAT in the regions your VMs are in, set up a Cloud Router, and choose the NAT IP addresses, which can be automatically allocated or you can bring your own static IPs in. 

In AWS, you can configure an internet gateway, add a NAT gateway as a public subnet, and configure your routing tables in your private subnets to forward internet traffic through your NAT gateway.


Doesn’t do inbound NAT

Cloud NAT services are designed to secure your internal endpoints and improve your security posture, but there may be times when you want to configure ingress NAT, particularly when your applications in the private subnet of one cloud provider need to communicate with applications in another cloud provider’s VPC and vice versa.

Metered pricing

The most common complaint about NAT gateways is the pricing model. The CSPs charge by the hour for device usage, and then they charge data transfer fees of five cents a GB. There are no volume discounts for escalating traffic levels. There’s also no free tier for lower levels of traffic.

So that means that if you NAT 1GB of traffic, it’s five cents per GB, and if you NAT petabytes of data, it’s still five cents. At higher levels of data transfer, your NAT gateway bill can get expensive fast.

Not appropriate for every cloud use case

As mentioned above, using private subnets is often a default for cloud developers because private means more secure, and if you go private, you’ll probably want to consider NAT. But not every cloud use case requires NAT and therefore, not all of your traffic needs to go through a NAT gateway even if you choose to use one. 

There are other ways to achieve NAT, including setting up your own bastion host or adding VPC endpoints. For applications that are less mission- or business-critical, using public subnets might be the way to go.

Are you looking for an alternative to NAT gateways?

We covered alternatives to NAT gateways, including using PacketFabric Cloud Router for NAT functions, in a previous blog. If you’re wondering whether a NAT gateway is right for your use case, we’re happy to talk to you about it. Reach out to one of our sales engineers.