CloudFormation: stack e change set

AWS CloudFormation è il servizio nativo di IaC: descrivi le risorse in un template dichiarativo (JSON o YAML) e CloudFormation le provisiona come uno stack, gestendone il ciclo di vita in modo atomico con rollback automatico in caso di errore. Prima di applicare una modifica genera un change set, un’anteprima di quali risorse verranno create, modificate o sostituite (replacement). Il replacement è il dettaglio critico: cambiare una proprietà immutabile ricrea la risorsa, con possibile perdita di dati o downtime — il change set te lo mostra prima di eseguire. Per proteggere le risorse stateful usa DeletionPolicy e UpdateReplacePolicy (Retain, Snapshot); le stack policy bloccano update accidentali durante un aggiornamento.

Drift detection

Change set e stack policy governano le modifiche fatte via CloudFormation. Il problema opposto sono le modifiche out-of-band: qualcuno cambia un security group dalla console e lo stack non lo sa. La drift detection confronta lo stato reale con il template e segnala le risorse DRIFTED: è la risposta quando la domanda parla di “configurazione modificata manualmente” o di conformità dell’infrastruttura. Attenzione, non è continua — va lanciata o schedulata (es. EventBridge + Lambda) — e non tutti i resource type la supportano. Anche gli StackSets la supportano sulle loro istanze.

StackSets: multi-account e multi-region

Uno stack vive in un solo account e una sola region. Per distribuire lo stesso template su decine di account e più region — baseline di sicurezza, ruoli IAM, logging — la risposta è StackSets, non lanciare N stack a mano. Due modelli di permessi: self-managed, dove crei tu i ruoli IAM (administration ed execution) in ogni target account; service-managed, integrato con AWS Organizations, che distribuisce a OU intere e, con automatic deployment, applica lo stack automaticamente ai nuovi account che entrano nell’OU (rimuovendolo da quelli che escono). Questo onboarding automatico è la discriminante tipica delle domande di governance multi-account.

Riuso dei template: nested stack e custom resource

Per non duplicare codice, i nested stack scompongono l’architettura in template figli riusabili richiamati da un parent (AWS::CloudFormation::Stack). In alternativa i cross-stack reference (Outputs con Export + Fn::ImportValue) condividono valori fra stack indipendenti, ma uno stack che esporta un valore non può essere eliminato finché l’import esiste: per componenti fortemente accoppiati preferisci i nested stack. Le custom resource (backed da Lambda o SNS) estendono CloudFormation a risorse non supportate nativamente o a logica esterna. Parameters, Mappings e Conditions permettono di riusare lo stesso template su ambienti diversi.

CDK e SAM: quando preferirli

CloudFormation puro è verboso. AWS CDK definisce l’infrastruttura in un linguaggio reale (TypeScript, Python, Java) con loop, condizioni e astrazioni, poi sintetizza un template CloudFormation standard: scelta giusta con team di sviluppatori e bisogno di logica e riuso programmatico. AWS SAM è specializzato sul serverless: sintassi compatta (transform AWS::Serverless-2016-10-09) per Lambda, API Gateway e DynamoDB, più sam local per il test in locale; sotto il cofano fa deploy via CloudFormation. App serverless con poco boilerplate → SAM; IaC generalista con un linguaggio di programmazione → CDK; entrambi restano CloudFormation a valle.

Trappole tipiche d’esame

  • Modifica manuale in console da rilevare → drift detection: il change set mostra solo l’impatto di una modifica al template, non le modifiche out-of-band fatte dalla console o via CLI.
  • Stesso template su una OU con onboarding automatico → StackSets service-managed: i nuovi account nell’OU ricevono lo stack senza intervento; il self-managed richiede ruoli IAM manuali e non ha questa integrazione con AWS Organizations.
  • Evitare ricreazione o perdita dati durante un update → leggi il change set + DeletionPolicy: una proprietà immutabile causa replacement; proteggi lo stato con Retain/Snapshot, non con la stack policy (che blocca gli update ma non preserva i dati).
  • App serverless con meno codice → AWS SAM: sintassi più asciutta per Lambda/API Gateway/DynamoDB rispetto a CloudFormation puro o CDK.
  • Componenti fortemente accoppiati da riusare → nested stack, non cross-stack export: un Export usato da Fn::ImportValue impedisce di eliminare o modificare lo stack che esporta.
  • Infrastruttura con logica in un linguaggio di programmazione → AWS CDK: sintetizza comunque CloudFormation, quindi change set e drift detection restano validi a valle.