Servicios de migración a AWS para cargas de trabajo

Las siete (Retire, Retain, Relocate, Rehost, Repurchase, Replatform, Refactor), pero nos resistimos de forma explícita a usar Rehost por defecto. La decisión se basa en una ejecución de AWS Migration Hub Strategy Recommendations más nuestro propio mapa de dependencias a partir de los agentes de Application Discovery Service. Puntuamos cada carga de trabajo en cinco ejes: radio de impacto, frecuencia de cambio, coste de ejecución en EC2 frente al equivalente gestionado, atadura de licencias y familiaridad del equipo. Las capas web sin estado suelen ir a Replatform en ECS Fargate o App Runner. Oracle/SQL Server con mucho PL/SQL van a Refactor a Aurora PostgreSQL mediante Babelfish o DMS + SCT. El COTS sin salida va a Rehost mediante MGN y se revisa 12 meses después.

Terraform por defecto, y ocasionalmente Pulumi cuando el equipo del cliente prefiere TypeScript de extremo a extremo. Nunca usamos ClickOps para los cimientos. La landing zone es AWS Control Tower con personalizaciones: OU separadas para Security, Audit, Log Archive, SharedServices, Workloads (dev/stage/prod) y Sandbox. La identidad es IAM Identity Center federado con su IdP (Okta, Entra ID, Google Workspace). La red es un Transit Gateway hub-spoke con una VPC de inspección centralizada que ejecuta AWS Network Firewall. Todo está en módulos de Terraform versionados en su repositorio: el código es suyo desde el primer día, no nuestro.

Las cargas de trabajo con datos personales de la UE aterrizan en eu-central-1 (Fráncfort), eu-west-1 (Irlanda) o AWS European Sovereign Cloud cuando procede. Fijamos los servicios a esas regiones mediante SCP a nivel de OU: un desarrollador no puede levantar por accidente un modelo de Bedrock en us-east-1. Para cumplir con Schrems II usamos AWS Nitro Enclaves cuando se requiere computación confidencial atestable, KMS con CMK gestionadas por el cliente (y XKS / almacén de claves externo para las cargas críticas para la soberanía) y SCC en el DPA. Los registros de CloudTrail y Config se cifran con claves independientes y se replican entre regiones solo dentro de la UE.

Instrumentamos los Cost and Usage Reports en Athena + QuickSight desde el primer día y etiquetamos cada recurso con centro de coste, entorno y servicio mediante una política aplicada por Terraform. La cadencia de FinOps es semanal: detección de anomalías con AWS Cost Anomaly Detection, recomendaciones de rightsizing de Compute Optimizer, seguimiento de la cobertura de Savings Plans y un informe mensual por escrito. Los ahorros típicos sobre una línea base de lift-and-shift son del 28–35 % en 90 días (migración a Graviton en las capas sin estado, S3 Intelligent-Tiering en datos fríos, Aurora I/O-Optimized en bases de datos con mucha escritura, Spot para lotes en EKS mediante Karpenter).

Sí; la entrega conjunta es nuestro modelo por defecto. Su equipo es responsable de la lógica de negocio, de los cambios en las aplicaciones y de las decisiones finales de cutover. Nuestro equipo es responsable de la landing zone, la red, la línea base de seguridad, los pipelines de MGN/DMS, el stack de observabilidad y los runbooks. Hacemos pair programming del Terraform, celebramos una revisión semanal de arquitectura con sus tech leads y entregamos el relevo con un periodo de sombra de 30 días. Al final del proyecto, sus ingenieros revisan nuestras PR y no al revés. Sin dependencia de YuSMP una vez termina el sprint; eso es contractual.

Precios en USD de alcance cerrado y todo incluido: servicios individuales desde $200, un lift-and-shift desde $1,800, un re-platform desde $4,100 y una salida completa de AWS/Azure/GCP desde $5,800. Usted ve el presupuesto desglosado al final del descubrimiento y lo aprueba antes de escribir una sola línea de código; sin recargo por intermediación, sin sobrecostes por herramientas y con los costes de la nube en sus propias cuentas, de modo que conserva el control del coste. Los plazos dependen del tamaño del parque: un parque de 200 servidores suele migrarse en 4–6 meses de extremo a extremo, con el trabajo de re-platform y refactor presupuestado por oleada.

