Ocho módulos han construido una arquitectura completa: seis subredes, dos grupos de autoescalado, cinco funciones Lambda, cuatro colas, un clúster Aurora, dos tablas de DynamoDB, cinco buckets, un balanceador, una distribución de CloudFront, catorce alarmas y un pipeline que despliega sin cortar el servicio. Todo funciona. Y nada de eso existe en ningún fichero: existe porque alguien escribió un comando algún día. Esta lección arregla la asimetría que Marta señaló al cerrar el módulo 8 con la herramienta nativa de AWS para hacerlo: CloudFormation, el servicio que convierte un fichero de texto en recursos reales y mantiene la relación entre ambos.

Aviso de coste. CloudFormation es gratuito cuando gestiona recursos de AWS: pagas los recursos, no las pilas. Solo cobra por recursos de terceros y tipos privados registrados (0,0009 USD por segundo de manejador). La plantilla de red crea dos NAT gateway: unos 0,045 USD/hora cada uno más tráfico, unos 65 USD al mes si la dejas puesta. El apartado de limpieza la borra con un comando. Datos ficticios.

1. La asimetría entre código e infraestructura
2. Qué es la infraestructura como código, y declarativo frente a imperativo
3. Anatomía de una plantilla
4. Parámetros: tipos, restricciones y valores desde SSM
5. Mappings, Conditions y funciones intrínsecas
6. Pilas: ciclo de vida, estados y ROLLBACK_COMPLETE
7. Políticas de eliminación y protección de terminación
8. Conjuntos de cambios y los tres tipos de actualización
9. Detección de deriva
10. La red de MercadoFresco en una plantilla
11. La capa de aplicación que importa las salidas
12. Varias pilas: exportaciones frente a SSM
13. Pilas anidadas, módulos y recursos personalizados
14. Importar recursos existentes a una pila
15. StackSets y despliegue desde el pipeline
16. Buenas prácticas, cfn-lint y cfn-guard
17. Límites, coste y limpieza
18. Errores comunes y consejos
19. Ejercicios
20. Conclusión

Marta hace inventario en una tarde y apunta cuatro hechos:

El tercero es el más caro. En el módulo 5 apareció un grupo de seguridad con una regla hacia un rango de IP que nadie reconocía y nadie borró: podía ser de un proveedor. Ese es el coste real de no tener infraestructura como código: no es que no puedas crearla; es que no puedes cambiarla con confianza.

Consiste en describir la infraestructura en ficheros de texto versionados en Git y dejar que una herramienta haga coincidir la realidad con la descripción. No es "automatizar la creación": es que el fichero sea la fuente de verdad. De ahí salen cuatro propiedades:

• Reproducibilidad. El mismo fichero produce el mismo resultado en otra región, en otra cuenta o dentro de seis meses.
• Revisión. La infraestructura pasa por una pull request como el código de 08-01: un cambio en un grupo de seguridad se comenta, se aprueba y queda con autor, fecha y motivo.
• Deriva controlada y documentación viva. La herramienta sabe qué debería existir, así que puede compararlo con lo que existe —sin IaC la deriva es invisible por definición— y el fichero no puede quedarse obsoleto respecto a la realidad, porque es lo que la crea.
• Se puede borrar sin miedo. Cuando levantar un entorno cuesta un comando, apagarlo el viernes deja de ser un riesgo y pasa a ser un ahorro. Es la propiedad que convence a los escépticos.

MercadoFresco ha usado hasta ahora el enfoque imperativo: comandos que describen cómo llegar al estado. CloudFormation es declarativo: describes qué quieres y el servicio calcula los pasos.

El script no sabe nada del estado anterior: cada comando crea. Hacerlo idempotente exigiría envolver cada línea en una comprobación, gestionar los identificadores generados y decidir qué hacer si el recurso existe con otra configuración; es decir, reimplementar CloudFormation en Bash.

Lo imperativo no desaparece: sigue siendo lo correcto para operaciones puntuales (aws s3 cp, reiniciar una instancia, consultar métricas). La regla: si el recurso debe seguir existiendo mañana, va en una plantilla; si es una acción que ocurre una vez, va en un comando.

Un documento YAML o JSON con nueve secciones posibles. Solo Resources es obligatoria.

