Een organisatie gebruikt AWS Organizations met acht lidaccounts en verwacht maximaal 20 accounts. Het bedrijf draait alle workloads op AWS en heeft een nieuw beveiligingsbeleid dat vereist: • Geen enkel account draait workloads in een VPC binnen dat account. • Alle workloads moeten worden gestart in subnets van een centraal beheerde VPC die toegankelijk is voor alle accounts. • Geen enkel account mag de applicatieresources van een ander account binnen de gedeelde VPC wijzigen. • De centraal beheerde VPC moet zich bevinden in een bestaand account genaamd Account-A binnen de organisatie. Een CloudFormation-template in Account-A creëert de VPC en meerdere subnets en exporteert de subnet-ID's als stack outputs. Welke oplossing voltooit de setup om aan deze vereisten te voldoen?

De correcte oplossing is het gebruik van AWS Resource Access Manager (AWS RAM) om de VPC-subnets in Account-A te delen met de lidaccounts. AWS RAM maakt het mogelijk om AWS-resources, zoals VPC-subnets, te delen tussen AWS-accounts binnen dezelfde AWS Organizations-organisatie. Dit voldoet aan de eis dat alle workloads in subnets van een centraal beheerde VPC moeten worden gestart en dat Account-A de VPC bevat. Lidaccounts kunnen vervolgens workloads starten in deze gedeelde subnets, zonder dat ze de applicatieresources van andere accounts kunnen wijzigen. De andere opties zijn minder geschikt: Het gebruik van Fn::ImportValue in elk lidaccount is niet voldoende, omdat dit alleen verwijst naar de subnet-ID's en niet de toegang tot de subnets zelf regelt. Een transit gateway is bedoeld voor netwerkconnectiviteit tussen VPC's, niet voor het starten van workloads direct in subnets van een andere VPC. VPC peering zou connectiviteit bieden, maar het starten van workloads in subnets van een andere VPC via peering is geen standaardpatroon en zou complexiteit toevoegen die niet nodig is met AWS RAM.