AWS Just Doubled SCP Limits. In a World Where AI Is Helping Attackers Move Faster Than Ever, That Matters.
AWS just pushed an update that deserves more attention than it will probably get. AWS Organizations now supports up to 10 Service Control Policies per node, up from 5, and the maximum size of each SCP has doubled from 5,120 to 10,240 characters. It is automatically available to every AWS organization with no action required, across all commercial regions, GovCloud, and China.
So what does that actually mean, and why should you care?
Service Control Policies are the preventive guardrails that sit above IAM in your AWS organization and define the absolute ceiling of what any identity in any member account can do, regardless of what their individual IAM policies permit:
- Block compute in regions you do not operate in.
- Prevent anyone from disabling CloudTrail or GuardDuty.
- Deny public S3 access at the organizational level.
- Restrict IAM user creation without approval.
- Deny AWS account(s) from leaving your Organization
- Deny the ability to spin up infrastructure in regions you don’t work in
- Deny terminations of critical production infrastructure
- Etc.
These controls do not alert you after something goes wrong. They make certain actions impossible before they start.
That distinction matters more than ever right now. Earlier this year, Sysdig’s Threat Research Team documented an attack on an AWS environment where a threat actor went from initial access to full administrative privileges in under 10 minutes, with strong evidence pointing to large language models being used to automate reconnaissance, generate malicious code, and make real-time decisions throughout the operation. Around the same time, Amazon’s own threat intelligence team published findings on a years-long Russian state-sponsored campaign where attackers harvested credentials from misconfigured customer environments and moved laterally into critical infrastructure networks across North America and Europe. In both cases, AWS was explicit: the root cause was not a weakness in AWS itself. It was environments without the structural controls in place to slow an attacker down or contain the damage once something got in.
Preventive guardrails at the account level are exactly what changes that equation. When an SCP blocks a category of actions organization-wide, it does not matter how fast an attacker moves or what tools they are using. The action simply does not execute.
The old limits created real friction for teams trying to build comprehensive controls. Experienced practitioners found ways to work around them. The most common approach was stacking SCPs across OU layers, since controls inherit down the hierarchy, which allowed more policies to be in effect on a given account but required adding OU depth that was often architectural noise rather than intentional design. Others consolidated multiple logical controls into a single policy document to stay within the 5 policy limit, which worked but produced policies that were difficult to read, harder to audit, and genuinely risky to modify. Some teams minified their JSON entirely, stripping whitespace and shortening statement IDs just to squeeze more coverage into the character limit.
In the early days of Control Tower, the security-forward engineers I worked alongside gravitated toward OrgFormation for exactly this reason. It was an open-source IaC tool that managed the entire AWS Organizations structure through code, and because the OU hierarchy was fully declarative, experienced teams could architect around the SCP limits far more cleanly than the Control Tower console allowed at the time. Control Tower has matured significantly since then, and tools like the Landing Zone Accelerator make it the right answer for most enterprise environments today. But the fact that skilled practitioners were building workarounds to a quota limitation tells you something about how real that constraint was.
Doubling both limits means organizations can now write policies the way the security model actually calls for them. Separate concerns in separate policies. Readable by the next engineer who inherits the environment. Room to add controls as compliance requirements evolve without restructuring your OU hierarchy just to stay within a quota.
If you are running workloads on AWS and the foundational multi-account governance layer is not in place, this is a good moment to revisit that. The tooling is better than it has ever been, and the threat landscape is not getting simpler.
Happy to talk through what that looks like for your environment.
