AWS Just Doubled the SCP Quotas. Here's What Actually Changes.

If you’ve ever opened a pull request to add one more Service Control Policy to your Landing Zone and watched it fail with “Max Allowed SCPs for ou ‘Infrastructure’ is 5, found total 6”, you’ve felt the pressure I’m about to talk about.

On 15 May 2026, AWS quietly doubled the two headline numbers on Service Control Policies. Five attached policies per node became ten. The 5,120-character per-policy ceiling became 10,240. The rollout is automatic, available in every commercial Region, GovCloud, and the China Regions, with no Service Quotas request needed.

Read past the press release and the interesting bit shows up. The cap was never just a number on a doc page. It was a design tax, paid by every team running a serious multi-account environment. That tax just got cut in half.

Let me walk through what was actually broken, what doubling the budget changes, and the bit nobody is putting in the announcement.

What was actually broken

Five attached SCPs sounds generous until you meet the real world.

Every account, OU, and root starts with FullAWSAccess attached by default. That alone takes one slot. If you run AWS Control Tower, it attaches two more (aws-guardrails-...) on top. That’s three of your five slots accounted for before you write a line of your own policy. If you also run Landing Zone Accelerator, LZA layers in AcceleratorGuardrails1 and AcceleratorGuardrails2. That’s five. You’re done. No room for the custom guardrails your security, FinOps, compliance, and data-residency teams all wanted to own separately.

This is not theoretical. LZA issue #705 captures exactly this failure: a sample config tried to attach a third AcceleratorGuardrails3 SCP and the deploy refused with Max Allowed SCPs for ou "Infrastructure" is 5, found total 6 scps in updated list to attach. The “fix” was to remove the new guardrail and forfeit the controls.

Then there’s the 5,120-character ceiling. That sounds like a lot until you write a real region-restriction SCP. A Deny aws:RequestedRegion not in [allowed] policy with 30 allowed Regions, exemptions for the global services AWS quietly hosts in us-east-1 (CloudFront, IAM, Route 53, Support, Organizations), readable Sid values, and an explicit ARN allow-list for cross-region replication targets, blows past 5,120 quickly.

What did teams do? They stripped whitespace. They dropped Sid. They collapsed explicit ARN lists into StringLike with * wildcards, which is the JSON equivalent of “we’ll be careful, trust us”. AWS’s own re:Post knowledge base documented these tricks. The Cloud Operations blog suggested offloading restrictions to S3 bucket policies as a workaround. It worked. It was also a quiet admission that the quota was wrong.

And here’s the part that compounds: console-edited SCPs and IaC-edited SCPs are not measured the same way. The console silently strips whitespace outside quoted strings. Terraform, CDK, and CloudFormation save the document character-for-character. The same policy can be 4,900 characters in the console and blow the limit when committed to Git.

So the “5,120 limit” was, in practice, a soft suggestion in the console and a hard wall in your pipeline. Lovely.

What 10 slots and 10,240 characters actually unlock

The doubling isn’t just “more”. It changes which patterns are now viable.

Single-purpose SCPs become possible. With ten slots per OU, your Infrastructure OU can carry one SCP each for region restriction, root-user denial, IAM tampering prevention, data-residency lock, preview-service blocking, and FinOps cost guardrails, with three slots still spare for whatever you haven’t thought of yet. Each policy gets a clear owner, a clear changelog, and a CI gate of its own.

Readable JSON returns. With 10,240 characters to spend, you can write "Sid": "DenyRegionExceptForGlobalServices" instead of "Sid": "D1". You can keep explicit ARN allow-lists that IAM Access Analyzer can actually reason about. You can leave breadcrumbs in the policy for the next engineer.

Control Tower and LZA stop being a budget tax. The FullAWSAccess default plus Control Tower’s two SCPs plus LZA’s two used to consume the entire five-slot budget. Now those same defaults leave you five custom slots free. The “do we keep Control Tower or roll our own?” debate, where one of the deciding factors was “Control Tower plus the defaults eat all our SCP capacity”, just lost half its weight.

Multi-team ownership becomes governable. Five teams competing for five slots is a queue. Five teams with ten slots is a roster. Security owns one, FinOps owns one, the data team owns one, the platform team owns one. Each can iterate without the merge-conflict drama of the kitchen-sink SCP.

The 10,000-per-org pool matters at scale. Most readers won’t notice this one. But if you maintain a policy library, where templates exist for many applications even though only a subset are attached at any time, you used to ration. Now you don’t.