Faltan Rules (validación de combinaciones de parámetros) y Hooks, mucho menos habituales. La estructura de un recurso siempre es la misma, con Type y Properties obligatorios y el resto opcional:

Primera regla importante: cambiar el nombre lógico de un recurso equivale a borrarlo y crear otro. CloudFormation identifica los recursos por su nombre lógico, no por lo que hacen. Renombrar Vpc a VpcPrincipal en una plantilla desplegada destruye la VPC.

Sin parámetros harían falta tres plantillas casi idénticas para los tres entornos.

Tres cosas separan una plantilla amateur de una profesional:

1. Los tipos específicos de AWS validan antes de empezar. Con Type: String para una clave SSH inexistente, la pila crea media docena de recursos y falla al llegar a la instancia. Con AWS::EC2::KeyPair::KeyName falla en el segundo cero, sin crear nada.
2. AWS::SSM::Parameter::Value<...> desacopla la plantilla de los valores. La AMI de la tienda cambia cada mes; la plantilla no debería cambiar por eso. MercadoFresco lo usa con /mercadofresco/produccion/ami-tienda.
3. NoEcho no cifra, solo oculta. Las contraseñas no van en parámetros: van en Secrets Manager (04-03) y se referencian con resolución dinámica, que se evalúa en el despliegue sin que el valor entre nunca en la plantilla:

Mappings es una tabla de consulta estática de dos niveles, útil para variar por región o por entorno; se lee con Fn::FindInMap. Conditions calcula booleanos con Fn::Equals, Fn::And, Fn::Or y Fn::Not.

Se leen con !FindInMap [ PorEntorno, !Ref Entorno, Tipo ]. Un recurso con Condition: CrearSegundoNat solo se crea si la condición es cierta: nat-mercadofresco-b existe en producción y no en desarrollo con la misma plantilla, y eso ahorra unos 32 USD al mes por entorno no productivo. Aviso: úsalas con moderación. Una plantilla con doce condiciones anidadas es ilegible e imposible de razonar cuando falla; si la diferencia entre entornos es grande, hacen falta plantillas distintas, no más condiciones.

Cada una tiene forma larga (Fn::Sub) y corta (!Sub). En YAML se usa la corta salvo cuando hay que anidar dos cortas seguidas, que YAML no permite.

Lo que más confusión genera es !Ref, porque devuelve cosas distintas según el tipo: en una VPC o subred, su identificador; en un bucket, el nombre; en una cola de SQS, la URL; en un tema de SNS, el ARN; en un rol de IAM, el nombre; en una Lambda, el nombre. Esa tabla explica el 80 % de los errores tipo Value of property X must be of type String. Cuando necesites un ARN, casi siempre es !GetAtt Recurso.Arn; la sección "Return values" de cada tipo tiene la lista exacta.

Los pseudoparámetros son variables que AWS proporciona siempre: AWS::AccountId (111122223333), AWS::Region (eu-west-1), AWS::StackName, AWS::StackId, AWS::Partition, AWS::URLSuffix y AWS::NoValue.

Una pila es una plantilla desplegada: recursos que se crean, actualizan y borran como una unidad. Es la unidad de gestión, de permisos y de deriva.

El estado que desconcierta el primer día es ROLLBACK_COMPLETE: ocurre cuando falla la creación inicial y CloudFormation deshace lo creado. La pila queda existiendo pero en estado terminal: no se puede actualizar, solo borrar y volver a crear con la plantilla corregida. No confundir con UPDATE_ROLLBACK_COMPLETE, que sí es sano: la pila volvió a su versión anterior y se puede seguir actualizando.

Las etiquetas de la pila se propagan a todos los recursos que las admitan: es la forma más barata de cumplir el etiquetado obligatorio de MercadoFresco sin repetirlo recurso a recurso (se retoma en 11-02). Para el día a día, deploy crea la pila si no existe y la actualiza si existe, con un conjunto de cambios por debajo:

--no-fail-on-empty-changeset evita que el pipeline se ponga en rojo cuando no hay nada que cambiar, el caso más frecuente. --capabilities es obligatorio cuando la plantilla crea recursos de IAM: es una confirmación explícita de que sabes que estás creando permisos (CAPABILITY_IAM, CAPABILITY_NAMED_IAM si les pones nombre, CAPABILITY_AUTO_EXPAND para macros y pilas anidadas).

