Planeamiento de la migración de cargas de trabajo desde Amazon Web Services (AWS) a Azure

Este artículo forma parte de una serie sobre cómo migrar una carga de trabajo de Amazon Web Services (AWS) a Azure.

La fase de planeación consta de estos pasos:

El objetivo de la fase de planeación es comprender la carga de trabajo de AWS existente desde un punto de vista técnico y empresarial para que pueda crear con confianza un plan para replicarlo en Azure.

Evaluación de la carga de trabajo de AWS

Para crear un sistema comparable en Azure, primero debe comprender completamente el sistema actual. Evalúelo desde varias perspectivas para asegurarse de que finalmente diseñe una implementación de Azure que satisfaga igualmente las necesidades de los usuarios, operadores, desarrolladores, cumplimiento y partes interesadas empresariales.

1. Documente la arquitectura de carga de trabajo existente: Documente completamente y compruebe la arquitectura de la carga de trabajo. Incluya todas las dependencias de carga de trabajo, como configuraciones de red, flujos de datos e integraciones externas.

2. Autenticación y autorización de documentos: Incluya configuraciones de administración de identidades y acceso (IAM) en la evaluación. Documentación completa sobre cómo AWS controla la autenticación y la autorización es fundamental para diseñar un equivalente de Azure seguro y funcional.

3. Usar herramientas de detección: Use herramientas específicas de AWS, como detección de cargas de trabajo en AWS, para visualizar la carga de trabajo de AWS. Esta herramienta usa datos de AWS Config y AWS Systems Manager para ayudar a identificar los componentes, las dependencias y las relaciones de la carga de trabajo. Use herramientas de Azure, como Azure Migrate, para ayudarle a detectar más componentes de carga de trabajo de AWS y a realizar recomendaciones específicas de Azure.

4. Identificar flujos críticos: Asigne interacciones y flujos de trabajo esenciales del usuario y del sistema. Al diseñar la arquitectura de destino en la sección siguiente, esta información le ayuda a priorizar los esfuerzos de confiabilidad y a proteger los componentes más importantes e impactantes frente a errores.

5. Cree un inventario detallado: Haga una lista de lo que el entorno de AWS actual necesita para ejecutar la carga de trabajo, incluidos todos los servidores, componentes de almacenamiento, bases de datos y servicios. Incluya también patrones de uso, métricas de rendimiento y requisitos de licencia.

6. Implicar a expertos en la materia (SMEs): Además de las herramientas de detección automatizadas, involucra a expertos en todo el equipo responsable de las cargas de trabajo para descubrir dependencias ocultas, relaciones complejas de componentes y estado confidencial. Las herramientas suelen perder componentes críticos, como scripts programados, integraciones no documentadas o configuraciones heredadas. Una conversación con pymes puede revelar estos matices y evitar un comportamiento inesperado durante la migración. Incluya su entrada en el plan de migración y el manual de operaciones.

7. Evaluar las aptitudes de su equipo: Céntrese en el mapeo de capacidades equivalentes. Identifique las aptitudes que su equipo ya usa en AWS y alinee con los servicios y herramientas de Azure equivalentes. Incluya el entrenamiento de Azure en la escala de tiempo del proyecto para preparar la carga de trabajo y los equipos de operaciones. Este enfoque reduce la fricción y crea confianza con Azure porque la experiencia existente en AWS se traduce directamente en el nuevo entorno.

8. Documente los compromisos existentes: Documente la base de referencia de rendimiento definida de la carga de trabajo, incluido el rendimiento, la latencia, las tasas de error y el uso de recursos. Si estos indicadores clave de rendimiento (KPI) no están disponibles, recopile estas métricas del entorno de AWS para establecer esta línea de base. Estos KPI se usan en la fase de evaluación después de la migración para validar que la carga de trabajo de Azure funciona como hizo en AWS.

   Averigüe si hay acuerdos de nivel de servicio (SLA) o objetivos de nivel de servicio (SLO) asociados a la carga de trabajo. Estos compromisos con los usuarios o partes interesadas no cambian en función de la plataforma en la nube. Por ejemplo, si el objetivo de tiempo de recuperación (RTO) en AWS es de 45 minutos, debe diseñar la carga de trabajo en Azure para que también tenga un RTO de 45 minutos.

