← Back to Overview

AWS SCP Guardrails: Five Service Control Policies for a Secure Organization

Service Control Policies (SCPs) set boundaries in AWS Organizations that no administrator in a member account can lift. Five targeted policies are enough to prevent the most common misconfigurations: an unrestricted root user, disabled CloudTrail logging, resources in unapproved regions, exposed instance metadata and publicly accessible S3 buckets.

Back in December I showed how to restrict the AWS root user with SCPs. The accompanying GitHub repository aws-scp-examples has since grown into a small collection of security guardrails. This article walks through all five policies and what to watch for when you roll them out.

Why SCPs Are the First Line of Defense

IAM policies control what an identity may do inside an account. Anyone with administrator rights there can change those policies at will. SCPs sit one level above: they define the maximum permissions available to an account or organizational unit (OU). A deny in an SCP applies to administrators and to the member account's root user alike.

It matters just as much what SCPs don't do: they never grant permissions, they only filter them. They also don't apply to the organization's management account or to service-linked roles. That is one more reason to keep workloads out of the management account.

Five Guardrails at a Glance

Each policy in the repository addresses one concrete risk and lives in its own JSON file. You can attach them to OUs individually or in combination:

• Lock down the root user completely: root-user-block-all.json denies every action for the root user. This is the right choice for most workload accounts.
• Root user as break-glass access: root-user-basic.json only allows unlocking misconfigured S3 bucket, SQS and SNS policies and managing the root user's own MFA. Requests are additionally limited to trusted IP addresses, and the root user cannot touch other IAM users' MFA devices.
• Baseline organization security: basic-org-security-settings.json prevents CloudTrail from being stopped, deleted or reconfigured, stops accounts from leaving the organization, and blocks resources outside the approved regions. Global services such as IAM, CloudFront and Route 53 are exempt from the region restriction, as is the Control Tower execution role.
• Enforce IMDSv2: enforce-imdsv2.json blocks API calls made with credentials obtained via IMDSv1, requires IMDSv2 when launching new EC2 instances, caps the hop limit at 2 and protects the metadata settings from later changes.
• Lock S3 Block Public Access: protect-s3-account-public-access-block.json prevents changes to the account-wide S3 Block Public Access setting. Only the central administrator role from IAM Identity Center is exempt.

Design Exceptions Deliberately

A guardrail that forbids every change eventually gets in the way. That is why several policies use targeted exemptions via the aws:PrincipalArn condition key. Only the AdministratorAccess role from IAM Identity Center may change the metadata and S3 settings, and the wildcard in its ARN keeps the exemption independent of the region Identity Center runs in. The region restriction exempts the role AWS Control Tower uses to manage accounts.

In the IMDSv2 policy, the exemption is built into the logic itself: the ec2:RoleDelivery key is only present on requests signed with instance credentials. Calls from users, Lambda functions or containers without an EC2 role are therefore unaffected. A hop limit of 2 still lets containers on EC2 instances reach IMDSv2 through an extra network hop.

Roll Out SCPs Safely

Before you use the policies, replace the placeholders: the IP address 203.0.113.10/32 for break-glass access, the allowed regions and the ARNs of your administrator roles. Attach each SCP to a test OU with a non-production account first, and verify your deployment pipelines before extending it to further OUs.

Keep the AWS Organizations limits in mind, too: an SCP can hold at most 5,120 characters, and you can attach no more than five SCPs to any root, OU or account. The policies in the repository are split by topic and stay well below the size limit, so you can combine them freely.

Conclusion

Five compact SCPs close the most common gaps in an AWS organization, centrally and regardless of how carefully individual teams configure their accounts. With well-defined exceptions and a staged rollout, they stay effective without getting in the way of operations.

← Back to Overview