Una grande azienda ha riscontrato un aumento inatteso degli addebiti di Amazon RDS e Amazon DynamoDB. L'organizzazione utilizza AWS Organizations con molti account di sviluppo e produzione. Non esiste una strategia di tagging applicata a tutti gli account, sebbene le linee guida richiedano che l'infrastruttura venga distribuita con AWS CloudFormation e tag coerenti. La direzione impone che tutte le tabelle DynamoDB e le istanze RDS esistenti e future includano i valori del centro di costo e dell'ID progetto. Quale approccio dovrebbe raccomandare l'architetto di soluzioni per soddisfare questi requisiti?

L'opzione corretta affronta sia le risorse esistenti che quelle future. Tag Editor è lo strumento appropriato per aggiungere tag in blocco a risorse esistenti, inclusi RDS e DynamoDB, per il centro di costo e l'ID progetto. La creazione di tag di allocazione dei costi è fondamentale per il tracciamento dei costi. Per le risorse future, l'applicazione di Service Control Policies (SCP) è il metodo più efficace e centralizzato in AWS Organizations per imporre la presenza di tag specifici al momento della creazione delle risorse, negando le operazioni API che non includono i tag richiesti. Le opzioni errate presentano diverse carenze: La prima opzione non impone il tagging per le nuove risorse e l'attesa di 24 ore per la propagazione dei tag di allocazione dei costi non aggiunge i tag alle risorse esistenti. La seconda opzione si basa sulla notifica e su una soluzione Lambda reattiva, che non è un metodo proattivo per imporre il tagging e potrebbe non essere scalabile o immediato come un SCP. La quarta opzione non affronta il tagging delle risorse esistenti e la modifica dei ruoli federati è meno efficace e più complessa rispetto all'uso di SCP per l'imposizione a livello di organizzazione.