9. Documente la supervisión y las alertas actuales: Documente cómo supervisa actualmente la carga de trabajo en AWS. Por ejemplo, puede usar métricas, alarmas o paneles de CloudWatch. Planee la supervisión equivalente de Azure para el entorno de destino. Puede usar registros, métricas o paneles de Application Insights de Azure Monitor. Póngase en contacto con el equipo de operaciones en esta evaluación para que estén listos para implementar y administrar alertas y supervisión basadas en Azure.

Diseño de una arquitectura similar a la de Azure

Muchas cargas de trabajo modernas basadas en la nube usan servicios administrados o sin servidor en lugar de máquinas virtuales (VM) para muchas de sus funciones. Si la carga de trabajo de AWS usa servicios administrados, como Amazon Elastic Kubernetes Service (EKS) o Amazon Elastic Container Service (ECS), debe encontrar la mejor coincidencia en Azure para su caso de uso. En algunos casos, Azure puede tener varios servicios entre los que puede elegir, como las aplicaciones en contenedores. Elija el servicio más similar. Por ejemplo, no cambie las plataformas de orquestación de contenedores durante la migración.

En el diagrama siguiente se muestra un ejemplo de arquitectura similar para una carga de trabajo de Kubernetes en AWS y Azure.

Para empezar a asignar su arquitectura equivalente, primero establezca una base sólida.

Comience con el networking. Analice los requisitos de red de la carga de trabajo con el equipo de la plataforma. Esta explicación debe abarcar la arquitectura de destino y la conectividad de migración. AWS Transit Gateway actúa como centro de red con Amazon Virtual Private Cloud (VPC) como red de radio. En el diseño de la zona de aterrizaje de aplicaciones de Azure, el equipo de la plataforma aprovisiona redes virtuales de radio para los equipos de carga de trabajo. Estas redes de radio se comunican con otras redes internas y externas a través del centro o de la red Azure Virtual WAN.

Para intercambiar datos durante la migración, puede usar una red privada virtual (VPN) de sitio a sitio o Azure ExpressRoute con AWS Direct Connect. Puede confiar en una VPN de sitio a sitio para migraciones más pequeñas o de prueba de concepto (POC). Se recomienda ExpressRoute con AWS Direct Connect para migraciones a escala de producción o transferencias de datos grandes. Si utiliza ambas opciones para una fiabilidad mejorada, use la VPN de sitio a sitio para la conmutación automática ante fallos.

Para más información, consulte Migración de redes de AWS a Azure.

Después de planear su red, siga estos pasos:

1. Identifique los servicios de Azure. Use la guía de comparación de recursos de AWS a Azure para ayudarle a elegir los componentes de Azure de la carga de trabajo. Cree POC para obtener confianza o ayudarle a elegir componentes y su configuración. Use las guías del servicio Azure Well-Architected Framework para ayudar a garantizar que su arquitectura similar es funcionalmente equivalente y optimizada para las características de la plataforma y los procedimientos recomendados en Azure.

2. Planear la administración de identidades. Planee cómo controlar la identidad y el acceso en Azure para los usuarios y para las operaciones de carga de trabajo. Si la carga de trabajo usa roles de AWS IAM o proveedores de identidades federados, determine cómo se traducen estos roles a roles de Microsoft Entra ID, identidades administradas o entidades de servicio principal. Revise los nombres de recursos de Amazon (ARN) codificados de forma codificada, las directivas de IAM o las integraciones de identidad en la aplicación. Si pasa por alto el mapeo de identidades, podría enfrentar problemas de acceso después de la migración o integraciones interrumpidas. La integración con los proveedores de identidades de asociados es un desafío durante las migraciones. Si es posible, consolide la administración de identidades mediante la transición a Microsoft Entra ID.

