Meerdere ontwikkelingsteams implementeren productieworkloads in een gedeeld AWS-productieaccount. Onlangs hebben leden van één ontwikkelingsteam een EC2-instantie beëindigd die toebehoorde aan een ander team. Ontwikkelaars gebruiken SAML-federatie via AWS Organizations om rollen aan te nemen. U moet voorkomen dat ontwikkelaars instanties beheren die toebehoren aan andere teams, terwijl ze wel hun eigen instanties kunnen beheren. Welke strategie voldoet aan deze vereisten?

De correcte optie maakt gebruik van AWS STS sessietags en IAM beleid om fijne controle te implementeren. Door een 'DevelopmentUnit' attribuut als sessietag door te geven tijdens SAML-federatie, kan het IAM-beleid van de aangenomen rol controleren of de gebruiker acties uitvoert op resources die overeenkomen met hun eigen ontwikkelingsunit. De 'deny'-actie met 'StringNotEquals' voor zowel de resourcetag als de principal tag voorkomt dat ontwikkelaars resources beheren die niet aan hun unit toebehoren, terwijl ze wel hun eigen resources kunnen beheren. De eerste optie is ongeschikt omdat SCP's op OU-niveau niet fijnmazig genoeg zijn om individuele resource-acties binnen een gedeeld account te beheren op basis van tags. De derde optie is onjuist omdat een 'allow'-actie in een SCP op de root OU te permissief zou zijn en niet de benodigde restricties zou bieden. De vierde optie is onjuist omdat het gebruik van afzonderlijke IAM-beleidsregels per ontwikkelingsunit niet schaalbaar is en niet direct de controle biedt op basis van tags van de resource en de principal in een gedeeld account.