A legacy on-premises app cannot be rewritten soon, but the city must improve reliability in AWS while planning a later migration. Which approach fits Associate-level constraints?
Select an answer to reveal the explanation.
Short Explanation
You don’t have to rebuild city hall to add fire exits—put the legacy app on multi-AZ EC2 behind an ALB, snapshot the disks, and plan the rewrite later.
Full Explanation
Lifting a legacy on-premises application behind an Application Load Balancer with multi-AZ EC2 and EBS snapshots improves reliability in AWS without waiting for a full rewrite. The approach works at Associate level because many municipal systems cannot be re-architected immediately, yet they still need better AZ resilience and recoverability. Multi-AZ instances behind an ALB remove single-host/AZ SPOFs for the web or app tier, while EBS snapshots or AWS Backup provide a restore path for disk state. The city gains meaningful HA and RPO improvements as an interim landing zone while a later migration to containers or microservices is planned.
Refusing any HA until a full rewrite to microservices and event-driven design is complete fails by concept because citizens still need the legacy system during the multi-year rewrite; perfection becomes the enemy of interim resilience. Exposing the legacy app only via a single public IP on one instance with no load balancer fails because it preserves the classic SPOF the city is trying to escape. Deleting all backups because immutable containers will be adopted someday fails because future architecture aspirations do not protect today’s data from failure or corruption.
Exam caveat: lift-and-shift HA does not fix application session affinity bugs or single-writer assumptions—test the legacy app under multi-instance load. Operational check: place at least two instances across AZs behind an ALB, confirm health checks match real app readiness, enable snapshot schedules, and document which components still require sticky sessions or manual failover until the rewrite lands.