El dominio D4 (20%) evalúa la capacidad de seleccionar la estrategia de migración correcta para cada aplicación y las herramientas específicas de AWS para ejecutarla. Las 7 Rs, DMS, MGN y el Snow Family son garantizados en el examen.
Contenido
Las 7 Rs (antes 6 Rs) es el framework de AWS para clasificar aplicaciones según su estrategia de migración. Cada aplicación en el portfolio necesita una R asignada basada en su complejidad, valor de negocio y dependencias.
Rehost
"Lift and Shift"Mover la aplicación a AWS sin cambios. Misma arquitectura, misma configuración — solo cambia el hardware subyacente.
Usar cuando:
Migración rápida, bajo riesgo, plazo corto, sin tiempo de modernización.
No usar cuando:
No aprovecha beneficios cloud como auto-scaling, managed services.
Relocate
"Hypervisor Lift and Shift"Mover VMware on-premises a VMware Cloud on AWS sin convertir a EC2. Los VMs mantienen su formato.
Usar cuando:
Gran inversión en VMware on-premises, quieren velocidad sin recertificar equipos.
No usar cuando:
No aplica para apps en hardware non-VMware.
Replatform
"Lift, Tinker and Shift"Pequeñas optimizaciones sin cambiar la arquitectura core. Migrar a managed services con mínimo esfuerzo.
Usar cuando:
Quieren beneficios de managed services sin rediseño de app.
No usar cuando:
Requiere algo de trabajo de adaptación — no es un lift puro.
Refactor
"Re-architect"Rediseñar la aplicación para aprovechar al máximo cloud-native. Más costoso y lento, mayor valor largo plazo.
Usar cuando:
App que necesita escala masiva, reducción de costo operacional, mayor agilidad.
No usar cuando:
No viable para apps legacy complejas con plazos cortos.
Repurchase
"Drop and Shop"Abandonar el software on-premises y reemplazarlo con una solución SaaS.
Usar cuando:
Software commodity sin ventaja competitiva diferenciada.
No usar cuando:
Si la app tiene customizaciones profundas difíciles de replicar en SaaS.
Retire
"Decommission"Identificar y eliminar aplicaciones que ya no son necesarias. Reduce costo y complejidad del portfolio.
Usar cuando:
10-20% del portfolio típicamente. Apps sin uso, funcionalidad duplicada.
No usar cuando:
Si la app tiene usuarios activos o dependencias conocidas.
Retain
"Revisit"Mantener on-premises por ahora. Para apps con razones de cumplimiento, latencia crítica o reciente inversión.
Usar cuando:
Mainframes críticos, apps con latency < 1ms, compliance que prohíbe cloud.
No usar cuando:
Debe ser temporal — revisar en próximo ciclo de migración.
El CAF identifica capacidades organizacionales que deben desarrollarse para una migración exitosa. Organiza las capacidades en 6 perspectivas (Perspectives).
Business
Asegura que TI esté alineada con el negocio. ROI, casos de negocio.
People
Gestión de cambio organizacional. Habilidades, roles, training.
Governance
Gestión de riesgos y compliance. Portfolio management.
Platform
Arquitectura de sistemas y datos. Procesos de deploy.
Security
IAM, detección de amenazas, respuesta a incidentes.
Operations
Monitoreo, continuidad de negocio, gestión de cambios operacionales.
MGN (antes CloudEndure Migration) es el servicio de rehost (lift-and-shift) de AWS. Replica servidores físicos, virtuales o de otras nubes a AWS continuamente con mínimo downtime de cutover.
Proceso de migración con MGN
Instalar Replication Agent
Agente en el servidor origen que inicia la replicación continua a nivel de bloque.
Replicación continua
Los datos se replican en tiempo real a un Staging Area en AWS (EC2 de bajo costo).
Launch Test Instance
Lanzar una instancia de prueba para validar que todo funciona sin afectar producción.
Cutover Window
Ventana de corte mínima (minutos). MGN convierte la última réplica en instancia de producción.
MGN vs SMS (Server Migration Service)
AWS SMS — DEPRECADO
El antiguo servicio de migración. Ya no recibe nuevas funcionalidades. Las preguntas del examen que mencionan SMS están siendo reemplazadas por MGN.
MGN — Recomendado
Replicación continua a nivel de bloque (más rápida y confiable), menor downtime en cutover, soporta más plataformas de origen.
DMS migra bases de datos a AWS con mínimo downtime usando replicación continua de cambios (CDC — Change Data Capture). Soporta migraciones homogéneas (Oracle→Oracle) y heterogéneas (Oracle→Aurora).
| Escenario | Herramienta |
|---|---|
| MySQL on-premises → Aurora MySQL | DMS sola (homogénea — mismo engine family) |
| Oracle on-premises → Aurora PostgreSQL | AWS SCT (Schema Conversion Tool) + DMS |
| SQL Server → RDS SQL Server | DMS sola (homogénea) |
| MongoDB → DynamoDB | DMS con endpoint de origen MongoDB |
| Data Warehouse Oracle/Teradata → Redshift | AWS SCT + DMS |
| Replicación continua como CDC (ongoing replication) | DMS con ongoing replication tasks |
DMS Replication Instance
El trabajo de DMS corre en una Replication Instance (EC2 gestionada). No en la fuente ni en el destino. Para minimizar la latencia de replicación, despliega la replication instance en la misma VPC/región del destino.
| Dispositivo | Capacidad | Compute edge? | Mejor para |
|---|---|---|---|
| Snowcone | 8–14 TB HDD/SSD | Sí (EC2, IoT Greengrass) | Entornos edge con espacio muy limitado, IoT, misiones remotas |
| Snowball Edge Storage Optimized | 80 TB por nodo | Sí (EC2, Lambda) | Migración de NAS, backup de datacenter, edge computing moderado |
| Snowball Edge Compute Optimized | 42 TB + GPU opcional | Sí (EC2, FPGA, GPU) | ML en edge, procesamiento video en ubicaciones remotas |
| Snowmobile | 100 PB por camión | No | Migración de datacenter completo (exabytes de datos) |
¿Cuándo usar Snow vs DataSync/Direct Connect?
Si el tiempo de transferencia por red supera semanas o meses → Snow Family. Regla: si tienes 100 TB y 1 Gbps de internet disponible, la transferencia dura ~9 días (sin overhead). Para 100 TB con 100 Mbps = 90 días → Snow es mejor. Para transferencias recurrentes una vez establecida la red → DataSync o Direct Connect.
AWS DataSync — transferencia de datos acelerada
Transfiere datos de NFS, SMB, HDFS, S3 on-premises hacia S3, EFS, FSx. Hasta 10× más rápido que herramientas estándar. Automatiza validación de integridad.
AWS Storage Gateway — extensión híbrida
Conecta aplicaciones on-premises con almacenamiento en S3 de forma transparente. No es para migración one-time — es para integración híbrida continua.
Migration Hub es el panel central para rastrear el progreso de la migración de aplicaciones, independientemente de las herramientas usadas (MGN, DMS, etc.). Agrega el estado de todas las migraciones en curso.
Application Discovery Service
Agente o sin agente para inventariar servidores on-premises, dependencias de red y patrones de uso. Input al plan de migración.
Migration Hub Orchestrator
Automatiza y orquesta flujos de migración multi-servicio con plantillas pre-construidas para SAP, SQL Server, etc.
Migration Hub Strategy
Analiza el portfolio de aplicaciones y recomienda estrategias de modernización (las 7 Rs).
Refactor Spaces
Facilita la transición incremental de monolitos a microservicios sin downtime usando proxy routing.
Trampa: "DMS puede migrar cualquier base de datos sin herramientas adicionales"
Realidad: Para migraciones heterogéneas (diferente engine, ej: Oracle → PostgreSQL), debes usar AWS Schema Conversion Tool (SCT) primero para convertir el esquema. DMS maneja la migración de datos, SCT convierte el schema.
Trampa: "Snowball Edge es solo para transferencia de datos"
Realidad: Snowball Edge tiene capacidad de compute (EC2, Lambda) además de almacenamiento. Se puede usar para procesamiento en el edge en ubicaciones sin internet (manufactura, buques, bases militares).
Trampa: "MGN y SMS son equivalentes y ambos están en uso"
Realidad: SMS está deprecado. MGN es el reemplazante oficial. Si el examen menciona SMS en una respuesta incorrecta, úsalo como señal de trampa.
Trampa: "Refactor siempre es la mejor estrategia de migración"
Realidad: Depende del contexto. Refactor es el más costoso y lento. Para plazos cortos o apps que se van a retirar pronto, Rehost es la opción correcta. La "mejor" estrategia depende de los requisitos del negocio.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene 5 PB de datos en un datacenter on-premises que debe migrar a Amazon S3 en 3 semanas. Tienen una conexión de internet de 1 Gbps al datacenter. ¿Cuál es la forma más práctica de completar la migración en el plazo dado?
Inicia sesión para llevar tu progreso.