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à.
Costruisci una zona di atterraggio
AWS Transform ti guida nella progettazione e implementazione di una zona di AWS atterraggio come parte del tuo progetto di migrazione. Una zona di destinazione è un AWS ambiente multi-account che funge da base per i carichi di lavoro con confini organizzativi, controlli di governance e struttura degli account prima dell'arrivo di qualsiasi carico di lavoro. AWS Transform analizza l'inventario delle migrazioni e i requisiti aziendali per consigliare un'unità organizzativa (OU) e una struttura degli account, applicare le politiche di controllo dei servizi (SCP) consigliate e generare e and/or distribuire l'infrastruttura come codice (IaC). Ciò che in genere richiede settimane di pianificazione e configurazione manuali, AWS Transform può essere completato in un'unica conversazione.
L'agente della zona di atterraggio automatizza due fasi:
-
Configurazione della base: stabilisce la struttura principale della zona di atterraggio: AWS Control Tower, unità organizzative fondamentali e account principali.
-
Progettazione degli account Workload: progetta e crea unità organizzative e account per i carichi di lavoro in base alle ondate di migrazione, alle unità aziendali e ai requisiti di separazione degli ambienti.
AWS Transform supporta sia ambienti greenfield (nessuna zona di atterraggio esistente) che ambienti brownfield (unità organizzative e account esistenti già implementati). Negli scenari dismessi, AWS Transform rileva la struttura organizzativa esistente e consiglia solo le modifiche necessarie per colmare le lacune rispetto alle AWS best practice, senza dover iniziare da zero o eseguire un'analisi manuale delle lacune.
Configurazione del connettore
Prima che l'agente possa effettuare il provisioning delle risorse, è necessario collegarlo all'account di gestione dell'organizzazione. L'agente della zona di atterraggio richiede un Account AWS connettore di destinazione con le autorizzazioni per:
-
Configurare AWS Control Tower
-
Crea unità organizzative e account
-
Configurare le politiche di controllo dei servizi (SCP)
Quando approvi la richiesta del connettore, concedi le autorizzazioni di AWS trasformazione a:
-
Fornisci e gestisci l'infrastruttura delle zone di atterraggio nella destinazione Account AWS e nella regione. Ciò include le autorizzazioni per i seguenti elementi, limitate alle risorse contrassegnate con
CreatedBy:AWSTransformeATWorkspace:{workspace-id}laddove applicabile:-
Operazioni sui bucket S3 (creazione, lettura, scrittura, eliminazione) per i bucket che iniziano con
transform-vmware-landing-zone- -
CloudFormation implementazioni degli stack e gestione dei set di modifiche per gli stack delle zone di atterraggio
-
AWS Operazioni della Control Tower (gestione delle zone di atterraggio, attivazione delle linee di base e dei controlli)
-
AWSGestione delle organizzazioni (creazione e gestione di unità organizzative, creazione di account e trasferimento di account)
-
Gestione delle politiche di controllo dei servizi (SCP) tramite AWS Control Tower
-
AWS Gestione degli artefatti relativi al provisioning di Service Catalog
-
Quando si crea il connettore, si specifica una destinazione. Regione AWS Questa regione deve essere la stessa della tua torre di controllo domestica. Per ulteriori informazioni sulle regioni di Control Tower, vedi Come Regioni AWS lavorare con AWS Control Tower.
All'inizio della configurazione della zona di atterraggio, AWS Transform recupera la configurazione del connettore e presenta l'ID dell'account di gestione AWS dell'organizzazione e la regione di destinazione per la conferma. Per ulteriori informazioni, consulta AWS Trasforma i connettori.
Importante
Dipendenza dalla regione del centro di identità IAM: AWS Transform richiede AWS IAM Identity Center (IAM Identity Center), il che significa che la regione del connettore deve corrispondere sia alla regione principale della AWS Control Tower che alla regione del centro di identità IAM. Se IAM Identity Center è già configurato nell'organizzazione, l'inizializzazione di AWS Control Tower fallirà se il connettore è destinato a una regione diversa. Per ulteriori informazioni, consulta Considerazioni per i clienti di IAM Identity Center nella AWS Control Tower User Guide.
Configurazione della base
La fase di configurazione della fondazione stabilisce l'infrastruttura principale della zona di atterraggio utilizzando AWS Control Tower. Quando AWS Control Tower configura una zona di atterraggio, fornisce automaticamente una serie di risorse gestite nel tuo account di gestione che costituiscono la base di governance per l'intera AWS organizzazione:
-
Root: l'elemento principale di primo livello che contiene tutte le unità organizzative presenti nella zona di atterraggio.
-
Unità organizzativa di sicurezza: creata automaticamente da Control Tower. Contiene due account condivisi: l'account Log Archive (registrazione centralizzata e immutabile per tutte le attività delle AWS API e le modifiche alle risorse nell'organizzazione) e l'account Audit (accesso in sola lettura a tutti gli account per la revisione della sicurezza e della conformità). Questi account non possono essere rinominati o sostituiti dopo la configurazione iniziale.
-
Controlli obbligatori (guardrail): Control Tower applica automaticamente controlli preventivi e investigativi in tutta l'organizzazione per far rispettare le politiche di governance di base. Questi non possono essere disabilitati.
-
Directory IAM Identity Center: Control Tower crea una directory nativa per il cloud con gruppi preconfigurati e accesso Single Sign-on per gli utenti della zona di atterraggio. Per ulteriori informazioni, consulta IAM Identity Center. AWS
Control Tower utilizza CloudFormation StackSets per distribuire e gestire queste risorse in modo coerente su tutti gli account e le regioni dell'organizzazione. Non è necessario modificare o eliminare le risorse gestite da Control Tower al di fuori dei metodi supportati, poiché così facendo la zona di atterraggio potrebbe entrare in uno stato sconosciuto.
Convenzione sulla posta elettronica dell'account
AWS richiede un indirizzo email univoco per ogni account. Queste e-mail ricevono notifiche importanti per l'account. AWS Transform utilizza l'indirizzamento plus per generare email di account univoche da una singola casella di posta.
Formato: prefix+account-name@domain
Fornisci un prefisso (ad esempioaws-admin) e un dominio (ad esempioacme.com) e AWS Transform ricava automaticamente tutte le email dell'account. Ad esempio:
-
Account di controllo:
aws-admin+audit@acme.com -
Account Log Archive:
aws-admin+log-archive@acme.com -
Account Sandbox:
aws-admin+sandbox@acme.com
In situazioni dismesse, AWS Transform esamina le email degli account esistenti per dedurre la convenzione plus-addressing già in uso e propone di continuare con lo stesso schema.
Struttura di base consigliata
Sulla base delle AWS migliori pratiche, AWS Transform consiglia la seguente struttura organizzativa di base. Puoi personalizzarlo prima della creazione.
| OU | Scopo | Account |
|---|---|---|
| Sicurezza | Registrazione e monitoraggio degli audit centralizzati. L'isolamento di questi servizi in account dedicati è progettato per aiutare a mantenere l'audit trail separato dai team addetti al carico di lavoro. | Audit, archivio dei log |
| Infrastruttura | Rete condivisa (Transit Gateway, VPN), DNS e servizi comuni. Si consiglia di centralizzarli per ridurre la duplicazione e offrire al team di rete un unico posto per gestire la connettività. | Nessuno (creato vuoto) |
| Sandbox | Sperimentazione da parte degli sviluppatori con limiti di spesa e accesso limitato. Consigliato per dare agli sviluppatori uno spazio per sperimentare senza rischiare le risorse di produzione. | Sandbox |
| Carichi di lavoro | Contiene unità organizzative secondarie di produzione e Non-Production, opzionalmente, regolamentate. Gli account Workload vengono progettati nella fase successiva in base ai requisiti di migrazione. | Nessuno (creato vuoto) |
Nota
L'unità organizzativa di sicurezza con account Audit e Log Archive viene creata come parte della configurazione di base di Control Tower. Le unità organizzative di Infrastructure, Sandbox e Workloads vengono create separatamente dopo la conferma della struttura.
Negli scenari dismessi, AWS Transform confronta le fondamenta esistenti con questa struttura consigliata e riporta solo le lacune. Ad esempio: «La tua fondazione dispone di unità operative di sicurezza e infrastruttura ma nessuna unità organizzativa Sandbox».
Policy di controllo dei servizi (SCP)
Gli SCP sono barriere di autorizzazione a livello di organizzazione che stabiliscono le autorizzazioni massime per tutti gli account dell'organizzazione. AWS Non concedono l'accesso, ma definiscono limiti che nessuno nell'account può superare, nemmeno gli amministratori dell'account.
Come parte dell'implementazione della Control Tower, i guardrail di base vengono applicati automaticamente. AWS Transform consiglia inoltre SCP aggiuntivi progettati per contribuire a rafforzare la postura dell'organizzazione. Questi si basano sulle AWS migliori pratiche per una zona di atterraggio minima praticabile.
Gli SCP possono essere applicati alle unità organizzative di Infrastructure, Sandbox e Workloads. L'unità organizzativa di sicurezza è gestita da Control Tower e non può essere presa di mira dagli SCP tramite questo strumento.
Importante
L'unità organizzativa di sicurezza è un'unità organizzativa di base gestita da Control Tower. Non è possibile aggiungere account, SCP o risorse tramite l'agente della zona di atterraggio.
Negli scenari dismessi, AWS Transform verifica quali SCP sono già applicati e consiglia solo quelli che potrebbero colmare le lacune.
Implementazione delle fondamenta
Una volta completata la progettazione della base, scegli come implementare:
-
Implementa per me: AWS Transform distribuisce le unità organizzative, gli account e gli SCP di base nella tua organizzazione. AWS
-
Lo installerò per conto mio: AWS Transform genera artefatti IaC (Infrastructure as Code) da scaricare nel formato preferito (vedi). Formati IaC
-
Progetta prima gli account del carico di lavoro: salta l'implementazione e passa alla fase di progettazione dell'account del carico di lavoro. Puoi distribuire tutto insieme in un secondo momento.
Inizializzazione della Control Tower
Se AWS Transform rileva che AWS Control Tower non è ancora inizializzato nell'organizzazione, fornisce all'utente un collegamento alla pagina della console AWS Transform. La generazione dell'operazione nel collegamento creerà uno CloudFormation stack per avviare Control Tower. Il processo creerà questo stack nella CloudFormation console per la regione di destinazione. Una volta completata la creazione dello stack, AWS Transform continua con la distribuzione.
Progettazione dell'account Workload
Nella fase di progettazione dell'account del carico di lavoro, AWS Transform progetta l'unità organizzativa e la struttura degli account per i carichi di lavoro delle applicazioni in base all'inventario delle migrazioni, ai requisiti aziendali e alle preferenze di separazione degli ambienti.
Contesto di pianificazione della migrazione
AWS Transform recupera i dati dalla fase di pianificazione della migrazione, compresi i piani di ondata, le mappature tra server e applicazioni e il contesto condiviso. Se sono disponibili dati di pianificazione della migrazione, AWS Transform visualizza un riepilogo e chiede di confermarlo o modificarlo. Se non sono disponibili dati sulla pianificazione della migrazione, AWS Transform pone direttamente le domande di individuazione.
Individuazione
AWS Transform pone domande per comprendere i requisiti del carico di lavoro. Puoi saltare qualsiasi domanda. Gli argomenti includono:
-
Numero di unità aziendali o team che utilizzano AWS
-
Industria e qualsiasi framework applicabile (HIPAA, SOC2 PCI-DSS, FedRAMP)
-
Se i carichi di lavoro gestiscono dati sensibili (PII, PHI, finanziari)
-
Preferenze di separazione dell'ambiente (dev/test/staging/prod come account separati o condivisi)
-
Requisiti di isolamento del carico di lavoro
-
Applicazioni aziendali e relative finalità
-
Raggruppamento dei server in applicazioni
-
Esigenze di monitoraggio e allocazione dei costi (per unità aziendale, progetto, ambiente)
-
Crescita prevista nei prossimi 12-24 mesi
-
Preferenza per la strategia dell'account (app singola per account, raggruppata o basata sull'ambiente)
Struttura del carico di lavoro proposta
In base alle tue risposte e ai dati di pianificazione della migrazione, AWS Transform propone un'unità organizzativa e una struttura degli account nell'ambito dell'unità organizzativa Workloads. La proposta include il ragionamento alla base di ogni decisione di progettazione.
AWS Transform segue questi principi di progettazione:
-
Tutti i server in un'ondata di migrazione vengono indirizzati allo stesso account: le ondate non possono essere suddivise tra account. Si tratta di una limitazione del rehost durante l'esecuzione di un'ondata.
-
Se richiedi ambienti isolati, AWS Transform crea un'unità Workloads/Production organizzativa Workloads/Non-Production secondaria.
-
Se vengono identificati i framework applicabili, AWS Transform crea Workloads/Regulated delle unità organizzative secondarie. Workloads/Standard
-
Se più unità aziendali richiedono una governance diversa, AWS Transform crea unità organizzative specifiche per unità di business in Workloads.
-
Le applicazioni con dati critici o sensibili ricevono un'unica app per account. In questo caso, ti potrebbe essere chiesto di ripetere il tuo piano d'ondata.
-
Le applicazioni strettamente collegate con dipendenze condivise sono raggruppate in un unico account.
Ogni account proposto include: nome, scopo, unità organizzativa di destinazione e unità aziendale. AWS Transform mostra la convenzione di denominazione utilizzata (ad esempio,<business-unit>-<environment>-<workload>).
È possibile rivedere e modificare la struttura proposta prima che AWS Transform applichi le modifiche. Dopo l'applicazione, puoi iterare, apportando ulteriori modifiche finché non sei soddisfatto.
Configurazione del carico di lavoro SCP
Dopo aver creato la struttura del carico di lavoro, AWS Transform presenta gli SCP disponibili e chiede se desideri applicarne qualcuno alle unità organizzative del carico di lavoro. È possibile selezionare quali SCP applicare e a quali OU. AWS Transform applica gli SCP e mostra l'albero organizzativo aggiornato con una tabella riassuntiva degli SCP.
Distribuzione del carico di lavoro
Una volta completata la progettazione del carico di lavoro, scegli come distribuire:
-
Implementa per me: AWS Transform distribuisce le unità organizzative, gli account e gli SCP del carico di lavoro nella tua organizzazione. AWS
-
Lo installerò per conto mio: AWS Transform genera artefatti IaC da scaricare nel formato preferito (vedi). Formati IaC
Formati IaC
Quando si sceglie la distribuzione automatica, AWS Transform genera artefatti Infrastructure as Code nei seguenti formati:
-
AWS Cloud Development Kit (AWS CDK)— TypeScript progetto per l'implementazione programmatica dell'infrastruttura.
-
HashiCorp Terraform: genera modelli HCL ( HashiCorp Configuration Language) per la gestione delle risorse della zona di atterraggio.
-
Landing Zone Accelerator (LZA) — File YAML di configurazione basati su LZA Universal Configuration versione 1.1.0. Questi modelli pronti per l'azienda funzionano con Landing Zone Accelerator per creare ambienti con più account. AWS AWS I file generati includono impostazioni preconfigurate per la governance, la struttura organizzativa e il networking in linea con le migliori pratiche. AWS Per saperne di più, consulta LZA Universal Configuration.
Nota
Quando si esegue la distribuzione tramite la pipeline Landing Zone Accelerator (LZA), l'account AWS Transform e l'installazione LZA devono trovarsi nella stessa organizzazione. AWS La distribuzione avrà esito negativo in caso di mancata corrispondenza tra gli ID dell'organizzazione utilizzati in Transform e LZA. AWS Per informazioni su come configurare l'installazione LZA utilizzando Organizations, vedi AWS Installazione basata sulle organizzazioni.
Dopo aver selezionato un formato, AWS Transform genera gli artefatti e li rende disponibili per il download.
Per verificare che il file scaricato non sia stato danneggiato o manomesso, genera e scarica un checksum, quindi confrontalo con un hash generato localmente utilizzando:
openssl dgst -sha256 -binary <file.zip> | base64
Processo di approvazione della distribuzione
Le richieste di distribuzione nelle zone di destinazione richiedono un'approvazione esplicita prima dell'esecuzione. Quando invii una richiesta di distribuzione, questa viene indirizzata automaticamente agli approvatori autorizzati tramite la scheda Trasforma le approvazioni. AWS
Gli approvatori CloudFormation esaminano i modelli e le configurazioni delle zone di destinazione. Solo gli utenti con il ruolo di amministratore in AWS Transform possono approvare le richieste di distribuzione. Ogni invio attiva un nuovo ciclo di revisione e le distribuzioni procedono solo dopo aver ricevuto la conferma.
Se un approvatore rifiuta la tua richiesta, contattalo direttamente per discutere delle modifiche necessarie. Il sistema tiene traccia di tutte le decisioni di approvazione a fini di audit e conserva la cronologia delle implementazioni.
Etichetta le risorse della zona di atterraggio
AWS Transform contrassegna automaticamente tutte le risorse generate "CreatedBy": "AWSTransform" insieme agli ID di definizione ed esecuzione per scopi di tracciamento.
Tag automatici
Tutte le risorse della zona di atterraggio ricevono i seguenti tag:
-
CreatedBy— AWS Transform -
ATWorkspace— Identificatore dell'area di lavoro
Nota
Se la migrazione fa parte del AWS Migration Acceleration Program (MAP 2.0), è possibile includere il tag MAP richiesto: Key: map-migrated Value: migMPE_ID (dove MPE_ID è l'identificatore di valutazione del portafoglio di migrazione). Il tag MAP viene richiesto durante la fase di configurazione del connettore. AWS Transform applica questi tag durante l'implementazione della zona di atterraggio.
Annullamento delle modifiche
È possibile rimuovere solo gli elementi non distribuiti. Una volta implementati, un'unità organizzativa o un account non possono essere rimossi tramite l'agente della zona di atterraggio.
Quando si rimuovono degli elementi, l'ordine è importante: è necessario rimuovere i bambini prima dei genitori:
-
Rimuovi prima gli account (tramite email).
-
Rimuovi gli SCP dalle unità organizzative.
-
Rimuovi unità organizzative secondarie: un'unità organizzativa non può essere rimossa se ha ancora account o unità organizzative annidate.
Risorse correlate
