Osservabilità come base delle decisioni

Non puoi migliorare ciò che non misuri: a livello professional l’osservabilità precede ogni refinement. Amazon CloudWatch fornisce metrics, alarms, dashboards e Logs; le custom metrics con dimensioni ben scelte (per-tenant, per-AZ, per-service) rendono diagnosticabili gli ambienti multi-account. Con CloudWatch Logs Insights interroghi i log applicativi, mentre Contributor Insights individua i top-N contributor di un problema (l’IP o la chiave che genera throttling). Per il distributed tracing usi AWS X-Ray: il service map mostra latenza e error rate per hop, indispensabile per capire quale downstream sta degradando una richiesta che attraversa API Gateway, Lambda e Aurora.

La regola d’esame: le metriche standard (es. CPUUtilization) hanno granularità e latenza limitate; per reagire in fretta servono detailed monitoring o custom metrics ad alta risoluzione. In contesti enterprise centralizzi con cross-account observability, così un monitoring account aggrega dashboard e trace di decine di workload account senza copiare i dati.

Refinement dell’Auto Scaling

Il target tracking è la scelta di default: definisci un target (es. utilizzo medio o richieste per target) e AWS regola la capacità per mantenerlo — semplice, reattivo, ma intrinsecamente reattivo, quindi in ritardo sui picchi improvvisi. Lo step scaling aggiunge capacità a scaglioni in base alla severità dell’allarme, utile per pattern noti e bruschi. Il predictive scaling analizza lo storico (pattern ciclici, giornalieri/settimanali) e pre-provisiona capacità prima del picco: la risposta corretta quando il carico è prevedibile ma la latenza di boot dell’istanza è alta e il target tracking arriva tardi. Le due strategie si combinano: predictive per la baseline anticipata, target tracking per correggere lo scostamento residuo.

Per performance affina anche i warm-up: il warm-up e i cooldown evitano scaling oscillante, mentre i warm pool riducono il tempo di avvio di istanze pesanti. Ricorda che lo scaling non è solo EC2: DynamoDB, Aurora (read replica auto scaling / Serverless v2) ed ECS/Fargate hanno i loro meccanismi, e la scelta dipende dal collo di bottiglia reale evidenziato dall’osservabilità.

Isolamento dei fault e blast radius

La resilienza professional è questione di contenimento. Nel serverless, la reserved concurrency per-funzione limita quante esecuzioni una singola Lambda può occupare: impedisce che una funzione impazzita consumi tutta la concurrency dell’account, isolando il fault e proteggendo le altre funzioni. Per non perdere messaggi, ogni consumer asincrono deve avere una dead-letter queue: gli eventi che falliscono ripetutamente finiscono in una DLQ (SQS o SNS) per analisi e replay, invece di andare persi o loopare all’infinito.

Il decoupling è la leva principale: inserire Amazon SQS o EventBridge tra producer e consumer assorbe i picchi (buffering), spezza la propagazione dei guasti e abilita retry con backoff. Un consumer lento non fa più fallire il producer. Riduci il blast radius anche isolando per cell/AZ, usando account separati per ambienti e workload, e progettando per il graceful degradation (rispondere con dati cached quando un downstream è giù).

Individuare i single point of failure

Un SPOF è qualsiasi componente non ridondato il cui guasto ferma il sistema: un NAT Gateway in una sola AZ, un database single-AZ, un’unica istanza dietro il load balancer. Correggerli significa progettare Multi-AZ (RDS/Aurora con standby e failover automatico), distribuire su più subnet/AZ, e per resilienza estrema valutare pattern multi-region (backup & restore, pilot light, warm standby, active/active) bilanciando RTO/RPO contro costo e complessità.

Trappole tipiche d’esame

  • Picco prevedibile ma boot lento delle istanze → predictive scaling: il target tracking reagisce solo dopo il superamento della soglia; per anticipare il carico ciclico serve il predictive, eventualmente combinato con target tracking.
  • Una Lambda difettosa esaurisce la concurrency dell’account → reserved concurrency per-funzione: isola il fault; non è compito di una DLQ, che serve a non perdere messaggi falliti.
  • Eventi asincroni persi dopo retry falliti → dead-letter queue: aggiungere una DLQ al consumer (SQS/SNS/Lambda) per capture e replay, non aumentare i retry all’infinito.
  • Producer che fallisce quando il consumer rallenta → decoupling con SQS/EventBridge: il buffering assorbe i picchi e spezza la propagazione del guasto; scalare il consumer da solo non basta.
  • Diagnosticare latenza in una catena di microservizi → AWS X-Ray: il service map isola l’hop lento; CloudWatch metrics da sole non mostrano la latenza per-segmento della singola richiesta.
  • NAT Gateway o database in una sola AZ → Multi-AZ: è un SPOF classico; distribuisci su più AZ, non affidarti a snapshot come unica difesa.