Question

Difficulty: MediumMulti-Account Governance and Organizational Structure

An enterprise is using AWS Organizations to manage its multi-account environment. The security team wants to restrict developers in the Sandbox organizational unit (OU) to launching Amazon EC2 instances only in the us-east-1 and us-west-2 Regions, and prevent them from launching GPU-based instance types (such as p or g families). The solution must prevent non-compliant resource creation even if local administrators have full administrative access within their accounts. Which strategy meets these requirements with the least administrative overhead?

  1. Attach a Service Control Policy (SCP) to the Sandbox OU that denies ec2:RunInstances if the requested Region is not us-east-1 or us-west-2, or if the instance type matches p* or g*. Configure local IAM policies within the sandbox accounts to grant developers the required ec2:RunInstances permissions.Answer
  2. B
    Attach a Service Control Policy (SCP) to the Sandbox OU that allows ec2:RunInstances only in us-east-1 and us-west-2 for instance types other than p* or g*. Remove local IAM policies from the sandbox accounts to let the SCP directly control developer access.
  3. C
    Configure an IAM role in a central governance account with the required Region and instance type restrictions. Set up web identity federation to allow developers in the sandbox accounts to assume this role directly and launch resources.
  4. D
    Define an IAM permissions boundary restricting Region and instance type usage in the management account. Use AWS Resource Access Manager (RAM) to share this permissions boundary with the Sandbox OU, and configure AWS RAM to automatically apply it to all IAM users and roles in the member accounts.

Answer

Attach a Service Control Policy (SCP) to the Sandbox OU that denies ec2:RunInstances if the requested Region is not us-east-1 or us-west-2, or if the instance type matches p* or g*, and configure local IAM policies within the sandbox accounts to grant developers the required permissions.
The correct strategy uses a Service Control Policy (SCP) with an explicit Deny effect applied to the Sandbox organizational unit. In AWS Organizations, SCPs act as guardrails that define the maximum permissions for member accounts. An explicit Deny in an SCP overrides any Allow permissions granted by local IAM policies, including those of administrators. However, since SCPs do not grant permissions directly, local IAM policies must still be created within the member accounts to grant developers the ability to run instances.

Step-by-Step Solution

1
Analyze the requirements for restricting EC2 regions and instance types across multiple sandbox accounts, ensuring the restrictions apply even to local administrators.
Identify that Service Control Policies (SCPs) are the primary mechanism in AWS Organizations to enforce maximum permission boundaries across accounts, including for local administrators.
SCPs apply to all users and roles in member accounts, including the root user and administrators, making them ideal for enforcing compliance constraints centrally.
2
Determine the correct policy structure for the SCP.
Construct an SCP with a Deny effect that blocks ec2:RunInstances when the region is not us-east-1/us-west-2, or when the instance type matches GPU families.
Explicit deny statements in SCPs override any local allow policies, ensuring compliance without restricting local administrative flexibility for other actions.
3
Define local IAM roles or policies in the member accounts to grant the actual permissions.
Create local IAM policies that allow developers to run instances.
SCPs do not grant permissions directly; they only restrict the maximum permissions. Local IAM policies are still required to grant the permissions to the identity.

Key Concept

Service Control Policies (SCPs) act as guardrails in AWS Organizations to limit the maximum permissions in member accounts, but they do not grant permissions directly; local IAM policies are still required.
Rate this question