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à.
Landing zone singola con più account vs. landing zone con più account FAQs
Alcune domande frequenti quando si sceglie di configurare una singola landing zone con più account o più zone di atterraggio con più account:
D1: Posso iniziare con una sola landing zone con più account e passare a più landing zone con più account, se si incontrano limiti di account o vincoli aziendali?
R: Sì. Puoi scegliere di configurare un'altra landing zone con più account in qualsiasi momento:
Sarà necessario configurare un nuovo account di pagamento per la fatturazione (attualmente AWS non supporta account con più paganti in una singola organizzazione AWS).
La creazione della base Multi-Account Landing Zone richiede fino a 2 settimane di lead time una volta compilato il questionario sulla zona di atterraggio multi-account.
Ogni landing zone con più account comporta un'aggiunta di circa 3.000 USD al mese per un costo di esercizio.
Per creare un nuovo MALZ sarà necessaria l'integrazione di N/W, AD, DNS e SSO.
Eventuali piani Reserved Instances (RIs) e Cost Saving dovranno essere configurati per la nuova landing zone multi-account (non RIs sono trasferibili).
La landing zone multi-account AMS non supporta la migrazione di un account tra account di landing zone con più account, ad esempio tra AWS Orgs. Tuttavia, è possibile spostare le applicazioni da un account all'altro utilizzando metodi di migrazione standard.
Q2: Qual è l'approccio di AMS a MALZ updates/changes all' underlying/shared infrastruttura e quantifica il rischio per i clienti? Fornisci dettagli sulle garanzie incluse nel processo. In che modo i clienti si rendono conto che MALZ non updates/changes avrà alcun impatto sui clienti? Esistono misure che il Cliente deve adottare per prevenire interruzioni?
R: AMS segue una rigorosa metodologia di modifica utilizzando strumenti interni che ci consentono di definire, rivedere, pianificare ed eseguire modifiche agli ambienti dei clienti.
Il processo di rilascio degli aggiornamenti prevede revisioni del codice, test di integrazione, implementazione in ambienti gamma e beta e tempi di preparazione aggiuntivi e test in ambienti beta e gamma prima del rilascio negli ambienti dei clienti. Tutte le versioni includono procedure di rollback e sono attentamente monitorate dal team addetto ai rilasci e dal team che ha creato e richiesto la modifica. L'ambito delle versioni è limitato agli stack di proprietà e forniti da AMS. In media, eseguiamo almeno una release a settimana.
Inoltre:
Gli SLA AMS sono applicabili. In base alla descrizione del servizio AMS, qualsiasi incidente sorto a seguito di un'attività di manutenzione a infrarossi condivisa rispetterebbe lo SLA valido per la risoluzione o i crediti.
I Clienti non richiedono misure preventive speciali per prevenire l'interruzione dell'infrastruttura comune. I clienti dispongono di autorizzazioni di sola lettura per gli account AWS Org o Core OU, quindi non possono apportare modifiche distruttive all'ambiente principale MALZ. Tutte le richieste dei clienti all'infrastruttura Core richiedono la revisione e l'approvazione di AMS.
I clienti possono testare determinate modifiche a livello di organizzazione, SCPs/Roles ad esempio a livello di account individuali non di produzione, prima di propagarle a livello di unità organizzativa dell'app. La roadmap di AMS prevede l'utilizzo di più APP OUs (secondo trimestre 2020), il che ridurrebbe ulteriormente il rischio di apportare alcune modifiche a livello di ORG. Il team MALZ ha già rilasciato un'unità organizzativa separata per gli account «Build Mode», per garantire una chiara separazione della proprietà del cliente e dei controlli separati.
La maggior parte di queste sono modifiche che consentono ad AMS di gestire il carico di lavoro in modo efficace ed efficiente e non influiscono necessariamente sul carico di lavoro dei clienti. Laddove AMS ritenga che una modifica condivisa dell'infrastruttura possa avere un impatto sul carico di lavoro dei clienti, viene quindi allineata alla finestra di modifica dei clienti.
Raccomandazione di alto livello, inizia con più zone di atterraggio con più account se:
Se ti aiuta a raggiungere una conformità specifica.
Se è necessario utilizzare Multi-Region.
Se disponi di carichi di lavoro locali ADs e reti diverse per carichi di lavoro diversi da Prod/Material quelli non presenti. Prod/Non-Material workloads, to clearly segregate b/w