En la mayoría de las cargas de trabajo, minutos y no horas. MGN mantiene en AWS una réplica continua a nivel de bloque del origen, de modo que el cutover es una breve sincronización final más un cambio de DNS o de balanceador de carga dentro de una ventana planificada. Las bases de datos se trasladan con DMS en modo CDC (captura de datos de cambios): replicamos la carga masiva con antelación y luego la mantenemos sincronizada hasta el cambio, lo que reduce la inactividad real al tiempo que lleva detener las escrituras y cambiar el endpoint. Cada oleada tiene una ruta de rollback ensayada, de modo que si falla una comprobación de validación volvemos al origen sin pérdida de datos. Los cutovers realmente sin inactividad son posibles en capas sin estado detrás de un balanceador de carga; le decimos de antemano qué cargas de trabajo pueden lograrlo y cuáles no.

No necesariamente. Cuando el esquema y la carga de trabajo lo permiten, hacemos refactor de SQL Server a Aurora PostgreSQL con Babelfish (que habla el protocolo TDS, de modo que muchas aplicaciones se conectan sin cambios) y de Oracle a Aurora mediante DMS + Schema Conversion Tool, retirando por completo la licencia comercial. Cuando un refactor no es viable en esta fase (mucho PL/SQL, dependencias de COTS de terceros), puede traer su propia licencia (BYOL) a hosts dedicados de EC2 o ejecutar RDS para Oracle/SQL Server con precios con licencia incluida, y lo marcamos como candidato a refactor para una oleada posterior. La estrategia de base de datos, la diferencia de coste de licencias y la estimación de esfuerzo forman parte del entregable de descubrimiento, de modo que la disyuntiva es una decisión que usted toma con números, no una sorpresa.

Seguridad por capas. La base de datos de origen nunca se desmantela hasta que se supera la validación posterior al cutover: DMS replica en lugar de mover, de modo que el original permanece intacto y con capacidad de escritura como alternativa. Ejecutamos una conciliación de recuento de filas y de checksums entre origen y destino antes de cada cutover, mantenemos activo el flujo CDC durante el cambio y hacemos instantáneas de ambos lados justo antes y justo después. En los sistemas de alto riesgo hacemos primero un ensayo completo contra un clon. No se borra nada del parque de origen hasta que usted confirma que el destino en AWS es correcto y estable.

Por carga de trabajo, según la forma del tráfico y el encaje operativo, no según la moda. Las cargas irregulares o dirigidas por eventos que no tienen estado van a Lambda o App Runner, donde se paga por petición y se escala a cero. Los servicios estables con imágenes de contenedor y un equipo que quiere Kubernetes van a EKS con Karpenter; los equipos que quieren contenedores sin operar clústeres van a ECS Fargate. EC2 se queda para el COTS ligado a licencias, las cargas de GPU o el software que presupone un host persistente. Modelamos el coste de ejecución a tres años de cada opción durante el descubrimiento, de modo que la elección es defendible tanto por criterios de ingeniería como de FinOps, y nada obliga a un único patrón en todo el parque.

La recuperación ante desastres (DR) forma parte del diseño de la landing zone, no es un añadido posterior. Fijamos un objetivo de RPO/RTO por nivel de carga de trabajo y lo implementamos: AWS Backup con bóvedas entre regiones (y, en la UE, solo dentro de la UE), copias de seguridad automáticas de Aurora más recuperación a un momento dado, y réplicas de lectura entre regiones o topologías pilot-light/warm-standby para los sistemas de nivel 1. Los runbooks de recuperación se redactan y, en las cargas críticas, la DR se prueba en game days para que el RTO sea una cifra medida y no una esperanza. Las políticas de copia y de retención se codifican en Terraform, de modo que se aplican automáticamente a los recursos nuevos en lugar de depender de que alguien se acuerde de activarlas.

Sí, y es un punto de partida habitual. Empezamos con una evaluación de la landing zone existente y de las oleadas en curso: qué es Terraform y qué es ClickOps, si la estructura de cuentas y los guardrails son sólidos y dónde se ha acumulado ya deuda técnica. Usted recibe una lectura honesta por escrito: a veces adoptamos y ampliamos lo que existe, a veces recomendamos volver a sentar cimientos concretos, y le decimos cuál y por qué. Como todo lo que construimos queda como Terraform en su repositorio, tampoco hay dependencia de nuestra parte: el siguiente equipo después de nosotros hereda código, no una caja negra.