

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Obiettivi per la transizione verso un'architettura multi-account
<a name="targeted-business-outcomes"></a>

La transizione verso un'architettura multi-account è in genere determinata dall'esigenza aziendale di ottenere uno o più dei seguenti vantaggi:
+ Raggruppamento dei carichi di lavoro in base allo scopo o alla proprietà dell'azienda
+ Applicazione di controlli di sicurezza distinti per ambiente
+ Limitazione dell'accesso ai dati sensibili
+ Promozione dell'innovazione e dell'agilità
+ Limitazione dell'ambito di impatto degli eventi avversi
+ Supporto di più modelli operativi IT
+ Gestione dei costi
+ Distribuzione delle Servizio AWS quote e dei limiti di frequenza delle richieste API

Per ulteriori informazioni sui numerosi vantaggi dell'utilizzo di un'architettura multi-account, consulta [Organizzare AWS l'ambiente utilizzando più account](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html) (AWS white paper) e [Linee guida per configurare un](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html#guidelines-for-multi-account-setup) ambiente ben progettato (documentazione).AWS Control Tower 

## Esempio di architettura con account singolo
<a name="sample-architecture"></a>

Come punto di partenza, è normale che le startup o le piccole aziende utilizzino un unico Regione AWS e dispongano di due cloud privati virtuali (VPC) collegati da [Peering di VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html). Ogni VPC contiene risorse di elaborazione, come le istanze di Amazon Elastic Compute Cloud (Amazon EC2). Il team di progettazione sviluppa il codice direttamente nel **VPC di sviluppo**. Il team di prodotto esamina le modifiche, quindi il team di progettazione promuove manualmente le modifiche al **VPC di produzione**. Il team finanziario ha accesso al file in modo da Account AWS poter rivedere la console. Gestione costi e fatturazione AWS 



![Single-account architettura con due VPC peer-to-peer in uno solo. Regione AWS](https://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/1_single-account-arch.png)


Di seguito sono riportati alcuni esempi di sfide che un'azienda potrebbe incontrare in questo ambiente:
+ Un ingegnere ha erroneamente eliminato i dati di produzione pensando di accedere a un database di sviluppo.
+ Una dimostrazione di vendita ne ha risentito quando un'implementazione in produzione ha richiesto più tempo del previsto.
+ Durante il test di caricamento del codice di sviluppo, il **VPC di produzione** è diventato lento e ha generato messaggi di errore relativi alla limitazione.
+ Il team finanziario non è in grado di differenziare i costi per gli ambienti di produzione e di sviluppo.
+ Il CEO teme che alcuni appaltatori esteri appena assunti abbiano accesso ai dati dei clienti tramite il **VPC di produzione**.
+ Il team finanziario non può impedire l'accesso a informazioni specifiche Servizi AWS che potrebbero comportare costi elevati.

L'adozione di una strategia multi-account risolve tutte queste sfide utilizzando sistemi Account AWS compartimentati per separare carichi di lavoro e accessi.