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à.
Scelta di MALZ singoli o multipli MALZs
La tabella seguente fornisce alcune considerazioni di alto livello sulla decisione tra una singola landing zone multiaccount (MALZ) e più zone di atterraggio multi-account (ad esempio, due landing zone multi-account, Prod e non-Prod). In generale, la scelta dipende dalle esigenze individuali, dai requisiti legali e dalle pratiche operative.
| Entità | Singola landing zone AMS | Zone di atterraggio multiple (due o più) |
|---|---|---|
Costo base |
Inferiore, ottimizzato a circa 3.000 dollari al mese. |
Più alto, un costo aggiuntivo di circa 3.000 dollari per ambiente. |
Fatturazione |
Fattura unica, grazie a un unico account di fatturazione/gestione. |
Fattura separata per ogni landing zone con più account. Attualmente AWS Org non supporta account multigestione con un'unica fattura. |
Portabilità delle istanze riservate esistenti () RIs |
Bassa. Al momento, AWS RIs non è convertibile tra più account di fatturazione. Riutilizzeresti l'esistente RIs per una landing zone con più account. |
Inferiore. Dovresti riutilizzare e distribuire RIs su tutte le landing zone con più account. |
Sconti per livelli di prodotto |
Elevato. Vedi Sconti Volume. |
Basso. Vedi Sconti Volume. |
Sovraccarico di configurazione iniziale (in base alle project/migration tempistiche) |
Basso. Integrazioni con Active Directory, networking e Single Sign-On (SSO) una sola volta. |
Elevato. Eseguiresti Active Directory, integrazione di rete e integrazioni SSO per ogni landing zone. Ciò potrebbe causare potenziali ritardi a qualsiasi progetto di migrazione. |
Configurabilità dei servizi comuni |
Sforzi ridotti. Configurate common/shared servizi come DNS, backup, monitoraggio, registrazione ecc. |
Grandi sforzi. È necessaria una pianificazione aggiuntiva per stabilire dove saranno collocati l'infrastruttura o i servizi comuni. Il traffico che attraversa più gateway di transito (TGWs) in ciascuna landing zone potrebbe comportare costi aggiuntivi. |
Scalabilità |
Medio. AMS ha attualmente un limite pratico di 150 account per landing zone con più account. Più team o fornitori che eseguono applicazioni sullo stesso account potrebbero avere accesso a stack di proprietà di team diversi. Questa limitazione può essere mitigata controllando l'accesso a stack specifici dell'applicazione a ServiceNow livello (integrando l'applicazione AMS ServiceNow Connector e utilizzando i tag). Chiedi ai responsabili della fornitura tecnica di AMS (TDMs) o agli architetti cloud () come implementarloCAs. |
Elevato. Possibilità di sfruttare più landing zone multi-account per distribuire i conti ottenendo al contempo un livello di segregazione dell'account o dell'applicazione. La gestione di un numero elevato di account potrebbe comportare spese operative o di costo. |
Rischio operativo |
(Dipende) Basso. Integrazione operativa e prontezza una sola volta. Meno possibilità di deviazioni dei processi. |
(Dipende) Basso. Molteplici attività operative e di integrazione. La deriva in più zone di atterraggio nel corso del periodo potrebbe comportare rischi operativi. |
Più regioni AWS |
Singola regione AWS. La landing zone multi-account AMS è limitata a una singola regione AWS. Per estendersi su più regioni AWS, utilizza più landing zone multi-account. |
Più regioni AWS. Con più zone di destinazione con più account, puoi avere ogni MALZ distribuito in una regione e interconnetterli utilizzando il peering del gateway di transito (TGW). |
Migrazione o portabilità dell'account |
Sì. È possibile spostare account da un'unità organizzativa all'altra all'interno della stessa AWS Organization. |
No. AMS non supporta la migrazione di un account tra zone di destinazione, ovvero tra AWS Organizations. I carichi di lavoro possono raggiungere tutte le zone di atterraggio con Transit Gateway (TGW) o peering VPC. |
Gestione delle modifiche |
Medio. Apportare modifiche distruttive a componenti comuni come TGW, Active Directory (AD) o in uscita (egress) può influire su tutti i carichi di lavoro in una landing zone con più account. Tuttavia, le modifiche ai componenti gestiti da AMS vengono testate internamente e inserite negli aggiornamenti periodici. |
Basso. Apportare modifiche distruttive a componenti comuni come TGW, AD o Outbound (egress) può influire solo sui carichi di lavoro in quella specifica landing zone multi-account. |
Controlli dei dati e degli accessi |
(Dipende) Controllo ridotto se desideri connetterti a reti ADs e reti locali diverse per carichi di lavoro Prod e Non-Prod. Anche la federazione SAML, i domini TGW e i gruppi di sicurezza () possono aiutare a implementare i controlli richiesti. SGs |
(Dipende) Controllo elevato se desideri connetterti a diverse reti ADs e locali per carichi di lavoro Prod e Non-Prod. Utilizza zone di atterraggio separate per requisiti di conformità rigorosi. |
Conformità e sicurezza |
(Dipende) Basso se esistono esigenze di conformità rigorose per separare completamente i carichi di lavoro materiali da quelli non materiali. Sono in atto controlli preventivi e investigativi standard AMS. |
(Dipende) High As Multi-Account landing zone potrebbe contribuire a soddisfare rigorosi requisiti di conformità separando completamente i carichi di lavoro materiali da quelli non materiali. Sono in atto controlli preventivi e investigativi standard AMS. |
Raccomandazione: senza una rigorosa conformità o una necessità multiregionale, iniziare con una singola landing zone AMS multi-account consentirebbe di raggiungere un buon equilibrio tra costi, sicurezza, eccellenza operativa e complessità della migrazione. Puoi sempre configurare una landing zone aggiuntiva, in caso di vincoli relativi all'account o all'attività.
