Vuit mòduls han construït una arquitectura completa: sis subxarxes, dos grups d'autoescalat, cinc funcions Lambda, quatre cues, un clúster Aurora, dues taules de DynamoDB, cinc buckets, un balancejador, una distribució de CloudFront, catorze alarmes i un pipeline que desplega sense tallar el servei. Tot funciona. I res de tot això no existeix en cap fitxer: existeix perquè algú va escriure una ordre algun dia. Aquesta lliçó arregla l'asimetria que la Marta va assenyalar en tancar el mòdul 8 amb l'eina nativa d'AWS per fer-ho: CloudFormation, el servei que converteix un fitxer de text en recursos reals i manté la relació entre tots dos.

Avís de cost. CloudFormation és gratuït quan gestiona recursos d'AWS: pagues els recursos, no les piles. Només cobra per recursos de tercers i tipus privats registrats (0,0009 USD per segon de manejador). La plantilla de xarxa crea dos NAT gateway: uns 0,045 USD/hora cadascun més trànsit, uns 65 USD al mes si la deixes posada. L'apartat de neteja l'esborra amb una ordre. Dades fictícies.

1. L'asimetria entre codi i infraestructura
2. Què és la infraestructura com a codi, i declaratiu enfront d'imperatiu
3. Anatomia d'una plantilla
4. Paràmetres: tipus, restriccions i valors des d'SSM
5. Mappings, Conditions i funcions intrínseques
6. Piles: cicle de vida, estats i ROLLBACK_COMPLETE
7. Polítiques d'eliminació i protecció de terminació
8. Conjunts de canvis i els tres tipus d'actualització
9. Detecció de deriva
10. La xarxa de MercadoFresco en una plantilla
11. La capa d'aplicació que importa les sortides
12. Diverses piles: exportacions enfront d'SSM
13. Piles imbricades, mòduls i recursos personalitzats
14. Importar recursos existents a una pila
15. StackSets i desplegament des del pipeline
16. Bones pràctiques, cfn-lint i cfn-guard
17. Límits, cost i neteja
18. Errors habituals i consells
19. Exercicis
20. Conclusió

La Marta fa inventari en una tarda i apunta quatre fets:

El tercer és el més car. Al mòdul 5 va aparèixer un grup de seguretat amb una regla cap a un rang d'IP que ningú no reconeixia i ningú no va esborrar: podia ser d'un proveïdor. Aquest és el cost real de no tenir infraestructura com a codi: no és que no la puguis crear; és que no la pots canviar amb confiança.

Consisteix a descriure la infraestructura en fitxers de text versionats a Git i deixar que una eina faci coincidir la realitat amb la descripció. No és "automatitzar la creació": és que el fitxer sigui la font de veritat. D'aquí en surten quatre propietats:

• Reproductibilitat. El mateix fitxer produeix el mateix resultat en una altra regió, en un altre compte o d'aquí a sis mesos.
• Revisió. La infraestructura passa per una pull request com el codi de 08-01: un canvi en un grup de seguretat es comenta, s'aprova i queda amb autor, data i motiu.
• Deriva controlada i documentació viva. L'eina sap què hauria d'existir, així que pot comparar-ho amb el que existeix —sense IaC la deriva és invisible per definició— i el fitxer no pot quedar-se obsolet respecte a la realitat, perquè és el que la crea.
• Es pot esborrar sense por. Quan aixecar un entorn costa una ordre, apagar-lo el divendres deixa de ser un risc i passa a ser un estalvi. És la propietat que convenç els escèptics.

MercadoFresco ha fet servir fins ara l'enfocament imperatiu: ordres que descriuen com arribar a l'estat. CloudFormation és declaratiu: descrius què vols i el servei calcula els passos.

L'script no sap res de l'estat anterior: cada ordre crea. Fer-lo idempotent exigiria embolcallar cada línia en una comprovació, gestionar els identificadors generats i decidir què fer si el recurs existeix amb una altra configuració; és a dir, reimplementar CloudFormation en Bash.

L'imperatiu no desapareix: continua sent el correcte per a operacions puntuals (aws s3 cp, reiniciar una instància, consultar mètriques). La regla: si el recurs ha de continuar existint demà, va en una plantilla; si és una acció que passa una vegada, va en una ordre.

Un document YAML o JSON amb nou seccions possibles. Només Resources és obligatòria.

