AWS SCP Policy Rule Sets for Popular AWS Services

Practical Service Control Policy guardrails for AWS Regions, S3, EC2, IAM, KMS, CloudTrail, GuardDuty, AWS Config, RDS, Lambda, VPC, DynamoDB, and EKS.

AWS Service Control Policies (SCPs) establish the maximum permissions available to accounts in an AWS Organization. They do not grant permissions; IAM policies and resource policies must still allow an operation.

1. Restrict operations to approved AWS Regions

This organization-wide guardrail denies most activity outside approved Regions while exempting selected global services.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnapprovedRegions",
    "Effect": "Deny",
    "NotAction": [
      "account:*", "aws-portal:*", "billing:*", "budgets:*",
      "cloudfront:*", "iam:*", "organizations:*", "route53:*",
      "route53domains:*", "support:*", "waf:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["us-east-1", "us-west-2"]
      }
    }
  }]
}

Use case: Data residency, cost control, and attack-surface reduction.

2. Amazon S3 guardrails

Prevent public-access protection from being disabled

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDisablingAccountPublicAccessBlock",
      "Effect": "Deny",
      "Action": "s3:PutAccountPublicAccessBlock",
      "Resource": "*"
    },
    {
      "Sid": "DenyChangingBucketPublicAccessBlock",
      "Effect": "Deny",
      "Action": ["s3:DeleteBucketPublicAccessBlock", "s3:PutBucketPublicAccessBlock"],
      "Resource": "*"
    }
  ]
}

The second statement is deliberately restrictive. A practical deployment can exempt a centrally controlled security role:

"Condition": {
  "ArnNotLike": {
    "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityAdministrationRole"
  }
}

Require encrypted object uploads

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3Uploads",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::*/*",
      "Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}
    },
    {
      "Sid": "DenyUnsupportedS3Encryption",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::*/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": ["AES256", "aws:kms"]
        }
      }
    }
  ]
}

Caution: Some AWS services write to S3 through service-specific mechanisms and may require carefully scoped exemptions.

3. Amazon EC2 guardrails

Permit only approved instance types

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnapprovedEC2InstanceTypes",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringNotEquals": {
        "ec2:InstanceType": ["t3.micro", "t3.small", "t3.medium", "m6i.large"]
      }
    }
  }]
}

Use case: Prevent expensive GPU or high-capacity instances from being launched.

Prevent disabling EBS encryption by default

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyDisablingDefaultEBSEncryption",
    "Effect": "Deny",
    "Action": "ec2:DisableEbsEncryptionByDefault",
    "Resource": "*"
  }]
}

Prevent creation of unencrypted EBS volumes

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnencryptedEBSVolumes",
    "Effect": "Deny",
    "Action": "ec2:CreateVolume",
    "Resource": "*",
    "Condition": {"Bool": {"ec2:Encrypted": "false"}}
  }]
}

4. IAM guardrails

Prevent member accounts from creating IAM users

This encourages workforce access through IAM Identity Center and temporary roles.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyIAMUserManagement",
    "Effect": "Deny",
    "Action": ["iam:CreateUser", "iam:CreateAccessKey", "iam:CreateLoginProfile"],
    "Resource": "*"
  }]
}

Protect designated administrative and security roles

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectSecurityRoles",
    "Effect": "Deny",
    "Action": [
      "iam:DeleteRole", "iam:DeleteRolePolicy", "iam:DetachRolePolicy",
      "iam:PutRolePolicy", "iam:UpdateAssumeRolePolicy"
    ],
    "Resource": [
      "arn:aws:iam::*:role/SecurityAdministrationRole",
      "arn:aws:iam::*:role/IncidentResponseRole",
      "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    ],
    "Condition": {
      "ArnNotLike": {
        "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityAdministrationRole"
      }
    }
  }]
}

Restrict role passing

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyPassingPrivilegedRoles",
    "Effect": "Deny",
    "Action": "iam:PassRole",
    "Resource": [
      "arn:aws:iam::*:role/SecurityAdministrationRole",
      "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    ]
  }]
}

This prevents users from indirectly gaining privilege by attaching a powerful role to Lambda, EC2, Glue, or another AWS service.

5. AWS KMS guardrails

Prevent deletion of KMS keys

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyKMSKeyDeletion",
    "Effect": "Deny",
    "Action": ["kms:ScheduleKeyDeletion", "kms:DeleteImportedKeyMaterial"],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/KMSAdministrationRole"}
    }
  }]
}

