TL;DR: AWS has doubled key Service Control Policy limits, giving platform teams more room to design granular guardrails across AWS Organizations. For teams running AWS Control Tower or multi-account landing zones, now is the right time to review policies, conditions, Amazon Bedrock model access and OU inheritance structures.
Table of Contents
On 15 May 2026, AWS announced the one change I thought was never going to happen to AWS Organizations. The number of Service Control Policies (SCPs) you can attach to a single node (Root, OU, or account) has doubled from 5 to 10. Not only that, but the maximum character size limit of each policy has doubled from 5,120 to 10,240 characters. No service quota request needed, no opt-in, no migration. It just got applied automatically across every commercial region, GovCloud, and the China regions.
SCPs set the maximum available permissions for the root user, IAM users and roles in member accounts across an AWS Organization. They act as guardrails, rather than granting permissions themselves. An action must be allowed by the role AND the SCP for it to succeed.
If you use Control Tower as part of your Landing Zone (we recommend this for all our customers) or any multi-account AWS environment, this is a feature you have been waiting for. I know personally I have spent time fighting with the previous character limit, using Json minimise to squeeze as much content as possible. This was all done to make sure Security Posture is as strong as possible within the AWS Organization.
There were always some concessions made where due to those previous limitations, rules were shifted to Identity Access Management (IAM) permissions to close the gap, but it was never a first preference.
I can only imagine the engineering that would have needed to happen behind the scenes for this to happen so massive kudos to the tam involved in getting this one live.
So, with this newfound capacity available to all users, these are the first couple of things I would be doing with my SCPs.
Review the Principal ARN conditions in policy statements
Principal ARN conditions are often one of the first places teams feel the SCP character limit. To stay within the previous limit, many policies used broader wildcards for reserved AWS management roles, pipeline roles, administrative roles and break-glass access.
With the larger policy size, it is worth reviewing these statements and asking where you can be more specific. In many cases, teams can now add more explicit ARNs, reduce wildcard use and split statements where that creates clearer, finer-grained controls.
The three common patterns used in the Service Control Policies are:
- running an explicit whitelist using Effect: Allow with an Actions list
- running an explicit blacklist using Effect: deny with an Actions list
- running an implicit whitelist using Effect: deny with a NotActions list
In all these scenarios a Principal ARN can be included with a condition “ArnNotLike” which determines whether the request should be evaluated by the policy statement.
The condition list was usually one of the areas where the character limit was felt. Wildcards would be applied to ARNs that were included in the list like the reserved AWS Management Roles, Pipeline Roles and other Administrative Roles used like Break Glass ones such as “arn:aws:iam::*:role/AWSControlTowerExecution*“.
With the increased character limit, the recommendation would be to go back and review all the policy statements and:
- Add more ARNs to the list and reduce the wildcard usage
- Split statements if it achieves finer grained controls
Create an explicit Amazon Bedrock model allow list
A lot of work we do for customers involves cost optimisation and finding areas where there is unnecessary spend. Generally, this involves looking at:
- S3 buckets that have incorrect lifecycles
- EBS Volumes that have been detached and never deleted
- Noisy applications writing to CloudWatch too much or
- Incorrect logging levels set
- Instance Right Sizing
The above is not an exhaustive list but enough to get an idea of where costs can be saved. The area where I foresee cost surprising users of AWS is letting users have free reign over what Amazon Bedrock models they can use. Amazon releases new models frequently and generally speaking the new models get more and more expensive to use. The recommendation is to create an explicit allow list for your users as a cost prevention exercise through SCP statements.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnapprovedBedrockModels",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "",
"Condition": {
"ArnNotLike": {
"bedrock:ModelId": [
"arn:aws:bedrock:::foundation-model/anthropic.claude-haiku-4-5-20251001-v1:0",
"arn:aws:bedrock:::foundation-model/anthropic.claude-opus-4-6-v1",
"arn:aws:bedrock:::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
]
}
}
}
]
}
A Principal exemption can be applied to the policy to allow certain roles to not be limited by the explicit allow list, however I prefer to have the policy applied through the Organization Unit and create a separate Account / OU path for AI exploration to have a clean line between the two purposes.
If you have not received a higher than usual bill from AWS due to Amazon Bedrock model usage, it is only a matter of time before it happens. Applying a policy like the one above will help prevent it from happening and allocate the money to go towards your next staff party instead.
Review Your OU inheritance structure
With the attachment limit being increased along with the characters, it is worth evaluating where policies live within the Organization Unit Inheritance Structure. This means any policy that is applied at a node is automatically inherited by nodes below it follows that OU path and accounts underneath.
If policies are being split, it may make sense to shift them either up or down the tree. After review there may not be any changes made, but it is worth spending time while the hood has been popped open so to speak to check.
Closing thoughts
From having discussions with our team over the last couple of years, we were almost in unanimous agreement that this change was never going to happen. When using the Control Tower service, three policies attached at a node are taken by default to support the functionality. This left users with only two attachments to play with and most implementations we came across with exhaust all five to meet their governance needs.
Personally, I think this is one of the biggest changes AWS has made and a change that has delivered incredible value to customers. Kudos once again to the team.
FAQs
What changed with AWS SCP limits?
AWS increased the number of Service Control Policies that can be attached to a root, OU or account from 5 to 10. AWS also increased the maximum SCP size from 5,120 to 10,240 characters.
Why does the SCP limit increase matter?
The increase gives platform and governance teams more room to create granular guardrails across AWS Organizations, especially in multi-account environments and AWS Control Tower landing zones.
What should teams review after the SCP quota increase?
Teams should review Principal ARN conditions, wildcard usage, Amazon Bedrock model access, OU inheritance structures and any policies that were previously compressed or shifted into IAM due to SCP limits.
How can SCPs help with Amazon Bedrock governance?
SCPs can help limit access to approved Amazon Bedrock models, supporting cost control and governance across accounts. Any policy example should be tested and validated before being applied broadly.