Falten Rules (validació de combinacions de paràmetres) i Hooks, molt menys habituals. L'estructura d'un recurs sempre és la mateixa, amb Type i Properties obligatoris i la resta opcional:

Primera regla important: canviar el nom lògic d'un recurs equival a esborrar-lo i crear-ne un altre. CloudFormation identifica els recursos pel seu nom lògic, no pel que fan. Reanomenar Vpc a VpcPrincipal en una plantilla desplegada destrueix la VPC.

Sense paràmetres caldrien tres plantilles gairebé idèntiques per als tres entorns.

Tres coses separen una plantilla amateur d'una de professional:

1. Els tipus específics d'AWS validen abans de començar. Amb Type: String per a una clau SSH inexistent, la pila crea mitja dotzena de recursos i falla en arribar a la instància. Amb AWS::EC2::KeyPair::KeyName falla al segon zero, sense crear res.
2. AWS::SSM::Parameter::Value<...> desacobla la plantilla dels valors. L'AMI de la botiga canvia cada mes; la plantilla no hauria de canviar per això. MercadoFresco ho fa servir amb /mercadofresco/produccion/ami-tienda.
3. NoEcho no xifra, només oculta. Les contrasenyes no van en paràmetres: van a Secrets Manager (04-03) i es referencien amb resolució dinàmica, que s'avalua en el desplegament sense que el valor entri mai a la plantilla:

Mappings és una taula de consulta estàtica de dos nivells, útil per variar per regió o per entorn; es llegeix amb Fn::FindInMap. Conditions calcula booleans amb Fn::Equals, Fn::And, Fn::Or i Fn::Not.

Es llegeixen amb !FindInMap [ PorEntorno, !Ref Entorno, Tipo ]. Un recurs amb Condition: CrearSegundoNat només es crea si la condició és certa: nat-mercadofresco-b existeix en producció i no en desenvolupament amb la mateixa plantilla, i això estalvia uns 32 USD al mes per entorn no productiu. Avís: fes-les servir amb moderació. Una plantilla amb dotze condicions imbricades és il·legible i impossible de raonar quan falla; si la diferència entre entorns és gran, calen plantilles diferents, no més condicions.

Cadascuna té forma llarga (Fn::Sub) i curta (!Sub). En YAML es fa servir la curta tret que calgui imbricar dues curtes seguides, cosa que YAML no permet.

El que més confusió genera és !Ref, perquè retorna coses diferents segons el tipus: en una VPC o subxarxa, el seu identificador; en un bucket, el nom; en una cua d'SQS, la URL; en un tema d'SNS, l'ARN; en un rol d'IAM, el nom; en una Lambda, el nom. Aquesta taula explica el 80 % dels errors del tipus Value of property X must be of type String. Quan necessitis un ARN, gairebé sempre és !GetAtt Recurso.Arn; la secció "Return values" de cada tipus té la llista exacta.

Els pseudoparàmetres són variables que AWS proporciona sempre: AWS::AccountId (111122223333), AWS::Region (eu-west-1), AWS::StackName, AWS::StackId, AWS::Partition, AWS::URLSuffix i AWS::NoValue.

Una pila és una plantilla desplegada: recursos que es creen, s'actualitzen i s'esborren com una unitat. És la unitat de gestió, de permisos i de deriva.

L'estat que desconcerta el primer dia és ROLLBACK_COMPLETE: passa quan falla la creació inicial i CloudFormation desfà el que s'ha creat. La pila queda existint però en estat terminal: no es pot actualitzar, només esborrar i tornar a crear amb la plantilla corregida. No s'ha de confondre amb UPDATE_ROLLBACK_COMPLETE, que sí que és sa: la pila va tornar a la seva versió anterior i es pot continuar actualitzant.

Les etiquetes de la pila es propaguen a tots els recursos que les admetin: és la manera més barata de complir l'etiquetatge obligatori de MercadoFresco sense repetir-lo recurs a recurs (es reprèn a 11-02). Per al dia a dia, deploy crea la pila si no existeix i l'actualitza si existeix, amb un conjunt de canvis per sota:

--no-fail-on-empty-changeset evita que el pipeline es posi en vermell quan no hi ha res per canviar, el cas més freqüent. --capabilities és obligatori quan la plantilla crea recursos d'IAM: és una confirmació explícita que saps que estàs creant permisos (CAPABILITY_IAM, CAPABILITY_NAMED_IAM si els poses nom, CAPABILITY_AUTO_EXPAND per a macros i piles imbricades).

