How do I manage the SCP character size limit or number of SCPs for an AWS Organization?

Resolution

The AWS Organizations service has a hard limit of five SCPs per account. If you attached too many SCPs to an account, OU, or root, then you might receive the ConstraintViolationException error.

The maximum size for SCPs is 5,120 characters which includes any extra spaces or line breaks. For more information, see Quotas and service limits for AWS Organizations.

Use the following methods to reduce the number of SCPs directly attached to an account to allow for additional restrictions in an Organization:

• Consolidate multiple SCPs into a single SCP
• Use SCP inheritance in the organizational unit's (OU) hierarchy

Consolidate multiple SCPs into a single SCP

Use this method if the size of the SCP is less than the policy size limit of 5,120 bytes.

Follow these recommendations to reduce the SCP size limit:

• Review your SCPs and remove any duplicate permissions. For example, put all actions with the same Effect and Resource elements in one statement instead of in multiple statements.

• Remove any unnecessary elements such as the statement ID (Sid) because that element counts against the total number of characters allowed.

• Use wildcards for actions with the same suffixes or prefixes. For example, the actions ec2:DescribeInstances, ec2:DescribeTags, and ec2:DescribeSubnets can be combined as ec2:Describe*.

  Important: Wildcards can create additional security risks in an Organization. Wildcards grant broad permissions, often for multiple resources. Wildcards can grant unintended permissions for AWS Identity and Access Management (IAM) identities (users, groups, roles) in your Organization. Don't use this method to AWS Lambda functions to apply permissions. Be sure that you use wildcards only after you've performed due diligence. It's a best practice to avoid granting wildcard permissions in IAM policies.

Use SCP inheritance in the OU hierarchy

The five SCPs limit doesn't include SCPs that are inherited from the parent. You can use the inheritance structure of SCPs for OUs and member accounts to distribute SCPs across multiple OUs. For example, to deny IAM users or roles with your Organization's member accounts access to AWS services, set up your Organization structure like this:

Root    <--- 1 full access SCP (1 directly attached)   |
OU1     <--- 1 full access, 4 deny SCPs (5 directly attached, 1 inherited)
 |
OU2     <--- 1 full access, 4 deny SCPs (5 directly attached, 6 inherited)
 |
Account <--- 1 full access, 4 deny SCPs (5 directly attached, 11 inherited)
 |
Bob

Permissions filtered by SCPs at each node of an Organization hierarchy are the intersection of directly attached and inherited SCPs. In this example, the IAM user Bob in a member account has full access minus the services denied by the 12 deny-based SCPs. This approach is scalable because the maximum number of nested OUs that you can have within your Organization hierarchy is five.

For more information, see SCP evaluation.

Related information

Get more out of service control policies in a multi-account environment