An allow-list SCP replaces the default FullAWSAccess policy and permits only approved services, so everything else is implicitly denied. It's one of the strongest guardrails in AWS Organizations. But each SCP has a maximum size of 5,120 characters, and a long list of approved services can approach it.
If your allow-list is long, here's how to stay under the limit and keep it maintainable:
- Allow by service, not by action.
"s3:*"is one short entry; listing individual S3 actions multiplies the size. Put fine-grained restrictions in separate deny statements or other policies. - Split by theme across SCPs at the same level. At any one level of the organization tree, an action is allowed if any SCP attached there allows it, so two allow-list SCPs on the same OU combine. Each root, OU and account can have up to five SCPs attached.
- Remember that every level must allow. An action has to be allowed at the root, at every OU on the path, and at the account. Splitting across the same level adds up; splitting across different levels doesn't.
- Keep denies separate. Guardrails such as region restrictions read more clearly as their own deny SCPs than as exceptions inside the allow-list.
- Generate the policy from data. Keep the approved-service list in version control, render the SCP from it, and add a test that fails before the size limit is reached rather than at deployment.
Before moving an OU onto an allow-list, check CloudTrail for the services its accounts actually use. Anything missing from the list stops working the moment FullAWSAccess is removed.
More context: Organization-wide AWS guardrails and detection