El Dominio 2 de DOP-C02, Gestion de Configuracion e IaC, representa el 17% del peso del examen. Va mucho mas alla de conocer la sintaxis de CloudFormation: evalua tu capacidad para desplegar infraestructura de forma consistente en cientos de cuentas, parchear automaticamente miles de servidores y recuperarse cuando ocurre deriva de configuracion. Este post cubre los patrones clave que aparecen repetidamente en los escenarios del examen DOP-C02.
Patrones Avanzados de CloudFormation
AutoScalingRollingUpdate — Reemplazo de Instancias sin Tiempo de Inactividad
Al desplegar una nueva AMI en un Auto Scaling Group, la forma mas segura es usar el atributo UpdatePolicy de CloudFormation para controlar como se reemplazan las instancias.
Resumen de parametros clave:
| Parametro | Proposito | |-----------|----------| | MaxBatchSize | Maximo de instancias reemplazadas simultaneamente | | MinInstancesInService | Minimo de instancias saludables durante el reemplazo | | WaitOnResourceSignals | Esperar cfn-signal antes de proceder al siguiente lote | | PauseTime | Tiempo de espera entre lotes |
AutoScalingReplacingUpdate reemplaza todo el ASG con uno nuevo, lo que significa que ambos existen simultaneamente y el costo se duplica durante la transicion. Cuando se necesita un reemplazo gradual y controlado, siempre elige AutoScalingRollingUpdate.
Gestion de Dependencias entre Stacks — Cross-Stack Export/Import vs Nested Stacks
Como separar y gestionar VPC, grupos de seguridad y capas de aplicacion en una arquitectura multi-capa es un tema recurrente en DOP-C02.
Patron Cross-Stack Export/Import: Los stacks de red, seguridad y aplicacion funcionan como stacks CloudFormation independientes La seccion Outputs del stack de red define un Export Name; el stack de la app lo referencia via Fn::ImportValue Cada stack se despliega de forma independiente, ideal cuando las capas tienen diferentes cadencias de lanzamiento
Patron Nested Stack: El stack padre declara los stacks hijo como recursos Actualizar el stack padre activa el redespliegue de todos los stacks anidados Alta reutilizabilidad de recursos, pero no soporta calendarios de despliegue independientes
Recuerda la restriccion de acoplamiento fuerte: mientras otro stack referencia un Export, no puedes eliminar el stack exportador ni renombrar su Export.
!Cross-Stack Export/Import vs Nested Stacks
Politicas de Proteccion de Datos en CloudFormation
Cuando se actualizan o eliminan stacks que contienen instancias RDS o volumenes EBS, se deben configurar dos politicas juntas para evitar la perdida de datos.
| Politica | Activacion | Comportamiento | |---------|-----------|---------------| | DeletionPolicy: Snapshot | Eliminacion del stack | Crea snapshot automatico antes de eliminar el recurso | | UpdateReplacePolicy: Snapshot | Recurso reemplazado durante actualizacion | Crea snapshot antes del reemplazo |
Solo configurar DeletionPolicy te deja expuesto cuando una actualizacion del stack causa el reemplazo de un recurso. Ambas politicas son necesarias para cubrir todos los escenarios de perdida de datos.
Recuperacion de UPDATE_ROLLBACK_FAILED
Cuando una actualizacion de stack falla y se queda atascada en el estado UPDATE_ROLLBACK_FAILED, la causa mas comun es que un recurso fue modificado o eliminado fuera de CloudFormation, haciendo imposible revertir al estado original.
Solucion oficial: Usa la API ContinueUpdateRollback con el parametro ResourcesToSkip para omitir el recurso problematico y dejar que el resto del rollback se complete. El recurso omitido se marca como derivado y debe ser corregido por separado usando Drift Detection.
Custom Resources de CloudFormation — Automatizacion Mas Alla del Soporte Nativo
Para operaciones que los tipos de recursos nativos de CloudFormation no soportan, como vaciar un bucket S3 no vacio, llamar APIs externas o crear un Active Directory Connector, usa un Custom Resource respaldado por Lambda.
Como funciona: CloudFormation invoca Lambda con un objeto de evento que contiene un ResponseURL (una URL S3 prefirmada) Lambda debe enviar una respuesta SUCCESS o FAILED al ResponseURL al completarse Si cfn-response nunca se envia, CloudFormation espera hasta una hora antes de fallar por timeout
El error mas comun es omitir la llamada a cfn-response en un bloque try/except. Si Lambda se ejecuta correctamente pero el stack de CloudFormation agota el tiempo de espera, un cfn-response faltante es casi siempre el culpable.
AWS CDK y CDK Pipelines
Relacion de CDK con CloudFormation
AWS CDK permite definir infraestructura usando TypeScript, Python, Java o C#. Ejecutar cdk synth produce una plantilla CloudFormation. Dado que los stacks generados por CDK se despliegan via CloudFormation, heredan todas sus capacidades: deteccion de deriva, change sets y rollback automatico.
Ventajas clave de CDK: Usa condicionales, bucles y funciones para expresar patrones de infraestructura complejos de forma concisa Los Constructs L2 y L3 incorporan mejores practicas El verificador de tipos e intellisense del IDE reduce errores
CDK Pipelines — Definiendo Pipelines como Codigo
CDK Pipelines es un Construct L3 que define CodePipeline como codigo CDK. Dado que el pipeline en si se despliega como un stack CloudFormation, cualquier cambio manual en la consola se detecta como deriva y se restaura automaticamente.
Gestionar el pipeline como IaC garantiza prevencion de deriva, capacidad de reaprovisionar un pipeline identico en cualquier momento y rollback automatico ante fallo de despliegue.
Sincronizacion Automatica de Service Catalog + CodePipeline
Cuando un equipo de plataforma distribuye plantillas CloudFormation aprobadas a las unidades de negocio, actualizar manualmente Service Catalog cada vez que cambia una plantilla genera omisiones y retrasos. CodePipeline tiene una accion de despliegue nativa de Service Catalog sin necesidad de Lambda. Cuando llega un commit a CodeCommit, el pipeline actualiza automaticamente la version del producto de Service Catalog.
Gobernanza Multi-Cuenta con AWS Organizations
Componentes Principales de Organizations
Las empresas que gestionan decenas o cientos de cuentas AWS usan Organizations y Control Tower juntos para la gobernanza.
| Componente | Rol | |-----------|-----| | Management Account | Raiz de la organizacion, aplica SCPs de nivel superior | | Organizational Unit (OU) | Agrupa cuentas, SCPs aplicadas a nivel de OU | | Service Control Policy (SCP) | Establece el limite maximo de permisos para IAM | | Control Tower | Automatizacion de landing zone, aprovisionamiento de cuentas, guardrails |
Las SCPs no reemplazan las politicas IAM. Una accion requiere que tanto la SCP como la politica IAM la permitan. Las SCPs solo establecen el limite superior de los permisos posibles.
CloudFormation StackSets — Despliegue Multi-Cuenta y Multi-Region
StackSets despliega una sola plantilla CloudFormation en multiples cuentas y regiones simultaneamente.
En modo SERVICE_MANAGED con auto-deployment habilitado, los stacks se despliegan automaticamente en nuevas cuentas cuando se agregan a una OU. Este es el patron de "incorporacion automatica de cuentas" que aparece frecuentemente en DOP-C02.
Controles de concurrencia de despliegue: MaxConcurrentPercentage: porcentaje de cuentas a desplegar simultaneamente FailureTolerancePercentage: porcentaje de cuentas que pueden fallar antes de detener la operacion
Integracion de GuardDuty y Config con Organizations
GuardDuty Organizations: Habilitar GuardDuty desde la cuenta de gestion o una cuenta de administrador delegado agrega los hallazgos de amenazas de todas las cuentas miembro de forma centralizada Con auto-enable, GuardDuty se activa automaticamente en las cuentas nuevas
Reglas Config de Organizations: Desplegar un Config Conformance Pack a nivel de Organizations aplica las mismas reglas de cumplimiento a todas las cuentas Un Aggregator centraliza el estado de cumplimiento de todas las cuentas y regiones en una sola vista
Patron de Roles IAM entre Cuentas
Cuando una cuenta CI/CD central despliega en cuentas de desarrollo, staging y produccion, la delegacion de roles entre cuentas es el enfoque estandar.
Crear CrossAccountDeployRole en cada cuenta destino con una politica de confianza que referencie el ID de la cuenta CI/CD CodePipeline/CodeBuild en la cuenta CI/CD llama a STS AssumeRole para obtener el rol de la cuenta destino Desplegar CloudFormation usando las credenciales temporales del rol asumido
Este patron implementa despliegue multi-cuenta con privilegios minimos y sin credenciales de larga duracion.
Automatizacion a Gran Escala con AWS Systems Manager
Patch Manager — Politicas de Parches por Entorno
Aplicar automaticamente diferentes baselines de parches a diferentes entornos para cientos de instancias EC2 es un escenario recurrente en DOP-C02.
Flujo de configuracion:
Patron de separacion por entorno:
| Entorno | Patch Baseline | Etiqueta Patch Group | |---------|---------------|---------------------| | Produccion | Solo clasificacion SECURITY | Patch Group: prod | | Staging | SECURITY (pre-validacion) | Patch Group: staging | | Desarrollo | ALL | Patch Group: dev |
Establecer la concurrencia de Rate Control (por ejemplo, 10%) limita cuantas instancias se parchean simultaneamente, evitando que cientos de instancias se reinicien a la vez y causen una interrupcion del servicio.