Mastering AWS Service Control Policies (SCPs)

Introduction: The Foundation of Multi-Account Governance

In the early days of cloud adoption, many organizations started with a single AWS account. This approach was simple to manage, but as organizations scaled and their needs became more complex, the single-account model quickly became a bottleneck. Security risks were concentrated, cost allocation was opaque, and innovation was stifled by the inability to isolate environments. Today, the industry standard is to use a multi-account strategy, often orchestrated through AWS Organizations. However, managing dozens or even hundreds of accounts introduces a new challenge: how do you ensure that every account adheres to your organization's security and compliance standards without manually auditing each one?

This is where Service Control Policies (SCPs) become essential. SCPs are a type of organization policy that you can use to manage permissions in your organization. Think of an SCP as a "guardrail" or a "boundary" that defines the maximum permissions for the accounts in your organization. Unlike IAM policies, which grant permissions to users and roles, SCPs do not grant any permissions themselves. Instead, they specify the maximum permissions that an account administrator can delegate to the users and roles within that account. If an action is not allowed by an SCP, it doesn't matter if an IAM policy explicitly grants it—the action will be denied.

Understanding SCPs is critical for any cloud engineer, security architect, or platform administrator. Without them, you are relying on the assumption that every local account administrator will perfectly configure their own IAM policies. In a large-scale environment, this is a dangerous assumption. By mastering SCPs, you gain the ability to enforce "deny-by-default" postures, restrict sensitive services to specific regions, and prevent the accidental deletion of critical infrastructure, all from a centralized location.

How SCPs Fit into the AWS Hierarchy

To understand SCPs, you must first understand the relationship between the different layers of permission in AWS. You can think of this as a funnel. A request must pass through several layers of evaluation before it is allowed to proceed.

1. Organization Level (SCPs): This is the outermost boundary. SCPs define the absolute ceiling of what is possible within an account. If an SCP denies an action, it is blocked, regardless of what happens in the lower layers.
2. Resource-Based Policies: These are policies attached directly to a resource, such as an S3 bucket policy or an SQS queue policy.
3. Identity-Based Policies (IAM): These are the policies attached to users, groups, or roles. This is where most day-to-day permission management happens.
4. Permissions Boundaries: These are an advanced feature used to set the maximum permissions that an identity-based policy can grant to an IAM entity.

Callout: The "Deny" Power A crucial concept to remember is that in AWS, an explicit "Deny" always overrides an "Allow." This applies to SCPs as well. Even if an IAM policy allows a user to perform an action, if an SCP attached to the account has an explicit "Deny" for that action, the request will fail. This makes SCPs an incredibly powerful tool for enforcing security boundaries that cannot be bypassed by local account administrators.

The Evaluation Logic

When a request is made, AWS evaluates all applicable policies. If there is an explicit deny anywhere in the chain, the request is denied. If there is no explicit deny, AWS looks for an allow. If there is at least one allow, the request is granted. SCPs work by filtering the "Allow" set. If you use an "Allow" list strategy in your SCP, you are essentially saying: "Even if an IAM policy tries to allow this, I will only permit it if the SCP also explicitly allows it."

Designing Your SCP Strategy

Before you start writing policies, you need a strategy. There are two primary ways to approach SCP design: the Blacklist approach and the Whitelist approach.

The Blacklist Approach (Deny-list)

In this model, you allow all actions by default and use SCPs to restrict specific, high-risk actions. For example, you might create an SCP that prevents users from disabling CloudTrail or deleting specific S3 buckets. This is the most common starting point because it is less disruptive to existing workloads.

• Pros: Low impact on existing workflows; easy to implement incrementally.
• Cons: Requires constant updates as new services are released; reactive rather than proactive.

The Whitelist Approach (Allow-list)

In this model, you deny everything by default and use SCPs to explicitly allow only the services and actions that your organization has approved. This is the "Gold Standard" for high-compliance environments, such as finance or healthcare.

• Pros: Extremely secure; forces developers to use only approved, vetted services.
• Cons: High operational overhead; requires significant testing to ensure you haven't blocked critical services.

Tip: Start with a "Deny" Strategy If you are new to SCPs, do not attempt to implement a full whitelist immediately. You will almost certainly break your production environments. Start by identifying 3-5 high-risk actions (like disabling logging or modifying network gateways) and create a blacklist SCP. Once you are comfortable with the deployment process, you can move toward more restrictive models.

Practical Examples of SCPs

Let's look at some real-world examples of SCPs. These are written in JSON, just like standard IAM policies.

Example 1: Preventing the Disabling of CloudTrail

This is a standard "must-have" for any security-conscious organization. It ensures that no one, not even an account administrator, can turn off audit logs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    }
  ]
}

