AWS DMS vs AWS SCT
En una migración heterogénea trabajan juntos, en este orden. Así se responde la pregunta 1 del inicio: SCT para el esquema, DMS para los datos y sus cambios.
| Criterio | AWS DMS | AWS SCT |
|---|---|---|
| Qué mueve | Datos y sus cambios | Esquema y código SQL |
| Homogénea | Sí, solo DMS | No hace falta |
| Heterogénea | Sí, tras convertir | Sí, primero |
| Dónde corre | Servicio administrado | Escritorio (o en DMS) |
| Palabra clave | “Mínima interrupción” | “Convertir el esquema” |
Responsabilidad compartida servicio por servicio
Qué es: la línea entre lo que hace AWS y lo que haces tú, aplicada a un servicio concreto. Cuanto más administrado el servicio, más tareas pasan a AWS.
El modelo general es el de la Sesión 4; aquí lo aplicas a los tres servicios que nombra la guía oficial. EC2 es IaaS: AWS te da el servidor virtual y desde el sistema operativo hacia arriba todo es tuyo. RDS es una base administrada: AWS opera el sistema y el motor; tú decides el tamaño, las copias y los accesos. Lambda es serverless: AWS opera hasta el entorno de ejecución y la capacidad; tú entregas código y permisos.
| Tarea | EC2 | RDS | Lambda |
|---|---|---|---|
| Hardware e instalaciones | AWS | AWS | AWS |
| Parches del sistema operativo | Tú | AWS | AWS |
| Parches del motor o runtime | Tú | AWS, en tu ventana | AWS |
| Copias de seguridad | Tú | AWS; tú fijas días | No aplica |
| Capacidad y escalado | Tú, con Auto Scaling | Tú eliges tamaño | AWS, automático |
| Tu código y consultas | Tú | Tú | Tú |
| Tus datos | Tú | Tú | Tú |
| Cifrado y permisos | Tú | Tú | Tú |
| Reglas de red | Tú | Tú | Tú, si usa VPC |
Analogía: el departamento de la Sesión 4, en tres versiones. EC2 es el departamento vacío: pintas, amueblas y reparas todo. RDS es el amueblado con mantenimiento: el dueño arregla la estufa, tú decides cuántas personas viven ahí. Lambda es el cuarto de hotel: llegas con tu maleta y nada más. Dónde falla la analogía: en el hotel no decides nada del cuarto. En Lambda sí eliges la memoria, escribes el código y defines su rol de ejecución, y en los tres casos la llave de tus datos es tuya.
Ejemplo real: Nébula corre su tienda en EC2, su base en RDS y las miniaturas en Lambda. Un parche crítico de Linux le toca aplicarlo en sus instancias EC2; en RDS y Lambda no hace nada. Pero un bucket con permisos abiertos o una contraseña débil en la base son fallos suyos en cualquiera de los tres.
Úsala cuando: una pregunta pida quién hace algo en un servicio concreto. Ubica el servicio en la escala IaaS, administrado, serverless, y busca la fila. No la uses cuando: pienses que algún servicio te libra de datos, permisos o cifrado: esas filas son tuyas siempre.
En el examen: “parchear el sistema operativo de una instancia EC2” es del cliente. “Parchear el motor de RDS” o “el sistema operativo bajo Lambda” es de AWS. “Código de la función”, “permisos de IAM” y “cifrado de los datos” son del cliente en todos.
Trampa común: en RDS, AWS aplica los parches, pero tú eliges la ventana de mantenimiento y activas el cifrado. Y que AWS haga las copias automáticas no significa que decida cuántos días guardarlas: ese número lo fijas tú.