Il Well-Architected Framework

Il Well-Architected Framework è l’insieme di best practice che AWS raccomanda per progettare e gestire workload sul cloud. Non è un servizio né un vincolo tecnico, ma una guida concettuale organizzata in sei pillars, ciascuno con domande di verifica e relativi design principle. AWS mette a disposizione anche il AWS Well-Architected Tool, gratuito nella console, che consente di eseguire una review del proprio workload e ricevere indicazioni di miglioramento. L’idea di fondo è valutare i trade-off in modo strutturato invece di improvvisare l’architettura, misurandola rispetto a criteri condivisi.

I sei pilastri

  • Operational Excellence: eseguire e monitorare i sistemi, automatizzare i cambiamenti e migliorare i processi nel tempo.
  • Security: proteggere dati, sistemi e asset applicando il principio del least privilege e la tracciabilità.
  • Reliability: garantire che un workload svolga la sua funzione e sappia recuperare da guasti (recovery), scalando in automatico.
  • Performance Efficiency: usare le risorse di calcolo in modo efficiente e adattarle all’evoluzione della domanda.
  • Cost Optimization: evitare spese non necessarie, pagando solo ciò che serve.
  • Sustainability: ridurre l’impatto ambientale dei workload ottimizzando l’uso delle risorse.

Nessun pilastro è “il più importante” in assoluto: la scelta dipende dal contesto e comporta trade-off (più reliability, per esempio, spesso significa più costo).

I design principle

I design principle traducono i pilastri in scelte pratiche. I più citati:

  • Design for failure: presumere che qualsiasi componente possa guastarsi e progettare di conseguenza. “Everything fails all the time”: si distribuiscono le risorse su più Availability Zone per eliminare i single point of failure.
  • Decoupling: disaccoppiare i componenti così che il guasto di uno non si propaghi all’intero sistema. Servizi come Amazon SQS (code) o Elastic Load Balancing riducono le dipendenze dirette.
  • Elasticity: aggiungere o rimuovere capacità automaticamente seguendo la domanda, invece di sovradimensionare. Amazon EC2 Auto Scaling ne è l’esempio tipico e sostiene sia performance sia cost optimization.

Altri principi ricorrenti: automatizzare, scalare in orizzontale (scale out) invece che in verticale (scale up), e provare periodicamente le procedure di recovery.

La global infrastructure AWS

L’infrastruttura globale è organizzata su tre livelli chiave:

  • Region: area geografica (es. Europe (Milan)) che contiene più data center. Ogni Region è isolata dalle altre per fault tolerance e data residency. La scelta della Region dipende da latenza verso gli utenti, compliance/sovranità dei dati, servizi disponibili e costo.
  • Availability Zone (AZ): uno o più data center distinti dentro una Region, con alimentazione e rete indipendenti ma collegati da link a bassa latenza. Distribuire un’applicazione su più AZ è la base della high availability: se una AZ fallisce, le altre continuano a servire il traffico.
  • Edge location: punti di presenza distribuiti globalmente, usati da Amazon CloudFront (CDN) e Amazon Route 53 (DNS) per servire contenuti e risolvere query vicino all’utente finale, riducendo la latenza. Sono molto più numerose delle Region.

Region e AZ sostengono reliability e high availability; le edge location riguardano soprattutto performance e latenza. Esistono inoltre AWS Local Zones e AWS Outposts per casi specifici di prossimità o on-premises.

Trappole tipiche d’esame

  • Alta disponibilità dentro una singola Region → distribuisci su più Availability Zone: più AZ, non più Region, è la risposta standard per high availability e failover automatico. Più Region serve per disaster recovery su larga scala o per compliance.
  • Ridurre la latenza per utenti globali su contenuti statici → edge location con CloudFront: le edge location servono la cache vicino all’utente; non aggiungere altre Region al solo scopo di velocizzare i download.
  • “Qual è il pilastro più importante?” → nessuno in assoluto: i sei pillars vanno bilanciati; diffida delle risposte che ne assolutizzano uno.
  • Scelta della Region → valuta compliance, latenza, servizi e costo, non solo la vicinanza: una Region può non offrire tutti i servizi o avere prezzi diversi.
  • Un singolo server EC2 “molto potente” per la reliability → sbagliato, è un single point of failure: design for failure impone ridondanza e scale out su più AZ, non scale up.
  • Sustainability vs Cost Optimization → sono pilastri distinti: ottimizzare i costi non equivale automaticamente a ridurre l’impatto ambientale, anche se spesso convergono.