En SAP-C02, las estrategias de despliegue y la continuidad del negocio abarcan dos dominios: D2 (Disenar nuevas soluciones) y D3 (Mejora continua de soluciones existentes). El examen no solo evalua si conoces los nombres de los servicios. Evalua tu capacidad para decidir que enfoque de despliegue elegir en una situacion dada. Este post cubre la gestion de cambios con CloudFormation, pipelines CI/CD, despliegues Blue/Green y patrones de recuperacion ante desastres usando escenarios reales del examen.
Gestion de cambios con CloudFormation — Change Sets y Stack Policy
El momento mas peligroso al gestionar infraestructura de produccion con CloudFormation es la actualizacion de un stack. Los cambios que requieren eliminar y recrear un recurso — llamados cambios de Reemplazo — pueden causar perdida de datos. Algunos ejemplos son modificar el esquema de claves de DynamoDB, renombrar un bucket S3, o cambiar una instancia RDS a Multi-AZ en ciertas configuraciones.
Los Change Sets resuelven este problema. Antes de tocar el stack, creas un plan de cambios que muestra exactamente que recursos seran Agregados, Modificados, Eliminados o Reemplazados. Los elementos marcados como Replacement: True seran eliminados y recreados, por lo que revisar y aprobar estos antes de proceder es esencial.
Stack Policy es un documento JSON que bloquea automaticamente las operaciones de Replace o Delete en recursos especificos. Si los Change Sets son la "vista previa", Stack Policy es la "barrera de seguridad". En entornos regulados como PCI DSS o SOX, el historial de Change Sets tambien sirve como pista de auditoria de aprobacion de cambios.
Drift Detection se confunde frecuentemente con estas herramientas. Drift Detection encuentra cambios realizados fuera de CloudFormation — directamente a traves de la consola o CLI — despues de que un despliegue ya ha ocurrido. Su proposito es diferente al de prevenir reemplazos antes de un despliegue. Conoce la distincion para el examen.
| Funcion | Proposito | Momento | |---------|-----------|---------| | Change Sets | Vista previa de cambios (identificar Reemplazos) | Antes del despliegue | | Stack Policy | Bloquear automaticamente reemplazos/eliminaciones en recursos especificos | Durante el despliegue | | Drift Detection | Detectar cambios manuales realizados fuera de CloudFormation | Despues del despliegue |
Pipelines CI/CD — CodePipeline, CodeBuild, ManualApproval
En el modelo CI/CD nativo de AWS, CodePipeline orquesta el pipeline completo, CodeBuild maneja compilaciones y pruebas, y CodeDeploy realiza el despliegue real.
El pipeline de despliegue seguro integrado con CloudFormation sigue este flujo: Deteccion de fuente (CodeCommit o GitHub) → Crear Change Set → Etapa de ManualApproval donde un ingeniero revisa el Change Set → Aprobar → ExecuteChangeSet. Este patron implementa la Segregacion de Funciones para la gestion de cambios en entornos PCI DSS.
La integracion con Jenkins se evalua frecuentemente. Las organizaciones que migran a AWS no siempre quieren reemplazar Jenkins por completo. CodePipeline permite designar Jenkins como proveedor en la etapa de compilacion, manteniendo la inversion existente en Jenkins mientras se agrega la orquestacion del pipeline de AWS. CodeBuild es la opcion cuando quieres reemplazar Jenkins. La combinacion de CodePipeline mas Jenkins es la opcion cuando quieres mantener Jenkins.
Para CI/CD de contenedores, el escaneo de imagenes ECR es importante. El Escaneo Basico usa una base de datos CVE. El Escaneo Mejorado usa Amazon Inspector para un analisis de vulnerabilidades mas profundo. Las opciones de despliegue de ECS son Rolling Update (reemplazo secuencial de instancias) y Blue/Green (basado en CodeDeploy, cero tiempo de inactividad). Cuando el requisito es cero tiempo de inactividad, elige Blue/Green.
Despliegue progresivo de Lambda — Alias, Canary, Linear
Para actualizar una funcion Lambda de forma segura, primero necesitas publicar una Version y crear un Alias, en lugar de invocar $LATEST directamente. La integracion con CodeDeploy proporciona tres estrategias de despliegue.
Canary envia un pequeno porcentaje del trafico (por ejemplo, 10%) a la nueva version primero. Despues de la validacion, cambia el 90% restante de una sola vez. Linear aumenta el trafico a la nueva version en un porcentaje fijo cada N minutos. AllAtOnce cambia todo inmediatamente y se usa para cambios de bajo riesgo donde no se espera rollback.
Conectar alarmas de CloudWatch a CodeDeploy habilita el rollback automatico a la version anterior si la tasa de errores aumenta. Con SAM, declaras esta configuracion usando la propiedad DeploymentPreference.
| Estrategia | Comportamiento | Rollback automatico | |------------|---------------|---------------------| | Canary | X% primero, luego 100% tras validacion | Alarma CloudWatch | | Linear | X% mas cada N minutos | Alarma CloudWatch | | AllAtOnce | 100% inmediatamente | Solo manual |
!Tipos de despliegue progresivo de Lambda
Despliegue Blue/Green — Cero tiempo de inactividad y rollback instantaneo
El principio central del despliegue Blue/Green es mantener dos entornos en paralelo y cambiar el trafico entre ellos para intercambiar versiones. El rollback significa volver a dirigir el trafico hacia Blue, lo que se completa en menos de cinco minutos. Los despliegues Rolling o in-place requieren redespliegue para el rollback, lo que lleva tanto tiempo como el despliegue original.
Cada plataforma implementa Blue/Green de manera diferente. Para EC2 con Auto Scaling, ejecutas un Blue ASG y un Green ASG en paralelo, luego cambias el grupo de destino del ALB. Para ECS, CodeDeploy ejecuta tareas Blue (version antigua) y Green (version nueva) en paralelo usando listeners duales del ALB — trafico de prueba en el puerto 8080 y trafico de produccion en el puerto 443. Para Elastic Beanstalk, realizas un intercambio instantaneo de CNAME entre los dos entornos.
El enrutamiento ponderado de Route 53 te da un control mas fino sobre el cambio de trafico durante las transiciones Blue/Green. Puedes comenzar con Blue 90% y Green 10%, luego cambiar gradualmente la proporcion — un enfoque Blue/Green de estilo canary.
Escenarios DR — RTO, RPO y compromisos de costo
Los criterios de juicio mas importantes en las preguntas de continuidad del negocio son RTO (Objetivo de Tiempo de Recuperacion) y RPO (Objetivo de Punto de Recuperacion). El costo y la velocidad de recuperacion son inversamente proporcionales. El examen SAP-C02 te pide encontrar la solucion de menor costo que cumpla con los requisitos indicados.
Aurora Global Database logra un RPO inferior a un segundo mediante replicacion a nivel de almacenamiento, y un RTO inferior a un minuto mediante la promocion de la region secundaria. Es adecuado para sistemas financieros y de salud con requisitos estrictos.
RDS Cross-Region Read Replica usa replicacion asincrona, por lo que el RPO se mide en segundos a minutos. Cuesta menos que Aurora Global Database pero tiene un RPO mas flexible. La promocion tarda de cinco a diez minutos en el momento del failover.
DynamoDB Global Tables proporciona una estructura Active-Active multi-region donde las lecturas y escrituras se aceptan desde cualquier region. Esto contrasta con Aurora Global Database, que es Active-Passive: solo la region primaria acepta escrituras. Cuando el escenario requiere NoSQL con capacidad de escritura multi-region, elige DynamoDB Global Tables.
Puntos clave del examen
"Replacement True en Change Sets significa" -- el recurso sera eliminado y recreado (riesgo de perdida de datos)
"Herramientas para prevenir reemplazos antes del despliegue" -- Change Sets mas Stack Policy
"Detectar cambios manuales hechos fuera de CloudFormation tras el despliegue" -- Drift Detection
"Enviar primero un pequeno porcentaje de trafico a nueva Lambda, luego cambiar el resto" -- despliegue Canary (CodeDeploy mas Alias)
"Aumentar el trafico de Lambda X% cada N minutos" -- despliegue Linear
"Por que el rollback Blue/Green se completa en 5 minutos" -- solo se redirige el trafico, sin redespliegue
"Escenario NoSQL multi-region Active-Active con escrituras" -- DynamoDB Global Tables
"RPO menor a 1 segundo y RTO menor a 1 minuto para BD relacional" -- Aurora Global Database
"Replicacion asincrona, promocion en 5-10 minutos, menor costo" -- RDS Cross-Region Read Replica
"Gestionar parches de servidores on-premises desde la consola AWS" -- Systems Manager Patch Manager mas Hybrid Activation