3. Documente las decisiones de migración. Documente los recursos que no migra y las decisiones de arquitectura que tome.

4. Reducir los riesgos. Identifique los componentes o flujos de alto riesgo y cree POC según sea necesario para probar y mitigar esos riesgos. Realice el análisis del modo de error (FMA) en los componentes para encontrar de forma proactiva posibles puntos de error y evaluar cómo afectan a la confiabilidad de la carga de trabajo. Los componentes de Azure pueden tener nuevos modos de error o producir errores de forma diferente a sus homólogos de AWS.

5. Compruebe la disponibilidad. Compruebe la disponibilidad y la capacidad del servicio de Azure en su región preferida, especialmente si planea usar tipos de recursos especializados. Al seleccionar la región de destino, alinee estrechamente con la región actual de AWS. La migración a una región de Azure geográficamente similar ayuda a mantener una latencia coherente.

6. Validar los requisitos. Si decide usar Azure Migrate, revise la matriz de compatibilidad de Azure Migrate para asegurarse de que las instancias de AWS cumplen los requisitos de configuración y del sistema operativo (SO). Si no usa Azure Migrate, compruebe manualmente la compatibilidad de la carga de trabajo con los servicios de Azure. Esta comprobación incluye la comprobación de las versiones admitidas del sistema operativo, los tamaños de máquina virtual, las configuraciones de disco y las dependencias de red.

7. Cumpla los requisitos de cumplimiento y seguridad. Asegure una postura de seguridad coherente en su carga de trabajo. Asegúrese de que la implementación de Azure coincide con las expectativas de seguridad, como la aplicación de revisiones de seguridad del sistema operativo, el aislamiento de red, la inspección de entrada y salida, el acceso con privilegios mínimos, el análisis de código estático y las programaciones de pruebas de penetración.

   Asegúrese de que cualquier infraestructura temporal, conexiones de red y procesos que cree para facilitar la migración también satisfaga las expectativas de seguridad. Las migraciones pueden ser caóticas, y un descuido o atajo en la seguridad durante la migración podría provocar un incidente.

   El modelo de seguridad que aws usa es significativamente diferente del modelo de seguridad de Azure. Para más información, consulte Migración de servicios de seguridad desde AWS.

Desarrollo y documentación de un plan de migración y creación de un runbook

Desarrolle un plan de migración y cree un runbook para la migración de AWS a Azure. Elija una estrategia de transición, seleccione enfoques de migración de datos en función de los requisitos del objetivo de punto de recuperación (RPO) y documente los procedimientos en un runbook detallado. Cree un plan completo aprobado por las partes interesadas que minimice el riesgo y garantice una transición controlada.

Su estrategia de transición

Planee cómo cortar el tráfico de producción desde el entorno de AWS al entorno de Azure. Los enfoques siguientes son los más comunes:

• Migración de Big Bang: Se migra y se cambia todo simultáneamente dentro de una ventana de mantenimiento.
• Migración por fases: Los componentes de carga de trabajo se migran de forma incremental.
• Migración azul-verde (recomendada): Dos entornos se ejecutan en paralelo y se cambia el tráfico después de la validación.

Diferencias clave de un vistazo

Para mantener el riesgo bajo y revertir fácilmente, elija un enfoque azul-verde. En este escenario, se mantienen dos entornos. Azul es el entorno actual (AWS) y verde es el nuevo entorno (Azure).

En el escenario azul-verde, planea una ventana de migración, ejecuta la carga de trabajo en AWS durante toda la migración y mueve el tráfico a Azure después de una ejecución seca correcta. Ambos entornos se ejecutan en paralelo durante toda la migración, por lo que puede cambiar el tráfico a AWS si surgen problemas en el entorno de Azure. En este escenario, también necesita una estrategia de reversión para el estado que podría cambiar. Considere las bases de datos y un estado menos obvio, como los elementos no procesados en las colas de mensajes.

