Service control policy examples - AWS Organizations

Service control policy examples

The example service control policies (SCPs) displayed in this topic are for information purposes only.

Before using these examples

Before you use these example SCPs in your organization, do the following:

  • Carefully review and customize the SCPs for your unique requirements.

  • Thoroughly test the SCPs in your environment with the AWS services that you use.

    The example policies in this section demonstrate the implementation and use of SCPs. They're not intended to be interpreted as official AWS recommendations or best practices to be implemented exactly as shown. It is your responsibility to carefully test any deny-based policies for its suitability to solve the business requirements of your environment. Deny-based service control policies can unintentionally limit or block your use of AWS services unless you add the necessary exceptions to the policy. For an example of such an exception, see the first example that exempts global services from the rules that block access to unwanted AWS Regions.

  • Remember that an SCP affects every user and role, including the root user, in every account that it's attached to.

  • Remember that an SCP does not affect service-linked roles. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs.

Tip

You can use service last accessed data in IAM to update your SCPs to restrict access to only the AWS services that you need. For more information, see Viewing Organizations Service Last Accessed Data for Organizations in the IAM User Guide.

Each of the following policies is an example of a deny list policy strategy. Deny list policies must be attached along with other policies that allow the approved actions in the affected accounts. For example, the default FullAWSAccess policy permits the use of all services in an account. This policy is attached by default to the root, all organizational units (OUs), and all accounts. It doesn't actually grant the permissions; no SCP does. Instead, it enables administrators in that account to delegate access to those actions by attaching standard AWS Identity and Access Management (IAM) permissions policies to users, roles, or groups in the account. Each of these deny list policies then overrides any policy by blocking access to the specified services or actions.

Contents