# Framework AWS Well-Architected
Data di pubblicazione: **10 aprile 2023** ([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 nel Cloud AWS. Permette di misurare in modo coerente le architetture rispetto alle best practice e identificare le aree da migliorare. Il processo di revisione di un'architettura consiste in 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.
AWS Solutions Architects vanta 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 canone 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 canone di architettura.
Questo canone è 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 maggiori 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) (AWS WA Tool) è un servizio cloud che fornisce un approccio coerente per la revisione e la valutazione della tua architettura tramite AWS Well-Architected Framework. AWS WA Tool fornisce raccomandazioni per rendere i tuoi 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 pratica di implementazione delle best practice. Abbiamo anche collaborato con AWS Partner Network (APN) selezionati, che sono membri del [programma AWS Well-Architected Partner](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 distribuisci 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 AWS Framework Well-Architected**
| **Nome** | **Descrizione** |
| --- | --- |
| Eccellenza operativa | The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value. |
| Sicurezza | The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture. |
| Affidabilità | The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS. |
| Efficienza delle prestazioni | The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve. |
| Ottimizzazione dei costi | The ability to run systems to deliver business value at the lowest price point. |
| Sostenibilità | The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required. |
Nel Framework AWS Well-Architected, si utilizzano i seguenti termini:
+ Un **componente** è costituito dal codice, dalla configurazione e dalle risorse AWS che insieme vengono forniti per soddisfare il requisito. Spesso un componente è l'unità di proprietà tecnica ed è disaccoppiato da altri componenti.
+ Con il termine **carico di lavoro** ci riferiamo a un insieme di componenti che forniscono valore aziendale. Un carico di lavoro, normalmente, è il livello di dettaglio comunicato dai leader aziendali e della tecnologia.
+ Pensiamo a un'**architettura** come al modo in cui in componenti operano insieme in un carico di lavoro. Il modo di comunicare e di interagire dei componenti è spesso l'aspetto principale dei diagrammi architetturali.
+ **Milestone** 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.
+ **Alto:** 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. Questo tipo di decisioni aziendali deve essere alla base delle tue priorità ingegneristiche. 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. L'eccellenza in ambito di sicurezza e operatività generalmente non viene sacrificata rispetto agli altri pilastri.
# Architettura
Negli ambienti in locale, 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 i team usano [TOGAF](http://pubs.opengroup.org/architecture/togaf9-doc/arch/?ref=wellarchitected-wp) o il [Framework di Zachman](https://www.zachman.com/about-the-zachman-framework?ref=wellarchitected-wp) come parte delle competenze architetturali aziendali.
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. Innanzitutto, abbiamo le *practice* (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 garantiscano che i team adottino standard più severi di quelli che devono rispettare. In secondo luogo, implementiamo *meccanismi* che eseguono controlli automatizzati per garantire 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. L'approccio distribuito è supportato dai [Principi di leadership di Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp) e stabilisce una cultura tra tutti i ruoli che *lavorano a ritroso* 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 ingegneri responsabili che possono eseguire la revisione dei loro progetti e aiutarli a comprendere le best practice di AWS. La community di ingegneri responsabili 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 garantire 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 Canone di architettura è 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 canone di architettura è un meccanismo scalabile che consente di trarre vantaggio da questi insegnamenti.
Seguendo l'approccio della community di ingegneri responsabili 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 in termini di capacità**: quando prendi decisioni sbagliate relative alla capacità per la distribuzione di un carico di lavoro, potresti ritrovarti con risorse inattive costose o ad affrontare le conseguenze a livello di performance della capacità limitata. Con il cloud computing, questi problemi vengono risolti. Puoi utilizzare la capacità di cui hai bisogno e ridimensionare 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, quindi 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 in locale.
+ **Automatizza per semplificare la sperimentazione dell'architettura**: l'automazione ti permette di creare e replicare i tuoi carichi di lavoro contenendo i costi e di evitare le spese delle attività manuali. Puoi tenere traccia delle modifiche all'automazione, effettuare l'audit dell'impatto e tornare ai parametri precedenti, se necessario.
+ **Consenti 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.