AWS Well-Architected Framework: come eseguire autovalutazioni

Ogni infrastruttura cloud di successo parte da fondamenta solide. Ho visto organizzazioni lottare con architetture cloud che all’inizio sembravano funzionare, ma crollavano sotto pressione, facendo perdere tempo, denaro e fiducia. L’AWS Well-Architected Framework esiste proprio per prevenire questi problemi alla radice.

In questo tutorial, ti guiderò attraverso l’AWS Well-Architected Framework, i suoi sei pilastri fondamentali e strategie pratiche di implementazione che puoi applicare quando progetti la tua prima soluzione cloud o ottimizzi un’infrastruttura esistente. Capire questo framework ti aiuterà a costruire sistemi sicuri, affidabili, efficienti e convenienti.

Se sei alle prime armi con AWS, ti consiglio di iniziare con il nostro corso Introduzione ad AWS. 

Che cos’è l’AWS Well-Architected Framework?

Partiamo capendo cos’è realmente questo framework e perché è importante.

L’AWS Well-Architected Framework è un insieme completo di best practice, principi di progettazione e linee guida architetturali sviluppati dagli AWS Solutions Architect sulla base di anni di esperienza con migliaia di clienti. Documenta una serie di domande fondamentali che ti aiutano a capire se una specifica architettura è allineata alle best practice del cloud.

Pensalo come un metro di misura per la tua architettura cloud. Non è davvero un meccanismo di audit, ma offre una conversazione costruttiva sulle decisioni architetturali. Descrive le best practice AWS e le strategie da usare quando progetti e operi un workload cloud, aiutandoti a capire i compromessi che stai facendo e le loro potenziali conseguenze.

Il framework era originariamente costruito su cinque pilastri. AWS ha aggiunto la sostenibilità come sesto pilastro alla fine del 2021 per riflettere l’importanza crescente della responsabilità ambientale nel cloud computing. Esploreremo ogni pilastro più avanti.

L’AWS Well-Architected Tool è disponibile gratuitamente nella AWS Management Console, così puoi valutare regolarmente i workload, identificare problemi ad alto rischio e registrare i miglioramenti. Questo significa che non ti limiti a leggere le best practice: misuri attivamente la tua architettura rispetto ad esse.

I sei pilastri dell’AWS Well-Architected Framework

Ora che abbiamo coperto le basi, esploriamo i sei pilastri che costituiscono il cuore del framework. Lavorano insieme per creare architetture cloud robuste ed efficienti. Ogni pilastro affronta aspetti diversi della creazione e manutenzione dei sistemi cloud. Ecco una panoramica rapida:

Operational excellence

Iniziamo con l’operational excellence, che si concentra sull’esecuzione e il monitoraggio dei sistemi per generare valore per il business. Questo pilastro riguarda il modo in cui operi i tuoi sistemi ogni giorno, ed è la base su cui si costruisce tutto il resto.

I principi di progettazione che guidano l’operational excellence sono:

• Eseguire le operazioni come codice
• Apportare cambiamenti piccoli e frequenti
• Anticipare i guasti
• Imparare dai fallimenti operativi

Ho notato che le organizzazioni eccellenti nell’operational excellence rispondono più rapidamente agli incidenti e distribuiscono le modifiche con maggiore sicurezza. Quando tratti le operazioni come codice, ottieni ripetibilità e coerenza, due ingredienti fondamentali per scalare la tua infrastruttura cloud.

Alcune best practice da tenere a mente:

• Stabilire priorità operative chiare
• Implementare un monitoraggio completo con Amazon CloudWatch
• Usare runbook e playbook per operazioni standardizzate
• Condurre retrospettive regolari per migliorare continuamente le procedure

Security

Con l’operational excellence come base per il funzionamento dei sistemi, la sicurezza è lo strato protettivo che garantisce che tali sistemi rimangano affidabili. È ovvio che sistemi sicuri sono imprescindibili per qualsiasi organizzazione.