Por omisión, borrar una pila borra sus recursos. Para aurora-mercadofresco-pedidos y mercadofresco-catalogo-fotos eso es inaceptable.

UpdateReplacePolicy es el que la gente olvida y el que más disgustos evita: cambiar el DBClusterIdentifier de Aurora provoca un reemplazo, y sin ella el clúster viejo —con los datos— desaparece en cuanto el nuevo está listo. La protección de terminación es una capa más, a nivel de pila: aws cloudformation update-termination-protection --stack-name mercadofresco-datos-produccion --enable-termination-protection, y con ella activa delete-stack falla directamente. La regla de MercadoFresco: protección de terminación en las tres pilas de producción, y Retain o Snapshot en todo recurso con estado, en cualquier entorno.

Un conjunto de cambios es una simulación: CloudFormation compara la plantilla nueva con la pila actual y dice qué haría, sin hacerlo. Es la respuesta a la pregunta que nadie podía contestar en el módulo 8: ¿qué va a pasar si aplico esto?

La última línea es una alarma roja: Replacement: True significa que la subred se borra y se crea otra, con identificador nuevo, y todo lo que dependa de ella se ve afectado. Sin mirar el conjunto de cambios, eso habría ocurrido un viernes a las once.

La tercera fila es la que duele: un reemplazo en mercadofresco-catalogo-fotos significa bucket nuevo vacío y bucket viejo borrado con las 40.000 fotos dentro, salvo que UpdateReplacePolicy lo impida. La documentación de cada tipo indica, propiedad a propiedad, el "Update requires", y hay que mirarla antes de escribir el cambio, no después.

Precaución: si alguien modifica la pila entre que lo creas y lo ejecutas, la simulación deja de ser válida; por eso los pipelines lo crean y lo ejecutan en etapas consecutivas, no con horas de por medio.

La deriva es la diferencia entre lo que dice la plantilla y lo que hay. Aparece siempre: durante un incidente, a las tres de la mañana, nadie edita una plantilla.

Los estados por recurso son IN_SYNC, MODIFIED, DELETED y NOT_CHECKED. Este último importa: no todos los tipos admiten detección de deriva, así que un IN_SYNC de pila no garantiza que nada haya cambiado. Al encontrar deriva hay dos caminos: actualizar la plantilla para reflejar la realidad, si el cambio manual era legítimo, documentando el motivo en la PR; o reaplicar la pila para deshacerlo. Matiz importante: CloudFormation no tiene un "corregir deriva" automático, porque una actualización solo toca lo que cambió en la plantilla; para forzarlo hay que alterar el valor derivado en la plantilla y actualizar. En MercadoFresco, un trabajo programado la ejecuta cada semana sobre las pilas de producción y publica el resultado en alertas-mercadofresco. AWS Config (05-04) tiene además la regla cloudformation-stack-drift-detection-check, que hace esto de forma continua.

red-mercadofresco.yaml, en el repositorio mercadofresco-infra, reproduce la red del módulo 3.

Cuatro comentarios. El orden de creación no está en ninguna parte: CloudFormation deduce que SubredPublicaA necesita Vpc porque la referencia con !Ref, y crea en paralelo lo independiente; el único DependsOn es la única dependencia que no se deduce de las propiedades. !GetAZs evita fijar eu-west-1a. !If con !Ref NatB degrada en entornos pequeños sin duplicar la plantilla. Y las salidas se exportan con el prefijo ${AWS::StackName}, de modo que producción y preproducción no chocan: los nombres de exportación son únicos por región.

Siete minutos después —los NAT tardan unos dos minutos cada uno— la red completa existe. Y esta vez existe también en un fichero, con historial en Git.

aplicacion-mercadofresco.yaml monta el ALB, el grupo de destino y el ASG encima, sin conocer un solo identificador:

Dos detalles. YAML no admite dos etiquetas cortas seguidas, así que !ImportValue con !Sub dentro obliga a escribir la interna en forma larga ('Fn::Sub'); el error que produce olvidarlo, unsupported structure, no ayuda nada. Y UpdatePolicy decide qué pasa cuando cambia la plantilla de lanzamiento: sin ella, CloudFormation actualiza el ASG y no toca las instancias existentes, así que el cambio no se aplica hasta el siguiente escalado. Es el despliegue por renovación de 08-03 aplicado a la infraestructura.

