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à.
Modalità e applicazioni o carichi di lavoro AMS
Considerate i requisiti operativi e di governance per le vostre applicazioni quando scegliete la modalità giusta, richiedendo un nuovo account applicativo o ospitando l'applicazione in un account applicativo esistente. La scelta della modalità AMS appropriata per ogni applicazione o carico di lavoro dipende dai seguenti fattori:
Il tipo di funzione del ciclo di vita SDLC che l'ambiente fornirà (ad esempio, sandbox con modifiche non moderate, UAT con alcune modifiche frequenti, produzione con modifiche minime e altamente regolamentata)
Le politiche di governance necessarie (applicate a livello di unità organizzativa) SCPs
Modello operativo (se desideri assumere la responsabilità operativa o desideri esternalizzarla ad AMS)
I risultati aziendali desiderati, come il tempo impiegato per operare nel cloud e il costo delle operazioni.
Nota
Per una descrizione dei tipi di modalità per servizio AMS, consulta Tipi di modalità e account in AMS.
Per i casi d'uso reali delle diverse modalità, consulta Casi d'uso nel mondo reale per le modalità AMS
La tabella seguente riporta le considerazioni chiave per i proprietari delle applicazioni per aiutarli a decidere la modalità AMS più adatta. I proprietari delle applicazioni dovrebbero includere una fase di valutazione prima della migrazione delle applicazioni per comprendere appieno quale modalità si applica alla loro applicazione specifica. Esempio: per le applicazioni basate su servizi nativi del cloud o su un'architettura serverless, l'opzione migliore potrebbe essere iniziare a creare e iterare in modalità sviluppatore e implementare l'infrastruttura come codice finale utilizzando la modalità AMS Managed — SSP. In questo caso può essere necessario un leggero rifattorizzazione per garantire che tutti i CloudFormation modelli creati per l'implementazione automatizzata soddisfino le linee guida di acquisizione stabilite da AMS. Inoltre, tutte le autorizzazioni IAM devono essere approvate da AMS Security per garantire che seguano il modello con privilegi minimi.
La modalità AMS selezionata per ospitare l'applicazione può aiutarvi a sviluppare il modello operativo cloud desiderato.
Nota
In una singola AMS Managed Landing Zone possono esistere più modelli operativi cloud in base alle diverse modalità AMS selezionate per ospitare le applicazioni.
| Problemi decisionali | Modalità CM standard/OOD* | AWS Service Catalog | Modalità Direct Change | Fornitura self-service | Modalità sviluppatore | Gestito dal cliente |
|---|---|---|---|---|---|---|
| Prontezza operativa | ||||||
| Registrazione, monitoraggio e gestione degli eventi | AMS è responsabile di tutte le infrastrutture gestite | Cliente responsabile dei Self-Service Provisioned Services (SSP) | Cliente responsabile del provisioning delle risorse utilizzando il ruolo di sviluppatore IAM esterno al sistema AMS CM | Responsabile del cliente | ||
| Gestione della continuità | Responsabilità di AMS di eseguire il piano di backup selezionato dal cliente | Cliente responsabile dei Self-Service Provisioned Services (SSP) | Cliente responsabile del provisioning delle risorse utilizzando il ruolo di sviluppatore IAM esterno al sistema AMS CM | |||
| Gestione degli accessi a livello di istanza | Gestione AMS tramite AD trust unidirezionale con dominio locale. Richiede un'infrastruttura gestita per entrare a far parte del dominio AMS | Non applicabile | Cliente responsabile del provisioning delle risorse utilizzando il ruolo di sviluppatore IAM esterno al sistema AMS CM | |||
| Gestione della sicurezza e gestione degli accessi a livello di account | Responsabilità di AMS per tutti gli account gestiti | AMS è responsabile di tutti gli account gestiti | Cliente responsabile delle risorse fornite utilizzando il ruolo di sviluppatore IAM esterno al sistema AMS CM | |||
| Gestione delle patch | Responsabilità di AMS per tutti gli account gestiti | Cliente responsabile dei Self-Service Provisioned Services (SSP) | Cliente responsabile del provisioning delle risorse utilizzando il ruolo di sviluppatore IAM esterno al sistema AMS CM | |||
| Gestione delle modifiche | Responsabilità di AMS per tutti gli account gestiti | Cliente responsabile dei Self-Service Provisioned Services (SSP) | Cliente responsabile del provisioning delle risorse utilizzando il ruolo di sviluppatore IAM esterno al sistema AMS CM | |||
| Gestione del provisioning | Prescrittiva e standardizzata per le opzioni di approvvigionamento offerte in AMS | Flessibilità di utilizzare direttamente l'API di servizio AWS per AWS Service Catalog secondo gli standard prescrittivi AMS | Flessibilità per utilizzare direttamente l'API dei servizi AWS secondo gli standard prescrittivi AMS | Flessibilità di utilizzare direttamente il servizio AWS APIs per i servizi SSP | Flessibilità di utilizzare direttamente l'API dei servizi AWS per il provisioning | |
| Gestione e audit degli incidenti | AMS è responsabile di tutti gli account gestiti | Cliente responsabile delle risorse fornite utilizzando il ruolo di sviluppatore IAM esterno ad AMS Change Management System | ||||
| GuardRails e infrastruttura condivisa (rete) e framework di sicurezza | Prescrittivo e standardizzato che sfrutta gli account AMS Core | Flessibile e personalizzato che sfrutta gli account AMS Core | ||||
| Prontezza delle applicazioni | ||||||
| Rifattorizzazione delle applicazioni | È necessaria una leggera rifattorizzazione | È necessaria una leggera rifattorizzazione (se fornita utilizzando AMS Standard CM) | Non è necessario il refactoring | |||
| Support per i servizi AWS | Limitato a quanto supportato da AMS | Non limitato | ||||
| Considerazioni aziendali | ||||||
| È ora di essere pronti all'operatività | Da tre a sei mesi | Oltre 6 mesi a seconda delle competenze operative delle applicazioni del cliente | 6-18 mesi a seconda dell'infrastruttura del cliente e delle competenze operative delle applicazioni | |||
| Costi | $$$$ | $$$ | $$ | $ | ||
| Esempi di applicazione | Server Web con stack a 3 livelli, app con requisiti di conformità e normativi | Server Web che utilizza API Gateway, applicazione containerizzata che sfrutta ECS/EKS | Iterazione/ottimizzazione su un'applicazione Data Lake che utilizza Lambda, Glue, Athena, ecc. | Applicazioni decentralizzate accounts/applications come sandbox, gestite da terze parti | ||
* Operations On Demand (OOD) offre un'offerta ai clienti che utilizzano la modalità CM Standard per gestire le modifiche tramite risorse dedicate. Per ulteriori dettagli, consultate il catalogo di offerte di Operations on Demand e contattate il vostro cloud service delivery manager (CSDM).
Nota
Il confronto dei prezzi tra la modalità SSP e la modalità Developer presuppone che vengano forniti gli stessi servizi AWS.
Confronto delle modalità AMS con gli obiettivi aziendali e IT
Come mostrato, se stai cercando un modello di governance altamente controllato e standardizzato per le tue applicazioni, le modalità Standard Change gestite da AMS, AWS Service Catalog o Direct Change sono la soluzione migliore. Se hai bisogno di un modello di governance personalizzato incentrato sull'innovazione delle applicazioni senza la necessità di una prontezza operativa, seleziona la modalità Customer Managed. Con la modalità Customer Managed, potrebbe essere necessario più tempo per rendere operative le applicazioni, in quanto spetta a te definire persone, processi e strumenti per supportare funzionalità operative come la gestione degli incidenti, la gestione della configurazione, la gestione del provisioning, la gestione della sicurezza, la gestione delle patch, ecc.
