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à.
# Gestione delle identità e controllo degli accessi per la transizione a un'architettura multi-account
La prima fase della transizione a un'architettura multi-account consiste nel configurare la nuova struttura degli account all'interno di un'organizzazione. Quindi puoi aggiungere utenti e configurare il loro accesso agli account. Questa sezione descrive gli approcci per la gestione dell'accesso umano in più Account AWS.
**Topics**
+ [Configurazione di un'organizzazione](set-up-organization.md)
+ [Creazione di una zona di destinazione](create-landing-zone.md)
+ [Aggiunta di unità organizzative](add-organizational-units.md)
+ [Aggiunta di utenti iniziali](add-initial-users.md)
+ [Gestisci gli account membri](manage-member-accounts.md)
# Configurazione di un'organizzazione
Se ne hai più Account AWS, puoi gestire logicamente tali account tramite un'organizzazione in [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). Un *account* in AWS Organizations è uno standard Account AWS che contiene AWS le tue risorse e le identità che possono accedere a tali risorse. Un'*organizzazione* è un'entità che consolida le tue informazioni Account AWS in modo da poterle amministrare come un'unica unità.
Quando utilizzi un account per creare un'organizzazione, tale account diventa l'*account di gestione* (noto anche come *account di pagamento* o *account root*) per l'organizzazione. Un'organizzazione può avere un solo account di gestione. Quando ne aggiungi altri Account AWS all'organizzazione, questi diventano account *membro*.
**Nota**
Ciascuno ha Account AWS anche un'unica identità chiamata *utente root*. Puoi accedere come utente root utilizzando l'indirizzo e-mail e la password usati per creare l'account. Ti consigliamo tuttavia di non utilizzare l’utente root per le attività quotidiane, anche quelle amministrative. Per ulteriori informazioni, consulta la sezione [Utente root Account AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html).
Consigliamo inoltre di [centralizzare l'accesso root per gli account dei membri](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) e di rimuovere le credenziali dell'utente root dagli account dei membri dell'organizzazione.
Gli account vengono organizzati in una struttura gerarchica ad albero composta dall'area principale dell'organizzazione, dalle unità organizzative () e dagli account dei membri. OUs Il *root* è il container genitore per tutti gli account dell'organizzazione. Un'*unità organizzativa* (UO) è un container per [account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) all'interno della [root](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root). Un'unità organizzativa può contenere account di altri membri o di altri membri OUs . Una UO può avere esclusivamente un genitore e attualmente ogni account può essere membro di una sola UO. Per ulteriori informazioni, vedere [Terminologia e concetti](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentazione).
Una [policy di controllo dei servizi (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) specifica i servizi e le azioni che gli utenti e i ruoli possono utilizzare. SCPs sono simili alle politiche di autorizzazione AWS Identity and Access Management (IAM) tranne per il fatto che non concedono autorizzazioni. SCPs Definisci invece le autorizzazioni massime. Quando alleghi una policy a uno dei nodi della gerarchia, questa si applica a tutti gli account OUs e agli account all'interno di quel nodo. Ad esempio, se si applica una politica alla radice, questa si applica a tutti gli [OUs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit)[account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) dell'organizzazione e se si applica una politica a un'unità organizzativa, si applica solo agli account OUs e nell'unità organizzativa di destinazione.
Una [politica di controllo delle risorse (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) offre il controllo centralizzato sulle autorizzazioni massime disponibili per le risorse dell'organizzazione. RCPs ti aiuta a garantire che le risorse del tuo account rispettino le linee guida per il controllo degli accessi dell'organizzazione.
Puoi utilizzare la AWS Organizations console per visualizzare e gestire centralmente tutti i tuoi account all'interno di un'organizzazione. Uno dei vantaggi dell'utilizzo di un'organizzazione è la possibilità di ricevere una fattura consolidata che riporta tutti i costi associati agli account di gestione e dei membri. Per ulteriori informazioni, consulta [Fatturazione consolidata](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) (AWS Organizations documentazione).
## Best practice
+ Non utilizzarne uno esistente Account AWS per creare un'organizzazione. Inizia con un nuovo account, che diventerà il tuo account di gestione dell'organizzazione. Le operazioni privilegiate possono essere eseguite all'interno dell'account di gestione di un'organizzazione SCPs e RCPs non si applicano all'account di gestione. Ecco perché dovresti limitare le risorse e i dati cloud contenuti nell'account di gestione solo a quelli che devono essere gestiti in tale account.
+ Limita l'accesso all'account di gestione solo alle persone che devono fornire nuovi account Account AWS e amministrare l'organizzazione.
+ Viene utilizzato SCPs per definire le autorizzazioni massime per gli account root, le unità organizzative e gli account dei membri. SCPs non può essere applicato direttamente all'account di gestione.
+ Utilizzato RCPs per definire le autorizzazioni massime per le risorse negli account dei membri. RCPsnon può essere applicato direttamente all'account di gestione.
+ Rispetta le [migliori pratiche per AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html) (AWS Organizations documentazione).
# Creazione di una zona di destinazione
Una *landing zone* è un AWS ambiente multi-account ben progettato che rappresenta un punto di partenza dal quale è possibile distribuire carichi di lavoro e applicazioni. Fornisce un punto di riferimento per iniziare a utilizzare l'architettura multi-account, la gestione delle identità e degli accessi, la governance, la sicurezza dei dati, la progettazione della rete e la registrazione. [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) è un servizio che semplifica la manutenzione e la governance di un ambiente multi-account fornendo guardrail automatizzati. In genere, si effettua il provisioning di un'unica AWS Control Tower landing zone che gestisce l'ambiente in tutti gli ambienti Regioni AWS. AWS Control Tower funziona orchestrando altri elementi Servizi AWS all'interno del tuo account. Per ulteriori informazioni, consulta [Cosa succede quando si imposta una landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup) (AWS Control Tower documentazione).
Quando configuri una landing zone con AWS Control Tower, identifichi tre account condivisi: l'account di gestione, l'account di archiviazione dei log e l'account di controllo. Per ulteriori informazioni, consulta [Cosa sono gli account condivisi](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared) (AWS Control Tower documentazione). Per l'account di gestione, devi utilizzare un account esistente che non ospita carichi di lavoro per configurare la zona di destinazione. Per l'archivio dei log e gli account di controllo, puoi scegliere di riutilizzare gli account esistenti Account AWS o AWS Control Tower crearli automaticamente.
Per istruzioni su come configurare la AWS Control Tower landing zone, vedi [Guida introduttiva](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) (AWS Control Tower documentazione).
## Best practice
+ Attieniti alle migliori pratiche contenute nei [principi di progettazione per la tua strategia multi-account](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html) (AWS Whitepaper).
+ Rispetta le [migliori pratiche](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html) per gli amministratori (documentazione). AWS Control Tower AWS Control Tower
+ Crea la tua landing zone nell'area Regione AWS che ospita la maggior parte dei tuoi carichi di lavoro.
**Importante**
Se decidi di cambiare questa regione dopo aver dispiegato la tua landing zone, hai bisogno dell' Supporto AWS assistenza e devi disattivare la zona di atterraggio. Questa pratica non è consigliata.
+ Per determinare quali regioni AWS Control Tower governeranno, seleziona solo le regioni in cui prevedi di distribuire immediatamente i carichi di lavoro. Puoi modificare queste regioni o aggiungerne altre in un secondo momento. Se AWS Control Tower governa una Regione, schiererà i suoi guardrail investigativi in quella Regione come. [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ Dopo aver determinato quali Regioni AWS Control Tower governeranno, nega l'accesso a tutte le Regioni non governate. In questo modo, puoi garantire che i carichi di lavoro e gli sviluppatori possano utilizzare solo le Regioni AWS approvate. Questa pratica è implementata come una policy di controllo dei servizi (SCP) nell'organizzazione. Per ulteriori informazioni, consulta [Configurare il controllo di Regione AWS rifiuto (documentazione).](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html)AWS Control Tower
+ Quando configuri la landing zone in AWS Control Tower, ti consigliamo di rinominare quanto segue OUs e gli account:
+ Ti consigliamo di rinominare l'UO **Security** in **Security\$1Prod** per indicare che questa UO verrà utilizzata per Account AWS legati alla sicurezza della produzione.
+ **Ti consigliamo di consentire la creazione AWS Control Tower di un'unità organizzativa aggiuntiva e quindi di rinominarla da **Sandbox** a Workloads.** Nella sezione successiva, ne creerai altre OUs all'interno dell'unità organizzativa **Workloads**, che utilizzerai per organizzare le tue. Account AWS
+ **Si consiglia di rinominare la registrazione centralizzata Account AWS da Log Archive a. **log-archive-prod****
+ **Si consiglia di rinominare l'account di controllo da Audit a. **security-tooling-prod****
+ Per prevenire le frodi, è AWS necessario Account AWS disporre di una cronologia di utilizzo prima di poter essere aggiunti a una AWS Control Tower landing zone. Se ne utilizzi una nuova Account AWS senza alcuna cronologia di utilizzo, nel nuovo account puoi avviare un'istanza Amazon Elastic Compute Cloud (Amazon EC2) che non rientra nel piano gratuito. AWS Lascia che l'istanza venga eseguita per qualche minuto, quindi terminala.
# Aggiunta di unità organizzative
Stabilire la struttura organizzativa adeguata è fondamentale per la creazione di un ambiente multi-account. Poiché utilizzi le policy di controllo del servizio (SCPs) per definire le autorizzazioni massime per un'unità organizzativa e gli account al suo interno, la struttura organizzativa deve essere logica dal punto di vista della gestione, delle autorizzazioni e dei report finanziari. Per ulteriori informazioni sulla struttura di un'organizzazione, incluse le unità organizzative (OUs), vedere [Terminologia e concetti](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations documentazione).
In questa sezione, personalizzi la landing zone creando nidi OUs che ti aiutano a segmentare e strutturare i tuoi ambienti, come quelli di produzione e non produzione. Queste best practice consigliate sono progettate per segmentare la zona di destinazione in modo da separare le risorse di produzione da quelle non di produzione e separare l'infrastruttura dai carichi di lavoro.
Per ulteriori informazioni su come creare OUs, consulta [Gestione delle unità organizzative](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations documentazione).
## Best practice
+ All'interno dell'unità **organizzativa Workloads** in cui hai creato[Creazione di una zona di destinazione](create-landing-zone.md), crea quanto segue annidato OUs:
+ **Prod**: utilizza questa UO per gli Account AWS che archiviano e accedono ai dati di produzione, inclusi i dati dei clienti.
+ **NonProd**— Utilizzate questa unità organizzativa per Account AWS archiviare dati non di produzione, come ambienti di sviluppo, gestione temporanea o test
Nella root dell'organizzazione, crea una UO **Infrastructure\$1Prod**. Utilizza questa UO per ospitare un account di rete centralizzato.
# Aggiunta di utenti iniziali
Esistono due modi per concedere alle persone l'accesso agli Account AWS:
+ Identità IAM, come utenti, gruppi e ruoli
+ Federazione delle identità, ad esempio utilizzando AWS IAM Identity Center
Nelle aziende più piccole e negli ambienti con account singolo, è normale che gli amministratori creino un utente IAM quando una nuova persona entra a far parte dell'azienda. La chiave di accesso e le credenziali della chiave segreta associate a un utente IAM sono note come *credenziali a lungo termine* perché non scadono. Tuttavia, questa non è una best practice di sicurezza consigliata perché se un utente malintenzionato compromettesse tali credenziali, dovresti generare un nuovo set di credenziali per l'utente. Un altro approccio per l'accesso Account AWS è tramite i [ruoli IAM](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/). Puoi anche utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) per richiedere temporaneamente *credenziali a breve termine* che scadono dopo un periodo di tempo configurabile.
Puoi gestire l'accesso delle persone al tuo Account AWS tramite [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). Puoi creare account utente individuali per ciascuno dei tuoi dipendenti o collaboratori, che possono gestire le proprie password e soluzioni di autenticazione a più fattori (MFA) e tu puoi raggrupparli per gestire l'accesso. Quando si configura l'MFA, è possibile utilizzare token software, ad esempio applicazioni di autenticazione, oppure è possibile utilizzare token hardware, come i dispositivi. YubiKey
IAM Identity Center supporta anche la federazione da provider di identità esterni (IdPs) come Okta e Ping Identity. JumpCloud Per ulteriori informazioni, consulta la sezione [Gestori delle identità supportati](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) (documentazione di Centro identità IAM). Effettuando la federazione con un IdP esterno, puoi gestire l'autenticazione degli utenti tra le applicazioni e quindi utilizzare IAM Identity Center per autorizzare l'accesso a specifiche applicazioni. Account AWS
## Best practice
+ Aderisci alle [Best practice relative alla sicurezza](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (documentazione IAM) per configurare l'accesso degli utenti.
+ Gestisci l'accesso all'account per gruppi anziché per singoli utenti. In Centro identità IAM, crea nuovi gruppi che rappresentino ciascuna delle tue funzioni aziendali. Ad esempio, potresti creare gruppi per l'ingegneria, la finanza, le vendite e la gestione dei prodotti.
+ Spesso, i gruppi vengono definiti separando coloro che hanno bisogno di accedere a tutti gli Account AWS (spesso accesso in sola lettura) e coloro che necessitano dell'accesso a un unico Account AWS. Ti consigliamo di utilizzare la seguente convenzione di denominazione per i gruppi in modo che sia facile identificare le autorizzazioni Account AWS e le autorizzazioni associate al gruppo.
`--`
+ Ad esempio, per il gruppo `AWS-A-dev-nonprod-DeveloperAccess`, `AWS-A` è un prefisso che indica l'accesso a un singolo account, `dev-nonprod` è il nome dell'account e `DeveloperAccess` è il set di autorizzazioni assegnato al gruppo. Per il gruppo `AWS-O-BillingAccess`, il prefisso `AWS-O` indica l'accesso all'intera organizzazione e `BillingAccess` indica il set di autorizzazioni per il gruppo. In questo esempio, poiché il gruppo ha accesso all'intera organizzazione, il nome dell'account non è rappresentato nel nome del gruppo.
+ Se utilizzi Centro identità IAM con un IdP esterno basato su SAML e desideri richiedere l'MFA, puoi utilizzare il controllo degli accessi basato su attributi (ABAC) per passare il metodo di autenticazione dall'IdP a Centro identità IAM. Gli attributi vengono inviati tramite le asserzioni SAML. Per ulteriori informazioni, consulta la sezione [Abilitazione e configurazione degli attributi per il controllo degli accessi](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) (documentazione di Centro identità IAM).
Molti IdPs, come Microsoft Azure Active Directory e Okta, possono utilizzare l'attestazione Authentication Method Reference (`amr`) all'interno di un'asserzione SAML per passare lo stato MFA dell'utente a IAM Identity Center. L'attestazione utilizzata per affermare lo stato di MFA e il relativo formato variano in base all'IdP. Per ulteriori informazioni, consulta la documentazione relativa al tuo IdP.
In IAM Identity Center, puoi quindi creare policy di set di autorizzazioni che determinano chi può accedere alle tue risorse. AWS Quando abiliti l'ABAC e specifichi gli attributi, Centro identità IAM trasmette il valore degli attributi dell'utente autenticato a IAM per l'utilizzo nella valutazione delle policy. Per ulteriori informazioni, consulta la sezione [Creazione di policy di autorizzazione per ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html) (documentazione di Centro identità IAM). Come illustrato nel seguente esempio, utilizzi la chiave di condizione `aws:PrincipalTag` per creare una regola di controllo di accesso per l'MFA.
```
"Condition": {
"StringLike": { "aws:PrincipalTag/amr": "mfa" }
}
```
# Gestisci gli account membri
In questa sezione inviti i tuoi account preesistenti nell'organizzazione e inizi a creare nuovi account all'interno della tua organizzazione. Una parte importante di questo processo è la definizione dei criteri da utilizzare per determinare se è necessario fornire un nuovo account.
**Topics**
+ [Invita il tuo account preesistente](#invite-account)
+ [Personalizza le impostazioni del VPC in AWS Control Tower](#customize-vpc-settings)
+ [Definizione dei criteri di determinazione dell'ambito](#define-scoping-criteria)
## Invita il tuo account preesistente
All'interno AWS Organizations, puoi invitare l'account preesistente della tua azienda nella tua nuova organizzazione. Solo l'account di gestione dell'organizzazione può invitare altri account a iscriversi. Nel momento in cui l'amministratore di un account invitato accetta, l'account di gestione di tale organizzazione diventa responsabile per tutte le spese maturate dal nuovo account membro. Per ulteriori informazioni, consulta la sezione [Invito a un Account AWS per entrare a far parte dell'organizzazione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) e [Accettazione o rifiuto di un invito da un'organizzazione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite) (documentazione AWS Organizations ).
**Nota**
Puoi invitare un account a entrare a far parte di un'organizzazione solo se tale account non appartiene attualmente a un'altra organizzazione. Se l'account è membro di un'organizzazione esistente, devi rimuoverlo dall'organizzazione. Se l'account è l'account di gestione di un'altra organizzazione creata per errore, è necessario eliminare l'organizzazione.
**Importante**
Se hai bisogno di accedere a informazioni storiche sui costi o sull'utilizzo dal tuo account preesistente, puoi usarle AWS Cost and Usage Report per esportare tali informazioni in un bucket Amazon Simple Storage Service (Amazon S3). Fallo prima di accettare l'invito a unirti a un'organizzazione. Quando un account entra a far parte di un'organizzazione, perdi l'accesso a questi dati storici relativi all'account. Per ulteriori informazioni, consulta la sezione [Configurazione di un bucket Amazon S3 per i report di costi e utilizzo](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html) (documentazione AWS Cost and Usage Report ).
*Best practice*
+ Ti consigliamo di aggiungere il tuo account preesistente, che probabilmente contiene carichi di lavoro di produzione, all'unità organizzativa **Workloads**>**Prod** che hai creato in[Aggiunta di unità organizzative](add-organizational-units.md).
+ Per impostazione predefinita, l'account di gestione dell'organizzazione non dispone dell'accesso amministrativo agli account membri invitati all'organizzazione. Se desideri che l'account di gestione abbia il controllo amministrativo, devi creare il ruolo **OrganizationAccountAccessRole**IAM nell'account membro e concedere l'autorizzazione all'account di gestione per assumere il ruolo. Per ulteriori informazioni, consulta [Creazione OrganizationAccountAccessRole di un account membro invitato](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role) (AWS Organizations documentazione).
+ Per l'account preesistente che hai invitato a far parte dell'organizzazione, consulta [le migliori pratiche per gli account dei membri](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) (AWS Organizations documentazione) e conferma che l'account rispetti questi consigli.
## Personalizza le impostazioni del VPC in AWS Control Tower
Ti consigliamo di effettuare il provisioning di nuovi Account AWS prodotti tramite [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) in AWS Control Tower. Utilizzando Account Factory, puoi utilizzare l' AWS Control Tower integrazione con Amazon EventBridge per fornire nuove risorse non Account AWS appena l'account viene creato.
Quando si configura un nuovo Account AWS[cloud privato virtuale (VPC) predefinito viene fornito](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) automaticamente. Tuttavia, quando crei un nuovo account tramite Account Factory, AWS Control Tower effettua automaticamente il provisioning di un VPC aggiuntivo. Per ulteriori informazioni, vedere [Panoramica AWS Control Tower e VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html) (AWS Control Tower documentazione). Ciò significa che, per impostazione predefinita, due AWS Control Tower disposizioni sono predefinite VPCs in ogni nuovo account.
È normale che le aziende desiderino un maggiore controllo all' VPCs interno dei propri conti. Molti preferiscono utilizzare altri servizi AWS CloudFormation, come Hashicorp Terraform o Pulumi, per configurare e gestire i propri. VPCs È necessario personalizzare le impostazioni di Account Factory per impedire la creazione del VPC aggiuntivo fornito da AWS Control Tower. Per istruzioni, consulta [Configurare le impostazioni di Amazon VPC](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html) (AWS Control Tower documentazione) e applicare le seguenti impostazioni:
1. Disabilita l'opzione **Sottorete accessibile da Internet**.
1. In **Numero massimo di sottoreti private**, scegli **0**.
1. In **Regioni per la creazione di VPC**, cancella tutte le regioni.
1. In **Zone di disponibilità**, scegli **3**.
*Best practice*
+ Elimina il VPC predefinito che viene fornito automaticamente in ogni nuovo account. Ciò impedisce agli utenti di avviare istanze EC2 pubbliche nell'account senza creare esplicitamente un VPC dedicato. Per ulteriori informazioni, consulta la sezione [Eliminazione delle sottoreti predefinite e del VPC predefinito](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc) (documentazione di Amazon Virtual Private Cloud). Puoi anche configurare [AWS Control Tower Account Factory per Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) per eliminare automaticamente il VPC predefinito negli account appena creati.
+ **Effettua il provisioning di un nuovo **dispositivo Account AWS chiamato dev-nonprod** nell'unità organizzativa Workload >. **NonProd**** Usa questo account per il tuo ambiente di sviluppo. Per istruzioni, vedere [Provision Account Factory accounts with AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html) (AWS Control Tower documentazione).
## Definizione dei criteri di determinazione dell'ambito
Devi selezionare i criteri che la tua azienda utilizzerà per decidere se fornirne uno nuovo Account AWS. Puoi decidere di effettuare il provisioning degli account per ogni unità aziendale oppure decidere di eseguire il provisioning degli account in base all'ambiente, ad esempio produzione, test o controllo qualità. Ogni azienda ha i propri requisiti per quanto grande o piccola Account AWS dovrebbe essere. In genere, quando decidi come dimensionare i tuoi account, valuti i seguenti tre fattori:
+ **Bilanciamento delle quote** di *servizio: le quote* di servizio sono i valori massimi per il numero di risorse, azioni e articoli per ciascuno Servizio AWS all'interno di un. Account AWS Se molti carichi di lavoro condividono lo stesso account e un carico di lavoro consuma la maggior parte o la totalità di una Service Quota, ciò potrebbe avere un impatto negativo su un altro carico di lavoro nello stesso account. In tal caso, potrebbe essere necessario separare tali carichi di lavoro in account diversi. Per ulteriori informazioni, consulta la sezione [Servizio AWS Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) (Riferimenti generali di AWS).
+ **Creazione di report sui costi**: l'isolamento dei carichi di lavoro in account separati consente di visualizzare i costi a livello di account nei report sui costi e sull'utilizzo. Quando utilizzi lo stesso account per più carichi di lavoro, puoi utilizzare i tag per gestire e identificare le risorse. [Per ulteriori informazioni sull'etichettatura, vedere Tagging resources (). AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)Riferimenti generali di AWS
+ **Controllo dell'accesso**: quando i carichi di lavoro condividono un account, è necessario considerare come configurare le policy IAM per limitare l'accesso alle risorse dell'account in modo che gli utenti non abbiano accesso ai carichi di lavoro di cui non hanno bisogno. In alternativa, puoi utilizzare più account e [set di autorizzazioni](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in Centro identità IAM per gestire l'accesso ai singoli account.
*Best practice*
+ Rispetta le migliori pratiche in materia di [strategia AWS multi-account per la tua AWS Control Tower landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) (AWS Control Tower documentazione).
+ Stabilisci una strategia di assegnazione dei tag efficace che ti aiuti a identificare e gestire le risorse AWS . È possibile utilizzare i tag per suddividere le risorse in categorie in base allo scopo, all'unità aziendale, all'ambiente o ad altri criteri. Per ulteriori informazioni, consulta [Best practice for tagging (documentazione](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices))Riferimenti generali di AWS .
+ Non sovraccaricare un account con troppi carichi di lavoro. Se la richiesta del carico di lavoro supera una Service Quota, ciò può causare problemi di prestazioni. Puoi separare i carichi di lavoro concorrenti in diversi Account AWS oppure richiedere un aumento della quota di servizio. Per ulteriori informazioni, consulta la sezione [Richiesta di aumento di una quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (documentazione Service Quotas).