Si eres nuevo en AWS, la frase "gestionar infraestructura como codigo" puede sonar abstracta. Esta guia explica que es CloudFormation, por que existe y como funciona, usando analogias del dia a dia para que cualquier persona pueda entenderlo.
Que es CloudFormation?
Piensa en construir una casa. Ningun constructor con experiencia empieza a colocar ladrillos sin un plano primero. El plano le dice a todos donde van las habitaciones, donde estan las puertas, y permite construir casas identicas a partir del mismo diseno.
CloudFormation es el plano para tu infraestructura en AWS. Escribes un archivo de plantilla que describe todo lo que necesitas — servidores EC2, almacenamiento S3, bases de datos, reglas de red — y CloudFormation lee ese archivo y crea automaticamente todos esos recursos.
Esto es lo que significa IaC (Infraestructura como Codigo): en lugar de hacer clic en la consola de AWS para configurar las cosas manualmente, describes lo que quieres en un archivo de texto, y el sistema lo construye por ti.
Por que importa esto? Imagina que tienes una tienda en linea. Necesitas tres entornos separados: desarrollo, donde los ingenieros prueban nuevas funciones; staging, donde haces las comprobaciones finales; y produccion, donde compran los clientes reales. Configurar cada uno a mano lleva horas, y es muy facil olvidar algun detalle. Con CloudFormation, despliegas desde la misma plantilla cada vez, y los tres entornos quedan garantizados como identicos.
Las secciones clave de una plantilla
Una plantilla de CloudFormation es un archivo YAML o JSON organizado en secciones, como los capitulos de un libro de recetas.
| Seccion | Funcion | Ejemplo | |---------|---------|---------| | Parameters | Valores que proporcionas en el momento del despliegue | Tipo de instancia, nombre del entorno | | Mappings | Tablas de consulta para valores condicionales | IDs de AMI diferentes por region | | Resources | Los recursos AWS que se crearan (la unica seccion obligatoria) | Instancia EC2, bucket S3, base de datos RDS | | Outputs | Valores exportados despues de crear el stack | Nombre DNS del balanceador de carga | | Conditions | Reglas para decidir si crear ciertos recursos | Solo crear una NAT Gateway en produccion |
Una analogia de receta ayuda aqui. Parameters son como "cuantas porciones quieres hacer". Mappings son como "la lista de ingredientes varia segun el pais". Resources son los pasos reales de cocina. Outputs son "en que plato sirves esto". Conditions son "si es una fiesta, agrega la decoracion".
Punto de examen: solo la seccion Resources es obligatoria. Todas las demas son opcionales. El patron de usar Parameters para la entrada, Mappings para buscar valores especificos de region, y Conditions para crear recursos segun el entorno aparece con frecuencia.
Change Sets — Vista previa antes de confirmar
Cuando compras en linea, revisas tu carrito antes de hacer clic en "Pagar". Los Change Sets funcionan igual para los cambios de infraestructura de AWS.
Imagina esta situacion: modificaste tu plantilla de CloudFormation para cambiar una regla de grupo de seguridad en tu servidor en ejecucion. Pero no estas seguro de si este cambio causara el reinicio de tu base de datos o solo actualizara una configuracion de forma silenciosa. Crea un Change Set y CloudFormation te mostrara una lista: "este recurso se modificara, ese recurso se reemplazara, este otro recurso se eliminara". Puedes revisarlo con calma antes de decidir.
Crear un Change Set no aplica ningun cambio. Nada ocurre hasta que haces clic en "Execute". Si no te gusta lo que ves, simplemente elimina el Change Set y nada fue alterado.
Punto de examen: "Quieres revisar el impacto de una actualizacion de infraestructura antes de que ocurra" — la respuesta es Change Sets.
Stack Policies — Proteger recursos criticos
Imagina que tienes una base de datos de produccion con anos de pedidos de clientes. Quieres asegurarte de que nadie la elimine o reemplace accidentalmente al actualizar el stack de CloudFormation. Las Stack Policies te dan esa proteccion.
Una Stack Policy es un conjunto de reglas adjuntas a un stack de CloudFormation que controla que recursos pueden actualizarse. Es como poner una doble cerradura en una boveda bancaria. Una vez que una Stack Policy esta en su lugar, solo los recursos explicitamente listados como "permitidos para actualizar" pueden modificarse, todo lo demas esta protegido.
Un comportamiento importante a recordar: una Stack Policy no puede eliminarse completamente una vez establecida. Sin embargo, puedes reemplazarla por una politica que permita todas las actualizaciones, lo que elimina la restriccion en la practica.
Punto de examen: "Proteger un recurso critico como una base de datos RDS de modificaciones accidentales" — la respuesta es Stack Policy.
Drift Detection — Encontrar cambios no autorizados
Construiste cuidadosamente tu infraestructura con CloudFormation. Luego un dia un colega inicia sesion en la consola de AWS y cambia manualmente una regla de grupo de seguridad en una instancia EC2. Ahora el estado real de tu entorno AWS ya no coincide con tu plantilla de CloudFormation. Esta brecha entre la plantilla y la realidad se llama "drift".
El drift es como tener un plano de edificio que dice que hay tres ventanas, pero alguien agrego una cuarta ventana al edificio real. El plano esta desactualizado.
Cuando ejecutas Drift Detection, CloudFormation verifica la configuracion actual de cada recurso contra lo que la plantilla dice que deberia ser. El resultado para cada recurso es IN_SYNC (coincide con la plantilla) o DRIFTED (difiere de la plantilla). Para los recursos con drift, puedes ver exactamente que propiedades cambiaron y cuales son los valores actuales versus los esperados.
Punto de examen: "Quieres encontrar diferencias entre tu plantilla de CloudFormation y los cambios hechos manualmente en la consola" — la respuesta es Drift Detection.
StackSets — Desplegar en multiples cuentas y regiones a la vez
Tu empresa crecio y ahora tiene quince cuentas de AWS, una por equipo o unidad de negocio. Necesitas desplegar la misma linea base de seguridad en todas. Iniciar sesion en cada cuenta y desplegar por separado tomaria todo el dia. StackSets resuelve esto.
StackSets te permite desplegar una sola plantilla de CloudFormation en multiples cuentas de AWS y multiples regiones de forma simultanea. Piensalo como que la sede central envia el mismo manual de operaciones a cada sucursal al mismo tiempo.
Asi funciona: creas un StackSet en tu cuenta de administrador, especificas las cuentas objetivo o las OUs de AWS Organizations, y CloudFormation crea automaticamente una instancia de stack en cada objetivo. Tambien puedes configurar cuantas cuentas se despliegan simultaneamente y cuantos fallos son aceptables antes de que la operacion se detenga.
Punto de examen: "Desplegar el mismo stack de CloudFormation en multiples cuentas y regiones" — la respuesta es StackSets.
Entendiendo el estado ROLLBACK_COMPLETE
Si algo sale mal mientras CloudFormation esta creando un stack, intentara automaticamente hacer rollback, es decir, intentara eliminar los recursos que ya creo para que no quedes con un despliegue parcial.
Pero que pasa si el propio rollback tambien falla? El stack termina en el estado ROLLBACK_COMPLETE. Este es un estado sin salida. No puedes actualizar un stack en ROLLBACK_COMPLETE. La unica accion disponible es eliminar el stack, corregir lo que causo el fallo original y luego crear un nuevo stack.
Las causas comunes incluyen permisos IAM insuficientes, alcanzar los limites del servicio AWS, o valores de parametros invalidos.
Punto de examen: "Como recuperas un stack en estado ROLLBACK_COMPLETE?" — eliminalo, corrige el error y recrealo desde cero.
cfn-init, cfn-signal y CreationPolicy
Supongamos que quieres que CloudFormation cree una instancia EC2 e instale automaticamente Apache y PHP en ella. Tambien quieres que CloudFormation espere hasta que la instalacion se complete antes de declarar el stack creado exitosamente.
cfn-init lee una seccion de metadatos en tu plantilla que lista que paquetes instalar, que archivos crear y que servicios iniciar. Cuando la instancia EC2 se lanza, cfn-init ejecuta esos pasos automaticamente.
cfn-signal es un comando que colocas al final de tu script de instalacion. Cuando la instalacion termina exitosamente, cfn-signal envia un mensaje de "listo" de vuelta a CloudFormation.
CreationPolicy es una configuracion en el recurso que le dice a CloudFormation "no marques este recurso como completo hasta que recibas la senal". Tambien especificas un tiempo limite: si la senal no llega dentro de ese tiempo, la creacion del stack falla.
Estos tres trabajan como equipo. cfn-init hace el trabajo, cfn-signal reporta la finalizacion, y CreationPolicy hace que CloudFormation espere el reporte.
Nested Stacks y AWS CDK
A medida que tu aplicacion crece, una sola plantilla de CloudFormation puede tener cientos de lineas y ser dificil de gestionar. Los Nested Stacks resuelven esto dividiendo una plantilla grande en modulos reutilizables mas pequenos.
Por ejemplo, podrias tener un stack de red (VPC, subredes, enrutamiento), un stack de seguridad (grupos de seguridad, roles IAM), un stack de computo (EC2, Auto Scaling) y un stack de base de datos (RDS). Un stack padre referencia y ensambla todos estos. Cada stack individual puede reutilizarse en otros proyectos.
AWS CDK (Cloud Development Kit) adopta un enfoque diferente. En lugar de escribir YAML o JSON directamente, escribes codigo de infraestructura en Python, TypeScript, Java u otros lenguajes familiares. Cuando ejecutas el CDK, genera la plantilla de CloudFormation por ti. Los desarrolladores que se sienten comodos programando tienden a encontrar CDK mas rapido y menos propenso a errores que escribir plantillas manualmente.
Puntos clave para el examen
"Vis