Service Control Policies that survive contact with engineering

Cloud Security

Most SCPs we inherit are either toothless or so aggressive that the platform team disabled them in a Friday outage. Here's the set we land on for every multi-account AWS org.

By Arjun Raghavan, Security & Systems Lead, BIPI · March 6, 2024 · 7 min read

A retail client had 60 AWS accounts and zero SCPs when we walked in. Their reasoning was that SCPs had broken a deploy in 2021 and nobody had touched them since. Two years later, an intern in a sandbox account had created an IAM user with a static access key, the key got committed to a public GitHub gist, and the attacker spun up 800 GPU instances in eu-north-1 before billing alerts caught it. SCPs would have stopped both the user creation and the eu-north-1 launch.

Service Control Policies are the only thing in AWS that the root user of a member account cannot override. They are the seatbelt of multi-account governance. Used poorly, they break legitimate work. Used well, they prevent entire categories of incident without anyone noticing they are there.

Build the OU structure first, policies second

We standardise on five top-level OUs: Security, Infrastructure, Workloads, Sandbox, and Suspended. Workloads splits into Production and NonProduction. Each OU gets policies attached at its level, and member accounts inherit the union. Trying to attach SCPs directly to accounts is how you end up with 200 policy attachments and no one able to reason about effective permissions.

The deny list every org should run

Six SCPs cover most of the common-sense controls. Deny IAM user creation outside the Security OU. Deny disabling CloudTrail, Config, and GuardDuty. Deny leaving the organisation. Deny use of regions outside an explicit allow-list. Deny launching EC2 instances without IMDSv2. Deny removal of mandatory tags on production resources.

• Deny iam:CreateUser and iam:CreateAccessKey outside Security OU
• Deny cloudtrail:StopLogging, config:DeleteConfigurationRecorder, guardduty:DeleteDetector
• Deny organizations:LeaveOrganization on every account
• Deny ec2:RunInstances when MetadataHttpTokens is not required
• Deny use of any region not in the allow-list, with a NotAction carve-out for global services
• Deny s3:PutBucketPublicAccessBlock that disables block public access

What breaks, and how to soften the landing

Region restrictions break Route53, IAM, CloudFront, and Support. Always carve those out with a NotAction. The IMDSv2 enforcement breaks legacy AMIs and some third-party marketplace images; we deploy it in audit mode for 30 days first by routing the deny to CloudTrail-only via a tag check. The IAM user deny breaks every team that has not yet adopted SSO; pair the policy with a 60-day SSO migration deadline and an exception OU.

An SCP that ships in audit mode for a month catches every break before it becomes an outage. Going straight to enforce is how the platform team learns to hate you.

Sandbox OUs deserve different rules

Engineers need a place to break things. Sandbox accounts get a budget cap, a region restriction to a single cheap region, a deny on data transfer above a threshold, and an automatic 30-day nuke. They do not get the full production deny list. The signal we want here is fast learning, not airtight isolation. The Suspended OU gets the inverse: deny almost everything except read APIs, used for accounts pending offboarding.

Test policies in a fork, not in prod

AWS now has IAM Access Analyzer policy validation and the SCP simulator, both of which are decent. We still maintain a fork of the production OU structure in a parallel test org, attach the new policy there, and run the platform team's standard deploy pipeline against it. About one in three new policies fail this test in a way the simulator missed, usually because of a service-linked role we did not anticipate.

SCPs are slow to change and that is a feature. Treat them like firewall rules for the entire organisation: code-reviewed, version-controlled, deployed through a pipeline, and rolled back the same way. The orgs that get this right have boring incident reports.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.