Prevent key rotation from being disabled

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyDisablingKMSKeyRotation",
    "Effect": "Deny",
    "Action": "kms:DisableKeyRotation",
    "Resource": "*"
  }]
}

6. AWS CloudTrail guardrails

Prevent users in member accounts from disabling or deleting audit trails.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectCloudTrail",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:DeleteTrail", "cloudtrail:StopLogging", "cloudtrail:UpdateTrail",
      "cloudtrail:PutEventSelectors", "cloudtrail:PutInsightSelectors"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/SecurityAdministrationRole"}
    }
  }]
}

7. Amazon GuardDuty guardrails

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectGuardDuty",
    "Effect": "Deny",
    "Action": [
      "guardduty:DeleteDetector", "guardduty:DisassociateFromAdministratorAccount",
      "guardduty:DisassociateMembers", "guardduty:StopMonitoringMembers",
      "guardduty:UpdateDetector"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/SecurityAdministrationRole"}
    }
  }]
}

8. AWS Config guardrails

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectAWSConfig",
    "Effect": "Deny",
    "Action": [
      "config:DeleteConfigurationRecorder", "config:DeleteDeliveryChannel",
      "config:StopConfigurationRecorder"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/SecurityAdministrationRole"}
    }
  }]
}

9. Amazon RDS guardrails

Require storage encryption

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedRDSInstances",
      "Effect": "Deny",
      "Action": "rds:CreateDBInstance",
      "Resource": "*",
      "Condition": {"Bool": {"rds:StorageEncrypted": "false"}}
    },
    {
      "Sid": "DenyUnencryptedRDSClusters",
      "Effect": "Deny",
      "Action": "rds:CreateDBCluster",
      "Resource": "*",
      "Condition": {"Bool": {"rds:StorageEncrypted": "false"}}
    }
  ]
}

Prevent public RDS databases

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyPublicRDSInstances",
    "Effect": "Deny",
    "Action": ["rds:CreateDBInstance", "rds:ModifyDBInstance"],
    "Resource": "*",
    "Condition": {"Bool": {"rds:PubliclyAccessible": "true"}}
  }]
}

10. AWS Lambda guardrails

Restrict approved Lambda runtimes

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnapprovedLambdaRuntimes",
    "Effect": "Deny",
    "Action": ["lambda:CreateFunction", "lambda:UpdateFunctionConfiguration"],
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "lambda:Runtime": ["python3.13", "nodejs22.x", "java21"]
      }
    }
  }]
}

Container-image Lambda functions do not use the standard runtime parameter, so this policy requires careful testing.

Prevent public Lambda function URLs

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyPublicLambdaURLs",
    "Effect": "Deny",
    "Action": ["lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig"],
    "Resource": "*",
    "Condition": {"StringEquals": {"lambda:FunctionUrlAuthType": "NONE"}}
  }]
}

11. Amazon VPC guardrails

Prevent unmanaged internet gateways

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyInternetGatewayChanges",
    "Effect": "Deny",
    "Action": [
      "ec2:CreateInternetGateway", "ec2:AttachInternetGateway",
      "ec2:DetachInternetGateway", "ec2:DeleteInternetGateway"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/NetworkAdministrationRole"}
    }
  }]
}

Prevent VPC Flow Logs from being deleted

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectVPCFlowLogs",
    "Effect": "Deny",
    "Action": "ec2:DeleteFlowLogs",
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/NetworkAdministrationRole"}
    }
  }]
}

12. Amazon DynamoDB guardrails

Prevent point-in-time recovery from being disabled

An SCP cannot force every new table to have point-in-time recovery enabled as part of a single table-creation operation because recovery is normally enabled through a separate API call. It can, however, prevent recovery from being disabled.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyDisablingDynamoDBRecovery",
    "Effect": "Deny",
    "Action": "dynamodb:UpdateContinuousBackups",
    "Resource": "*",
    "Condition": {"Bool": {"dynamodb:PointInTimeRecoveryEnabled": "false"}}
  }]
}

Use AWS Config or CloudFormation hooks to identify or prevent tables that never enable recovery.

13. Amazon EKS guardrails

Prevent public Kubernetes API endpoints

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyPublicEKSEndpoint",
    "Effect": "Deny",
    "Action": ["eks:CreateCluster", "eks:UpdateClusterConfig"],
    "Resource": "*",
    "Condition": {"Bool": {"eks:EndpointPublicAccess": "true"}}
  }]
}