Per omissió, esborrar una pila esborra els seus recursos. Per a aurora-mercadofresco-pedidos i mercadofresco-catalogo-fotos això és inacceptable.

UpdateReplacePolicy és el que la gent oblida i el que més disgustos evita: canviar el DBClusterIdentifier d'Aurora provoca un reemplaçament, i sense ella el clúster vell —amb les dades— desapareix tan bon punt el nou està llest. La protecció de terminació és una capa més, a nivell de pila: aws cloudformation update-termination-protection --stack-name mercadofresco-datos-produccion --enable-termination-protection, i amb ella activa delete-stack falla directament. La regla de MercadoFresco: protecció de terminació a les tres piles de producció, i Retain o Snapshot en tot recurs amb estat, en qualsevol entorn.

Un conjunt de canvis és una simulació: CloudFormation compara la plantilla nova amb la pila actual i diu què faria, sense fer-ho. És la resposta a la pregunta que ningú no podia contestar al mòdul 8: què passarà si aplico això?

L'última línia és una alarma vermella: Replacement: True significa que la subxarxa s'esborra i se'n crea una altra, amb identificador nou, i tot el que en depengui se'n veu afectat. Sense mirar el conjunt de canvis, això hauria passat un divendres a les onze.

La tercera fila és la que fa mal: un reemplaçament a mercadofresco-catalogo-fotos significa bucket nou buit i bucket vell esborrat amb les 40.000 fotos dins, tret que UpdateReplacePolicy ho impedeixi. La documentació de cada tipus indica, propietat a propietat, el "Update requires", i cal mirar-la abans d'escriure el canvi, no després.

Precaució: si algú modifica la pila entre que el crees i l'executes, la simulació deixa de ser vàlida; per això els pipelines el creen i l'executen en etapes consecutives, no amb hores pel mig.

La deriva és la diferència entre el que diu la plantilla i el que hi ha. Apareix sempre: durant un incident, a les tres de la matinada, ningú no edita una plantilla.

Els estats per recurs són IN_SYNC, MODIFIED, DELETED i NOT_CHECKED. Aquest últim importa: no tots els tipus admeten detecció de deriva, així que un IN_SYNC de pila no garanteix que res no hagi canviat. En trobar deriva hi ha dos camins: actualitzar la plantilla perquè reflecteixi la realitat, si el canvi manual era legítim, documentant el motiu a la PR; o reaplicar la pila per desfer-lo. Matís important: CloudFormation no té un "corregir deriva" automàtic, perquè una actualització només toca el que ha canviat a la plantilla; per forçar-ho cal alterar el valor derivat a la plantilla i actualitzar. A MercadoFresco, una tasca programada l'executa cada setmana sobre les piles de producció i publica el resultat a alertas-mercadofresco. AWS Config (05-04) té a més la regla cloudformation-stack-drift-detection-check, que fa això de manera contínua.

red-mercadofresco.yaml, al repositori mercadofresco-infra, reprodueix la xarxa del mòdul 3.

Quatre comentaris. L'ordre de creació no és enlloc: CloudFormation dedueix que SubredPublicaA necessita Vpc perquè la referencia amb !Ref, i crea en paral·lel el que és independent; l'únic DependsOn és l'única dependència que no es dedueix de les propietats. !GetAZs evita fixar eu-west-1a. !If amb !Ref NatB degrada en entorns petits sense duplicar la plantilla. I les sortides s'exporten amb el prefix ${AWS::StackName}, de manera que producció i preproducció no xoquen: els noms d'exportació són únics per regió.

Set minuts després —els NAT triguen uns dos minuts cadascun— la xarxa completa existeix. I aquesta vegada existeix també en un fitxer, amb historial a Git.

aplicacion-mercadofresco.yaml munta l'ALB, el grup de destinació i l'ASG a sobre, sense conèixer ni un sol identificador:

Dos detalls. YAML no admet dues etiquetes curtes seguides, així que !ImportValue amb !Sub a dins obliga a escriure la interna en forma llarga ('Fn::Sub'); l'error que produeix oblidar-ho, unsupported structure, no ajuda gens. I UpdatePolicy decideix què passa quan canvia la plantilla de llançament: sense ella, CloudFormation actualitza l'ASG i no toca les instàncies existents, així que el canvi no s'aplica fins al següent escalat. És el desplegament per renovació de 08-03 aplicat a la infraestructura.