Si concentra sulla protezione delle informazioni e dei sistemi attraverso valutazioni del rischio e strategie di mitigazione. Per costruire una solida postura di sicurezza nel cloud, dovresti seguire questi sette principi di progettazione:

• Implementare solide fondamenta di identità
• Abilitare la tracciabilità
• Applicare la sicurezza a tutti i livelli
• Automatizzare le best practice di sicurezza
• Proteggere i dati in transito e a riposo
• Tenere le persone lontane dai dati
• Prepararsi agli eventi di sicurezza

La forza della sicurezza nel cloud sta nella possibilità di implementarla automaticamente a ogni livello. A differenza dell’infrastruttura tradizionale, dove la sicurezza può essere un ripensamento, l’approccio Well-Architected integra la sicurezza nel tessuto della tua architettura fin dall’inizio.

Reliability

Costruendo sulle fondamenta operative e di sicurezza che abbiamo stabilito, l’affidabilità garantisce che i workload svolgano correttamente e costantemente le loro funzioni, riprendendosi rapidamente dai guasti per soddisfare la domanda. 

Puoi avere operazioni eccellenti e sicurezza rigorosa, ma se il tuo sistema non è affidabile, non stai generando valore. Quando progetti per l’affidabilità nel cloud, questi principi di progettazione dovrebbero guidare il tuo approccio:

• Ripristino automatico dai guasti
• Test delle procedure di ripristino
• Scalabilità orizzontale
• Gestione dei cambiamenti tramite automazione

Il bello dell’affidabilità basata sul cloud è la possibilità di progettare considerando il guasto invece di provare a prevenirlo del tutto. Assumendo che i guasti avverranno e costruendo sistemi che si ripristinano automaticamente, crei architetture più resilienti rispetto agli approcci tradizionali.

Performance efficiency

Una volta che hai sistemi affidabili, la performance efficiency si concentra sull’uso efficiente delle risorse di calcolo per soddisfare i requisiti del sistema e mantenere tale efficienza al variare della domanda. Questo pilastro riguarda l’erogazione del giusto livello di prestazioni senza sovra-provisionare o sotto-utilizzare le risorse.

I principi di progettazione chiave per ottenere performance efficiency sono:

• Democratizzare le tecnologie avanzate
• Espandersi a livello globale rapidamente
• Usare architetture serverless
• Sperimentare più spesso

La performance efficiency è direttamente collegata al pilastro successivo, perché le risorse che scegli e come le usi hanno implicazioni dirette sui costi. È qui che le decisioni architetturali iniziano a riflettersi in fattura.

Cost optimization

Ora che abbiamo affrontato le prestazioni, vediamo come raggiungerle in modo conveniente. L’ottimizzazione dei costi consiste nel far funzionare i sistemi per generare valore per il business al costo più basso possibile, soddisfacendo al contempo i requisiti funzionali. Nota che questo pilastro non dice “più economico”, ma “ottimizzato”. C’è una differenza fondamentale.

Alcune best practice includono: 

• Monitorare i costi con AWS Cost Explorer e i Cost and Usage Reports
• Dimensionare correttamente le risorse usando AWS Compute Optimizer
• Implementare l’auto scaling per allineare la capacità alla domanda
• Usare gli AWS Savings Plans per workload prevedibili

Per esperienza, l’ottimizzazione dei costi è dove i compromessi tra i pilastri diventano più evidenti. Potresti spendere di più per funzionalità di affidabilità come le distribuzioni multi-regione, ma quell’investimento protegge i ricavi. 

Potresti scegliere istanze con prestazioni più elevate che costano di più ma elaborano i workload più velocemente, riducendo alla fine il costo totale. La chiave è prendere decisioni informate su questi compromessi.

Sustainability

Infine, arriviamo alla sostenibilità, il pilastro più recente. Il pilastro della sostenibilità si concentra sulla minimizzazione degli impatti ambientali dell’esecuzione dei workload nel cloud, in particolare consumo energetico ed efficienza

Ci sono alcune strategie che puoi seguire per rendere il tuo sistema più sostenibile, come:

