An architect places a NAT gateway inside a private subnet and updates that subnet's route table to send 0.0.0.0/0 traffic to the NAT gateway, hoping to give the private instances outbound internet access. The setup does not work. What is wrong?
- NAT gateways must be deployed in a public subnet that itself routes to an internet gateway
- NAT gateways can only be used with IPv6 traffic
- The route table update should point to the internet gateway instead
- NAT gateways require a security group allowing all outbound traffic
Correct answer: A. NAT gateways must be deployed in a public subnet that itself routes to an internet gateway
A NAT gateway needs its own path out to the internet, so it must be launched in a public subnet — one whose route table sends 0.0.0.0/0 to an internet gateway — and be assigned an Elastic IP. Placing it in a private subnet leaves the NAT gateway itself with no way to reach the internet, so nothing it forwards on behalf of private instances can get out either. Option B is wrong because NAT gateways translate IPv4 traffic; the IPv6 equivalent is an egress-only internet gateway, a different resource entirely. Option C is wrong because pointing the private subnet's route table directly at an internet gateway would require the instances to have public IPs, defeating the purpose of keeping them private. Option D is wrong because NAT gateways are fully AWS-managed and are not controlled by security groups; only the subnet's network ACL can restrict their traffic.
Source: AWS VPC docs: NAT gateways — how NAT gateways work