Una pila amb 300 recursos triga 40 minuts, reverteix sencera davant de qualsevol fallada i no la pot tocar una persona sense coordinar-se amb les altres dues. La partició segueix dos criteris: per cicle de vida (el que canvia junt va junt) i per propietat (cada pila té un amo clar).

La primera fila és la clau: una exportació en ús és un forrellat. Això és bo —evita trencar coses— i és dolent —bloqueja evolucions—. La regla de MercadoFresco: exportacions per a l'estructural que no canviarà (VPC i subxarxes), i paràmetres d'SSM per a tota la resta i sempre que el valor creui comptes o regions (ARN de cues, noms de taules, àlies de claus).

Les piles imbricades inclouen una plantilla dins d'una altra com si fos un recurs; la filla ha de ser a S3 (mercadofresco-artefactos serveix) i les seves sortides es llegeixen amb !GetAtt PilaSubredes.Outputs.SubredesApp.

Tard o d'hora apareix alguna cosa que CloudFormation no sap crear: un usuari en una eina externa, una càrrega inicial de dades. Un recurs personalitzat delega en una Lambda: CloudFormation li envia un esdeveniment amb RequestType i una URL prefirmada, i la funció ha de respondre a aquesta URL.

Els proveïdors de recursos són l'alternativa formal: es registra un tipus nou, per exemple MercadoFresco::Facturacion::Cliente, amb el seu esquema JSON i els seus manejadors, i a partir d'aquí es fa servir com qualsevol altre recurs, amb deriva i validació incloses. Costa més i es paga per segon de manejador, però el registre públic ja porta tipus de tercers —Datadog, MongoDB Atlas, GitHub— que s'activen en un clic.

Aquesta és l'operació que MercadoFresco necessita de veritat, perquè la seva infraestructura ja existeix. L'alternativa ingènua —crear piles noves i esborrar el vell— implicaria migrar dades i una finestra de tall. La importació adopta els recursos existents sense tocar-los. Quatre passos:

1. Escriure la plantilla que descriu exactament el que existeix. Aquí no s'improvisa: si diu /health i el grup de destinació real té /salud, la importació passa i el següent update-stack canvia la realitat sense avisar.
2. Afegir DeletionPolicy: Retain a tots els recursos a importar —és obligatori— i preparar el fitxer d'identificadors, que aparella cada nom lògic amb el recurs real.
3. Crear i executar un conjunt de canvis de tipus IMPORT.

La importació no comprova que la plantilla coincideixi amb la realitat: només que els recursos existeixin i siguin del tipus declarat. La deriva immediatament després és el que revela les diferències. La Marta en troba tres:

El tercer cas explica per què l'ordre importa: primer importar i detectar, després corregir. Escriure la plantilla "com hauria de ser" i aplicar-la directament hauria relaxat una política de seguretat sense que ningú se n'assabentés. MercadoFresco importa per capes, començant per la xarxa —la més estable— i deixant la de dades per al final, amb finestra acordada i còpia recent d'Aurora.

Un StackSet desplega la mateixa plantilla en un conjunt de comptes i regions des d'una única operació. Avui MercadoFresco té un compte, així que la seva utilitat és limitada; a 09-04, amb quatre, serà la peça que garanteixi que tot compte nou neix amb la línia base posada: trail, gravador de Config, alarmes de facturació i rols.

SELF_MANAGED exigeix crear a mà dos rols d'IAM; SERVICE_MANAGED es recolza en Organizations i no requereix res. Amb --auto-deployment Enabled=true, un compte afegit a una OU destinació rep la pila sol. I la conclusió pràctica del mòdul 8: si la infraestructura és codi, es desplega des del pipeline. CodePipeline té acció nativa amb quatre modes; el patró de MercadoFresco separa simulació d'execució amb una aprovació al mig.

RoleArn és clau: CloudFormation assumeix aquest rol per crear els recursos, no els permisos de qui llança el pipeline, així que el Luis pot disparar un desplegament d'infraestructura sense tenir ell permís per crear VPC. I TemplateConfiguration apunta a un JSON per entorn al repositori amb Parameters i Tags: amb això, la diferència entre preproducció i producció deixa de ser un misteri i passa a ser un fitxer que es compara amb diff en deu segons.

Sis regles al README de mercadofresco-infra:

