Un'organizzazione utilizza AWS Organizations con otto account membro e prevede un massimo di 20 account. L'azienda esegue tutti i carichi di lavoro su AWS e ha una nuova policy di sicurezza che richiede: • Nessun account esegue carichi di lavoro in una VPC all'interno di tale account. • Tutti i carichi di lavoro devono essere avviati in sottoreti di una VPC gestita centralmente e accessibile da tutti gli account. • Nessun account può modificare le risorse dell'applicazione di un altro account all'interno della VPC condivisa. • La VPC gestita centralmente deve risiedere in un account esistente denominato Account-A nell'organizzazione. Un template CloudFormation in Account-A crea la VPC e più sottoreti ed esporta gli ID delle sottoreti come output dello stack. Quale soluzione completa la configurazione per soddisfare questi requisiti?

La soluzione corretta è utilizzare AWS Resource Access Manager (AWS RAM) per condividere le sottoreti VPC di Account-A con gli account membro. AWS RAM consente di condividere risorse AWS, incluse le sottoreti, tra account AWS all'interno della stessa organizzazione. Questo soddisfa il requisito che tutti i carichi di lavoro siano avviati in sottoreti di una VPC gestita centralmente e accessibile da tutti gli account, senza che gli account membro possano modificare le risorse di altri account. L'opzione di utilizzare un template CloudFormation con Fn::ImportValue in ogni account membro non è adatta perché gli account membro non possono avviare carichi di lavoro direttamente nelle sottoreti di un altro account in questo modo; Fn::ImportValue recupera solo valori esportati, non abilita la creazione di risorse in un account diverso. Creare un Transit Gateway non è la soluzione più diretta per questo requisito specifico di condivisione di sottoreti per l'avvio di carichi di lavoro, in quanto il Transit Gateway è più orientato alla connettività di rete tra VPC e reti on-premise, non alla condivisione di sottoreti per l'implementazione di risorse. Il VPC peering tra Account-A e ogni account membro consentirebbe la comunicazione, ma non permetterebbe agli account membro di avviare carichi di lavoro direttamente nelle sottoreti di Account-A, né sarebbe scalabile per un numero crescente di account.