A county constituent portal must remain available if an entire AWS Region fails. Architects currently run Multi-AZ inside one Region and assume that covers regional outages. What should they redesign for Region-level disruption?
Select an answer to reveal the explanation.
Short Explanation
Multi-AZ is a neighborhood generator backup—great when one block goes dark, useless when the whole town loses power. Region failure needs another Region, replicated data, and DNS that knows when to move traffic.
Full Explanation
Multi-AZ inside one Region protects against Availability Zone failure but does not cover entire Region disruption for a county constituent portal. A multi-Region architecture with cross-Region data replication and Route 53 or equivalent failover and health-based routing enables recovery outside the disrupted Region. Keeping single-AZ because Multi-AZ supposedly implies multi-Region failover confuses zonal with regional continuity. Disabling health checks so DNS never fails away traps users on unhealthy endpoints. Same-Region S3 versioning alone cannot keep a portal online when that Region is unavailable to clients. Exam caveat: multi-Region RPO/RTO depend on replication mode and runbook maturity—untested diagrams overstate readiness. Operational check: fail primary Region health, activate secondary data, shift DNS, and measure portal availability from an external client against regional RTO. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure.