AWS: NAT Gateway in public subnet. Why?

Question

As I understand it, a public subnet is one that can route traffic to the internet via an Internet Gateway, and a private subnet is one that cannot (can't reach the internet nor it can be reached from it). In order to reach the internet, a private subnet needs to route traffic through a NAT Gateway.

I can confirm this because I am actually using this setup successfully.

But... the Amazon docs say otherwise (bold emphasis is mine):

The instances in the public subnet can receive inbound traffic directly from the Internet, whereas the instances in the private subnet can't. The instances in the public subnet can send outbound traffic directly to the Internet, whereas the instances in the private subnet can't. Instead, the instances in the private subnet can access the Internet by using a network address translation (NAT) instance that you launch into the public subnet.

Does it matter where the NAT gateway resides? If it does, what are the use cases of putting it in a private/public subnet?

Answer 1

A NAT Gateway (as well as a NAT Instance, for what it's worth) must be in a public subnet because only devices on public subnets can actually use a public IP address.

That's what makes a public subnet a public subnet.

The pedantic definition of a public subnet is a subnet whose associated VPC route table has at least one route pointing to the Internet Gateway... but in practice, it's usually a subnet with its default route (in the VPC route table) pointing to the Internet Gateway.

By contrast, a private subnet is a subnet without such a route. Usually, the default route for a private subnet points to a NAT device, though it could point to a hardware VPN or Direct Connect connection.

If a NAT device isn't on a public subnet, it (by definition) has no routes by which the traffic it has translated can reach the Internet, because its outgoing traffic follows the route table for the subnet on which it is located... so the subnet the NAT Gateway is placed on -- again, by definition -- must be a public subnet.

There is no security implication of placing a NAT Gateway on a public subnet, since incoming connection attempts are never accepted under any circumstances. This is something you can't misconfigure.

If you're thinking in LAN terms, the natural assumption is that a NAT device needs to be "on" at least 2 subnets, the external (public addresses) subnet and the internal (private addresses) subnet -- but the VPC network is not the LAN it appears to be. It's a software-defined layer 3 network that emulates Ethernet very cleanly, but it isn't Ethernet.

Answer 2

The difference between public and private addressing is that ISPs have agreed not to route packets using the arbitrarily assigned private addressing. From the perspective of IP, there is actually no difference between private and public addresses, and addressing is done the same way with either.

The logical place for NAT is where you connect a private network to an ISP, which will not route packets with private addresses. This is usually at the edge of the private addressing zone, but that is not necessarily the best place. For example, many companies have both private and public addresses, and it isn't necessary to NAT between the public and private zones within the company, but it is required between the company and any ISPs the company uses for any traffic using private addresses to and from the public Internet. That location may be in a company's public zone if all the traffic with private addressing flows through the company's public zone to get to the public Internet.

Answer 3

NACLs and route-tables apply to a NAT-gateway, so you can consider NAT-gateway as another EC2 instance and hence it needs to be in public subnet to access internet-gateway and route traffic.

I dont see any other uses of NAT-gateway in AWS, which cant be solved by route-tables.