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à.
Tipi di modalità e account in AMS
Le modalità AWS Managed Services (AMS) possono essere definite come modalità di interazione con il servizio AMS nell'ambito del framework di governance specifico per ciascuna modalità. Sono riportate le differenze tra le zone di atterraggio, la multi-account landing zone o MALZ e la single-account landing zone o SALZ.
Nota
Per dettagli sull'implementazione delle applicazioni e sulla scelta della modalità AMS corretta, consulta Modi e applicazioni o carichi di lavoro AMS.
Per i casi d'uso reali delle diverse modalità, consulta Casi d'uso nel mondo reale per le modalità AMS
La tabella seguente fornisce le descrizioni delle modalità per servizio AMS.
| Funzionalità AMS | modalità RFC (precedentemente modalità CM standard) /OOD* | modalità Direct Change | AWS Service Catalog | Self-service provisioning//modalità sviluppatore | Gestito dal cliente |
|---|---|---|---|---|---|
| Configurazione della zona di atterraggio | MALZ e SALZ | MALZ e SALZ | MALZ e SALZ | ||
| Gestione delle modifiche | Pianificazione delle modifiche, revisione delle modifiche manuali e registrazione delle modifiche | Uguale alla modalità RFC per modifiche ad alto rischio come IAM o gruppi di sicurezza | Nessuno | ||
| Registrazione, monitoraggio, guardrail e gestione degli eventi | Sì (risorse supportate) | No | |||
| Gestione della continuità | Sì (risorse supportate) | Non applicabile/No | No | ||
| Gestione della sicurezza | Controlli di sicurezza a livello di istanza e controlli a livello di account | Controlli a livello di account | Controlli a livello di AWS Org | ||
| Gestione delle patch | Sì | Non applicabile/No | No | ||
| Gestione degli incidenti e dei problemi | SLA di risposta e risoluzione per le risorse supportate da AMS | SLA di risposta per le risorse risultanti | No | ||
| Creazione di report | Sì | No | |||
| Gestione delle richieste di assistenza | Sì | Solo richieste di supporto | No | ||
* Operations On Demand (OOD) offre un'offerta ai clienti che utilizzano la modalità RFC per gestire le modifiche tramite risorse dedicate. Per ulteriori dettagli, consultate il catalogo di offerte di Operations on Demand e contattate il vostro responsabile della fornitura di servizi cloud (CSDM).
Nota
Modalità Self-Service Provisioning in AMSe Modalità AMS Advanced Developer possono entrambi sembrare adatti per un'applicazione con un'architettura complessa radicata nei servizi AWS nativi. Quando si progettano carichi di lavoro, si fanno compromessi tra eccellenza operativa e agilità, in base al contesto aziendale. Questo è un buon modo di pensare alla selezione della modalità SSP o della modalità Sviluppatore per l'applicazione. La selezione può cambiare anche in base alla fase SDLC dell'applicazione. Ad esempio: quando l'applicazione è pronta per la produzione, la modalità SSP potrebbe essere l'opzione più appropriata a causa dei guardrail AMS più rigidi in questa modalità. I guardrail vengono applicati sotto forma di controlli preventivi come il controllo delle RFC-based modifiche per gli aggiornamenti IAM e gli SCP a livello di unità organizzativa dell'applicazione. Le decisioni aziendali possono stabilire le priorità di progettazione. È possibile ottimizzare per aumentare la flessibilità per i proprietari delle applicazioni nella fase di «pre-produzione», a scapito della governance e del supporto operativo.
Architettura MALZ e modalità AMS associate
AMS multi-account landing zone (MALZ) offre la possibilità di effettuare automaticamente il provisioning degli account delle applicazioni (o account delle risorse) nelle unità organizzative (OU) predefinite: Customer Managed OU, Managed OU o Development OU. L'infrastruttura fornita negli account applicativi creati in ciascuna di queste unità organizzative è soggetta alla modalità AMS specifica offerta da tali unità organizzative di base. È comune trovare una combinazione di due o più modalità nello stesso account dell'applicazione. Ad esempio: la modalità RFC e la modalità SSP possono coesistere in un account gestito AMS che ospita un'architettura di pipeline composta da API Gateway e Lambda per le funzioni di attivazione ed EC2, S3 e SQS per l'ingestione e l'orchestrazione. In questo caso, la modalità SSP si applicherebbe a Lambda e API Gateway.
La Figura 1 illustra come vengono offerte diverse modalità tramite le unità organizzative di base di AMS. Quando si richiede un nuovo account di applicazione in AMS, è necessario selezionare l'unità organizzativa per l'account.
Architettura MALZ e modalità AMS associate
.png)
AMS sfrutta le unità organizzative di base basate sulle best practice di AWS per gestire in modo logico gli account utilizzando le Service Control Policies (SCP). Questo serve come modo per applicare il framework di governance con ciascuna modalità AMS. Qualsiasi barriera di governance e sicurezza (sotto forma di SCP) applicata alle unità organizzative di base viene applicata automaticamente anche alle unità organizzative. custom/child È possibile richiedere SCP aggiuntivi per le unità organizzative secondarie. È importante comprendere che gli account delle applicazioni non sono la stessa cosa delle modalità. Le modalità vengono applicate all'infrastruttura fornita all'interno degli account e definiscono le responsabilità operative tra AMS e i clienti.
Figura 1: Architettura MALZ e modalità AMS associate
Nota
«Restrittivo» implica la possibilità di richiedere politiche personalizzate per queste unità organizzative, che vengono approvate da AMS caso per caso per garantire che non interferiscano con le capacità di AMS di fornire l'eccellenza operativa. Per un elenco dettagliato dei guardrail AMS, consulta AMS Guardrails nella guida per l'utente.