1. Plantilles petites i amb una responsabilitat. Més de 400 línies o 80 recursos: es parteix, per cicle de vida.
2. Paràmetres mínims. Cada paràmetre és una decisió que algú pot prendre malament. El que no varia entre entorns és una constant, no un paràmetre.
3. Res de valors màgics, i noms físics només quan calen. Ni AMI a mà, ni CIDR repetits, ni ARN a pèl: !Sub, Mappings i SSM cobreixen tots els casos. I fixar BucketName o GroupName impedeix actualitzacions sense interrupció i bloqueja desplegar dues vegades la mateixa plantilla en un compte.
4. Tot passa per PR i per validació automàtica. Cap deploy manual contra producció; una emergència obliga a obrir la PR de reconciliació el mateix dia.

Aquesta segona regla és la que hauria impedit la diferència entre preproducció i producció del principi de la lliçó. Totes dues eines s'executen a build-mercadofresco-integracion (08-02) i fallen la construcció: no són avisos.

CloudFormation no cobra per gestionar recursos d'AWS; cobra 0,0009 USD per segon de manejador en recursos de tercers i tipus privats, amb 1.000 operacions mensuals gratuïtes. El cost real és sempre el dels recursos creats.

Si l'esborrat queda en DELETE_FAILED, la causa gairebé sempre és un bucket amb objectes dins o una interfície de xarxa creada a mà a la subxarxa; --retain-resources permet acabar l'esborrat deixant fora aquests recursos concrets.

Error: reanomenar un recurs lògic i perdre el recurs. Canviar Vpc per VpcPrincipal no reanomena: esborra la VPC i en crea una altra. Consell: els noms lògics són immutables a la pràctica; si cal reanomenar, es fa en dos passos amb DeletionPolicy: Retain més una importació posterior.

Error: desplegar sense mirar el conjunt de canvis. És fusionar una PR sense llegir el diff. Consell: que el pipeline el generi i el publiqui abans de l'aprovació, parant atenció a la columna Replacement. Error: no entendre ROLLBACK_COMPLETE. És un estat terminal d'una creació fallida. Consell: esborra-la i torna-la a crear, però mira els esdeveniments abans d'esborrar, filtrant CREATE_FAILED: el primer és la causa, els altres són conseqüències.

Error: contrasenyes en paràmetres amb NoEcho creient que estan segures, o exportacions per a tot. Amb vint exportacions creuades la xarxa es torna immodificable. Consell: {{resolve:secretsmanager:...}} o {{resolve:ssm-secure:...}} per als secrets, exportacions només per a l'estructural i SSM per a la resta.

Error: creure que la importació valida la plantilla. No ho fa: detecció de deriva just després de cada importació, sense excepció.

Consell: fes servir --role-arn en tots els desplegaments i una política de pila en els recursos amb dades. El primer és la diferència entre "qualsevol que pugui desplegar pot crear qualsevol cosa" i "només la plantilla revisada crea el que declara"; el segon, amb set-stack-policy, denega Update:Replace i Update:Delete sobre recursos concrets, un cinturó per als elàstics d'UpdateReplacePolicy.

Consell: mira la plantilla desplegada, no només la del repositori. get-template --template-stage Processed la retorna amb macros i transformacions ja aplicades; és el que cal revisar quan el resultat no coincideix amb el que et pensaves escriure.

Consell: Description a la plantilla, a cada paràmetre i a cada sortida. És la documentació viva del principi, i costa trenta segons.

Escriu integracion-mercadofresco.yaml: la cua cola-mercadofresco-pedidos amb la seva DLQ mercadofresco-pedidos-fallidos i 5 intents, el tema mercadofresco-pedido-confirmado, la subscripció de la cua al tema i la publicació de l'ARN de la cua a Parameter Store. Requisits: xifratge amb alias/mercadofresco-datos, retenció de 14 dies a la DLQ i 4 a la cua, sufix d'entorn als noms, etiquetatge obligatori complet i DeletionPolicy adequada a la DLQ. Indica quin tipus d'actualització provocaria canviar VisibilityTimeout i quin canviar QueueName.

alb-mercadofresco-tienda i tg-mercadofresco-tienda porten vuit mesos en producció, creats a mà. La Marta els vol adoptar a mercadofresco-aplicacion-produccion sense tallar el servei. Descriu el procediment: què recopilar abans i amb quines ordres, què ha de portar la plantilla obligatòriament, com es construeix el fitxer d'identificadors, quines ordres s'executen i en quin ordre, i què es fa immediatament després. Explica què passaria si la plantilla declarés HealthCheckIntervalSeconds: 30 quan el grup de destinació real té 15, i en quin moment exacte es manifestaria.

