Gli sviluppatori in più account AWS della tua Organizzazione possono creare VPC e avviare istanze EC2 in una singola Regione. Ogni istanza EC2 scarica circa 1 TB/giorno da S3, causando elevati costi di trasferimento dati inter-account e di NAT gateway, oltre ai costi di calcolo. L'azienda desidera applicare in modo proattivo modelli architetturali approvati (ad esempio, utilizzando gateway endpoint) tra gli account degli sviluppatori senza rallentare la velocità degli sviluppatori, e farlo in modo economicamente vantaggioso. Quale soluzione soddisfa al meglio questi requisiti?

La risposta corretta è la migliore perché AWS Service Catalog consente di pubblicare e gestire un catalogo di prodotti IT approvati, inclusi VPC con endpoint S3 gateway (che riducono i costi di trasferimento dati e NAT gateway) e tipi di istanze EC2 approvati. Condividendo questo portfolio con gli account degli sviluppatori e limitando le loro autorizzazioni IAM per utilizzare solo Service Catalog, si garantisce che gli sviluppatori implementino solo architetture conformi e ottimizzate per i costi, senza rallentare la loro velocità. I vincoli di avvio assicurano che le risorse siano create con configurazioni approvate. Le opzioni errate: Le SCP e i template CloudFormation richiedono agli sviluppatori di usare CloudFormation, che potrebbe rallentarli, e le SCP non applicano proattivamente modelli architetturali specifici come gli endpoint S3 gateway. I budget AWS sono reattivi (monitorano e reagiscono ai costi), non proattivi nell'applicazione di modelli architetturali. Terminare le istanze interromperebbe il lavoro degli sviluppatori. AWS Config è reattivo (rileva e corregge dopo la creazione), non proattivo nell'applicazione di modelli architetturali approvati prima del provisioning.