NAT Gateways#

Just like an Internet Gateway, a NAT Gateway (NATGW) allows us to route traffic between our VPC, its subnets, and the public Internet. But there's a key difference: unsolicited traffic from the Internet cannot initiate a connection to a resource inside the VPC. NATGWs are for enabling Internet connection in the other direction: from inside the VPC to the Internet, with the NATGW automatically routing the response (from the remote Internet based host that was contacted) back to the internal resource.

What NATGWs do, to a point, is act as a security architectural barrier because they allow us to prevent access to our resources from the public Internet, whilst allowing our resources to send data to the public Internet without needing a public IP. We can route traffic to our resources from the public Internet using other methods, like load balancers (we cover these later.)

Let's create a visual workflow of this:

This diagram illustrates how a NATGW works. The connection from our "App Server" is now coming from 10.1.1.30 (the EC2 Instance no longer has a public IP in this example.) That connection is routed to the NATGW, which performs Network Address Translation (NAT), "converting" (sort of) the internal IP to the public IP 4.5.6.7. It's the 4.5.6.7 address that the remote server on 1.2.3.4 sees. When the remote server replies, the NATGW is aware of the connection from 10.1.1.30 and it translates the IP address back from 4.5.6.7 to 1.2.3.4 so that the internal server can get the reply.

Also observe that the 1.2.3.4 server tries to make a connection to 4.5.6.7, the NATGW, but it fails. NATGWs do not support the handling of insolicited connections from the Internet to internal systems, only the other way around.

The benefits of a NATGW is security and efficiency: one entire VPC can use a single NATGW for all the internal servers (which no longer need a public IP address), enabling them to connect to the Internet to reach updates and more.

It's also worth noting how a NATGW doesn't attach to the VPC like an IGW does. Instead, a NATGW goes into its own subnet, raising a few interesting questions about its capabilities and redundancy. Visually this looks like this:

A NATGW isn't as redundant as an IGW. IGWs are fully managed, as are NATGWs, but an IGW is VPC wide and therefore is completely insensitive to Availability Zone (AZ) failures. NATGWs are very sensitive to an AZ failure, because a NATGW has to be placed inside of a subnet, and a subnet can only exist inside of a single AZ - if the AZ fails, the subnet fails, and everything in it loses connectivity to the Internet.

So besides the differences in how an IGW routes traffic versus a NATGW, there's also the fact you'll need multiple NATGWs, one in each AZ, to avoid connectivity issues. It's also worth noting that NATGWs cost money, a lot of money (relative to an IGW) and as such they're a more expensive routing option.

Which one you use will depend on the use case(s) on an architecture by architecture basis.

We won't go any further into NATGWs right now, but we will later on.