Un company ha escrit una plantilla de 780 línies amb 96 recursos: VPC i subxarxes, Aurora, dues taules de DynamoDB, ElastiCache, ALB, ASG, quatre cues, bus d'esdeveniments, dotze alarmes i tres buckets. Triga 41 minuts i qualsevol fallada ho reverteix tot; la setmana passada, un error en una alarma va revertir també un canvi de subxarxa correcte. Proposa la partició: quines piles, amb quin contingut i amb quin criteri; per a cada frontera, si faries servir exportació o SSM i per què; l'ordre de desplegament i el d'esborrat; i què hauria passat la setmana passada amb la teva partició.

Solució 1

Canviar VisibilityTimeout és sense interrupció: SQS ho aplica en calent i la URL no canvia. Canviar QueueName és amb reemplaçament: SQS no permet reanomenar, així que es crea una cua nova i s'esborra la vella amb els missatges dins. És un exemple perfecte de per què fixar noms físics té cost i de per què la DLQ porta Retain. I un detall fàcil d'oblidar: sense la política de cua, SNS no pot lliurar i els missatges es perden en silenci; la condició aws:SourceArn evita que qualsevol altre tema del compte hi escrigui, el mínim privilegi de 04-01 aplicat a recursos.

Solució 2

Abans: llegir la configuració real, mai escriure-la de memòria.

La plantilla s'escriu a partir d'aquests fitxers, propietat per propietat, inclosos els atributs poc evidents: deregistration_delay.timeout_seconds, stickiness.enabled, la política TLS de l'oient i el certificat d'ACM. Obligatori: DeletionPolicy: Retain a l'ALB, al grup de destinació i a l'oient; sense ella la importació es rebutja, i convé afegir UpdateReplacePolicy: Retain. El fitxer d'identificadors aparella LogicalResourceId amb LoadBalancerArn i TargetGroupArn, fent servir l'ARN complet (arn:aws:elasticloadbalancing:eu-west-1:111122223333:loadbalancer/app/alb-mercadofresco-tienda/a1b2c3).

Ordre: cfn-lint; create-change-set amb --change-set-type IMPORT; describe-change-set per confirmar que totes les accions són Import i cap no és Add o Modify —una sola Modify significa que la plantilla no coincideix amb la realitat i cal corregir-la abans—; execute-change-set; wait stack-import-complete. Immediatament després: detecció de deriva, resolent cas a cas si mana la plantilla o la realitat. El cas de 30 enfront de 15. La importació passa sense queixar-se: només verifica existència i tipus. La deriva ho marcaria com a MODIFIED. I si ningú no ho mira, el problema es manifesta en el següent update-stack qualsevol, encara que no tingui res a veure amb el grup de destinació: CloudFormation aplica la plantilla completa i l'interval passa a 30 segons. A la pràctica, l'ALB triga el doble a detectar una instància caiguda —de 30 a 60 segons amb dues comprovacions fallides—, just el tipus de degradació silenciosa que ningú no relaciona amb un desplegament d'una altra cosa. Aquest és l'argument sencer a favor del pas de deriva.

Solució 3

