After an AZ failure, failover targets for a city’s multi-AZ app are unreachable even though instances launched. What networking baseline should architects verify?

After an AZ failure, architects should verify that route tables and subnet placement keep failover targets reachable—with correct routes to NAT, Internet Gateway, or peering as designed—because launched instances that cannot reach dependencies are not recovered service. The networking baseline works as the root-cause check when compute appears healthy yet the city’s multi-AZ app still fails: private subnets may lack a path to NAT in surviving AZs, peering or Transit Gateway routes may have pointed only at the failed AZ’s attachments, or application subnets may not have been spread correctly. HA is a networking design as much as an Auto Scaling design; reachability after AZ loss must be intentional.

That only one private subnet exists for all AZs and shares a single broken route entry fails as a desired baseline—it describes an anti-pattern that concentrates failure. Claiming security groups alone define VPC routing and that route tables can be empty fails by concept because security groups filter connections; they do not replace route tables that select gateways and paths. Giving every instance a public IP in a private subnet with no route to any gateway fails because a public address without a valid IGW/NAT path still leaves the instance unreachable for the designed flows.

Exam caveat: “instances launched” in CloudWatch or the console can look green while application health checks fail for DNS, NAT, or dependency routing reasons. Operational check: after AZ impairment drills, traceroute or VPC reachability analysis from failover subnets to NAT/IGW/peering targets, confirm each AZ’s route table is independent and correct, and fix shared single-route designs before declaring multi-AZ readiness.