Una empresa está migrando dos aplicaciones Node.js sencillas de un entorno local a AWS. Una aplicación recopila datos de sensores y los escribe en una base de datos MySQL; la otra agrega datos en informes. Cuando se ejecutan los trabajos de agregación, algunos trabajos de carga fallan. La migración debe resolver los fallos de carga y realizarse sin interrupciones ni cambios visibles para los clientes. ¿Qué debería recomendar un arquitecto de soluciones?

La opción correcta aborda todos los requisitos: AWS DMS permite la replicación continua y sin interrupciones de la base de datos local a Aurora MySQL. Ejecutar los trabajos de agregación en una réplica de Aurora descarga la base de datos principal, resolviendo los fallos de carga sin afectar las escrituras. Alojar los puntos finales de recopilación como funciones Lambda detrás de un ALB proporciona escalabilidad y resiliencia, mientras que Amazon RDS Proxy gestiona eficientemente las conexiones a la base de datos, evitando interrupciones durante la migración. Finalmente, actualizar el DNS del recopilador al ALB completa la migración sin cambios visibles para los clientes. Las opciones incorrectas fallan en varios aspectos: La primera opción sugiere configurar una instancia de Aurora como objetivo de replicación para la base de datos local, lo cual no es el método estándar para una migración sin interrupciones. La segunda opción propone instancias EC2 en un grupo de Auto Scaling, lo cual es menos eficiente y escalable para aplicaciones sencillas que Lambda. La cuarta opción introduce Kinesis, que es una solución más compleja y no necesaria para este caso de uso, además de no abordar la replicación de la base de datos existente de manera óptima.