Una pila con 300 recursos tarda 40 minutos, revierte entera ante cualquier fallo y no la puede tocar una persona sin coordinarse con las otras dos. La partición sigue dos criterios: por ciclo de vida (lo que cambia junto va junto) y por propiedad (cada pila tiene un dueño claro).

La primera fila es la clave: una exportación en uso es un cerrojo. Eso es bueno —evita romper cosas— y es malo —bloquea evoluciones—. La regla de MercadoFresco: exportaciones para lo estructural que no va a cambiar (VPC y subredes), y parámetros de SSM para todo lo demás y siempre que el valor cruce cuentas o regiones (ARN de colas, nombres de tablas, alias de claves).

Las pilas anidadas incluyen una plantilla dentro de otra como si fuera un recurso; la hija debe estar en S3 (mercadofresco-artefactos sirve) y sus salidas se leen con !GetAtt PilaSubredes.Outputs.SubredesApp.

Antes o después aparece algo que CloudFormation no sabe crear: un usuario en una herramienta externa, una carga inicial de datos. Un recurso personalizado delega en una Lambda: CloudFormation le envía un evento con RequestType y una URL prefirmada, y la función debe responder a esa URL.

Los proveedores de recursos son la alternativa formal: se registra un tipo nuevo, por ejemplo MercadoFresco::Facturacion::Cliente, con su esquema JSON y sus manejadores, y a partir de ahí se usa como cualquier otro recurso, con deriva y validación incluidas. Cuesta más y se paga por segundo de manejador, pero el registro público ya trae tipos de terceros —Datadog, MongoDB Atlas, GitHub— que se activan en un clic.

Esta es la operación que MercadoFresco necesita de verdad, porque su infraestructura ya existe. La alternativa ingenua —crear pilas nuevas y borrar lo viejo— implicaría migrar datos y una ventana de corte. La importación adopta los recursos existentes sin tocarlos. Cuatro pasos:

1. Escribir la plantilla que describe exactamente lo que existe. Aquí no se improvisa: si dice /health y el grupo de destino real tiene /salud, la importación pasa y el siguiente update-stack cambia la realidad sin avisar.
2. Añadir DeletionPolicy: Retain a todos los recursos a importar —es obligatorio— y preparar el fichero de identificadores, que empareja cada nombre lógico con el recurso real.
3. Crear y ejecutar un conjunto de cambios de tipo IMPORT.

La importación no comprueba que la plantilla coincida con la realidad: solo que los recursos existan y sean del tipo declarado. La deriva inmediatamente después es lo que revela las diferencias. Marta encuentra tres:

El tercer caso explica por qué el orden importa: primero importar y detectar, después corregir. Escribir la plantilla "como debería ser" y aplicarla directamente habría relajado una política de seguridad sin que nadie se enterara. MercadoFresco importa por capas, empezando por la red —la más estable— y dejando la de datos para el final, con ventana acordada y copia reciente de Aurora.

Un StackSet despliega la misma plantilla en un conjunto de cuentas y regiones desde una única operación. Hoy MercadoFresco tiene una cuenta, así que su utilidad es limitada; en 09-04, con cuatro, será la pieza que garantice que toda cuenta nueva nace con la línea base puesta: trail, grabador de Config, alarmas de facturación y roles.

SELF_MANAGED exige crear a mano dos roles de IAM; SERVICE_MANAGED se apoya en Organizations y no requiere nada. Con --auto-deployment Enabled=true, una cuenta añadida a una OU destino recibe la pila sola. Y la conclusión práctica del módulo 8: si la infraestructura es código, se despliega desde el pipeline. CodePipeline tiene acción nativa con cuatro modos; el patrón de MercadoFresco separa simulación de ejecución con una aprobación en medio.

RoleArn es clave: CloudFormation asume ese rol para crear los recursos, no los permisos de quien lanza el pipeline, así que Luis puede disparar un despliegue de infraestructura sin tener él permiso para crear VPC. Y TemplateConfiguration apunta a un JSON por entorno en el repositorio con Parameters y Tags: con eso, la diferencia entre preproducción y producción deja de ser un misterio y pasa a ser un fichero que se compara con diff en diez segundos.

Seis reglas en el README de mercadofresco-infra:

