AWS SCP — Mastering AWS Service Control Policies

Service control policies (SCP) are organizational policies that you can use to manage different permissions in your organization. Using SCP, you can have centralized control over permissions for accounts and different departments in your organization. As a result, you can ensure that all the accounts stay within the access control limits defined by your organization through SCP.

Note that SCP policies are different from Identity and Access Management (IAM) policies. SCP policies are applied on the account level, whereas IAM policies are applied to users and roles. Also, SCP policies are not available unless all the features of AWS organizations have been enabled. Merely enabling the consolidated billing feature will not enable SCP for your organization. The below diagram will give you an idea of how organization units, accounts, and SCP work.

Today we will discuss AWS Service Control Policies in detail. We will cover some of the use cases of SCP, explain how SCP is different from IAM, how it is structured, and explore the best practices when using SCP. So, let’s start with the major use cases of SCP.

Use cases for AWS SCP

Below you’ll find typical use cases for AWS SCP:

• You want to empower your teams so they can set up and deploy only the allowed services in AWS
• You have multiple accounts in AWS, and you want to group them into different organizational units (OU)
• Your organization has multiple accounts and multiple services, and you are following a ‘one account per service’ strategy
• You have many team members who are managing the AWS infrastructure, and you want to minimize the chances of human error in infrastructure management.

Difference between AWS SCP and IAM policies

At first glance, SCP and IAM policies might look the same. Both are used to control access, and both work on the principle of least privilege access. However, the scope and application of both policies are different. Here are a few major differences between the two:

• IAM policies are applied on the user/role level. For example, Role DevManager cannot provision any EC2 instance in the region US-EAST-1. SCP policies are applied on the service level. No EC2 instance can be provisioned in the US-EAST-1 region.
• SCP makes more sense when there are multiple accounts and multiple organizational units in an organization, as the SCP refers to the accounts level. On the other hand, IAM is applied to different users and roles in an AWS account.

Both IAM and SCP complement each other. SCP control policies on the account level, whereas users in each account can define IAM policies within the boundaries of SCP limits on that account.

Examples of service control policies at work

Here are some practical examples of SCP policies at work.

• MFA is mandatory if you want to stop or terminate an EC2 instance

In this example, the SCP policy is applied to all the users and roles in the account to require multi-factor authentication before stopping or terminating an EC2 instance. See the below policy from the official AWS knowledge base:

{

“Version”: “2012–10–17”,

“Statement”: [

{

“Sid”: “DenyStopAndTerminateWhenMFAIsNotPresent”,

“Effect”: “Deny”,

“Action”: [

“ec2:StopInstances”,

“ec2:TerminateInstances”

],

“Resource”: “*”,

“Condition”: {“BoolIfExists”: {“aws:MultiFactorAuthPresent”: false}}

}

]

}

• Share resources only with certain accounts and organizations

In this example, users can share resources only with a certain organization, organizational unit, and one specific account. If you look closely at the “ram:principal” section of the policy, you will notice that the organization name is “o-12345abcdef”, organizational unit is “ou-98765fedcba”, and account number is “111111111111”.

{

“Version”: “2012–10–17”,

“Statement”: [

{

“Effect”: “Deny”,

“Action”: [

“ram:AssociateResourceShare”,

“ram:CreateResourceShare”

],

“Resource”: “*”,

“Condition”: {

“ForAnyValue:StringNotEquals”: {

“ram:Principal”: [

“arn:aws:organizations::123456789012:organization/o-12345abcdef”,

“arn:aws:organizations::123456789012:ou/o-12345abcdef/ou-98765fedcba”,

“111111111111”

]

}

}

}

]

}

Scope of AWS SCP

Here is a quick overview of the scope of the SCP policies. This is a high-level summary of where SCP policies can be applied and where they cannot be applied:

