Service control policy examples

Service control policies (SCPs) are meant to be used as coarse-grained guardrails, and they don't directly grant access. The administrator must still attach identity-based or resource-based policies to IAM principals or resources in your accounts to actually grant permissions. The effective permissions are the logical intersection between the Service control policy/Resource control policy and an identity policy or the Service control policy/Resource control policy and a resource policy. You can get more details about SCP effects on permissions here.

A Service control policy (SCP), when attached to an organization, organization unit or an account offers a central control over the maximum available permissions for all accounts in your organization, organization unit or an account. As an SCP can be applied at multiple levels in an organization, understanding how SCPs are evaluated can help you write SCPs that yield the right outcome.

The service control policies in this repository are shown as examples. You should not attach SCPs without thoroughly testing the impact that the policy has on accounts. Once you have a policy ready that you would like to implement, we recommend testing in a separate organization or OU that can be represent your production environment. Once tested, you should deploy changes to more specific OUs and then slowly deploy the changes to broader and broader OUs over time.

The SCP examples in this repository use a deny list strategy, which means that you also need a FullAWSAccess policy or other policy that allows access attached to your organization entities to allow actions. You still also need to grant appropriate permissions to your principals by using identity-based or resource-based policies.