1. Plantillas pequeñas y con una responsabilidad. Más de 400 líneas u 80 recursos: se parte, por ciclo de vida.
2. Parámetros mínimos. Cada parámetro es una decisión que alguien puede tomar mal. Lo que no varía entre entornos es una constante, no un parámetro.
3. Nada de valores mágicos, y nombres físicos solo cuando hacen falta. Ni AMI a mano, ni CIDR repetidos, ni ARN a pelo: !Sub, Mappings y SSM cubren todos los casos. Y fijar BucketName o GroupName impide actualizaciones sin interrupción y bloquea desplegar dos veces la misma plantilla en una cuenta.
4. Todo pasa por PR y por validación automática. Ningún deploy manual contra producción; una emergencia obliga a abrir la PR de reconciliación el mismo día.

Esa segunda regla es la que habría impedido la diferencia entre preproducción y producción del principio de la lección. Ambas herramientas se ejecutan en build-mercadofresco-integracion (08-02) y fallan la construcción: no son avisos.

CloudFormation no cobra por gestionar recursos de AWS; cobra 0,0009 USD por segundo de manejador en recursos de terceros y tipos privados, con 1.000 operaciones mensuales gratuitas. El coste real es siempre el de los recursos creados.

Si el borrado queda en DELETE_FAILED, la causa casi siempre es un bucket con objetos dentro o una interfaz de red creada a mano en la subred; --retain-resources permite terminar el borrado dejando fuera esos recursos concretos.

Error: renombrar un recurso lógico y perder el recurso. Cambiar Vpc por VpcPrincipal no renombra: borra la VPC y crea otra. Consejo: los nombres lógicos son inmutables en la práctica; si hay que renombrar, se hace en dos pasos con DeletionPolicy: Retain más una importación posterior.

Error: desplegar sin mirar el conjunto de cambios. Es fusionar una PR sin leer el diff. Consejo: que el pipeline lo genere y lo publique antes de la aprobación, prestando atención a la columna Replacement. Error: no entender ROLLBACK_COMPLETE. Es un estado terminal de una creación fallida. Consejo: bórrala y vuelve a crearla, pero mira los eventos antes de borrar, filtrando CREATE_FAILED: el primero es la causa, los demás son consecuencias.

Error: contraseñas en parámetros con NoEcho creyendo que están seguras, o exportaciones para todo. Con veinte exportaciones cruzadas la red se vuelve inmodificable. Consejo: {{resolve:secretsmanager:...}} o {{resolve:ssm-secure:...}} para los secretos, exportaciones solo para lo estructural y SSM para el resto.

Error: creer que la importación valida la plantilla. No lo hace: detección de deriva justo después de cada importación, sin excepción.

Consejo: usa --role-arn en todos los despliegues y una política de pila en los recursos con datos. Lo primero es la diferencia entre "cualquiera que pueda desplegar puede crear cualquier cosa" y "solo la plantilla revisada crea lo que declara"; lo segundo, con set-stack-policy, deniega Update:Replace y Update:Delete sobre recursos concretos, un cinturón para el tirante de UpdateReplacePolicy.

Consejo: mira la plantilla desplegada, no solo la del repositorio. get-template --template-stage Processed la devuelve con macros y transformaciones ya aplicadas; es lo que hay que revisar cuando el resultado no coincide con lo que creías escribir.

Consejo: Description en la plantilla, en cada parámetro y en cada salida. Es la documentación viva del principio, y cuesta treinta segundos.

Escribe integracion-mercadofresco.yaml: la cola cola-mercadofresco-pedidos con su DLQ mercadofresco-pedidos-fallidos y 5 intentos, el tema mercadofresco-pedido-confirmado, la suscripción de la cola al tema y la publicación del ARN de la cola en Parameter Store. Requisitos: cifrado con alias/mercadofresco-datos, retención de 14 días en la DLQ y 4 en la cola, sufijo de entorno en los nombres, etiquetado obligatorio completo y DeletionPolicy adecuada en la DLQ. Indica qué tipo de actualización provocaría cambiar VisibilityTimeout y cuál cambiar QueueName.

alb-mercadofresco-tienda y tg-mercadofresco-tienda llevan ocho meses en producción, creados a mano. Marta quiere adoptarlos en mercadofresco-aplicacion-produccion sin cortar el servicio. Describe el procedimiento: qué recopilar antes y con qué comandos, qué debe llevar la plantilla obligatoriamente, cómo se construye el fichero de identificadores, qué comandos se ejecutan y en qué orden, y qué se hace inmediatamente después. Explica qué ocurriría si la plantilla declarase HealthCheckIntervalSeconds: 30 cuando el grupo de destino real tiene 15, y en qué momento exacto se manifestaría.