What this does not solve

I want to be honest about this part, because the announcement carefully isn’t.

The hardest problem in SCPs was never the slot count. It was reasoning about effective permissions. An effective SCP is the intersection of every SCP on the path from the Root through the OUs to the account. Doubling the attached count multiplies the surface area you have to reason about. Ten policies intersecting is harder to read than five, not easier.

There is still no native SCP dry-run. You can’t ask AWS “given this proposed change, what permissions would actually be removed?” You can use IAM Access Analyzer to validate syntax. You can stage in a sandbox OU. You can use third-party tooling like Account Assessment for AWS Organizations. None of that is the same as a first-class preview.

Resource Control Policies, the newer org-wide resource-perimeter sibling of SCPs, did not get this bump. RCPs are still capped at five attached and 5,120 characters. If your security model leans on RCPs for things like cross-account S3 access denial, you’re back in the old envelope.

The console-vs-SDK whitespace asymmetry is unchanged. Pipelines still get charged for every byte of whitespace. If you’re paying close to the 10,240 ceiling, format your JSON deliberately and lint it in CI.

And the failure modes get more interesting, not less. With more policies attached, the surface for unintended denials grows. The teams that benefit most from this change are also the teams that need the best SCP-testing discipline.

What I’d actually do on Monday

If I had a Landing Zone with the old kitchen-sink SCP that everyone tiptoes around, I’d start here.

First, audit which restrictions live in the merged SCP. Most of them belong to clear domains: region, root-user, IAM tampering, preview services, data residency, cost. Each is a candidate for its own policy.

Second, identify a single owner per domain. Not a committee. One name on the policy. If nobody owns it, it shouldn’t be there.

Third, move the policies into Git, one file per policy, with a CI step that runs aws accessanalyzer validate-policy --policy-type SERVICE_CONTROL_POLICY on every change. Validation isn’t dry-run, but it catches the silly mistakes before they hit Organizations.

Fourth, stand up a sandbox OU that mirrors your production OU layout. Attach policy changes there first. Run a few synthetic workloads. Check the IAM Access Analyzer findings. Then promote.

Fifth, write down which OU each policy attaches to and why. This is the artefact that survives team turnover and stops policies from drifting into the wrong scope.

None of this is new advice. The old quotas just made it harder to follow, because every “let’s split this SCP for clarity” idea ran into the 5-slot wall.

The bigger picture

I keep coming back to the observation that AWS rarely doubles quotas for purely operational reasons. When they do, it usually signals that the underlying service is being asked to do more than it was originally designed for, and the constraints are no longer protecting anything important.

SCPs started as a coarse blast-radius tool. Stop new accounts from spinning up rogue Regions. Stop the root user from doing root-user things. They’ve quietly become the place where security teams encode the actual perimeter of their organisation. The 5-slot limit was a relic of the original “few coarse rules” intent, and it had outlived its usefulness.

One thing the announcement won’t acknowledge: the bill we paid living without this for years doesn’t get refunded. The warped OU layouts engineered just to multiply attachable policies, the minified JSON with cryptic Sid values, the bucket-policy offload patterns built around the character ceiling, all of that is still in your repo. The new quotas make better designs possible. They don’t retire the old ones. That cleanup is your homework, not AWS’s.

The release is also a soft acknowledgement that the workarounds AWS itself had been recommending, the compacting and the bucket-policy offloading, were never the solution. The solution was always more headroom. Now we have it.

For platform teams, the question this week isn’t “can we now write more SCPs”. It’s “which policies should we split out of the kitchen-sink, and who owns each one going forward”. The capacity is here. The governance discipline is the part you still have to build.

One thing I’d love AWS to write up. At the scale Organizations runs, the engineering required to lift these quotas without breaking evaluation semantics or downstream tooling is non-trivial. Why did 5,120 characters and 5 attached policies hold for as long as they did? What had to change in the policy evaluator, the storage path, or the propagation model to make 10,240 and 10 safe? There has to be an awesome engineering blog post in that one. Or at least I hope so.

I hope someone else finds this useful.

Cheers.

Sources

• AWS What’s New, AWS Organizations now supports higher quotas for SCPs (15 May 2026)
• AWS Organizations quotas and service limits
• Service Control Policy syntax reference
• AWS Cloud Operations Blog: Achieving operational excellence with design considerations for AWS Organizations SCPs
• AWS Control Tower limitations and quotas
• Landing Zone Accelerator issue #705: sample configurations have too many SCPs in Infrastructure OU