This is appropriate where administrative access is available through private connectivity. Confirm relevant condition-key support before production deployment.

14. Consolidated security-service protection

This example protects CloudTrail, AWS Config, GuardDuty, Security Hub, and IAM Access Analyzer against tampering.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenySecurityServiceTampering",
    "Effect": "Deny",
    "Action": [
      "access-analyzer:DeleteAnalyzer", "cloudtrail:DeleteTrail",
      "cloudtrail:StopLogging", "config:DeleteConfigurationRecorder",
      "config:DeleteDeliveryChannel", "config:StopConfigurationRecorder",
      "guardduty:DeleteDetector", "securityhub:DisableSecurityHub"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {
        "aws:PrincipalArn": [
          "arn:aws:iam::*:role/SecurityAdministrationRole",
          "arn:aws:iam::*:role/AWSControlTowerExecution"
        ]
      }
    }
  }]
}

Recommended SCP rule-set structure

Implementation cautions

• Test each SCP against a sandbox OU before attaching it to production.
• An explicit SCP denial overrides IAM permissions, including administrator permissions.
• SCPs restrict the permissions available to principals; they do not grant permissions.
• Service-linked roles have special behavior and may not be restricted by SCPs in the same way as ordinary IAM principals.
• Use ArnNotLike with aws:PrincipalArn for carefully controlled break-glass exemptions.
• Avoid one enormous policy. Smaller policies are easier to test, version, and attach by OU.
• Combine SCPs with AWS Config, AWS Control Tower controls, CloudFormation hooks, and detective controls. Not every configuration requirement can be enforced reliably through an SCP alone.

These examples are starting points, not drop-in production policies. Validate action names, condition-key support, service dependencies, and exemption paths against your organization’s current AWS architecture.

The post AWS SCP Policy Rule Sets for Popular AWS Services appeared first on AWS Security Architect.

AWS Resource Control Policies: Practical RCP Rule Sets for 11 AWS Services

AWS Resource Control Policies provide a centrally managed resource-side security boundary. This guide presents practical RCP rule sets for eleven widely used AWS services and explains where RCPs complement—rather than replace—SCPs, IAM policies, key policies, and resource policies.

What is an AWS Resource Control Policy?

A Resource Control Policy, or RCP, is an AWS Organizations policy that defines the maximum permissions available on resources in member accounts. An RCP can prevent an external or unintended principal from accessing an organizational resource even when a resource policy mistakenly permits that access.

RCPs do not grant permissions. Actual access must still be granted through an identity-based or resource-based policy. Effective access is the intersection of the applicable RCPs, SCPs, IAM policies, and resource policies.

Recommended controls by service

Rule set 1: Establish an organizational resource perimeter

This consolidated policy denies access from IAM principals outside the organization while allowing AWS service principals. Replace o-xxxxxxxxxx with the actual AWS Organization ID.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyExternalPrincipalAccessToProtectedResources",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*",
        "kms:*",
        "logs:*",
        "dynamodb:*",
        "autoscaling:*",
        "inspector2:*",
        "kinesisvideo:*",
        "sqs:*",
        "codebuild:*",
        "codepipeline:*",
        "secretsmanager:*"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false"
        },
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxx"
        }
      }
    }
  ]
}

Exempt approved external roles

If a partner or controlled break-glass role requires access, add a narrow ArnNotLike exception. Avoid broad account-wide exceptions.

"Condition": {
  "BoolIfExists": {
    "aws:PrincipalIsAWSService": "false"
  },
  "StringNotEqualsIfExists": {
    "aws:PrincipalOrgID": "o-xxxxxxxxxx"
  },
  "ArnNotLike": {
    "aws:PrincipalArn": [
      "arn:aws:iam::111122223333:role/ApprovedPartnerRole",
      "arn:aws:iam::*:role/OrganizationBreakGlassRole"
    ]
  }
}

Rule set 2: Reduce cross-service confused-deputy risk

AWS service principals frequently need legitimate resource access—for example, CloudTrail writing to S3 or EventBridge sending to SQS. Where the integration supplies the relevant source context, require the calling service to act for a resource associated with your organization.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyServiceAccessFromOutsideOrganization",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*", "kms:*", "logs:*", "dynamodb:*",
        "autoscaling:*", "inspector2:*", "kinesisvideo:*",
        "sqs:*", "codebuild:*", "codepipeline:*",
        "secretsmanager:*"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:PrincipalIsAWSService": "true"
        },
        "Null": {
          "aws:SourceAccount": "false"
        },
        "StringNotEqualsIfExists": {
          "aws:SourceOrgID": "o-xxxxxxxxxx"
        }
      }
    }
  ]
}

