CLF-C02
Deep Dive
Migrar a AWS no es solo mover servidores — es una transformación del negocio. Comprende los beneficios del AWS Cloud Adoption Framework (CAF), las 7 estrategias de migración y las herramientas que AWS ofrece para planificar y ejecutar la migración.
Contenido
Según el AWS Cloud Adoption Framework (CAF), migrar a la nube genera cuatro grandes categorías de beneficios para el negocio.
Reducción del riesgo del negocio
Mayor resiliencia, recuperación ante desastres más rápida, seguridad gestionada por AWS, cumplimiento de estándares globales. Reduce la exposición a fallos de hardware y ciberataques.
Mejora de ESG (Medioambiente, Social, Gobernanza)
Menor huella de carbono al consolidar infraestructura en centros de datos de alta eficiencia de AWS. AWS opera con energía renovable. Reduce el consumo eléctrico propio.
Aumento de ingresos
Lanzamiento más rápido de productos y funcionalidades, expansión global en minutos, capacidad de experimentar e innovar sin inversión inicial de hardware.
Eficiencia operacional
Automatización de tareas manuales, eliminación de mantenimiento de hardware, equipos de TI redirigidos a proyectos de mayor valor diferenciador en lugar de gestión de infraestructura.
AWS define 7 estrategias de migración (las "7 R's") para mover cargas de trabajo a la nube. Cada aplicación puede requerir una estrategia diferente según su arquitectura, valor de negocio y tolerancia al cambio.
Identificar aplicaciones que ya no son necesarias y eliminarlas. No tiene sentido migrar lo que no se usa.
Cuándo usar
Aplicaciones obsoletas, sistemas legados que nadie usa actualmente, duplicados funcionales.
Esfuerzo
Ninguno
Ejemplo
Sistema de reportes legacy reemplazado por una solución SaaS moderna.
Mantener aplicaciones on-premises por ahora. Puede ser por dependencias técnicas, regulación o falta de urgencia.
Cuándo usar
Apps que acaban de ser renovadas, requisitos regulatorios estrictos, no hay business case para migrar todavía.
Esfuerzo
Ninguno
Ejemplo
Base de datos Oracle con contrato de mantenimiento vigente por 2 años más.
Mover la aplicación tal cual está a AWS, sin cambiar la arquitectura ni el código. La misma app, en EC2 en lugar de servidores propios.
Cuándo usar
Migración rápida, minimizar riesgo de cambio, fase inicial de migración masiva.
Esfuerzo
Bajo
Ejemplo
Servidor web Apache + MySQL on-premises movido a EC2 + RDS sin cambios.
Hacer optimizaciones menores para aprovechar la nube sin cambiar la arquitectura core. No hay reescritura de código, solo ajustes.
Cuándo usar
Quieres reducir costos de gestión sin reescribir. Puedes aceptar algunas optimizaciones de configuración.
Esfuerzo
Medio
Ejemplo
Migrar base de datos MySQL on-premises a Amazon RDS (misma app, AWS gestiona el SO y los parches).
Reemplazar la aplicación por un producto diferente, típicamente SaaS. Abandonar la versión actual y adoptar un producto cloud-native.
Cuándo usar
El proveedor tiene una versión SaaS superior, la app actual es costosa de mantener.
Esfuerzo
Bajo a medio (configuración SaaS)
Ejemplo
Reemplazar sistema CRM on-premises por Salesforce o HubSpot.
Reimaginar cómo se diseña la aplicación usando características cloud-native. Cambios profundos de arquitectura para mejor rendimiento, escala o mantenibilidad.
Cuándo usar
La app tiene necesidades urgentes de escala/rendimiento que no puede satisfacer en su estado actual.
Esfuerzo
Alto
Ejemplo
Monolito Java migrado a microservicios en AWS Lambda + API Gateway + DynamoDB.
Mover infraestructura a AWS a nivel de hipervisor, sin necesidad de comprar hardware nuevo. Específico para migraciones de VMware a AWS (VMware Cloud on AWS).
Cuándo usar
Entorno VMware que quieres migrar masivamente a AWS sin reescribir nada.
Esfuerzo
Bajo (automatizado a nivel hipervisor)
Ejemplo
Mover 500 VMs de VMware on-premises a VMware Cloud on AWS en días.
Para el examen — Trampa frecuente
Rehost = Lift-and-shift puro. Sin cambios. Solo mueve la VM a EC2.
Replatform = Lift-tinker-and-shift. Pequeña optimización (ej: pasar a RDS). Sin reescritura.
Refactor = Reescritura profunda. Microservicios, serverless, cloud-native.
Repurchase = Cambia a un SaaS. No migras la app — la reemplazas.
El AWS CAF proporciona orientación y mejores prácticas para ayudar a las organizaciones a desarrollar un plan eficiente para la adopción de la nube. Define 6 perspectivas que cubren todos los aspectos de una migración exitosa.
Business
Perspectiva: Negocio
Alinea la migración con los objetivos de negocio. Define el business case y el ROI de la nube. Stakeholders: directores, jefes de negocio.
People
Perspectiva: Personas
Gestión del cambio organizacional. Capacitación del equipo, nuevas estructuras de roles, cultura cloud-first. Stakeholders: RRHH, directores de personal.
Governance
Perspectiva: Gobernanza
Controles de gestión, políticas de uso de la nube, gestión de riesgos y compliance. Stakeholders: CIO, gestores de programas, arquitectos empresariales.
Platform
Perspectiva: Plataforma
Principios de arquitectura, diseño de la plataforma target en AWS, patrones de migración técnica. Stakeholders: CTO, arquitectos de soluciones.
Security
Perspectiva: Seguridad
Modelo de responsabilidad compartida, controles de seguridad, clasificación de datos, gestión de identidad. Stakeholders: CISO, equipos de seguridad.
Operations
Perspectiva: Operaciones
Procesos operativos, monitoreo, gestión de eventos, continuidad del negocio. Stakeholders: IT operations, site reliability engineers.
CAF y las 7 R's juntos
El CAF define la preparación organizacional (cultura, personas, gobernanza) mientras las 7 R's definen la estrategia técnica para cada aplicación individual. En una migración real: primero CAF para evaluar madurez, luego 7 R's para planificar cada workload.
AWS ofrece un conjunto completo de herramientas para cada fase de la migración: descubrimiento, planificación, ejecución y seguimiento.
AWS Application Discovery Service
DescubrimientoRecopila información sobre la infraestructura on-premises antes de migrar. Descubre servidores, dependencias entre aplicaciones, uso de CPU/memoria/red. Genera un inventario automático para planificar la migración.
Para el examen
Cuando el escenario menciona "inventario on-premises" o "descubrir qué hay en el datacenter", la respuesta es Application Discovery Service.
AWS Application Migration Service
EjecuciónServicio principal de lift-and-shift automatizado (anteriormente CloudEndure Migration). Replica servidores físicos, virtuales o en la nube a AWS en tiempo real con mínimo downtime.
Para el examen
Para migrar servidores físicos o VMs a AWS automáticamente (Rehost/lift-and-shift).
AWS Migration Hub
SeguimientoProporciona una ubicación centralizada para rastrear el progreso de las migraciones de aplicaciones. Consolida el estado de todas las migraciones en un solo panel, independientemente de qué herramienta se esté usando.
Para el examen
Centralizar y monitorear el estado de una migración masiva con múltiples herramientas.
AWS Migration Evaluator
PlanificaciónAnaliza el uso on-premises actual y genera un business case con el TCO (Total Cost of Ownership) comparando on-premises vs AWS. Antes llamado TSO Logic.
Para el examen
Cuando el escenario pide "justificar la migración con datos de costos" o "crear un business case para migrar".
AWS Database Migration Service (DMS)
Migración de datosMigra bases de datos a AWS con mínimo downtime. Soporta migraciones homogéneas (MySQL → RDS MySQL) y heterogéneas (Oracle → Aurora PostgreSQL). La base de datos origen permanece operativa durante la migración.
Para el examen
Migrar una base de datos a AWS con mínimo downtime. Siempre DMS para datos en movimiento.
AWS Schema Conversion Tool (SCT)
Migración de datosConvierte automáticamente el esquema de base de datos de un motor a otro (Oracle → PostgreSQL, SQL Server → Aurora). También convierte código de procedimientos almacenados.
Para el examen
SCT convierte el ESQUEMA. DMS migra los DATOS. Se usan juntos para migraciones heterogéneas.
AWS Snow Family
Migración de datos masivosDispositivos físicos para migrar grandes volúmenes de datos cuando el ancho de banda de internet es insuficiente. Snowcone (8 TB), Snowball Edge (80 TB), Snowmobile (100 PB — camión físico de AWS).
Para el examen
Cuando hay petabytes de datos y la conexión de red tardaría meses: Snow Family. Regla: si tarda más de 1 semana por red → Snow.
Costos reales de on-premises
Muchas empresas subestiman el costo total
Rightsizing — Ajustar al uso real
En on-premises se aprovisiona para el pico máximo (se usa 15-30% de la capacidad promedio). En AWS pagas por lo que usas. Rightsizing = analizar el uso real de las instancias y ajustar el tipo de instancia al mínimo necesario sin degradar rendimiento.
BYOL vs licencias incluidas
BYOL (Bring Your Own License): traes tu licencia existente de Windows/SQL Server a AWS (en Dedicated Hosts o EC2).Licencias incluidas: AWS incluye la licencia en el precio (ejemplo: RDS para SQL Server, Windows AMIs). Evalúa cuál es más económico según tus contratos actuales.
Beneficios de la automatización
AWS permite automatizar tareas que antes requerían personal: parches de SO (Systems Manager), backups (AWS Backup), escalado (Auto Scaling), despliegues (CloudFormation). Esto elimina trabajo manual repetitivo y reduce errores humanos.
| Dimensión | On-premises (Costos fijos) | AWS Cloud (Costos variables) |
|---|---|---|
| Inversión inicial | Alta — hardware antes de usarlo | Cero — paga cuando empiezas a usar |
| Capacidad | Sobreprovisionar para picos (infrautilizado) | Elasticidad: ajusta en minutos según demanda |
| Personal de infra | Equipo propio para hardware, red, DC | AWS gestiona la infra física; equipo en valor |
| Tiempo al mercado | Semanas para aprovisionar hardware nuevo | Minutos para aprovisionar cualquier recurso |
| Escala global | Contratos, datacenters, meses de trabajo | Deploy en nueva región en minutos |
| Tipo de costo | CapEx (activos fijos que se deprecian) | OpEx (gasto operativo variable) |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa de retail quiere migrar su sistema de gestión de inventario a AWS. El equipo técnico quiere minimizar los cambios en el código y la arquitectura de la aplicación, pero están dispuestos a cambiar de base de datos MySQL on-premises a Amazon RDS (sin modificar el código de la aplicación). ¿Qué estrategia de migración describe mejor esta situación?