Amazon EC2 Auto Scaling: scaling policy e criteri di scelta

Un Auto Scaling group (ASG) mantiene una capacità desiderata distribuendo le istanze su più Availability Zone e sostituendo automaticamente quelle non sane. La leva principale sono le scaling policy, e all’esame la difficoltà è scegliere quella giusta:

  • Target tracking: mantieni una metrica (es. ASGAverageCPUUtilization al 50%, o request-count-per-target di un Application Load Balancer) attorno a un valore obiettivo. È la scelta predefinita per carichi variabili e continui.
  • Step scaling: regolazioni di ampiezza diversa in base a quanto una CloudWatch alarm supera la soglia. Utile quando servono risposte graduate a picchi di intensità differente.
  • Simple scaling: singola regolazione con cooldown, ormai legacy.
  • Scheduled action: capacità pianificata per pattern noti nel tempo (es. apertura uffici lunedì mattina).
  • Predictive scaling: usa il machine learning per prevedere la domanda ciclica e provisionare capacità in anticipo (solo scale-out); si combina con una policy dinamica come rete di sicurezza.

L’instance warmup dice all’ASG quanto attendere prima che una nuova istanza contribuisca alle metriche aggregate, evitando scale-out a raffica durante il boot.

Lifecycle hook e warm pool

I lifecycle hook mettono in pausa un’istanza in uno stato di attesa per eseguire azioni personalizzate. In Pending:Wait esegui bootstrap, registrazione a un servizio o warm-up applicativo prima che l’istanza entri in servizio; in Terminating:Wait puoi drenare connessioni, estrarre log o deregistrare l’host prima della terminazione. L’azione si completa esplicitamente (o allo scadere dell’heartbeat, che applica il default ABANDON o CONTINUE). Sono il punto di aggancio tipico per automazioni con AWS Systems Manager, Amazon EventBridge o AWS Lambda.

La warm pool è la risposta agli scenari con tempi di avvio lunghi (immagini pesanti, download di dati, licensing): mantiene istanze pre-inizializzate in stato Stopped, Hibernated o Running, pronte a passare rapidamente in servizio durante uno scale-out. Riduce la latenza di risposta ai picchi senza pagare capacità piena a regime; rispetta comunque i lifecycle hook definiti.

Health check e recupero automatico

L’ASG determina la salute delle istanze secondo il health check type configurato. Con solo gli EC2 status check un’istanza viene sostituita se l’hardware o il sistema è compromesso, ma un’app in crash che risponde comunque al ping resta viva. Impostando il tipo ELB (o attivando gli health check del load balancer), l’istanza è considerata unhealthy se fallisce il controllo applicativo del target group, e l’ASG la rimpiazza. Il health check grace period concede tempo al boot prima della prima valutazione, evitando cicli di terminazione prematura. L’Instance Refresh consente rollout controllati (con percentuale di healthy minima) quando cambi launch template o AMI.

Route 53 ed Elastic Load Balancing per la resilienza

Elastic Load Balancing distribuisce il traffico tra istanze e AZ: Application Load Balancer (L7, routing per path/host), Network Load Balancer (L4, alte prestazioni e IP statici) e Gateway Load Balancer (appliance di sicurezza). Il deregistration delay (connection draining) svuota le connessioni prima di rimuovere un target.

Amazon Route 53 aggiunge resilienza a livello di DNS. Le routing policy rilevanti: failover (attivo/passivo con health check), latency (regione più vicina), weighted (canary/blue-green e ripartizione), multivalue answer (più record sani). Gli health check di Route 53 monitorano endpoint o allarmi CloudWatch e abilitano il DNS failover automatico verso una Region secondaria. Da qui la scelta della strategia di disaster recovery in base a RTO/RPO: pilot light (nucleo minimo sempre acceso, resto avviato all’occorrenza) contro warm standby (ambiente ridotto ma già operativo, più costoso ma con failover più rapido).

Trappole tipiche d’esame

  • Istanze in crash ma non sostituite → health check type ELB: con solo EC2 status check l’ASG ignora i guasti applicativi; serve il controllo del load balancer per farle rimpiazzare.
  • Cold start lento sotto picco → warm pool, non solo target tracking: aumentare la scaling policy non elimina il tempo di boot; le istanze pre-inizializzate sì.
  • Drenare connessioni o salvare log prima dello shutdown → lifecycle hook Terminating:Wait: non lo fa lo scaling policy né il deregistration delay da solo.
  • Failover cross-Region automatico → Route 53 failover routing + health check: l’ELB bilancia dentro una Region, non tra Region.
  • NLB con traffico sbilanciato tra AZ → cross-zone load balancing: è attivo di default sull’ALB ma disattivato (e a pagamento) sull’NLB.
  • Terminazioni premature dopo lo scale-out → health check grace period adeguato: senza grace period l’ASG valuta l’istanza prima che l’app sia pronta.