AWS CloudFormation: change set, drift e StackSets

CloudFormation gestisce l’infrastruttura come codice in modo dichiarativo: descrivi lo stato desiderato in un template e il servizio calcola le azioni. Il change set è lo strumento chiave in produzione: genera un’anteprima delle modifiche prima dell’apply, segnalando in particolare le risorse che subiranno un replacement (ricreazione con nuovo id) invece di un semplice update in place. Serve a non scoprire in corsa che una modifica apparentemente innocua ricrea un database.

La drift detection confronta lo stato reale delle risorse con il template: individua le modifiche fatte fuori banda (console, CLI manuale). Attenzione: rileva la deriva, non la corregge. Le StackSets distribuiscono lo stesso stack su più account e region con un’unica operazione, tipicamente integrate con AWS Organizations per il roll-out a livello di OU. Per logica non nativa (es. lookup o azioni custom in fase di deploy) si usano le custom resource basate su una funzione Lambda invocata da CloudFormation.

AWS Systems Manager: la cassetta degli attrezzi operativa

Systems Manager è il cuore delle operazioni su fleet EC2 e on-prem. Run Command esegue comandi su molte istanze senza SSH; richiede lo SSM Agent attivo e un IAM instance profile con la policy gestita adeguata (oltre alla connettività verso gli endpoint SSM). Se un’istanza non compare come managed node, la causa quasi sempre è profile mancante, agent non in esecuzione o endpoint di rete irraggiungibili.

State Manager applica e mantiene lo stato desiderato tramite associazioni ricorrenti (es. garantire che un agent resti installato). Patch Manager usa patch baseline e maintenance window per applicare le patch in finestre pianificate, senza interventi manuali. Parameter Store centralizza configurazioni e segreti (tipo SecureString cifrato con KMS, organizzati in gerarchie). Session Manager apre una shell interattiva senza porta 22 aperta e senza bastion host, con logging su Amazon CloudWatch o Amazon S3 e audit tramite CloudTrail: è l’opzione da preferire rispetto a SSH negli scenari di sicurezza.

Automation runbook, EventBridge e Lambda

Gli Automation runbook sono workflow multi-step per operazioni ripetibili e remediation: esistono runbook AWS-owned (per riavvii, snapshot, hardening) e runbook custom. Il pattern operativo tipico è Amazon EventBridge → SSM Automation runbook: una rule intercetta un evento (cambio di stato, finding di sicurezza) e lancia il runbook per la correzione automatica. Un runbook può a sua volta invocare una funzione Lambda per la logica che non è esprimibile nei passi nativi. La stessa Lambda ricorre anche come backend delle custom resource CloudFormation e per micro-automazioni serverless event-driven, mantenendo il controllo operativo senza gestire server.

AWS Elastic Beanstalk: strategie di deployment

Elastic Beanstalk è la PaaS che astrae provisioning e scaling. In esame contano le deployment policy: All at once (veloce ma con downtime), Rolling (a batch, capacità temporaneamente ridotta), Rolling with additional batch (mantiene la capacità piena), Immutable (crea un nuovo set di istanze in un Auto Scaling Group temporaneo e le promuove solo se sane, con rollback pulito e nessuna riduzione di capacità) e Blue/Green (ambiente parallelo con swap del CNAME). L’immutable è la scelta più sicura per rollback e integrità, al prezzo di tempi e costi maggiori durante il deploy.

Trappole tipiche d’esame

  • Anteprima di un update rischioso in produzione → change set: mostra quali risorse subiranno replacement prima dell’apply; l’update diretto le ricrea senza avviso.
  • Rilevare modifiche manuali su uno stack → drift detection: individua la deriva ma non la corregge; la remediation è ri-applicare il template.
  • Stesso stack su molti account/region → StackSets (non nested stack): i nested stack compongono uno stack singolo, le StackSets distribuiscono su più target via Organizations.
  • Accesso a istanza in subnet privata senza porta 22 né bastion → Session Manager: con audit CloudTrail e log centralizzati, non SSH con key pair.
  • Istanza assente tra i managed node in Run Command → IAM instance profile / SSM Agent: verifica prima ruolo, agent ed endpoint, non i comandi.
  • Deploy senza capacità ridotta e con rollback pulito → Immutable (o Rolling with additional batch): All at once comporta downtime, Rolling riduce temporaneamente la capacità.