• Scegliere le regioni AWS in base all’uso di energia rinnovabile
• Implementare strategie di caching efficienti
• Usare linguaggi di programmazione efficienti
• Gestire il ciclo di vita dei dati con Amazon S3 Intelligent-Tiering
• Usare tipi di istanze a basso consumo come i processori AWS Graviton

Anche se Amazon l’ha reso un pilastro a sé stante, spesso è in linea con gli altri pilastri e li richiama. Un codice più efficiente riduce sia l’impatto ambientale sia i costi. Un migliore utilizzo tramite il right-sizing aiuta sostenibilità e ottimizzazione dei costi. I servizi gestiti spesso funzionano in modo più efficiente rispetto all’infrastruttura autogestita.

Implementazione pratica del framework

Con una solida comprensione dei sei pilastri, passiamo a come implementare concretamente questo framework nella tua organizzazione. Capire la teoria è una cosa; applicarla è ciò che genera il vero valore.

Prepararsi all’implementazione

Prima di iniziare una revisione Well-Architected, una buona preparazione ti mette sulla strada giusta. Pensala come la posa delle fondamenta. Più chiara è la preparazione, più preziosa sarà la revisione:

• Definisci i concetti di base: Inizia comprendendo i termini chiave che guideranno la revisione. Un componente soddisfa un requisito, un workload è un insieme di componenti che generano valore per il business e il tuo portafoglio tecnologico include tutti i tuoi workload. Avere questo vocabolario condiviso assicura che tutti parlino la stessa lingua durante la revisione.
• Definisci gli obiettivi: Allinea gli obiettivi della revisione alle reali esigenze di business. Ti stai preparando a un grande lancio? Vuoi ridurre i costi? Migliorare la postura di sicurezza? Stabilisci KPI misurabili, come percentuali di uptime target o obiettivi di riduzione dei costi. Obiettivi chiari mantengono la revisione focalizzata su ciò che conta davvero.
• Costruisci un team di progetto: Metti insieme le persone giuste, ad esempio architetti, sviluppatori, membri del team operations e stakeholder di business. Prospettive diverse aiutano a non tralasciare punti di vista importanti. Prima della sessione di revisione, raccogli diagrammi architetturali e documentazione così i partecipanti possono prepararsi.

Con il team riunito e gli obiettivi chiari, sei pronto a condurre la revisione vera e propria.

Condurre una Well-Architected Review

Il processo di revisione è il momento in cui valuti la tua architettura rispetto alle best practice AWS.

Inizia definendo chiaramente l’ambito del tuo workload. Seleziona quali pilastri dare priorità in base ai tuoi obiettivi. Struttura la revisione come una discussione collaborativa, non un’interrogazione. Rispondi onestamente alle domande di revisione per ciascun pilastro, prendendo nota del perché certe pratiche sono o non sono in atto.

Dopo la revisione, avrai identificato rischi categorizzati come alti, medi o bassi. Osserva le revisioni in modo olistico per individuare temi ricorrenti che potrebbero essere affrontati tramite formazione o meccanismi standardizzati.

Usare l’AWS Well-Architected Tool

L’AWS Well-Architected Tool è un servizio gratuito che fornisce un processo coerente per misurare la tua architettura usando le best practice AWS.

Per iniziare

Vai allo strumento nella tua AWS Management Console. Crea un nuovo workload con le informazioni di base. Seleziona le lenti da applicare (al minimo, la lente dell’AWS Well-Architected Framework), più lenti specializzate se applicabili.

Per creare un nuovo workload, apri l’AWS Well-Architected Tool nella AWS Management Console e fai clic su Define workload. La configurazione si articola in tre passaggi:

1. Specifica le proprietà: Dai un nome al workload, una descrizione, un responsabile della revisione e l’ambiente (Production o Pre-production). Puoi anche aggiungere regioni AWS, ID account e dettagli facoltativi come il tipo di settore o un link al design architetturale.
2. Applica un profilo: Allega facoltativamente un profilo per precompilare le risposte di best practice per il tuo caso d’uso.
3. Applica le lenti: Seleziona le lenti per la tua revisione. La lente dell’AWS Well-Architected Framework è la base e dovrebbe essere sempre inclusa. Lenti ufficiali aggiuntive coprono scenari specifici:

• DevOps Lens: per integrare le pratiche DevOps
• Serverless Lens: per architetture serverless
• Mergers & Acquisitions Lens: per scenari di crescita guidati da M&A

4. Puoi anche applicare lenti personalizzate condivise da altri account AWS.

Una volta terminato, fai clic su Define workload per completare la configurazione.

Condurre la valutazione

Il workload contiene una serie di domande per ciascun pilastro. Procedi con le domande per ogni pilastro per condurre la valutazione. Lo strumento fornisce contesto, spiegazioni delle best practice e risorse come documentazione e video.

Per ciascun pilastro troverai un insieme di domande a cui rispondere in base al tuo workload specifico. Ad esempio, il pilastro Operational Excellence contiene 11 domande, e avrai a disposizione risorse che ti guidano nel processo di valutazione. 

Ogni risposta confluisce direttamente in una valutazione del rischio automatica, visibile sia a livello di singola domanda sia riepilogata nella panoramica del pilastro. Una volta completati tutti i pilastri, lo strumento aggrega questi risultati in un report completo.

Rivedere i risultati e agire

Il report generato categorizza i risultati in quattro livelli di rischio:

• Alto rischio: best practice critiche mancanti o non seguite
• Rischio medio: alcune best practice sono coperte solo parzialmente
• Nessun miglioramento identificato: tutte le best practice rilevanti sono coperte
• Non applicabile: best practice fuori ambito per questo workload

Usa questi risultati per creare un piano di miglioramento, dando priorità ai problemi in base all’impatto sul business. Lo strumento ti consente di tracciare i progressi creando milestone. 

Si integra anche con AWS Trusted Advisor e AWS Service Catalog AppRegistry per semplificare la scoperta delle informazioni, e con i Cloud Intelligence Dashboards per visualizzare metriche appresso i workload.

Applicare i principi Well-Architected in scenari reali

Dopo teoria e passaggi di implementazione, vediamo come le organizzazioni applicano questi principi nella pratica. Gli esempi reali danno vita al framework e mostrano come si presenta il successo.

Casi di studio ed esempi

Tricentis Flood ha affrontato una Well-Architected Review condotta dal partner AWS Cprime in vista di un audit di conformità SOC 2. La revisione ha identificato miglioramenti in sicurezza, affidabilità e operation, su cui Tricentis è intervenuta immediatamente. 

Hanno aggiunto rilevamento delle intrusioni, logging di rete dettagliato e distribuito calcolo e storage su più zone e regioni di disponibilità AWS per garantire la disponibilità anche se un data center va offline. La revisione ha fornito un elenco di remediation chiaro e prioritizzato proprio quando serviva.

QSRSoft, un’azienda di tecnologia per la ristorazione, non completava una revisione Well-Architected da oltre cinque anni. Il loro processo precedente richiedeva un team di sei persone e 60 ore per rivedere un singolo workload, quindi le revisioni venivano continuamente rimandate. 

Collaborando con Rego (un partner AWS) usando strumenti assistiti dall’AI, la stessa revisione è stata completata in soli 72 minuti, portando alla luce vulnerabilità di sicurezza ad alto rischio e blocchi di scalabilità, e risultando nel deployment di AWS Security Hub per un monitoraggio automatico continuo.

Entrambi i casi illustrano lo stesso punto: il Well-Architected Tool mette in evidenza rischi reali, e prima lo esegui, meno costa risolverli.

Sfide comuni e soluzioni

Anche con benefici chiari, implementare il framework non è privo di ostacoli. Ecco le sfide più comuni che le organizzazioni affrontano e soluzioni pratiche per superarle:

Resistenza del team

• Sfida: I team potrebbero temere che le revisioni mettano in evidenza problemi
• Soluzione: Presenta le revisioni come opportunità di apprendimento, sottolineando l’identificazione precoce dei problemi, che previene guai maggiori

La chiave qui è la sicurezza psicologica. Chiarisci che trovare problemi è l’obiettivo, non un segno di fallimento. I team migliori cercano attivamente i problemi quando sono ancora gestibili.

Vincoli di tempo

• Sfida: I team spesso dicono di essere troppo occupati, soprattutto prima dei lanci
• Soluzione: Le revisioni contano di più prima dei grandi lanci. Una revisione mirata delle aree ad alto rischio è meglio di niente

Questa sfida spesso indica proprio quando una revisione è più critica. Se sei troppo impegnato per verificare la tua architettura, potresti essere troppo impegnato anche per recuperare da eventuali fallimenti architetturali.

Lacune di competenze

• Sfida: Non tutti i team hanno competenze su tutti i pilastri
• Soluzione: Usa gli AWS Well-Architected Partner, sfrutta le guide integrate nello strumento e fai cross-training tra i membri del team

Ricorda, non devi essere esperto in tutti e sei i pilastri per condurre una revisione di valore. Lo strumento ti guida attraverso le domande e i partner possono colmare le lacune di conoscenza.

Requisiti unici

• Sfida: I workload possono avere esigenze specifiche non coperte dalle lenti standard
• Soluzione: Crea lenti personalizzate che incorporino best practice specifiche dell’organizzazione e requisiti di conformità

Questa è in realtà un’opportunità, non una limitazione. Le lenti personalizzate ti permettono di codificare i requisiti unici della tua organizzazione in un framework riutilizzabile per garantire coerenza su tutti i tuoi workload. Ti mostrerò come farlo più avanti.

Miglioramento continuo e monitoraggio

L’AWS Well-Architected Framework non è un esercizio una tantum. È un impegno continuo verso l’eccellenza. È qui che molte organizzazioni si distinguono: non solo facendo una revisione, ma integrando il miglioramento continuo nella loro cultura. 

Dopotutto, la tua architettura si evolve costantemente, si aggiungono nuove funzionalità, cambiano i pattern di traffico e AWS rilascia nuovi servizi. Anche la tua pratica Well-Architected dovrebbe evolvere di pari passo.

Stabilire un calendario di revisione

Revisioni regolari mantengono la tua architettura allineata alle best practice mentre cambia. Pensa alle revisioni come ai controlli di salute regolari. Intercettano i piccoli problemi prima che diventino grandi. Conduci revisioni in momenti chiave:

• Dopo rilasci di funzionalità importanti
• Prima di lanci significativi
• Trimestralmente per i workload critici
• Annualmente per tutti i workload in produzione

Per i team di continuous delivery, integra revisioni leggere prima di effettuare il merge di cambiamenti significativi. Questo intercetta le derive architetturali precocemente, quando è più facile correggerle. Rendi la conformità al Well-Architected un requisito per i deployment in produzione. In questo modo ti assicuri che ogni workload parta da basi solide.

Integrare il feedback

Le revisioni creano valore solo quando agisci sui risultati. Crea cicli di feedback che trasformino i risultati della revisione in miglioramenti specifici. Dopo ogni revisione, sviluppa un piano prioritizzato. Concentrati prima sui miglioramenti a forte impatto e basso sforzo per creare slancio.

Condividi i risultati tra i team. Se più workload hanno problemi simili, hai identificato un problema sistemico che merita una soluzione sistemica. Forse standard aggiornati, componenti condivisi o programmi di formazione. Documenta le lezioni apprese in modo che altri team possano beneficiare della tua esperienza ed evitare di ripetere gli stessi errori.

Questa condivisione della conoscenza trasforma le revisioni individuali in apprendimento organizzativo.

Monitorare i progressi

Tracciare i miglioramenti nel tempo dimostra il valore della tua iniziativa Well-Architected e aiuta a giustificare investimenti continui. Usa la funzionalità di milestone dell’AWS Well-Architected Tool per catturare lo stato della tua architettura in momenti specifici e creare un chiaro prima-e-dopo dei tuoi miglioramenti.