Test this rule carefully because AWS integrations do not all populate source context keys identically. Where appropriate, use aws:SourceAccount, aws:SourceArn, aws:SourceOrgID, or aws:SourceOrgPaths based on the integration.

Rule set 3: Enforce S3 transport security

Require HTTPS

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnencryptedS3Transport",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "Bool": { "aws:SecureTransport": "false" }
    }
  }]
}

Require TLS 1.2 or later

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyS3RequestsBelowTLS12",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "NumericLessThan": { "s3:TlsVersion": "1.2" }
    }
  }]
}

TLS 1.2 is a broadly compatible enterprise baseline. AWS Control Tower also provides a stricter preventive control that requires TLS 1.3.

Rule set 4: Require SSE-KMS for S3 object uploads

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3UploadsWithoutSSEKMSKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::*/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
        }
      }
    },
    {
      "Sid": "DenyIncorrectS3EncryptionAlgorithm",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::*/*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

Rule set 5: Protect customer-managed KMS keys

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyExternalAccessToCustomerManagedKeys",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "kms:*",
    "Resource": "*",
    "Condition": {
      "BoolIfExists": {
        "aws:PrincipalIsAWSService": "false"
      },
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-xxxxxxxxxx"
      },
      "ArnNotLike": {
        "aws:PrincipalArn": "arn:aws:iam::111122223333:role/ApprovedExternalKMSRole"
      }
    }
  }]
}

RCPs do not apply to AWS-managed KMS keys or to kms:RetireGrant. Key policies and IAM policies remain necessary to grant access.

Service-specific organizational perimeter policies

The same tested perimeter pattern can be applied separately when different OUs, exemptions, or rollout schedules are required. Change the Sid, action prefix, and—in the SQS example—the resource ARN as shown below.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyExternalAccessToSERVICE",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "SERVICE_PREFIX:*",
    "Resource": "*",
    "Condition": {
      "BoolIfExists": {
        "aws:PrincipalIsAWSService": "false"
      },
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-xxxxxxxxxx"
      }
    }
  }]
}

What these RCPs do not control

• CodeBuild and CodePipeline execution roles: use IAM policies and SCPs to control what build and pipeline roles can access.
• Kinesis Data Streams: use SCPs, IAM, and stream resource policies because the kinesis prefix is not currently listed for RCP support.
• Management-account resources: RCPs apply to member-account resources, not resources in the AWS Organizations management account.
• Service-linked roles: RCPs do not restrict calls made by service-linked roles.
• Permission grants: an RCP establishes a ceiling; it never grants access by itself.

Safe deployment sequence

1. Inventory existing public and cross-account access with IAM Access Analyzer.
2. Identify partner roles and required AWS service integrations.
3. Add narrow, documented exceptions.
4. Attach the RCP to a dedicated test account.
5. Review CloudTrail for unexpected AccessDenied events.
6. Expand to a nonproduction OU.
7. Progressively deploy to production OUs.
8. Attach at the organization root only after broad validation.

RCP syntax reminders

• Customer-created RCPs use explicit Deny statements.
• The Principal in an RCP must be "*"; use conditions to distinguish principals.
• A customer-managed RCP cannot use a bare "Action": "*"; specify one or more supported service prefixes.
• The AWS-managed RCPFullAWSAccess policy remains attached automatically and does not grant permissions.
• Narrow resources and exceptions where service authorization semantics allow it.

Conclusion

The strongest RCP design begins with a common organizational resource perimeter, adds confused-deputy protection for AWS service access, and then layers service-specific controls such as S3 transport encryption and SSE-KMS requirements. SCPs constrain identities; RCPs protect resources. Used together, they create a stronger preventive boundary for a multi-account AWS environment.

References

• AWS Organizations: Resource Control Policies
• AWS Organizations: RCP Syntax
• AWS Organizations: RCP Examples
• AWS Control Tower RCP Controls
• AWS KMS Resource Control Policies
• AWS Data Perimeter Implementation Guidance

The post AWS Resource Control Policies: Practical RCP Rule Sets for 11 AWS Services appeared first on AWS Security Architect.