AWS SAM: template serverless e deployment graduale

AWS SAM è un’estensione di AWS CloudFormation dedicata alle applicazioni serverless. Un template SAM dichiara Transform: AWS::Serverless-2016-10-09 e, al momento del deploy, viene espanso in un template CloudFormation completo: SAM è quindi uno “shorthand” sopra CloudFormation, non un motore separato. Risorse come AWS::Serverless::Function, AWS::Serverless::Api e AWS::Serverless::SimpleTable riducono il boilerplate rispetto alle risorse native equivalenti (AWS Lambda, Amazon API Gateway, Amazon DynamoDB).

Il flusso tipico è sam build (impacchetta codice e dipendenze) seguito da sam deploy, che carica gli artefatti su Amazon S3 e crea o aggiorna lo stack. Per il rilascio graduale di AWS Lambda si usa DeploymentPreference, che si appoggia ad AWS CodeDeploy per spostare il traffico fra le versioni dell’alias. Le strategie da distinguere:

  • Canary (es. Canary10Percent5Minutes): sposta subito una piccola quota di traffico, poi tutto il resto dopo il bake time.
  • Linear (es. Linear10PercentEvery1Minute): incrementi uguali a intervalli regolari.
  • AllAtOnce: switch immediato.

Si possono agganciare CloudWatch Alarms per il rollback automatico e Hooks PreTraffic/PostTraffic (funzioni Lambda di validazione).

AWS CloudFormation: parametri e change set

I Parameters rendono un template riutilizzabile. Con AllowedValues si vincola l’input a un elenco chiuso (es. solo dev/staging/prod), con AllowedPattern a una regex e con NoEcho: true si maschera un valore sensibile nell’output. Per non incollare segreti nel template esistono le dynamic reference verso Parameter Store e Secrets Manager ({{resolve:ssm:...}}, {{resolve:secretsmanager:...}}).

Il change set è lo strumento chiave per aggiornamenti sicuri: genera un’anteprima delle modifiche prima di applicarle, indicando quali risorse verranno aggiunte, modificate o rimosse e, soprattutto, quali richiedono Replacement (ricreazione con perdita dell’ID e potenzialmente dei dati). È il modo corretto per capire in anticipo se un update è “no interruption” o distruttivo, prima di eseguirlo.

Elastic Beanstalk: deployment policy e .ebextensions

Elastic Beanstalk astrae provisioning e capacity. Le deployment policy da confrontare:

  • All at once: veloce ma con downtime.
  • Rolling: aggiorna a batch, riducendo temporaneamente la capacità.
  • Rolling with additional batch: mantiene la capacità piena avviando un batch extra.
  • Immutable: crea istanze nuove in un Auto Scaling group parallelo; è la più sicura, con rollback semplice e nessuna riduzione di capacità.
  • Blue/Green: ambiente separato con swap del CNAME, ideale per zero downtime e rollback immediato.

I file .ebextensions/*.config (YAML/JSON) personalizzano l’ambiente: option_settings, packages, files, commands e container_commands. Le environment variables si impostano nel namespace aws:elasticbeanstalk:application:environment.

Configurazione: Parameter Store e variabili d’ambiente

SSM Parameter Store centralizza la configurazione: tipi String, StringList e SecureString (cifrato con AWS KMS), path gerarchici e versioning. Rispetto a Secrets Manager è più economico ma non offre la rotazione automatica gestita: se lo scenario richiede rotazione nativa di credenziali, la risposta è Secrets Manager. Le environment variables di Lambda sono comode per config non sensibili (cifrate a riposo con KMS), ma hanno un limite di dimensione complessiva e finiscono nel template: per valori sensibili o condivisi fra servizi si preferisce Parameter Store o Secrets Manager.

Trappole tipiche d’esame

  • Anteprima delle modifiche prima di applicarle → change set: un normale update-stack applica subito; solo il change set mostra cosa cambia e quali risorse richiedono Replacement.
  • Zero downtime e capacità sempre piena su Beanstalk → Immutable (o Blue/Green): “Rolling” riduce la capacità durante il deploy; se serve rollback rapido senza degrado, la risposta è Immutable o lo swap Blue/Green.
  • Rilascio Lambda con esposizione controllata → DeploymentPreference (SAM + CodeDeploy): Canary/Linear spostano il traffico gradualmente; distinguere canary (una quota, poi il resto) da linear (incrementi costanti).
  • Segreti fuori dal template → dynamic reference o SecureString: non usare NoEcho come cifratura (maschera solo l’output); i valori vanno in Parameter Store/Secrets Manager e risolti a runtime.
  • Rotazione automatica delle credenziali → Secrets Manager, non Parameter Store: SecureString cifra ma non ruota da solo.
  • Vincolare l’input a valori ammessi → AllowedValues: non affidarsi a Default, che imposta solo un valore iniziale senza impedire input arbitrari.