Cinc piles, les mateixes de la taula de la lliçó: red (gairebé immutable, tot en depèn), datos (estat, esborrat catastròfic, requereix protecció), integracion (sense estat durador, propietari el Luis), aplicacion (el que més canvia) i observabilidad (canvia amb els incidents, risc nul). Fronteres i ordre. Xarxa → totes: exportació, perquè els identificadors de VPC i subxarxes són estructurals, no canviaran, i volem el forrellat: ningú no ha de poder esborrar la xarxa mentre hi hagi alguna cosa a sobre. Dades → aplicació (endpoint d'Aurora, noms de taules): SSM, perquè canvien amb més facilitat de la que sembla —una migració a Serverless v2, un endpoint de lectura— i una exportació bloquejaria justament això. Integració → aplicació: SSM, a més perquè a 09-04 aquestes piles viuran en comptes diferents, on les exportacions no funcionen. Totes → observabilitat: SSM; la pila que menys importa i més canvia no ha de poder bloquejar ningú.

L'ordre de desplegament és xarxa → dades i integració en paral·lel → aplicació → observabilitat, i el d'esborrat, l'invers exacte: les exportacions l'imposen soles en el cas de la xarxa, i a la resta cal respectar-lo per disciplina perquè SSM no imposa res.

La setmana passada. L'error a l'alarma hauria fet fallar únicament mercadofresco-observabilidad, que desplega en menys de dos minuts i no té recursos crítics; el canvi de subxarxa, a mercadofresco-red, ja estaria aplicat i no s'hauria revertit. L'àmbit de la fallada passa de 96 recursos a 12, i els 41 minuts passen a quatre desplegaments d'entre 2 i 12 minuts, alguns en paral·lel. Un matís honest: la partició no és gratis. Introdueix ordre de desplegament, obliga a mantenir les fronteres i fa que un canvi que toca dues capes necessiti dues piles. La regla que ho justifica és la mateixa de 08-05 amb els desplegaments: l'àmbit d'una fallada ha de ser proporcional al risc del canvi, i barrejar una alarma amb una subxarxa viola aquesta regla.

La infraestructura de MercadoFresco és per fi en fitxers. red-mercadofresco.yaml descriu la VPC, les sis subxarxes, el gateway d'internet, els NAT —dos en producció i un a la resta, amb la mateixa plantilla— i l'endpoint d'S3, amb historial a Git; aplicacion-mercadofresco.yaml munta a sobre l'ALB, el grup de destinació i el grup d'autoescalat sense conèixer ni un sol identificador, important les sortides de la primera. I tens l'anatomia d'una plantilla, amb paràmetres que validen abans de començar gràcies als tipus específics d'AWS, valors que arriben des de Parameter Store sense tocar la plantilla i secrets resolts amb {{resolve:secretsmanager:...}} en lloc del fals amic que és NoEcho. Tens les funcions intrínseques i la taula que evita l'error més freqüent: que !Ref retorna la URL d'una cua, l'ARN d'un tema i el nom d'un rol, i que gairebé sempre el que busques és !GetAtt Recurso.Arn. I tens el cicle de vida d'una pila, amb l'estat que desconcerta el primer dia: ROLLBACK_COMPLETE, que només es pot esborrar.

El que de veritat canvia la manera de treballar són tres mecanismes. Els conjunts de canvis, que contesten per escrit la pregunta que al mòdul 8 ningú no podia contestar —què passarà si aplico això?— i que mostren la columna Replacement que separa un canvi rutinari de la destrucció d'una subxarxa. Les polítiques d'eliminació i de reemplaçament més la protecció de terminació, l'única cosa que s'interposa entre una ordre i les dades d'Aurora. I la detecció de deriva, que converteix els canvis manuals d'invisibles en un informe setmanal. Amb la importació de recursos existents, MercadoFresco no recrea res: adopta el que ja funciona, capa a capa, començant per la xarxa, i executa la deriva just després —el pas que ningú no ha de saltar-se, perquè la importació comprova que els recursos existeixin, no que la plantilla els descrigui bé—. Les cinc piles per entorn queden repartides per cicle de vida i per propietat, amb exportacions per a l'estructural i SSM per al que pot canviar o creuar comptes, sabent que una exportació en ús és un forrellat. I la infraestructura passa pel pipeline de 08-04 amb el mateix rigor que el codi: cfn-lint i cfn-guard que fallen la construcció, un conjunt de canvis publicat, l'aprovació de la Marta i l'execució amb RoleArn, perquè qui dispara no necessiti els permisos que s'exerceixen.

Queda una limitació que es nota tan bon punt la plantilla creix. La xarxa descriu sis subxarxes gairebé idèntiques repetides a mà: no hi ha bucles, no hi ha funcions, no hi ha manera d'escriure "crea una subxarxa per cada AZ" ni d'encapsular "la xarxa estàndard de MercadoFresco" en alguna cosa reutilitzable. Les condicions serveixen per a dos casos i es tornen il·legibles a partir de cinc. I no hi ha manera d'escriure una prova que verifiqui que cap plantilla no obre el port 22 al món: cfn-guard ajuda, però és un altre llenguatge més per aprendre.

A 09-02, «AWS CDK», aquesta mateixa infraestructura s'escriu en TypeScript i en Python, amb bucles, condicionals, tipus, constructes reutilitzables i proves unitàries de veritat, i el resultat continua sent una plantilla de CloudFormation desplegada com una pila. Tot el d'aquesta lliçó continua sent cert per sota: el CDK no substitueix CloudFormation, l'escriu per tu.