SCP Implementation Types

A service control policy is written in one of two shapes. The choice determines how much maintenance it needs and how likely it is to break something.

Deny lists

A deny list leaves the default FullAWSAccess policy attached and adds explicit Deny statements. Everything not denied remains available, subject to the identity-based and resource-based policies.

• Acts as a guardrail rather than a permission model
• Permissive by default, which makes it low-risk to introduce
• Layers cleanly with IAM: IAM grants, the SCP subtracts
• Stays manageable as the estate grows, because a new service is not blocked by default

Typical uses

• Preventing accounts from leaving the organisation
• Blocking Regions the organisation does not operate in
• Preventing deletion or reconfiguration of logging and audit resources
• Denying the creation of public resources
• Enforcing tagging or encryption conditions on resource creation

Example

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyLeavingOrganization",
            "Effect": "Deny",
            "Action": "organizations:LeaveOrganization",
            "Resource": "*"
        },
        {
            "Sid": "DenyDisablingLogging",
            "Effect": "Deny",
            "Action": [
                "cloudtrail:StopLogging",
                "cloudtrail:DeleteTrail",
                "config:DeleteConfigurationRecorder",
                "config:StopConfigurationRecorder",
                "guardduty:DeleteDetector",
                "guardduty:DisassociateFromMasterAccount"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyUnauthorizedRegions",
            "Effect": "Deny",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "cloudfront:*",
                "route53:*",
                "support:*",
                "sts:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-west-1",
                        "eu-west-2"
                    ]
                }
            }
        }
    ]
}

The NotAction block in the Region restriction is not optional. Several AWS services are global and have their endpoints in us-east-1; denying every action outside the approved Regions without excluding them breaks IAM, Organizations, CloudFront, Route 53, STS and Support.

Allow lists

An allow list replaces FullAWSAccess with explicit Allow statements. Anything not listed is implicitly denied.

• Starts from zero permissions
• Every service and action the organisation uses must be named
• The strongest posture available through SCPs
• Correspondingly heavy to maintain: adopting a new service means editing the policy first, and the failure mode is an opaque AccessDenied in an unrelated team’s pipeline

Typical uses

• Tightly controlled environments where the service inventory is fixed and audited
• Regulated workloads that require explicit approval for each service
• Sandbox or training accounts deliberately limited to a handful of services

Example

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowApprovedServices",
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "rds:*",
                "s3:*",
                "cloudwatch:*",
                "logs:*",
                "sts:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowTaggedIAMUserManagement",
            "Effect": "Allow",
            "Action": [
                "iam:CreateUser",
                "iam:DeleteUser",
                "iam:ListUsers",
                "iam:GetUser"
            ],
            "Resource": "arn:aws:iam::*:user/*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/Department": "IT"
                }
            }
        }
    ]
}

Comparison

	Deny list	Allow list
Default state	Everything allowed	Everything denied
Introducing it	Incremental and low-risk	Requires a full service inventory first
New services	Available immediately	Blocked until the policy is updated
Troubleshooting	The denied action is named in the policy	Absence, not presence, is the cause — harder to find
Best suited to	Most organisations, most OUs	Highly regulated or deliberately limited accounts

The two can coexist: a deny-list baseline at the organisation root, and an allow list on the one OU that needs it.

Limits worth knowing before writing either

• An SCP never grants a permission. Both shapes above only set the maximum; the IAM policies still have to allow the action.
• SCPs do not apply to the management account. They apply only to member accounts, including any member account designated as a delegated administrator.
• SCPs do not apply to service-linked roles.
• SCPs do not directly affect resource-based policies, and do not reach principals in accounts outside the organisation. Resource control policies (RCPs) cover that case.
• All characters count towards the policy size limit, so remove decorative whitespace from a policy that is approaching it.

Practice

1. Start with deny lists for most OUs.
2. Record the intent of every statement — a comment in the source repository, since JSON policies carry none.
3. Test in a non-production OU before attaching anywhere else, and never attach an untested policy to the organisation root.
4. Version-control SCPs and change them through the same review process as any other infrastructure.
5. Review periodically against IAM service last accessed data, which shows which permitted services are never used and can therefore be removed.
6. Keep development and production guardrails separate, in separate OUs.

Remember that SCPs and IAM policies form a layered model: an action is permitted only when both allow it.