AWS CodeDeploy: in-place vs blue/green

AWS CodeDeploy orchestra il rilascio verso tre piattaforme di compute (EC2/on-premises, AWS Lambda, Amazon ECS) e la scelta della strategia è il cuore delle domande DOP-C02. Con il modello in-place (solo EC2/on-premises) l’applicazione viene fermata sulle istanze esistenti, la nuova revision installata e riavviata: nessun costo di capacità aggiuntiva, ma finestra di indisponibilità sull’istanza mentre gira l’aggiornamento. Mitighi il downtime dietro un load balancer scegliendo una deployment configuration come OneAtATime o HalfAtATime, che riduce la percentuale di flotta offline contemporaneamente.

Con blue/green provisioni un ambiente “green” parallelo, sposti il traffico e mantieni il “blue” pronto per un rollback immediato. Il vantaggio è che il rollback significa solo ridirigere il traffico al vecchio ambiente, non reinstallare. Il costo è la capacità doppia durante la transizione. Su EC2 blue/green richiede un load balancer e (tipicamente) un Auto Scaling group; su Lambda ed ECS il blue/green è di fatto l’unica modalità gestita da CodeDeploy.

Traffic shifting su Lambda ed ECS

Per Lambda, CodeDeploy non reinstalla nulla: pubblichi una nuova version e sposti il traffico dell’alias dalla versione corrente a quella nuova con weighted routing. Le deployment configuration predefinite seguono tre pattern: AllAtOnce (100% subito), Canary (una quota fissa, es. 10%, poi il resto dopo N minuti in un unico salto) e Linear (incrementi uguali a intervalli regolari fino al 100%). Canary è ideale per esporre un piccolo campione e osservare le metriche prima del commit totale; Linear distribuisce il rischio nel tempo.

Per ECS, CodeDeploy usa blue/green con due target group dietro un listener dell’Application/Network Load Balancer: crea un nuovo task set (green), puoi validarlo su un test listener separato, poi sposta il production listener con gli stessi profili Canary/Linear/AllAtOnce. Ricorda: il rolling update nativo di ECS (deployment controller ECS) è un’altra cosa: il traffic shifting canary/linear con validazione arriva solo con il controller CodeDeploy.

AWS Elastic Beanstalk

Beanstalk offre deployment policy di crescente sicurezza: All at once (veloce ma con downtime), Rolling (a batch, capacità ridotta durante il rilascio), Rolling with additional batch (mantiene la capacità piena aggiungendo istanze temporanee), Immutable (crea istanze nuove in un ASG temporaneo e le promuove solo se sane: rollback pulito, nessuna mutazione delle istanze esistenti) e Traffic splitting (canary: instrada una percentuale del traffico client verso le nuove istanze). Il blue/green su Beanstalk si realizza con due environment e lo swap dei CNAME URL: è la scelta quando vuoi zero-downtime e rollback istantaneo su cambi non retrocompatibili.

Rollback automatico e validazione

Il rollback automatico in CodeDeploy scatta su due condizioni: fallimento del deployment o superamento di una soglia di un Amazon CloudWatch alarm associato. Il rollback non “annulla”: ridistribuisce l’ultima revision nota funzionante come nuovo deployment. La validazione post-deploy si aggancia agli hook del lifecycle: su Lambda ed ECS gli hook BeforeAllowTraffic e AfterAllowTraffic invocano funzioni Lambda di test (smoke test, health check) e, se falliscono, il traffic shifting si interrompe e si torna indietro prima di esporre gli utenti. Su EC2 gli hook vivono nell’appspec.yml (es. ValidateService). Integra le metriche in AWS CodePipeline e allinea gli alarm alla finestra canary per intercettare regressioni durante lo shift graduale.

Trappole tipiche d’esame

  • Zero downtime + rollback istantaneo su cambi non retrocompatibili → blue/green (o swap URL Beanstalk): rolling e in-place riusano istanze, quindi il rollback è più lento e rischioso.
  • Esporre l’1-10% degli utenti prima del rilascio totale → Canary con hook di validazione: Linear distribuisce nel tempo ma espone subito una quota crescente, non un campione controllato.
  • Traffic shifting graduale con validazione su ECS → controller CodeDeploy, non deployment controller ECS: il rolling update nativo ECS non fa canary/linear né rollback su alarm.
  • Deploy Lambda senza reinstallare codice → shifting su alias tra due version: la domanda che parla di “in-place” per Lambda è un distrattore, non esiste.
  • Rollback automatico al degrado delle metriche → CloudWatch alarm collegato al deployment group: senza alarm il rollback scatta solo sul fallimento tecnico, non sulla regressione applicativa.
  • Beanstalk con capacità piena e rollback pulito → Immutable (o Rolling with additional batch): “All at once” è la trappola veloce ma con downtime e senza rete di sicurezza.