How SCPs Restrict EC2 Instance Types Without Affecting Root User

A company uses AWS Organizations with multiple accounts. The central IT team wants to restrict the use of specific EC2 instance types across all accounts to control costs. Which approach should the team use?

⚠ Common exam trap

It's easy for candidates to confuse IAM policies with SCPs, thinking that attaching a deny policy to the root user or individual IAM users is sufficient, but SCPs are the only mechanism that can enforce restrictions across all principals in an AWS Organization account, including the root user.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a service control policy (SCP) that denies the ec2:RunInstances action for prohibited instance types and apply it to the organization.

Service control policies (SCPs) are the correct mechanism to centrally restrict permissions across all accounts in an AWS Organization. By creating an SCP that denies the ec2:RunInstances action for specific instance types and applying it to the organization (or relevant OUs), the central IT team can enforce this restriction globally, preventing any IAM principal in any account from launching prohibited instance types, regardless of their IAM permissions.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use AWS Budgets to send alerts when costs exceed a threshold.
Why it's wrong here
AWS Budgets only monitors spend and sends notifications; it cannot block an EC2 instance type from launching in any account. It is tempting because cost control is the stated goal, and budgets would be correct for alerting on overspend. Restricting instance types requires service control policies applied through AWS Organizations.
✗
Configure Amazon CloudWatch Events to detect launches and terminate instances.
Why it's wrong here
CloudWatch Events can react to instance launches, but termination happens after the instance exists, so the restriction is reactive and bypassable. It is tempting because event-driven automation is a familiar pattern, and it would suit remediation of non-compliant resources. Preventing specific instance types requires service control policies in AWS Organizations.
✗
Attach an IAM policy to each account's root user to deny the ec2:RunInstances action for certain instance types.
Why it's wrong here
IAM policies attached to a root user cannot restrict service actions across member accounts; root users are not constrained by identity policies in that way. Service control policies in AWS Organizations set the maximum permissions for all principals in each account, which is the mechanism that enforces instance-type restrictions organisation-wide.
✓
Create a service control policy (SCP) that denies the ec2:RunInstances action for prohibited instance types and apply it to the organization.
Why this is correct
An SCP applied at the organisation root enforces the instance-type restriction across every member account, satisfying the requirement to govern all accounts centrally. The ec2:RunInstances deny with a condition on instance type blocks launches regardless of each account's IAM permissions, since SCPs define the maximum available permissions.

Go deeper

How SCPs Restrict EC2 Instance Types Without Affecting Root User

Why each option matters

Option-by-option breakdown

Related to this question