A manufacturer runs aging MySQL on VMs and containerized schedulers on VMs, spending weekends patching OS and databases while planning an AWS migration with minimal code changes and lower operational overhead. Downtime windows are short and staff is small. Which replatforming strategy using managed services should the migration architect recommend?

The recommended strategy fits both workloads with minimal change and sharply reduced patching because Amazon Aurora remains MySQL-compatible for replatforming with automated backups, patching, failover and read scaling, while Amazon ECS on Fargate runs existing containers without provisioning or patching EC2 hosts or Kubernetes control planes, preserving images and scheduling logic for a small team with short windows. Migrating the database to RDS for MySQL with Lambda schedulers is operationally attractive but fails the minimal-change constraint because extracting embedded scheduler logic into event-driven functions typically requires redesign, testing and new observability. Pairing Aurora with EKS using managed nodes keeps relational compatibility but fails the lower-overhead constraint because cluster upgrades, networking, rightsizing and node lifecycle still demand Kubernetes skills and ongoing attention compared to serverless Fargate. Moving relational data to DynamoDB while keeping Fargate preserves container benefits but fails compatibility and downtime constraints because changing to NoSQL requires schema redesign, query rewrites and extensive validation. On exams, distinguish rehost lift-and-shift from replatform managed-substitution from refactor rewrite by matching operational and code-change keywords to the stem. In practice, confirm source MySQL version compatibility with Aurora, inventory container CPU memory and cron dependencies, and validate with a pilot using AWS DMS and a Fargate task definition before cutover.