Skip to content

Writing an SCP in AWS: An Introduction

Preventive guardrails are a key component of cloud governance. (Cloud governance is the process of defining and creating policies to control costs, minimize security risks, and improve efficiency.) In AWS, preventive guardrails are SCPs (Service Control Policies). Eventually you may need a preventive guardrail in AWS that is not already available. In this case, writing an SCP is an option. Beware, SCPs do have logical limitations on what you can represent.

What is an SCP?

Service Control Policies are a type of AWS Organizations policy that is used to manage permissions for your resources. SCPs allow you to centrally control over the permissions for all accounts in your organization. Thus, SCPs help you to ensure that your accounts stay within your organization’s access control guidelines. You can only use SCPs if you have all features enabled on your Organization, not only the consolidated billing features.

A Service Control Policy does not grant any permissions. SCPs only limit the actions a user can take. Consequently, an administrator can still attach IAM policies to grant permissions to allow access. The effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the IAM policy. For more information on the interactions between SCPs, IAM, and resource policies, see the AWS documentation. Think of SCPs as a filter that specifies the maximum permissions allowed.

The Anatomy of an SCP

You create an SCP by building a statement that either denies or allows access to services and actions that you specify. The following example shows a single statement that consists of single Effect, Action, and Resource elements.

"Statement": {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*"
    }

The following table shows the elements that compose an SCP. Some effects are only available for deny statements.

ElementPurposeSupported effects
VersionSpecifies the language syntax rules to use for processing the policy. The current value is "2012-10-17".Allow, Deny
StatementServes as the container for policy elements. You can have multiple statements in SCPs, separated by a comma.Allow, Deny
Statement ID (Sid)(Optional) Provides a friendly name for the statement.Allow, Deny
EffectDefines whether the SCP statement allows or denies access to the IAM users and roles in an account.Allow, Deny
ActionSpecifies AWS service and actions that the SCP allows or denies. Can be a single action or a list of actions. Valid values use IAM action syntax.Allow, Deny
NotActionSpecifies AWS service and actions that are exempt from the SCP. Used instead of the Action element. Valid values use IAM not action syntax.Deny
ResourceSpecifies the AWS resources that the SCP applies to.Deny
ConditionSpecifies conditions for when the statement is in effect. Valid values use IAM condition syntax.Deny

Examples

The following SCP allows the user to perform any action on Amazon S3.

{
    "Statement": {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "*"
    }
}

The following SCP limits the user from launching EC2 instances that are not t2.micro.

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "ec2:RunInstances",
        "Resource": "arn:aws:ec2:*:*:instance/*",
        "Condition": {
            "StringNotEquals": {
                "ec2:InstanceType": "t2.micro"
            }
        }
    }
}

Finally, the following SCP allows the user to describe, start, stop, and terminate EC2 instances.

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
          "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs",
          "ec2:DescribeSecurityGroups", "ec2:DescribeAvailabilityZones", "ec2:RunInstances",
          "ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances"
        ],
        "Resource": "*"
    }
}

Final Thoughts

As you can see, writing an SCP is not difficult. Having a knowledge of JSON syntax and IAM policy language is helpful, but not necessary. Determining if you want to write policies in an Allow or Deny fashion is the decision that requires the most strategy. If you have any questions or need help developing an Allow/Deny strategy, please reach out to us.

Michael McCarthy

Michael is veteran software engineer and cloud computing aficionado. After starting his career as a Java software engineer, he evolved into a consultant, focusing first on enterprise content management and later on AWS. He is currently an AWS Cloud Practitioner and AWS Solutions Architect Associate, although he has held many more certifications in the past.

//