What are AWS Service Control Policies (SCPs)

AWS Service Control Policies or AWS SCPs are a set of rules that allow you to set permissions on the AWS resources that are being used for all AWS accounts within your AWS Organization.

If you want to make use of an AWS SCP, then you’ll need to create an AWS organization in your AWS account. After that, you can enable Service Control Policies and attach them to an AWS account or Organizational Unit (OU).

Now you can create your own AWS SCPs, but how can you be so certain whether our AWS SCP is implemented properly, and if it’s effective or not?

This guide explains what AWS Service Control Policies (SCPs) are and shows you how to create, activate and test an AWS SCP. So If you are in a position where you have responsibility for the AWS Cloud infrastructure, then you must read this post!

Table of Contents

What is an AWS SCP?

An AWS Service Control Policy (SCP) is a set of rules you can create to control access to your AWS resources within the AWS accounts in your AWS Organization.

Why you should use AWS Service Control Policies (SCPs)

When your organization grows bigger and you need to manage more AWS accounts for different teams and workloads, it becomes harder to maintain rules and guardrails strictly via IAM.

IAM allows you to control users and roles within an account, but it becomes harder to manage permissions and policies when you have to deal with multiple roles on different AWS accounts.

That’s where SCPs become utterly important because it acts as an extra layer of security that overrules the permission that is set on IAM resources.

The biggest benefit is that you have better control over what an account can and cannot use and therefore reduce costs dramatically, especially when the number of accounts is growing over time.

To give an example; developers on their development account are spinning up very large EC2 instance types for testing because they have no idea which EC2 instance to use. With an SCP you have control over which EC2 instances are allowed to be used by that specific account.

Organizational Units (OUs) are groups of AWS accounts that can be managed like a single unit. That means that if you apply an SCP on an OU, the whole group of AWS Accounts activates these permissions as configured in the SCP.

To show you an example, here is what an AWS Organization with multiple AWS accounts under OUs would look like.

AWS Organizations account setup with OU and SCPs

The OUs are categorized in the type of workload that is hosted on these accounts within an OU. The application OU contains the actual business application accounts separated between test and production.

The development OU contains the development and sandbox accounts where developers can test their changes and experiment with new features and services. As you can imagine these accounts typically need fewer restrictions compared to the accounts in the application OU.

Since the accounts are categorized in the type of workload via OUs it becomes a lot easier to manage and restrict actions on multiple AWS accounts. But be aware that if you plan on making various SCPS, you’re allowed to attach a maximum of 5 SCPs to a root, OU, or account.

Number of policies that you can attach to an entity

How to create and activate an AWS SCP

Now that you know what an AWS SCP is including the benefits and features, we’ll go deeper into the material and you’ll learn how you can create a service control policy and activate it in your AWS Organization in the following 4 steps.

1. Create an AWS Organization

To be able to start using AWS Service Control Policies you need to enable AWS Organizations first in the AWS Console

AWS Console: create an AWS Organization

Click on the orange Create an organization button to create an AWS Organization with all features enabled. You’ll want all features enabled because that allows you to configure and delegate SCPs. Once you’ve created an AWS Organization you’ll see the organization structure in the AWS Console

AWS console: AWS Organizations organizational structure

From this overview, you can manage and control how the AWS accounts are organized and grouped together using OUs.

2. Enable Service Control Policies in AWS organizations

Now that we’ve created an organization, you’ll notice that all the policies are disabled by default.

There you need to enable AWS Service Control Policies in the AWS console by clicking on the button Enable service control policies.

AWS console: AWS Organizations enable Service Control Policy

After enabling service control policies a new SCP is added automatically called FullAWSAccess. This is a policy that’s managed by AWS and can’t be modified.

This SCP allows access to every operation and is attached to the Root of the AWS organization, this means that all AWS accounts inherit this SCP.

Without this SCP the accounts are useless since you can’t perform any action on them anymore, so it’s important to keep it attached to the Root OU.

3. Create an AWS Service Control Policy

From within the Service control policies tab in the AWS console, you can create a new policy.

AWS console: AWS Organizations create new Service Control Policy

You can add a policy name and description to describe what the SCP is supposed to restrict or allow. Service Controle Policies are structured in JSON format and use a similar syntax to that used by AWS IAM.

The AWS console provides an editor that you can use to easily add statements to your policy. For this example, we’ll add a deny rule for the AWS service: AWS Shield service.

AWS console: AWS Organizations create new Service Control Policy deny statement

Now you can click the Create policy button to create the SCP.

Note: keep in mind that the maximum size of an SCP can only be 5120 bytes, see Quoatas for AWS Organizations.

4. Activate and attach a Service Control Policy

Now that the SCP is created it’s not activated yet. You need to attach it to an OU or account to activate the rule and restrict access. In order to do so, you need to go to the targets tab of the rule and click attach.

AWS console: AWS Organizations Service Control Policy rule target tab

Then you can pick the account you wish to apply the SCP with the deny AWS Shield statement.

AWS console: AWS Organizations attach Service Control Policy to a target AWS account

The SCP will immediately be in effect on your chosen AWS account or OU. This means every IAM user or role doesn’t have access to call any AWS Shield actions on behalf of all AWS resources.

How to test an AWS SCP

Now that you’ve seen how to create an SCP using the basic example in the previous section, you want to customize it even further by making more complex rules.

Adding more complex rules to an existing organization calls for testing before you apply it to for example a production account.

Because you can imagine that if you make a mistake by for example denying certain actions or services that are used by important users or services that it can have a devastating effect since SCPs overrule all other permissions within the scope of an AWS account.

Therefore to test out a new SCP, you’re advised to create a new OU and attach the SCP to it. Don’t attach an untested SCP directly to the root of your organization!

This will apply the rules directly to all accounts in your AWS organization. You should move your accounts into the new OU that you created (one at a time), starting with developer and sandbox accounts. Then Gradually move on to staging and production accounts.

During this process of moving the accounts into the new OU, you should notify the members of the organization that you’ve activated your new rules. Then you can actively receive feedback if they get denied to a specific service. Then it’s up to you or your team to check if you want to revert a specific rule or keep it.

Tools like AWS CloudTrail and the service last accessed data in IAM are good ways to determine whether a specific AWS Service that you wish to block is being used in your target AWS account.

Best practices for creating a Service Control Policy

You can configure the SCPs in your AWS Organization to work as either of the following:

A deny list – actions are allowed by default, and you specify what services and actions are prohibited
An allow list – actions are prohibited by default, and you specify what services and actions are allowed

To stay flexible and be prepared for any new AWS services in the future it’s best practice for most organizations to manage a deny list instead of an allow list. The reason is that it requires less maintenance and you don’t need to update it when AWS announces a new AWS service (which happens often).

By default, the organization has the FullAWSAccess SCP enabled on the root OU, which means all accounts have access to every service. We can use that as a starting point to create new SCPs with explicit deny rules.

Conclusion

Cloud security remains an important aspect of distributed computing, and AWS Service Control Policies provide a way to implement best practices in an easy manner.

By adopting AWS Service Control Policies you will likely reduce the number of unwanted running AWS services, data breaches, and other catastrophic events that have plagued companies without these restrictions.

Now that you know how Service Control Policies work within AWS, you will be well prepared to create your own Service Control Policies and use them in your AWS accounts.

What are AWS Service Control Policies (SCPs) – 2022 guide