Un compañero ha escrito una plantilla de 780 líneas con 96 recursos: VPC y subredes, Aurora, dos tablas de DynamoDB, ElastiCache, ALB, ASG, cuatro colas, bus de eventos, doce alarmas y tres buckets. Tarda 41 minutos y cualquier fallo revierte todo; la semana pasada, un error en una alarma revirtió también un cambio de subred correcto. Propón la partición: qué pilas, con qué contenido y con qué criterio; para cada frontera, si usarías exportación o SSM y por qué; el orden de despliegue y el de borrado; y qué habría pasado la semana pasada con tu partición.

Solución 1

Cambiar VisibilityTimeout es sin interrupción: SQS lo aplica en caliente y la URL no cambia. Cambiar QueueName es con reemplazo: SQS no permite renombrar, así que se crea una cola nueva y se borra la vieja con los mensajes dentro. Es un ejemplo perfecto de por qué fijar nombres físicos tiene coste y de por qué la DLQ lleva Retain. Y un detalle fácil de olvidar: sin la política de cola, SNS no puede entregar y los mensajes se pierden en silencio; la condición aws:SourceArn evita que cualquier otro tema de la cuenta escriba en ella, el mínimo privilegio de 04-01 aplicado a recursos.

Solución 2

Antes: leer la configuración real, nunca escribirla de memoria.

La plantilla se escribe a partir de esos ficheros, propiedad por propiedad, incluidos los atributos poco evidentes: deregistration_delay.timeout_seconds, stickiness.enabled, la política TLS del listener y el certificado de ACM. Obligatorio: DeletionPolicy: Retain en el ALB, el grupo de destino y el listener; sin ella la importación se rechaza, y conviene añadir UpdateReplacePolicy: Retain. El fichero de identificadores empareja LogicalResourceId con LoadBalancerArn y TargetGroupArn, usando el ARN completo (arn:aws:elasticloadbalancing:eu-west-1:111122223333:loadbalancer/app/alb-mercadofresco-tienda/a1b2c3).

Orden: cfn-lint; create-change-set con --change-set-type IMPORT; describe-change-set para confirmar que todas las acciones son Import y ninguna es Add o Modify —una sola Modify significa que la plantilla no coincide con la realidad y hay que corregirla antes—; execute-change-set; wait stack-import-complete. Inmediatamente después: detección de deriva, resolviendo caso a caso si manda la plantilla o la realidad. El caso de 30 frente a 15. La importación pasa sin quejarse: solo verifica existencia y tipo. La deriva lo marcaría como MODIFIED. Y si nadie mira, el problema se manifiesta en el siguiente update-stack cualquiera, aunque no tenga nada que ver con el grupo de destino: CloudFormation aplica la plantilla completa y el intervalo pasa a 30 segundos. En la práctica, el ALB tarda el doble en detectar una instancia caída —de 30 a 60 segundos con dos comprobaciones fallidas—, justo el tipo de degradación silenciosa que nadie relaciona con un despliegue de otra cosa. Ese es el argumento entero a favor del paso de deriva.

Solución 3

Cinco pilas, las mismas de la tabla de la lección: red (casi inmutable, todo depende de ella), datos (estado, borrado catastrófico, requiere protección), integracion (sin estado duradero, propietario Luis), aplicacion (lo que más cambia) y observabilidad (cambia con los incidentes, riesgo nulo). Fronteras y orden. Red → todas: exportación, porque los identificadores de VPC y subredes son estructurales, no van a cambiar, y queremos el cerrojo: nadie debe poder borrar la red mientras haya algo encima. Datos → aplicación (endpoint de Aurora, nombres de tablas): SSM, porque cambian con más facilidad de la que parece —una migración a Serverless v2, un endpoint de lectura— y una exportación bloquearía justamente eso. Integración → aplicación: SSM, además porque en 09-04 estas pilas van a vivir en cuentas distintas, donde las exportaciones no funcionan. Todas → observabilidad: SSM; la pila que menos importa y más cambia no debe poder bloquear a nadie.

