Une organisation utilise AWS Organizations avec une OU racine et une OU enfant. Le SCP de l'OU racine autorise toutes les actions sur toutes les ressources. Le SCP de l'OU enfant autorise toutes les actions DynamoDB et Lambda et refuse toutes les autres actions. Il existe un compte nommé vendor-data dans l'OU enfant. Un utilisateur IAM dans ce compte possède la politique IAM AdministratorAccess mais reçoit AccessDenied lorsqu'il tente de lancer une instance EC2. Quelle modification doit être apportée pour que l'utilisateur IAM puisse lancer des instances EC2 dans le compte vendor-data ?

Les SCP (Service Control Policies) dans AWS Organizations sont des gardes-fous qui définissent les permissions maximales pour tous les utilisateurs et rôles dans les comptes affectés. Un SCP attaché à une OU enfant ou à un compte individuel peut restreindre davantage les permissions définies par les SCP de l'OU parente, mais ne peut jamais les étendre. Dans ce scénario, le SCP de l'OU enfant refuse toutes les actions autres que DynamoDB et Lambda. Même si l'utilisateur IAM a la politique AdministratorAccess, le SCP de l'OU enfant prévaut et bloque les actions EC2. Pour permettre le lancement d'instances EC2, le SCP de l'OU enfant doit être modifié pour explicitement autoriser les actions EC2. Attacher une politique IAM à l'utilisateur ne fonctionnera pas car les SCP sont évalués en premier et limitent les permissions maximales. Créer un nouveau SCP et l'attacher au compte vendor-data ou à l'OU racine ne résoudrait pas le problème car le SCP de l'OU enfant continuerait de refuser les actions EC2.