A logistics firm runs shipment tracking on self-managed PostgreSQL and RabbitMQ on EC2 with heavy patching overhead, needing HA, automated backups, and simpler deployment without rewriting apps. Which replatforming strategy best reduces operational overhead?
Select an answer to reveal the explanation.
Short Explanation
Patch Tuesdays should not run your roadmap. Managed data plus containers removes undifferentiated toil, so managed services handle HA and backups for you.
Full Explanation
The correct replatforming replaces undifferentiated operations with managed services while preserving compatibility: Aurora PostgreSQL remains wire-compatible with PostgreSQL so code stays unchanged while AWS handles patching, Multi-AZ availability, automated backups with point-in-time recovery, and storage scaling, RDS Proxy adds pooling for many short tracking connections, Amazon MQ provides managed RabbitMQ-compatible brokering preserving protocols and libraries, and ECS on Fargate removes host patching for simpler deployment. The RDS Multi-AZ plus SQS design fails on compatibility because SQS uses different APIs and semantics from RabbitMQ exchanges and routing, forcing rewrites despite managed availability and serverless compute. The Aurora plus EC2-hosted RabbitMQ design fails on messaging operations because self-managed brokers on EC2 retain patching, failover, and monitoring burden, missing the required overhead reduction and managed high availability. The Aurora plus Amazon MQ plus Docker on EC2 design fails on compute operations because containers on EC2 still need host patching and capacity management, unlike Fargate serverless. For exams, distinguish replatform to managed equivalents from refactor to different service models, favoring protocol compatibility when no rewrite is required, and as a practical check confirm Aurora version and extension support, Amazon MQ RabbitMQ compatibility, Proxy pooling mode, backup retention and Multi-AZ configuration, plus Fargate scaling and VPC connectivity for throughput.