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 | Provisioning self-service /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 di incidenti e 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 modifiche basato su RFC per gli aggiornamenti IAM e a livello di unità organizzativa dell'applicazione. SCPs 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 con ciascuno di questi account OUs è soggetta alla specifica modalità AMS offerta da tali account di base. OUs È 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 e 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 la funzionalità di base di AMS. OUs 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 best practice di OUs base basate su AWS per gestire in modo logico gli account utilizzando Service Control Policies (). SCPs Questo serve come modo per applicare il framework di governance con ogni modalità AMS. Qualsiasi barriera di governance e sicurezza (sotto forma di SCPs) applicata al sistema di base viene applicata OUs anche automaticamente. custom/child OUs SCPs È possibile richiederne di aggiuntivi per il bambino. OUs È 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
Il termine «restrittivo» implica la possibilità di richiedere politiche personalizzate in merito OUs, che vengono approvate da AMS per garantire che non interferiscano con le capacità di AMS di fornire l'eccellenza operativa. case-by-case Per un elenco dettagliato dei guardrail AMS, consulta AMS Guardrails nella guida per l'utente.