Si la carga de trabajo es más compleja y desea minimizar el riesgo, puede combinar la estrategia azul-verde con un enfoque canario para redirigir el tráfico. El enfoque controlado enruta un pequeño porcentaje de tráfico al nuevo entorno y, a continuación, aumenta incrementalmente. El enfoque canario aumenta la complejidad de la migración porque el estado activo debe existir tanto en AWS como en Azure durante la transición.

Si cualquier componente en AWS coexiste con componentes que se ejecutan en Azure, considere la posibilidad de aplicar patrones como la Strangler Fig façade como parte de una estrategia de transición controlada. Estas capas adicionales de direccionamiento indirecto se implementan en la siguiente fase de migración.

El enfoque azul-verde introduce un equilibrio de costos. Incurrirás en costos con ambos proveedores de nube durante la transición. Para la mayoría de los equipos, los costos adicionales merecen la pena porque la estrategia azul-verde reduce el riesgo y la carga operativa.

Planeamiento de una ventana de mantenimiento

Se recomienda negociar una ventana de mantenimiento generosa durante la fase de planificación para la estrategia de transición que use. Una ventana suficiente respeta la naturaleza confidencial de las actividades de migración y tiene en cuenta la pérdida de funcionalidad durante la migración. Use este tiempo de inactividad planeado para desarrollar planes que reduzcan el riesgo de pérdida de datos, daños en los datos o experiencias de usuario incoherentes. Por ejemplo, use este tiempo para vaciar mensajes de Amazon Simple Queue Service (SQS).

Si su carga de trabajo tiene un presupuesto para interrupciones, considere excluir la ventana de migración de ese presupuesto y reservarla para problemas posteriores a la migración. Tenga en cuenta cómo afecta esta decisión a los Acuerdos de Nivel de Servicio contractuales.

Elección de la estrategia de migración de datos

La estrategia de migración de datos depende de la cantidad de datos, el tipo de almacenamiento de datos y los requisitos de uso. Decida entre la migración sin conexión (copia de seguridad y restauración) y la replicación en vivo.

Alinee la estrategia con el RPO de su carga de trabajo. Consulte el RPO de la carga de trabajo para guiar las decisiones durante la fase de retirada y al elegir una estrategia de migración de base de datos. El RPO es la cantidad máxima de pérdida de datos que puede aceptar como parte de la transición. Por ejemplo, un RPO podría no permitir más de cinco minutos de pérdida de datos durante la transición. Minimice el riesgo de pérdida de datos deteniendo las operaciones de cambio de estado dentro de la tarea de trabajo antes de realizar la transición.

Cuanto menor sea el RPO, más debe considerar la replicación continua, copias de seguridad recientes o ventanas de mantenimiento. Los RPO más bajos también pueden aumentar el costo y el esfuerzo para migrar los datos.

Migre la base de datos. Evalúe las herramientas de AWS y Azure para la migración de la base de datos. Por ejemplo, puede usar Azure Data Studio para replicar Amazon Relational Database Service (Amazon RDS) para SQL Server en Azure SQL Database. Esta característica admite la replicación continua de Amazon RDS a SQL Database. También puede usar AWS Database Migration Service (AWS DMS), que proporciona replicación continua y captura de cambios de datos hasta que se realiza la transición.

En la mayoría de los escenarios, la migración de datos se produce en varias fases. Por ejemplo, puede realizar una migración inicial para pruebas y validación, seguida de una migración de transición final o sincronización continua para garantizar la actualización de los datos. Este enfoque permite a los equipos validar el comportamiento de la aplicación en Azure antes de la migración final. También reduce el riesgo de pérdida de datos y admite la planificación de reversión.

Transferir datos de almacenamiento. Tenga en cuenta las siguientes opciones para transferir datos de almacenamiento de Amazon Simple Storage Service (Amazon S3) a Azure.

Planee una ventana de mantenimiento. Programe una ventana dedicada para los pasos finales de transición y retirada. Documente y comuniquelo con las partes interesadas antes de iniciar la migración. Incluya tiempo para una posible reversión y cambio del Sistema de Nombres de Dominio (DNS).

