Amazon SAP-C02: Migración y Modernización — Guía de estudio
Forma parte de la AWS Solutions Architect Professional SAP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.
Estrategia y planificación de la migración
Una migración eficaz comienza con un descubrimiento disciplinado, un mapeo de dependencias y una priorización basada en el riesgo. Utilice AWS Application Discovery Service y AWS Migration Hub para inventariar servidores, recopilar métricas de rendimiento y visualizar las dependencias de las aplicaciones; complemente esto con un análisis de flujo de red sin agentes y datos de gestión de la configuración para encontrar enlaces con estado (stateful) ocultos. Traduzca el descubrimiento en decisiones para la landing zone: elija una estrategia de cuentas con AWS Control Tower y Organizations, defina la topología de red con Transit Gateway y dimensione la computación de destino utilizando Compute Optimizer y las directrices de right-sizing. La estrategia de transición (cutover) debe elegirse por aplicación: big-bang para sistemas pequeños y de bajo riesgo; por fases u oleadas para suites críticas para el negocio; blue/green o canary para servicios de cara al cliente para minimizar el impacto en el usuario. Considere las ventanas de sincronización de datos, los TTL de DNS, las limitaciones de ancho de banda y las restricciones regulatorias al planificar la transición. Las trampas comunes incluyen subestimar el tiempo y los costos de transferencia de datos, tratar el lift-and-shift como el estado final, descuidar la portabilidad de las licencias y no planificar una reversión (rollback). Los criterios de decisión a menudo sopesan el costo frente al esfuerzo operativo y la resiliencia: los servicios gestionados (RDS/Aurora, DocumentDB) aumentan la previsibilidad del OPEX y la resiliencia, pero pueden requerir cambios en el esquema; la migración a una nueva plataforma (replatforming) hacia ofertas gestionadas reduce la carga de operaciones a expensas de una mayor complejidad en la migración.
Herramientas de lift-and-shift y migración de datos
Para un realojamiento (rehosting) rápido, AWS Application Migration Service (MGN) automatiza la replicación a nivel de bloque desde VMware, Hyper-V y servidores físicos a EC2, minimizando el tiempo de transición y preservando las configuraciones a nivel de sistema operativo. La migración de grandes volúmenes de datos o la migración sin conexión (offline) puede requerir AWS Snow Family o DataSync para archivos y cargas de trabajo POSIX/NFS, mientras que Amazon S3 Transfer Acceleration y Direct Connect aceleran la transferencia de objetos y masiva. La migración de bases de datos se basa en AWS Database Migration Service (DMS) para migraciones homogéneas o heterogéneas, junto con Schema Conversion Tool (SCT) cuando se requieren cambios estructurales. Tenga en cuenta las limitaciones de DMS: el comportamiento de MongoDB como origen/destino tiene restricciones de versión y características, el manejo de LOB grandes y un posible retraso en la replicación (replication lag) durante el CDC. Diseñe la arquitectura para la integridad de los datos: valide con sumas de verificación (checksums), ejecute una carga completa más CDC para un tiempo de inactividad mínimo y organice la transición durante ventanas de bajo tráfico. Las decisiones de diseño giran en torno a la velocidad frente a la fidelidad: MGN o el rehost minimizan los cambios en la aplicación pero perpetúan los modelos operativos heredados; el replatforming reduce las operaciones a largo plazo pero requiere refactorización y pruebas. Las trampas comunes incluyen descuidar la seguridad de los endpoints, una validación insuficiente antes de la transición y asumir un IOPS/rendimiento idénticos en el almacenamiento en la nube.
Modernización: contenedores, serverless y patrones para la refactorización
Las opciones de modernización van desde el replatforming a la orquestación de contenedores hasta la refactorización completa a serverless. Elija Amazon ECS on Fargate para despliegues rápidos en contenedores con una gestión mínima de la infraestructura, o Amazon EKS para cargas de trabajo nativas de Kubernetes que requieran portabilidad y orquestación compleja. Para microservicios impulsados por eventos, combine AWS Lambda con API Gateway, EventBridge y Step Functions para reducir la sobrecarga operativa y escalar por solicitud. Los servicios de datos deberían moverse hacia backends gestionados: Amazon RDS/Aurora para bases de datos relacionales, Amazon DynamoDB o Amazon DocumentDB para almacenes NoSQL/documentales, y ElastiCache para el almacenamiento en caché de baja latencia. Las decisiones dependen de la complejidad operativa frente al costo y la previsibilidad del rendimiento: EKS ofrece control y portabilidad a un mayor costo operativo; Fargate simplifica las operaciones pero puede ser más caro a gran escala. La arquitectura serverless ofrece eficiencia de costos para cargas de trabajo con picos, pero introduce arranques en frío (cold starts), límites de concurrencia y desafíos de observabilidad. Las trampas comunes para los arquitectos incluyen migrar monolitos a contenedores sin descomponer los componentes con estado (stateful), una CI/CD e IaC (CloudFormation, CDK, Terraform) insuficientes para gestionar los despliegues, e ignorar el principio de privilegio mínimo de IAM para los roles de tarea y los roles de ejecución de Lambda.
← Bases de Datos y Análisis · Todos los dominios · Resiliencia →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →