# Framework AWS Well-Architected Data di pubblicazione: **6 novembre 2024** ([Revisioni del documento](document-revisions.md)) Il Framework AWS Well-Architected aiuta a comprendere i pro e i contro delle decisioni prese durante la progettazione di sistemi in AWS. Utilizzando il Framework, scoprirai le best practice architetturali per progettare e gestire sistemi affidabili, sicuri, efficienti, convenienti e sostenibili nel cloud. ## Introduzione Il Framework AWS Well-Architected aiuta a comprendere i pro e i contro delle decisioni prese durante la progettazione di sistemi in AWS. Utilizzando il Framework, scoprirai le best practice architetturali per progettare e gestire carichi di lavoro affidabili, sicuri, efficienti, convenienti e sostenibili nell'Cloud AWS. Offre un metodo per misurare con coerenza le proprie architetture rispetto alle best practice e individuare le aree di miglioramento. Il processo di revisione di un'architettura è una conversazione costruttiva sulle decisioni relative all'architettura e non un meccanismo di audit. Disporre di sistemi ben architettati aumenta notevolmente la probabilità di successo aziendale. Gli AWS Solutions Architect vantano anni di esperienza nell'architettura di soluzioni in un'ampia gamma di business e casi di utilizzo. Abbiamo supportato migliaia di clienti nella progettazione e revisione delle loro architetture su AWS. Grazie a questa esperienza, abbiamo identificato best practice e strategie principali per i sistemi di architettura nel cloud. Il Framework AWS Well-Architected documenta un insieme di domande fondamentali per capire se un'architettura specifica si allinea bene con le best practice del cloud. Il framework fornisce un approccio coerente per la valutazione dei sistemi rispetto alle qualità che ti aspetti da sistemi basati sul cloud moderni e i rimedi necessari per raggiungere tali qualità. Man mano che AWS continua a evolversi e noi continuiamo a imparare di più dal lavoro che svolgiamo con i nostri clienti, continueremo a ridefinire la definizione di architettura ottimale. Questo framework è rivolto a chi svolge ruoli tecnologici, ad esempio ai Chief Technology Officer (CTO), ai progettisti, agli sviluppatori e ai membri dei team operativi. Descrive le best practice e le strategie AWS da usare per la progettazione e il funzionamento di un carico di lavoro cloud, e fornisce collegamenti a ulteriori dettagli di implementazione e pattern architetturali. Per ulteriori informazioni, consulta la [homepage di AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp). AWS offre anche un servizio gratuito di revisione dei carichi di lavoro. [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/?ref=wellarchitected-wp) (Strumento AWS WA) è un servizio cloud che fornisce un approccio coerente per la revisione e la valutazione della tua architettura tramite il Framework AWS Well-Architected. Lo Strumento AWS WA fornisce suggerimenti per rendere i carichi di lavoro più affidabili, sicuri, efficienti e convenienti. Per aiutarti ad applicare le best practice, abbiamo creato [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp), che fornisce un repository di codice e documentazione per un'esperienza concreta di implementazione delle best practice. Abbiamo anche collaborato con partner della rete dei partner AWS selezionati, che sono membri del [programma per partner AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp). Tali partner AWS vantano una conoscenza approfondita di AWS e possono aiutarti nella revisione e nel miglioramento dei tuoi carichi di lavoro. # Definizioni Tutti i giorni, gli esperti AWS supportano i clienti nella progettazione di sistemi di architettura per sfruttare le best practice nel cloud. Ti aiutiamo a trovare i compromessi relativi all'architettura nel processo di evoluzione dei tuoi progetti. Quando implementi questi sistemi in ambienti live, analizziamo le prestazioni di questi sistemi e le conseguenze dei suddetti compromessi. Sulla base di quello che abbiamo imparato, abbiamo creato il Framework AWS Well-Architected, che fornisce a clienti e partner un insieme coerente di best practice per valutare le architetture, e comprende un insieme di domande che puoi utilizzare per valutare se la tua architettura è ben allineata alle best practice AWS. Il Framework AWS Well-Architected si basa su sei pilastri: eccellenza operativa, sicurezza, affidabilità, efficienza delle prestazioni, ottimizzazione dei costi e sostenibilità. **Tabella 1. I pilastri del Framework AWS Well-Architected** | **Nome** | **Descrizione** | | --- | --- | | Eccellenza operativa | Comprende la capacità di supportare lo sviluppo ed eseguire carichi di lavoro in modo efficace, ottenere informazioni approfondite sulle loro operazioni e migliorare continuamente i processi e le procedure di supporto per offrire valore aggiunto. | | Sicurezza | Il pilastro della sicurezza descrive come sfruttare le tecnologie cloud per proteggere dati, sistemi e risorse in modo da migliorare il livello di sicurezza. | | Affidabilità | Il pilastro dell'affidabilità comprende la capacità di un carico di lavoro di eseguire la funzione attesa in modo corretto e coerente quando previsto. Ciò comprende la possibilità di utilizzare e testare il carico di lavoro per tutto il ciclo di vita. Il presente documento fornisce linee guida dettagliate sulle best practice per l'implementazione di carichi di lavoro affidabili in AWS. | | Efficienza delle prestazioni | La capacità di utilizzare in modo efficiente le risorse di elaborazione per soddisfare i requisiti di sistema e di mantenere tale efficienza di fronte al cambiamento delle richieste e all'evoluzione delle tecnologie. | | Ottimizzazione dei costi | La capacità di eseguire i sistemi per distribuire il valore aziendale al prezzo minore. | | Sostenibilità | La capacità di migliorare continuamente l'impatto sulla sostenibilità riducendo il consumo energetico e aumentando l'efficienza di tutti i componenti di un carico di lavoro, massimizzando i benefici delle risorse allocate e riducendo al minimo le risorse totali richieste. | Nel Framework AWS Well-Architected, si utilizzano i seguenti termini: + Un **componente** è il codice, la configurazione e le risorse AWS che insieme soddisfano un requisito. Spesso un componente è l'unità di proprietà tecnica ed è disaccoppiato da altri componenti. + Con il termine **carico di lavoro** ci riferiamo all'insieme di componenti che forniscono valore aziendale. Un carico di lavoro, normalmente, è il livello di dettaglio comunicato dai leader aziendali e della tecnologia. + Secondo il nostro punto di vista, l'**architettura** è il modo in cui i componenti interagiscono in un carico di lavoro. Il modo di comunicare e di interagire dei componenti è spesso l'aspetto principale dei diagrammi architetturali. + Le **tappe fondamentali** indicano cambiamenti chiave della tua architettura man mano che si evolve nel corso del ciclo di vita del prodotto (progettazione, test, messa online e produzione). + Nell'ambito di un'organizzazione il **portfolio delle tecnologie** rappresenta l'insieme di carichi di lavoro necessari affinché l'azienda possa essere operativa. + Il **livello di impegno** è la categorizzazione della quantità di tempo, sforzo e complessità che un'attività richiede per la sua realizzazione. Ogni organizzazione deve considerare le dimensioni e le competenze del team e la complessità del carico di lavoro per ottenere un contesto aggiuntivo che consenta di classificare correttamente il livello di impegno. + **Elevato:** il lavoro potrebbe richiedere più settimane o più mesi. Potrebbe essere suddiviso in molteplici fasi, rilasci e attività. + **Medio:** il lavoro potrebbe richiedere più giorni o settimane. Potrebbe essere suddiviso in molteplici rilasci e attività. + **Basso:** il lavoro potrebbe richiedere più ore o giorni. Potrebbe essere suddiviso in molteplici attività. Quando progetti l'architettura dei carichi di lavoro, devi trovare dei compromessi tra i pilastri su cui si regge il tuo contesto aziendale. Le decisioni aziendali possono stabilire le priorità di progettazione. Potresti ottimizzare per migliorare la sostenibilità e ridurre i costi a spese dell'affidabilità in ambienti di sviluppo oppure, per quanto riguarda le soluzioni mission-critical, potresti ottimizzare l'affidabilità a fronte di costi più elevati e di un impatto ambientale maggiore. Nelle soluzioni di e-commerce, le prestazioni possono avere un impatto sui profitti e sulla propensione all'acquisto da parte dei clienti. Solitamente, la sicurezza e l'eccellenza operativa non sono soggette a compromessi rispetto agli altri pilastri. # Architettura Negli ambienti on-premises, i clienti spesso hanno un team centrale per l'architettura delle tecnologie che funziona da livello superiore per altri team di prodotto o funzionalità, al fine di garantire che i team rispettino le best practice. I team dell'architettura delle tecnologie spesso sono composti da diversi ruoli come il Technical Architect (infrastruttura), il Solutions Architect (software), il Data Architect, il Networking Architect e il Security Architect. Spesso questi team utilizzano [TOGAF](https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework) o il [Framework Zachman](https://zachman-feac.com/zachman/about-the-zachman-framework) nell'ambito di una funzionalità dell'architettura aziendale. Noi di AWS preferiamo distribuire le competenze tra i team, invece di centralizzarle in un unico team. Quando si sceglie di distribuire il potere decisionale si corrono dei rischi, ad esempio il rischio di garantire che i team interni rispettino gli standard. Noi mitighiamo questo rischi in due modi. In primo luogo, disponiamo di *pratiche* (modalità per eseguire attività, processi, standard e norme accettate) che hanno lo scopo di permettere a ogni team di possedere tali competenze e ci serviamo di esperti che verificano che i team adottino standard più severi di quelli che devono rispettare. In secondo luogo, implementiamo *meccanismi* che eseguono controlli automatizzati per verificare che gli standard vengano rispettati. **** "Le buone intenzioni non bastano mai, per avere successo servono buoni meccanismi", Jeff Bezos. Questo significa sostituire gli sforzi di una persona con meccanismi (spesso automatizzati) che verificano la conformità alle regole e ai processi. Tale approccio distribuito è supportato dai [principi di leadership di Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp) e stabilisce una cultura in tutti i ruoli che *parte* dal cliente. Il lavoro a ritroso è una parte fondamentale del nostro processo di innovazione. Partiamo dal cliente e da quello che vuole e sulla base di questo definiamo e indirizziamo i nostri sforzi. I team che mettono il cliente al centro sviluppano prodotti sulla base delle necessità del cliente. Per l'architettura questo significa che ci aspettiamo che ogni team sia in grado di creare architetture e di seguire le best practice. Per aiutare i nuovi team ad acquisire queste competenze o i team esistenti ad alzare il livello, abilitiamo l'accesso a una community virtuale di capo ingegneri che possono eseguire la revisione dei loro progetti e aiutarli a comprendere le best practice di AWS. La community di capo ingegneri lavora per rendere visibili e accessibili le best practice. Uno dei modi per fare ciò, ad esempio, è servirsi delle lunchtime talk che si concentrano sull'applicazione di best practice a esempi reali. Le lunchtime talk sono registrate e possono essere utilizzate come materiale di onboarding per i nuovi membri del team. Le best practice AWS sono il risultato della nostra esperienza nell'esecuzione di migliaia di sistemi su Internet. Preferiamo utilizzare i dati per definire le best practice, ma ci serviamo anche di esperti in materia, come i capo ingegneri. Quando i capo ingegneri vedono emergere nuove best practice, lavorano con la community per verificare che i team le rispettino. Con il tempo, queste best practice vengono formalizzate nei nostri processi di revisione interna e nei meccanismi che rafforzano la compliance. Il Framework Well-Architected è l'implementazione del nostro processo di revisione interno rivolta ai clienti, in cui abbiamo codificato la nostra idea di ingegneria responsabile attraverso ruoli di campo come Solutions Architect e i team di ingegneria interni. Il Framework Well-Architected è un meccanismo scalabile che consente di trarre vantaggio da questi insegnamenti. Seguendo l'approccio della community di capi ingegneri con la proprietà distribuita dell'architettura, riteniamo che si possa ottenere un'architettura aziendale Well-Architected che si basa sulle necessità del cliente. I leader della tecnologia (come i CTO o i manager dello sviluppo) che eseguono revisioni Well-Architected tra tutti i carichi di lavoro ti permettono di comprendere più a fondo i rischi relativi al portfolio delle tecnologie. Tramite questo approccio puoi identificare dei temi tra i team che la tua organizzazione può affrontare tramite meccanismi, formazione o dialoghi informali in cui i capo ingegneri possono condividere le loro idee su aree specifiche con diversi team. # Principi generali di progettazione Il Framework Well-Architected identifica una serie di principi generali per facilitare la corretta progettazione nel cloud: + **Smetti di ipotizzare quali siano le tue esigenze di capacità**: se prendi una decisione sbagliata sulla capacità al momento dell'implementazione di un carico di lavoro, rischi di ritrovarti con risorse inattive o ad affrontare le conseguenze della capacità limitata. Con il cloud computing, questi problemi vengono risolti. Puoi utilizzare la capacità di cui hai bisogno e ridurre orizzontalmente o aumentare orizzontalmente il sistema automaticamente. + **Esegui test dei sistemi su scala produttiva**: nel cloud, puoi creare un ambiente di test su scala produttiva on demand, completare i test e disattivare le risorse. Poiché paghi per l'ambiente di test solo quando è in esecuzione, puoi simulare un ambiente live a un costo notevolmente inferiore rispetti ai test on-premises. + **Automatizza pensando alla sperimentazione architettonica**: l'automazione ti permette di creare e replicare i tuoi carichi di lavoro a basso costo e di evitare le spese della gestione manuale. Puoi tenere traccia delle modifiche all'automazione, effettuare l'audit dell'impatto e tornare ai parametri precedenti, se necessario. + **Considera le architetture evoluzionistiche**: in un ambiente tradizionale, le decisioni relative all'architettura spesso sono implementate come eventi singoli e statici, con poche versioni principali di un sistema durante il ciclo di vita. Alla luce del continuo cambiamento di un'azienda e del suo contesto, le decisioni iniziali potrebbero ostacolare la capacità del sistema di soddisfare i requisiti aziendali in evoluzione. All'interno del cloud, la capacità di automatizzare e testare on demand diminuisce il rischio di impatto dovuto alle modifiche della progettazione. Questo permette ai sistemi di evolversi nel tempo, in modo che le aziende possano trarre vantaggio dalle innovazioni come pratica standard. + **Promuovi le architetture servendoti dei dati**: nel cloud puoi raccogliere dati relativi all'impatto delle tue scelte architetturali sul comportamento del tuo carico di lavoro. Questo ti permette di prendere decisioni basate sui fatti su come migliorare il carico di lavoro. La tua infrastruttura cloud è un codice, quindi, puoi usare tali dati a vantaggio delle scelte e dei miglioramenti relativi all'architettura nel tempo. + **Migliora con le giornate di gioco**: testa le prestazioni dell'architettura e dei processi pianificando regolarmente giornate di gioco per simulare eventi della produzione. Questi ti aiuta a capire dove puoi apportare dei miglioramenti e ti può aiutare a sviluppare un'esperienza organizzativa nella gestione degli eventi.