Users on the internet cannot open a city's public web instances. Those instances have public addresses, and their subnet route table sends 0.0.0.0/0 to a NAT gateway. A private subnet in the same VPC is the one that was meant to use that NAT gateway. What should change?
Select an answer to reveal the explanation.
Short Explanation
Return traffic from a public instance is taking the hallway to the NAT gateway, and that hallway does not lead back to the person who knocked. You point the public subnet's default route at the internet gateway. The NAT gateway stays the private subnet's door, not the public one's.
Full Explanation
A public subnet that should answer internet clients needs 0.0.0.0/0 targeted at the internet gateway. Pointed at a NAT gateway, return packets for connections that started on the internet are not delivered back to those clients. The private subnet is the one that should use the NAT gateway, so the fix is to give the public subnet its own route, or to retarget this table, toward the internet gateway. Removing public addresses makes the instances unreachable from the internet rather than fixing the return path. A route table cannot hold two default routes as a way to use both targets. Flow logs will show the symptom and will not change the route. Caveat: if both subnets currently share this table, split them before you retarget the default route, or the private instances lose their NAT path. Operational check: the public table's default target should be the internet gateway, and a test connection from the internet should complete. Internet gateways and NAT gateways solve different directions. The internet gateway is what makes a public address answer someone who connected first. The NAT gateway is for private instances that open their own outbound connections. Once the public subnet has its own table, check that its association is the one you edited and not a second subnet you did not mean to move.