Documentar en un runbook

Documente la siguiente información en un runbook para compartir con todos los equipos y partes interesadas implicados en la migración.

Secuencia de pasos: Documente la secuencia de pasos en un nivel alto. Defina los pasos exactos, su secuencia y el tiempo de migración. Incluya la ventana de mantenimiento planeado en la documentación. Considere incluir una simulación, especialmente para transiciones complejas. Documente la estrategia de reversión, el período de vida de DNS (TTL) y cómo probar las métricas de éxito.

Configuración de seguridad y redes: Incluya todos los cambios en las reglas de firewall, las aperturas de puertos necesarias y las actualizaciones de los grupos de seguridad de red (NSG) o los grupos de seguridad de aplicaciones (ASG) necesarios para admitir la conectividad de Azure. Documente las excepciones o anulaciones temporales necesarias durante la transición y asegúrese de que los procedimientos de reversión tengan en cuenta estos cambios.

Criterios de aceptación de aprobación final: Defina lo que significa una operación estable y haga que sea medible. Por ejemplo, acepte que después de la migración, Azure debe ejecutarse durante un número específico de minutos o horas sin errores y que la carga de trabajo supere todas las pruebas.

Criterios y pasos del desencadenador de reversión: Documente las condiciones exactas que desencadenan una reversión al entorno de AWS. Por ejemplo, inicie una reversión si alguna funcionalidad crítica está inactiva o el sistema está en un estado degradado, como un porcentaje específico por debajo de la línea base, durante más de un número especificado de minutos. Documente los pasos de reversión.

En función de los cambios de estado, las reversiones pueden ser más complejas que mitigar el problema en Azure. Los intentos fallidos de mitigación también pueden complicar el proceso de reversión. Comprenda cuándo debe corregir un problema y cuándo debe revertir los cambios para ayudar a reducir el riesgo durante la migración.

Cambios en la configuración del cliente: Identifique y documente todos los elementos de configuración orientados al cliente que afecta la migración de la carga de trabajo. Estos elementos incluyen puntos de conexión DNS, flujos de autenticación y cadenas de conexión. Implique a los equipos cliente pronto y comunique los próximos cambios, escalas de tiempo y responsabilidades.

Cambios de tráfico y enrutamiento: Planee y documente los cambios de enrutamiento del tráfico con detalle. Defina exactamente cómo actualizar registros DNS, configuración del equilibrador de carga y reglas de enrutamiento para dirigir el tráfico a Azure. Considere cualquier valor de TTL que configure porque determina cuánto tiempo tardan los cambios de DNS en propagarse.

Muchas aplicaciones y scripts hacen referencia a nombres de dominio completos (FQDN) para puntos de conexión, API y servicios. Si los FQDN cambian inesperadamente durante la migración, las integraciones pueden interrumpirse. Como parte de la planificación de enrutamiento y transición, realice un inventario de todos los FQDN que usa la carga de trabajo. Decida si desea conservar los nombres existentes a través del reenvío DNS o actualizar las configuraciones de la aplicación para usar nuevos FQDN de Azure. En el caso de los servicios orientados al público, planee la transición de DNS cuidadosamente para minimizar el tiempo de inactividad y garantizar una transición sin problemas.

Revise el plan con las partes interesadas y concilie las expectativas diferentes. Incluya los equipos de administración de riesgos y seguridad de TI desde el principio y asegúrese de que aprueban el plan. Un taller conjunto en esta etapa puede ayudar a minimizar los retrasos en fases posteriores.

Una vez que las partes interesadas y los responsables de la toma de decisiones revisen y acepten el plan y el runbook, pasen a la fase de preparación.

Salidas y artefactos

Al final de la fase de planificación, debe tener implementados los siguientes elementos:

• Diagrama de arquitectura objetivo
• Registros de decisión de arquitectura (ADR)
• Presupuesto y estimaciones de costos
• Runbook y cronograma de migración
• Aprobación de las partes interesadas del plan de migración

Checklist

Paso siguiente