• SCP can be applied only to those users and roles which are managed by accounts that are part of any organization. SCP is not applied to resource-based policies directly.
• SCP can be applied to all the users and roles in the member account, including the account’s root user.
• SCP can only be applied to member accounts; it cannot be applied to management accounts.
• Even if SCP policies allow all the services and all actions to an account, users and roles in that account must still be allocated proper IAM permissions to access the relevant services.
• If a user or role has been given access to an action in an account, but SCP has denied the access, then the user/role will not be able to perform that action.
• SCP cannot be applied to service-linked roles in AWS

Structure of AWS SCP

The structure of the SCP policy is similar to the IAM policy. Below example explains how the SCP policy is structured.

Statement

This is the container of the whole policy. A single policy can have multiple statements.

Statement ID (Sid)

It is just a friendly name for the statement. This is optional.

Action

It specifies an action and AWS service (e.g. stop the EC2 instance).

Effect

It determines if the SCP statement will allow or deny access to the IAM users and roles. The effect will be based on the action defined in the statement. Usually, it will contain either “deny” or “allow”.

NotAction

It specifies the AWS services and actions that are exempt from this SCP policy.

Resource

It specifies the resources to which this SCP policy will be applied. It can be a role, a user, an EC2 instance, etc.

SCP Condition

It specifies the condition for which this statement will be effective (e.g. The policy will be effective if the region is US-EAST-1).

Testing and Debugging AWS Service Control Policies

Why it’s important

Testing SCP policies properly is essential because the impact of any SCP is huge. Usually, SCP policy is applied to organizational units, whole accounts, and even root accounts. Imagine what would happen if you attach an incorrect policy to the root account. That’s why it is absolutely critical to thoroughly test every SCP policy before attaching it to the actual account.

How to test

Testing and debugging SCP policies is not easy because the member accounts cannot see the SCP policies attached to them. Similarly, if a misconfigured SCP policy is attached, you cannot identify the cause, and you will keep guessing if the IAM policy or the SCP policy is the culprit.

The best way to test SCP is not to attach it to the root account of your organization without testing it on test organizational units. You will create a sample OU in which you can move some of your accounts for testing. This will help you ensure that you do not mistakenly lock your users out of required AWS services. You can use the AWS cloud trail to track the service usage at the API level. You can also check service last accessed data in IAM to see which service was used by which accounts.

You should also take advantage of the official AWS policy simulator tool at https://policysim.aws.amazon.com/. If your AWS account is part of an AWS organization, then you can test your SCP policies using this tool. However, you cannot test SCP with global condition keys.

Note that once the SCP policy is attached, it is immediately applied.

Best practices

Some of the best practices for SCP are the following:

• Use a management account for setting up the organizations. Remember that you cannot apply SCP to the management account.
• Unless you test your SCP on a temporary test OU (organizational units), do not attach any SCP policy to the root account.
• SCP policies should be applied at the OU level instead of the account level. That will make the troubleshooting easier for you.
• Enforce MFA for specific actions
• When applying SCP policies, the more restrictive policies are applied to lower levels of OU and accounts in the organization. The less restrictive policies are applied higher in the hierarchy.
• Manage a deny list instead of allow list. It will need minimum maintenance, and you will not need to update it if AWS announces a new service.
• Ensure that the users cannot disable or modify services like CloudWatch, Config, GuardDuty, CloudTrail, etc.
• Restrict AWS regions allowed in your organization for regulatory requirements or geographical proximity

Conclusion

SCP is a powerful feature from AWS in a multi-account environment. If you are using AWS organizations and you want to apply policies to different OU or accounts, then SCP is for you. Note that SCP policies complement IAM policies, so a combination of both policies will cover all the access control you need in your organization. Learning SCP is not difficult, and the best way to understand AWS services is through AWS certifications. Check out our AWS training courses which will fully prepare you for your next AWS certification.

Learn how to Master the Cloud

AWS Training — Our popular AWS training will maximize your chances of passing your AWS certification the first time.
Membership — For unlimited access to our entire cloud training catalog, enroll in our monthly or annual membership program.
Challenge Labs — Build hands-on cloud skills in a secure sandbox environment. Learn, build, test and fail forward without risking unexpected cloud bills.