A county is using AWS Application Migration Service to move a permitting app. What must the cutover target architecture include for resilience?
Select an answer to reveal the explanation.
Short Explanation
Migration is the moment to stop copying bad habits—do not lift a single-AZ SPOF into AWS and call it done. Target multi-AZ from day one of cutover. Familiar failure modes are not a feature.
Full Explanation
When a county uses AWS Application Migration Service to move a permitting app, cutover is the moment to improve resilience rather than faithfully reproduce on-premises single points of failure. The cutover target architecture must land on a multi-AZ high-availability topology in AWS—load-balanced compute across Availability Zones, Multi-AZ data stores, and removal of one-box dependencies—so citizens gain cloud HA instead of a lifted SPOF with new branding.
Lifting the workload into a single Availability Zone to minimize subnet count fails because subnet simplicity is not an HA strategy and recreates AZ-level outage risk. Placing all migrated servers in one public subnet with no load balancer fails by combining exposure, lack of distribution, and no health-based replacement path. Keeping the on-premises SPOF design unchanged so cutover stays familiar fails conceptually: familiarity with failure is not a municipal resilience goal.
Exam caveat: Application Migration Service moves servers efficiently, but HA topology is an architecture choice at landing—you must design Multi-AZ targets, not assume MGN creates them automatically. Operational check: define Multi-AZ subnets, ALB/NLB, and Multi-AZ database targets before cutover; validate health checks; and retire the single-AZ interim pattern as part of the go-live checklist.