Distribuire il carico su più Availability Zone

Il fondamento dell’alta disponibilità su AWS è progettare per il guasto di una singola Availability Zone (AZ). Un workload resiliente distribuisce le sue risorse su almeno due AZ della stessa Region, così che la perdita di un’intera AZ degradi la capacità ma non provochi un outage.

Elastic Load Balancing (ELB) è il punto d’ingresso di questo pattern: distribuisce il traffico su target registrati in più AZ. Application Load Balancer opera a layer 7 (routing HTTP/HTTPS per path e host), Network Load Balancer a layer 4 (TCP/UDP, latenza minima, IP statici). Ogni load balancer esegue health check periodici verso i target e instrada solo verso quelli sani. Due meccanismi da conoscere: il cross-zone load balancing, che consente a un nodo del load balancer di inviare traffico a target in altre AZ, e il connection draining (in ELB moderno chiamato deregistration delay): quando un target viene deregistrato o diventa unhealthy, le connessioni in corso vengono completate entro il timeout configurato invece di essere troncate bruscamente.

EC2 Auto Scaling: capacità elastica e self-healing

Un Auto Scaling group (ASG) mantiene la desired capacity di istanze EC2 distribuendole in modo bilanciato tra le AZ configurate. Se un’istanza viene terminata o un’intera AZ diventa indisponibile, l’ASG lancia automaticamente sostituzioni in una AZ sana per riportarsi al valore desiderato: questo è il comportamento di self-healing.

Il criterio da padroneggiare è l’health check type. Con tipo EC2 l’ASG considera unhealthy solo istanze che falliscono gli status check di sistema o istanza (hardware, OS). Con tipo ELB l’ASG usa anche l’esito dell’health check del load balancer: così un’istanza in cui l’applicazione è bloccata (processo web morto) ma il sistema operativo risponde viene comunque terminata e ricreata. Per il resto, le scaling policy (target tracking, step, scheduled) governano quando aggiungere o rimuovere capacità in base a metriche Amazon CloudWatch.

RDS Multi-AZ e read replica

Sono due funzionalità distinte, spesso confuse all’esame.

Amazon RDS Multi-AZ serve alla disponibilità: mantiene uno standby sincrono in un’altra AZ. In caso di guasto dell’istanza primaria (o della sua AZ), RDS esegue un failover automatico aggiornando il record DNS dell’endpoint verso lo standby, tipicamente in uno-due minuti. L’applicazione continua a usare lo stesso endpoint: non serve cambiare connection string. Lo standby classico non serve traffico in lettura.

Le read replica servono invece allo scaling in lettura: sono repliche asincrone con endpoint proprio, verso cui indirizzare query di sola lettura per alleggerire la primaria. Possono essere cross-Region, utile come componente di una strategia di disaster recovery, ed essere promosse a database autonomo.

Route 53 failover e disaster recovery

Amazon Route 53 estende la resilienza a livello DNS. La failover routing policy associa un record primario e uno secondario a health check: quando l’endpoint primario risulta unhealthy, Route 53 smette di risolverlo e instrada verso il secondario, permettendo failover tra AZ, Region o verso un sito statico di cortesia.

Le strategie di disaster recovery si scelgono in base a RTO e RPO desiderati, con costo crescente: backup & restore (RTO/RPO alti, economico), pilot light (nucleo minimo sempre attivo), warm standby (ambiente ridotto ma funzionante), multi-site active/active (RTO/RPO quasi nulli, costo massimo).

Trappole tipiche d’esame

  • Serve scalare le letture, non la disponibilità → read replica, non Multi-AZ: lo standby Multi-AZ non serve traffico; per distribuire query di lettura si usano read replica con endpoint dedicato.
  • L’applicazione si blocca ma l’istanza risponde → health check type ELB: con tipo EC2 l’ASG non se ne accorge; solo l’health check del load balancer rileva l’app morta e forza la sostituzione.
  • Connessioni troncate durante deploy o scale-in → deregistration delay (connection draining): consente di completare le richieste in volo prima di rimuovere il target.
  • Failover automatico del database senza cambiare connection string → RDS Multi-AZ: il failover avviene via aggiornamento DNS dell’endpoint, trasparente all’applicazione.
  • Route 53 non commuta sul sito secondario → manca l’health check: la failover routing policy richiede health check associati per rilevare l’endpoint primario down.
  • ASG in una sola AZ non è ad alta disponibilità → configurare più AZ: un gruppo confinato in un’unica AZ non sopravvive al guasto di quella AZ, per quanto grande sia la desired capacity.