El orden de despliegue es red → datos e integración en paralelo → aplicación → observabilidad, y el de borrado, el inverso exacto: las exportaciones lo imponen solas en el caso de la red, y en el resto hay que respetarlo por disciplina porque SSM no impone nada.

La semana pasada. El error en la alarma habría fallado únicamente mercadofresco-observabilidad, que despliega en menos de dos minutos y no tiene recursos críticos; el cambio de subred, en mercadofresco-red, ya estaría aplicado y no se habría revertido. El ámbito del fallo pasa de 96 recursos a 12, y los 41 minutos pasan a cuatro despliegues de entre 2 y 12 minutos, algunos en paralelo. Un matiz honesto: la partición no es gratis. Introduce orden de despliegue, obliga a mantener las fronteras y hace que un cambio que toca dos capas necesite dos pilas. La regla que lo justifica es la misma de 08-05 con los despliegues: el ámbito de un fallo debe ser proporcional al riesgo del cambio, y mezclar una alarma con una subred viola esa regla.

La infraestructura de MercadoFresco está por fin en ficheros. red-mercadofresco.yaml describe la VPC, las seis subredes, el gateway de internet, los NAT —dos en producción y uno en el resto, con la misma plantilla— y el endpoint de S3, con historial en Git; aplicacion-mercadofresco.yaml monta encima el ALB, el grupo de destino y el grupo de autoescalado sin conocer un solo identificador, importando las salidas de la primera. Y tienes la anatomía de una plantilla, con parámetros que validan antes de empezar gracias a los tipos específicos de AWS, valores que llegan desde Parameter Store sin tocar la plantilla y secretos resueltos con {{resolve:secretsmanager:...}} en lugar del falso amigo que es NoEcho. Tienes las funciones intrínsecas y la tabla que evita el error más frecuente: que !Ref devuelve la URL de una cola, el ARN de un tema y el nombre de un rol, y que casi siempre lo que buscas es !GetAtt Recurso.Arn. Y tienes el ciclo de vida de una pila, con el estado que desconcierta el primer día: ROLLBACK_COMPLETE, que solo se puede borrar.

Lo que de verdad cambia la forma de trabajar son tres mecanismos. Los conjuntos de cambios, que contestan por escrito a la pregunta que en el módulo 8 nadie podía contestar —¿qué va a pasar si aplico esto?— y que muestran la columna Replacement que separa un cambio rutinario de la destrucción de una subred. Las políticas de eliminación y de reemplazo más la protección de terminación, lo único que se interpone entre un comando y los datos de Aurora. Y la detección de deriva, que convierte los cambios manuales de invisibles en un informe semanal. Con la importación de recursos existentes, MercadoFresco no recrea nada: adopta lo que ya funciona, capa a capa, empezando por la red, y ejecuta la deriva justo después —el paso que nadie debe saltarse, porque la importación comprueba que los recursos existan, no que la plantilla los describa bien—. Las cinco pilas por entorno quedan repartidas por ciclo de vida y por propiedad, con exportaciones para lo estructural y SSM para lo que puede cambiar o cruzar cuentas, sabiendo que una exportación en uso es un cerrojo. Y la infraestructura pasa por el pipeline de 08-04 con el mismo rigor que el código: cfn-lint y cfn-guard que fallan la construcción, un conjunto de cambios publicado, la aprobación de Marta y la ejecución con RoleArn, para que quien dispara no necesite los permisos que se ejercen.

Queda una limitación que se nota en cuanto la plantilla crece. La red describe seis subredes casi idénticas repetidas a mano: no hay bucles, no hay funciones, no hay forma de escribir "crea una subred por cada AZ" ni de encapsular "la red estándar de MercadoFresco" en algo reutilizable. Las condiciones sirven para dos casos y se vuelven ilegibles a partir de cinco. Y no hay manera de escribir una prueba que verifique que ninguna plantilla abre el puerto 22 al mundo: cfn-guard ayuda, pero es otro lenguaje más que aprender.

En 09-02, «AWS CDK», esa misma infraestructura se escribe en TypeScript y en Python, con bucles, condicionales, tipos, constructos reutilizables y pruebas unitarias de verdad, y el resultado sigue siendo una plantilla de CloudFormation desplegada como una pila. Todo lo de esta lección sigue siendo cierto por debajo: el CDK no sustituye a CloudFormation, lo escribe por ti.