Application Migration Service (MGN)

AWS Application Migration Service (MGN) es el servicio principal de AWS para realojar (lift and shift) servidores locales —físicos o virtuales— en Amazon EC2. MGN replica continuamente los servidores de origen en un área de preparación de AWS, por lo que, cuando esté listo para migrar, la ventana de cambio será muy breve (minutos en lugar de horas). MGN admite servidores Windows y Linux de cualquier hipervisor o entorno bare-metal.

MGN instala un AWS Replication Agent ligero en cada servidor de origen. El agente establece una conexión cifrada a través del puerto TCP 1500 y replica continuamente los cambios de disco a nivel de bloque en un área de preparación de su Región de AWS de destino. El área de preparación consta de Replication Servers de bajo coste (que MGN lanza automáticamente) y volúmenes de EBS que reflejan los discos de origen prácticamente en tiempo real. La replicación no provoca ningún tiempo de inactividad.

Cada servidor de origen tiene una Launch Template que define cómo se configurará la instancia de EC2 migrada: tipo de instancia, subred, grupos de seguridad, perfil de instancia de IAM, tipos de volúmenes de EBS y si se asignará una IP pública. Debe configurar la plantilla de lanzamiento antes de realizar las pruebas. MGN utiliza esta plantilla al lanzar una instancia de prueba o de cambio a partir de las instantáneas de EBS replicadas.

La fase de Test de MGN le permite lanzar una instancia de EC2 de prueba a partir de la instantánea replicada más reciente sin detener el servidor de origen. Ejecute pruebas básicas de la aplicación, valide la conectividad de red y compruebe que el servidor migrado se inicia y responde correctamente en AWS. Después de realizar las pruebas, termine la instancia de prueba y la replicación continuará; durante la prueba, el origen activo no se ve afectado en absoluto.

Cuando tenga confianza en los resultados de las pruebas, inicie el cambio. MGN toma una instantánea final de los discos de origen, lanza la instancia de EC2 de cambio y el servidor de origen deja de recibir nuevas replicaciones de escritura. Actualice el DNS para que apunte a la nueva instancia de EC2. Toda la ventana de cambio —desde que se inicia el cambio hasta que la nueva instancia de EC2 está activa— suele durar menos de 15 minutos, lo que permite utilizar ventanas de mantenimiento muy breves.

MGN admite Post-Launch Actions: scripts que se ejecutan automáticamente en la instancia de EC2 migrada inmediatamente después del lanzamiento. Utilícelos para instalar agentes de monitorización (CloudWatch Agent, SSM Agent), aplicar configuraciones de referencia de seguridad, registrar la instancia en sistemas CMDB internos o ejecutar comprobaciones de estado de validación. Las acciones posteriores al lanzamiento se asocian a una plantilla de lanzamiento y se ejecutan mediante Systems Manager Run Command, lo que reduce los pasos manuales posteriores a la migración.

AWS ofrecía anteriormente Server Migration Service (SMS) para la migración de servidores. MGN es su sucesor y actualmente es el servicio recomendado. Entre las mejoras principales de MGN se incluyen las siguientes: replica a nivel de bloque (no a nivel de instantánea), lo que permite una replicación continua prácticamente en tiempo real en lugar de instantáneas periódicas; admite una gama más amplia de entornos de origen; y proporciona un flujo de trabajo de cambio de prueba sin interrupciones. Si una pregunta de examen menciona SMS como opción, prefiera MGN, a menos que la pregunta trate específicamente sobre SMS.

MGN replica a través de una conexión TLS cifrada en el puerto 1500 hasta el Replication Server del área de preparación. La replicación inicial sincroniza todos los datos de los discos de origen, lo que puede requerir mucho ancho de banda. Para servidores grandes en centros de datos con un ancho de banda de Internet limitado, considere utilizar AWS Direct Connect o AWS Site-to-Site VPN para transportar el tráfico de replicación en lugar de la Internet pública. Después de la sincronización inicial, solo se envían los cambios incrementales de bloques.

MGN tiene un modelo de precios sencillo: es gratuito durante los primeros 90 días por servidor y, después, se aplica un cargo por servidor y hora. El área de preparación genera cargos por las instancias de EC2 de Replication Server (normalmente t3.small) y por los volúmenes de EBS que replican los discos de origen. Minimizar la duración total de la replicación realizando las pruebas y el cambio rápidamente permite mantener los costes bajos. No se cobra por el propio MGN Agent.

En el examen SAA-C03, MGN aparece en escenarios que requieren una migración de servidores rápida y de bajo riesgo. Indicadores clave: realojar con un tiempo de inactividad mínimo, realizar lift and shift de cientos de servidores, una ventana de cambio breve y ningún cambio en la aplicación. Compárelo con DMS (migración de bases de datos), Snowball (transferencia masiva de datos sin un servidor activo) y Glue/DataSync (movimiento de datos entre servicios de almacenamiento). MGN es para servidores, no para bases de datos ni transferencias de datos puras.

Para aplicaciones de varios niveles (servidores web, de aplicaciones y de bases de datos que deben migrarse juntos), MGN admite agrupaciones de tipo Wave y Application. Agrupe los servidores de origen en una aplicación y, después, lance las pruebas y el cambio para todo el grupo en secuencia, de modo que los niveles dependientes se inicien en el orden correcto. Esto evita el fallo habitual de migrar un servidor web antes de que su servidor de base de datos esté disponible en AWS.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que MGN proporciona replicación continua a nivel de bloque desde servidores locales hasta AWS para realizar cambios con un tiempo de inactividad prácticamente nulo, que la función de pruebas sin interrupciones permite validar los servidores migrados sin detener el origen y que Post-Launch Actions automatiza la configuración posterior a la migración mediante Systems Manager. A continuación, exploraremos Database Migration Service para conocer escenarios de migración específicos de bases de datos.