Example 2: Restricting Regions

Many organizations have compliance requirements that mandate data residency. If you are required to store data only in the us-east-1 and us-west-2 regions, you can use an SCP to block any action performed in other regions.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllRegionsExceptApproved",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*",
        "acm:*",
        "budgets:*",
        "cloudfront:*",
        "iam:*",
        "importexport:*",
        "organizations:*",
        "route53:*",
        "shield:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

Warning: The "Global Service" Trap Note the NotAction block in the region restriction example above. Global services (like IAM, Route53, and CloudFront) do not have a "Region" in the same way that EC2 or RDS do. If you attempt to block these services based on region, you will break your entire AWS environment. Always ensure you exclude global services from your regional restrictions.

Implementing SCPs: Step-by-Step

Implementing SCPs should always be done with caution. A mistake in an SCP can effectively lock you out of your own AWS accounts. Follow these steps to ensure a safe rollout.

Step 1: Enable All Features

To use SCPs, your AWS Organization must be in "All Features" mode. If you are currently in "Consolidated Billing" mode, you must initiate the upgrade process. This requires approval from the management account and is a one-way street.

Step 2: Create a Test OU

Never apply an SCP directly to your production accounts or the root of your organization. Create a dedicated "Sandbox" or "Test" Organizational Unit (OU) in your AWS Organization. Move one or two non-critical accounts into this OU for testing.

Step 3: Draft and Attach the Policy

In the AWS Organizations console, navigate to "Policies" and select "Service Control Policies." Create your policy, give it a clear description, and paste your JSON code. Once saved, attach it to your Test OU.

Step 4: Validate

Log into one of the accounts within your Test OU. Attempt to perform the actions you intended to block. If the policy is working, you should receive an "Access Denied" error message, even if you are logged in as the root user of that account.

Step 5: Iterative Deployment

Once you have validated the policy, you can move it to your "Development" OU. Monitor the logs for a few days to ensure no unexpected issues arise. Finally, move the policy to your "Production" OU.

Best Practices for SCP Management

Managing SCPs is not a "set it and forget it" task. As your infrastructure evolves, your policies need to evolve with it.

• Keep Policies Small and Focused: Rather than creating one massive "master" SCP, create multiple, smaller policies that address specific concerns (e.g., Deny-CloudTrail, Restrict-Regions, Block-Root-User). This makes troubleshooting significantly easier.
• Use Versioning and IaC: Store your SCPs in a version control system like Git. Use Infrastructure as Code (IaC) tools like Terraform or AWS CloudFormation to deploy them. This ensures that you have a clear history of who changed a policy and why.
• Avoid Over-Complexity: If your SCP logic becomes too complex, it becomes impossible to audit. If you find yourself writing hundreds of lines of JSON, step back and consider if there is a more efficient way to structure your OUs or if you are trying to solve a problem that should be handled by IAM policies instead.
• Monitor for Denials: Use CloudTrail logs to monitor for AccessDenied errors across your organization. If you see a sudden spike in denials, it is a sign that an SCP might be too restrictive or that a team has changed their deployment patterns.

Common Pitfalls and How to Avoid Them

Even experienced engineers run into trouble with SCPs. Here are the most frequent mistakes:

1. The "Lockout" Scenario

The most dangerous mistake is applying a policy that denies access to the very users or roles needed to manage the account. For example, if you accidentally deny iam:CreateRole to your entire organization, you will be unable to create new service roles.

• The Fix: Always test in a sandbox account. Never apply a new policy to the root of your organization without extensive testing.

2. Ignoring the "Root" User

Many engineers forget that SCPs also apply to the root user of member accounts. This is intentional and a powerful security feature, but it means that even the root user cannot override an SCP.

• The Fix: Ensure that your "break-glass" procedures do not rely on actions restricted by your SCPs.

3. Policy Size Limits

AWS has a limit on the size of an SCP (currently 5,120 bytes). If your policy exceeds this, you will be unable to save it.

• The Fix: If you hit this limit, it is a sign that you should break your policy into smaller, more granular components.

4. Lack of Documentation

An SCP that says "Deny-All" with no context is a nightmare for the next engineer who has to debug a permission issue.

• The Fix: Use the Sid (Statement ID) field in your JSON to provide a clear explanation of what the statement does. Add comments or a README file in your Git repository explaining the business justification for each policy.

Comparison: SCPs vs. IAM Policies

It is common to confuse SCPs with IAM policies. This table highlights the key differences:

