Private subnet egress depends on a single NAT Gateway in one Availability Zone. What redesign removes that single point of failure?
Select an answer to reveal the explanation.
Short Explanation
One NAT in one AZ is a single drawbridge—if that island floods, private subnets can’t get out. Put a NAT in each AZ and aim routes locally. Opening every instance to the public internet or banning egress altogether “solves” the wrong problem.
Full Explanation
Private subnet egress that depends on a single NAT Gateway in one Availability Zone fails when that AZ or NAT fails, blackholing outbound patching and API calls from other AZs that routed to it. The redesign is to deploy NAT Gateways in each AZ used by private subnets and update route tables so each private subnet’s default route targets the NAT in its local AZ. That removes the cross-AZ NAT single point of failure for municipal private workloads such as patch management and private API calls.
Keeping one NAT Gateway and disabling AZ-aware routing preserves the single point of failure for the sake of simpler troubleshooting theater. Replacing all private subnets with public subnets and assigning public IPs to every workload abandons private placement the city likely requires for those tiers. Removing NAT entirely and requiring sneaker-net USB patching is not a viable enterprise egress strategy for ongoing operations.
Exam caveat: highly available egress means per-AZ NAT Gateways with matching routes, not one shared NAT for all AZs—NAT Gateway capacity and failure domains are AZ-scoped. Operational check: place a NAT in each AZ, set private route tables accordingly, terminate the NAT in AZ-a during a test, and confirm AZ-b private instances still reach required endpoints via their local NAT without cross-AZ dependency.