Usa i Cloud Intelligence Dashboards per visualizzare metriche tra i workload, rendendo facile individuare tendenze e capire quali workload richiedono attenzione. 

Traccia metriche di business come disponibilità del sistema e tempo medio di ripristino per dimostrare come i miglioramenti si traducano in valore. Questi risultati di business contano più, per gli stakeholder, delle metriche tecniche.

Esplorare le lenti AWS Well-Architected

Le lenti AWS Well-Architected estendono le linee guida del framework a domini specifici. Mentre i sei pilastri si applicano universalmente, le lenti riconoscono che un workload di machine learning ha considerazioni diverse rispetto a un’applicazione serverless, che a sua volta differisce da una piattaforma di servizi finanziari. Ogni lente fornisce domande e best practice specializzate per questi contesti specifici.

Attualmente, il framework contiene 16 lenti, ma nella tabella qui sotto trovi le lenti più utilizzate:

Come vedi, le lenti affrontano esigenze specialistiche oltre il framework principale e ti aiutano a ottimizzare per specifiche tecnologie e settori. Ad esempio, se stai costruendo una piattaforma di machine learning, la ML Lens pone domande su qualità dei dati, training del modello e deployment che non compaiono nel framework generale, ma sono essenziali per il successo dell’ML.

Personalizzare il framework

Sebbene le lenti fornite da AWS coprano molti scenari, potresti dover affrontare esigenze organizzative uniche. Qui brillano le lenti personalizzate.

Le lenti personalizzate ti permettono di incorporare best practice interne, requisiti di conformità e policy organizzative direttamente nel framework. Crea lenti personalizzate per la conformità PCI, i requisiti HIPAA o standard di sicurezza specifici del tuo settore o modello di business.

Per creare una lente personalizzata, segui questo flusso di lavoro:

1. Scarica il template JSON dallo strumento
2. Definisci i tuoi pilastri, le domande e i piani di miglioramento
3. Caricalo nuovamente

Le lenti personalizzate possono essere condivise in tutta l’organizzazione, così puoi assicurarti che ogni team applichi in modo coerente gli standard della tua azienda.

Per esempio, un’organizzazione sanitaria potrebbe creare una lente che combini la conformità HIPAA con gli standard di sicurezza interni, ponendo domande su policy di rotazione delle chiavi di cifratura, conservazione dei log di audit e procedure di risposta agli incidenti specifiche per violazioni di dati sanitari. Una volta creata, ogni team dell’organizzazione può applicare questa lente per garantire la conformità su tutti i workload.

La forza delle lenti personalizzate è che ti permettono di codificare la conoscenza istituzionale. Quando i tuoi architetti senior vanno in pensione o cambiano ruolo, la loro esperienza rimane incorporata nelle lenti personalizzate.

Conclusione

L’AWS Well-Architected Framework offre un approccio strutturato per costruire architetture cloud sicure, affidabili, ad alte prestazioni, convenienti e sostenibili. Applicare i sei pilastri ti dà solide fondamenta per i tuoi workload nel cloud.

La vera forza del framework sta nel miglioramento continuo. La tua prima revisione individua le opportunità e le successive tracciano i progressi. Questo approccio iterativo trasforma buone architetture in ottime architetture.

Inizia con un singolo workload, conduci una revisione, implementa i miglioramenti e misura i risultati. Le lezioni apprese informano come progetterai i workload futuri. Ricorda che il framework è una guida per prendere decisioni consapevoli. Farai compromessi in base al tuo contesto, e va bene così finché ne comprendi le implicazioni.

Adottando l’AWS Well-Architected Framework, stai sviluppando la disciplina per l’eccellenza architetturale che servirà la tua organizzazione per gli anni a venire.

Per approfondire i contenuti di questo tutorial, ti consiglio i nostri corsi su Understanding Modern Data Architecture o AWS Security and Cost Management.