Callout: The "Maximum Permissions" Concept Think of SCPs as the "boundary of the playground." You can build anything you want inside the playground (using IAM), but you cannot build anything outside the fence. IAM policies are the tools you use to build within that space. If you try to build something outside the fence, the SCP will stop you, no matter how good your tools are.

Scaling Your Multi-Account Governance

As your organization grows, managing SCPs manually becomes unsustainable. This is where automation becomes vital. By integrating your SCP management into a CI/CD pipeline, you can treat your governance policies with the same rigor as your application code.

Automating with Terraform

Using Terraform to manage SCPs allows you to define your organization's security posture as code. Here is a simple example of how you might structure this:

resource "aws_organizations_policy" "deny_cloudtrail" {
  name        = "DenyCloudTrailDisable"
  description = "Prevents disabling of CloudTrail"
  content     = file("policies/deny_cloudtrail.json")
}

resource "aws_organizations_policy_attachment" "attach_to_prod" {
  policy_id = aws_organizations_policy.deny_cloudtrail.id
  target_id = "ou-abcd-12345678" # Your Production OU ID
}

By using file() to load your JSON, you keep your policy definitions clean and manageable. You can run terraform plan to see exactly what changes will be applied to your organization before committing them.

Auditing and Compliance

Once you have your SCPs in place, you need a way to verify that they are working as expected. AWS Config is an excellent tool for this. You can create custom Config rules that check if specific SCPs are attached to your OUs. If an SCP is detached, Config can alert your security team or even trigger an automated remediation function to re-attach it.

The Role of SCPs in Compliance Frameworks

For organizations subject to regulations like PCI-DSS, HIPAA, or SOC2, SCPs are not just a "nice-to-have"—they are a requirement for demonstrating that you have implemented technical controls to prevent unauthorized access.

When auditors ask how you ensure that logging remains enabled across all accounts, you can point to your "Deny-CloudTrail" SCP. When they ask how you prevent sensitive data from being stored in unauthorized regions, you can point to your "Region-Restriction" SCP. This provides clear, immutable evidence of your security controls.

Advanced Topics: The "FullAWSAccess" Policy

When you first enable SCPs in AWS Organizations, every account is automatically attached to a policy called FullAWSAccess. This policy essentially allows all actions. It is important to understand that this policy exists to ensure that you don't accidentally lock yourself out of your accounts the moment you turn on SCPs. Once you start attaching your own custom policies, you must ensure they interact correctly with the existing environment. You can replace the FullAWSAccess policy with your own, but always do so with extreme caution.

Frequently Asked Questions (FAQ)

Q: Can SCPs be applied to specific IAM users? A: No. SCPs are applied at the account or OU level. They affect everyone in the account, including the root user.

Q: What happens if I have multiple SCPs attached to an OU? A: AWS evaluates all attached SCPs. For an action to be allowed, it must be allowed by every SCP in the chain. If any one SCP denies the action, it is blocked.

Q: Can I use variables in SCPs? A: SCPs support policy variables, such as ${aws:PrincipalTag/Project}. This allows you to create dynamic policies that change behavior based on the tags assigned to the user or role making the request.

Q: How do I troubleshoot a blocked action? A: Check the CloudTrail event history for the AccessDenied error. The error message will usually tell you which policy caused the denial. If it was an SCP, it will specifically reference the policy ID.

Q: Do SCPs affect AWS services that operate outside of the account? A: SCPs only apply to actions taken within the accounts in your organization. They do not affect actions taken by AWS services on your behalf outside of your account, though they may restrict the service's ability to interact with your resources.

Key Takeaways

1. SCPs are Guardrails, Not Permissions: They define the maximum possible permissions for an account. They cannot grant access; they can only restrict it.
2. Explicit Deny is Absolute: In the AWS permission evaluation logic, an explicit "Deny" in an SCP will always override any "Allow" in an IAM policy.
3. Start Small: Begin with a blacklist approach to avoid breaking critical production services. Only move to a whitelist approach once you have a deep understanding of your organization's service usage.
4. Test Before You Deploy: Always use a sandbox OU for testing. A mistake in an SCP can result in a widespread outage or complete loss of control over your accounts.
5. Use IaC for Governance: Manage your SCPs using version control and automated deployment pipelines. This makes your security posture consistent, auditable, and easier to manage.
6. Granularity is Key: Break complex policies into smaller, specific statements. This makes troubleshooting much easier and keeps you within the size limits for SCPs.
7. Documentation Matters: Always include justifications and descriptions in your policies. Your future self (and your teammates) will thank you when you need to audit or modify a policy months later.

By following these principles and treating SCPs as a core component of your infrastructure-as-code strategy, you can build a secure, scalable, and compliant multi-account environment that empowers your developers while maintaining the necessary oversight for your organization.