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à.
# Progettazione dell'unità organizzativa: fase 1
Per l'azienda farmaceutica multinazionale, nel nostro esempio, la progettazione iniziale delle organizzazioni e OUs le raccomandazioni per la costituzione seguite AWS Organizations AWS da vicino. AWS Control Tower Per un esempio, vedi [Landing Zone Accelerator on AWS](https://github.com/aws-samples/landing-zone-accelerator-on-aws-for-healthcare) for Healthcare. AWS Control Tower inizialmente OUs, come descritto nel post di blog [Best Practices for Organizational Units, ho fornito una struttura di unità organizzative semplice con basi comuni AWS Organizations, tra cui l'unità organizzativa](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog) di sicurezza, l'unità organizzativa dell'infrastruttura della piattaforma e specifiche dell'azienda. OUs
## Progettazione dell’architettura
Il diagramma seguente mostra l'architettura dell'unità organizzativa iniziale.
## Unità organizzativa di sicurezza
L'unità organizzativa di sicurezza raggruppa ampiamente le funzionalità Account AWS correlate alla sicurezza e utilizza due account (Audit e Log Archive) per archiviare i dati operativi di sicurezza per la registrazione centralizzata e il controllo dell'accesso all'ambiente. AWS servizi di sicurezza di base come Amazon GuardDuty e AWS Security Hub CSPM risiedono nell'account Audit.
## Piattaforma di infrastruttura OU
L'Infrastructure Platform OU Account AWS si raggruppa per fornire le fondamenta dell'infrastruttura. All'interno di questa unità organizzativa sono inizialmente distribuiti i componenti della rete centrale (gateway, firewall, hub di rete centrale e servizi simili). Account AWS
## Aggiuntivo OUs
Altre, specifiche dell'azienda OUs (come un'unità operativa clinica) aumentano le basi OUs all'interno di una gerarchia di basso livello. I carichi di lavoro sono implementati con una struttura multi-account e con ambienti separati al loro interno. OUs
Alla base di questo progetto iniziale ci sono diverse considerazioni:
+ I Nested non OUs erano disponibili in quel momento AWS Control Tower e richiedevano un'ampia personalizzazione.
+ I carichi di lavoro iniziali destinati al cloud si concentravano su aspetti particolari dell'azienda, come le sperimentazioni cliniche o l'analisi delle apparecchiature di produzione (visualizzazioni funzionali).
+ L'azienda distingue tra cinque ambienti di carico di lavoro (sviluppo, convalida, integrazione, formazione e produzione). L'azienda aveva bisogno di un terreno di gioco per lo sviluppo di applicazioni senza la rigida governance tramite AWS controlli richiesti dai carichi di lavoro di produzione. A questo scopo sono stati assegnati progetti OUs come Manufacturing-Dev OU.
+ L'automazione del carico di lavoro faceva parte dell'ecosistema di ciascuna applicazione e non necessitava di separazione.
+ I processi di qualificazione dell'infrastruttura (IQ) e di conformità GxP non richiedevano una distinzione AWS di controlli a livello di unità organizzativa.