Une organisation utilise AWS Organizations avec huit comptes membres et anticipe un maximum de 20 comptes. L'entreprise exécute toutes les charges de travail sur AWS et a une nouvelle politique de sécurité exigeant : • Aucun compte n'exécute de charges de travail dans un VPC au sein de ce compte. • Toutes les charges de travail doivent être lancées dans des sous-réseaux d'un VPC géré de manière centralisée et accessible par tous les comptes. • Aucun compte ne peut modifier les ressources d'application d'un autre compte au sein du VPC partagé. • Le VPC géré de manière centralisée doit résider dans un compte existant nommé Account-A dans l'organisation. Un modèle CloudFormation dans Account-A crée le VPC et plusieurs sous-réseaux et exporte les ID de sous-réseau en tant que sorties de pile. Quelle solution complète la configuration pour satisfaire ces exigences ?

L'option correcte est d'utiliser AWS Resource Access Manager (AWS RAM) pour partager les sous-réseaux VPC d'Account-A avec les comptes membres. AWS RAM permet de partager des ressources AWS, y compris des sous-réseaux, entre comptes AWS au sein d'une organisation ou avec des comptes spécifiques. Cela répond à l'exigence que toutes les charges de travail soient lancées dans des sous-réseaux d'un VPC géré de manière centralisée et accessible par tous les comptes, tout en garantissant qu'aucun compte ne modifie les ressources d'application d'un autre compte car chaque compte membre déploie ses propres charges de travail dans les sous-réseaux partagés. L'utilisation de Fn::ImportValue dans chaque compte membre n'est pas une solution car Fn::ImportValue ne peut importer des valeurs qu'au sein du même compte ou de la même région, et non entre comptes. La création d'une Transit Gateway ou l'établissement de peering VPC permettraient la connectivité, mais ne permettraient pas aux comptes membres de lancer directement des charges de travail dans les sous-réseaux du VPC d'Account-A ; elles fourniraient uniquement un chemin réseau.