AWS RCP Support by Service: What's Covered Today (S3, Control Tower, and More)

Key Takeaways

• Resource control policies (RCPs) are an AWS Organizations policy type that sets the maximum available permissions on your resources, regardless of what any IAM or resource-based policy allows. They work from the resource side of the access equation, complementing SCPs, which work from the identity side.
• The AWS Organizations documentation lists 44 service entries for RCPs as of August 2026. S3, KMS, STS, SQS, and Secrets Manager were available at the November 2024 launch; new services have been added regularly since. The list continues to expand.
• AWS Control Tower includes managed RCP controls for only those five original services. For any service added to the RCP list after that initial launch, teams need to author and maintain custom RCPs independently.
• Several widely used services, including Lambda, RDS, SNS, API Gateway, and Bedrock, don't currently have RCP support. Any data perimeter architecture that routes sensitive workloads through those services has a gap at the organization policy layer.

RCPs set a permission ceiling on your resources at the organization level, overriding any more permissive resource-based or IAM policy beneath them. The list of supported services is still partial, and the managed controls available through Control Tower are more limited still.

Last verified against the AWS Organizations User Guide: August 11, 2026. The supported services list expands without a predictable schedule. Verify before using this page in an architecture decision.

RCP-Supported Services

The table below covers the 44 service entries currently listed in the AWS Organizations documentation as supporting RCPs. The "CT Managed Control" column indicates whether AWS Control Tower provides a pre-built, managed RCP control for that service. Services without a managed control still support custom RCPs authored directly in Organizations.

Entries marked "--" were present in the AWS Organizations documentation as of the last verification date; individual addition dates weren't confirmed via AWS announcements. Verify in the AWS What's New feed when precision is required. The rows below Amazon Translate are listed alphabetically rather than by date for the same reason, and aws:PrincipalOrgID is the org-boundary key that works across all of them. Confirm the specific actions each service exposes in the Service Authorization Reference before writing a policy against it.

KMS note: kms:RetireGrant is not affected by RCPs regardless of policy.

Services Not Yet Covered by RCPs

These services appear in many AWS architectures but aren't currently on the supported list. Without RCP support, there's no organization-level resource policy ceiling for these services, which means a permissive resource-based policy on one of them isn't bounded by anything at the org layer. Perimeter enforcement has to live entirely at the resource or identity layer.

One related feature worth knowing about: AWS Declarative Policies are a separate AWS Organizations feature that launched around the same time as RCPs and address some EC2-adjacent gaps. Where RCPs restrict what anyone can do with your resources, Declarative Policies enforce desired configuration states on services like EC2 directly. They're not a substitute for RCPs and they cover different services, but for teams trying to close org-level enforcement gaps on EC2 resources specifically, they're worth evaluating alongside RCPs.

This table reflects services not currently listed in the AWS Organizations documentation. Verify before relying on any entry as a confirmed gap.

S3 and RCPs

S3 was one of the five services available when RCPs launched, and it remains the most commonly referenced example in AWS's own guidance because it's where organizations most often encounter unintended external access risk.

The identity perimeter use case is the most common starting point. An RCP using aws:PrincipalOrgID requires that any principal accessing S3 resources belongs to your organization. This applies even if a bucket policy explicitly grants access to an external account; the RCP takes precedence, and the request is denied. The key distinction from a bucket policy is scope: a bucket policy applies to one bucket, and an RCP applies to every bucket in every member account within the attachment scope.

The network perimeter is the next layer. Using aws:SourceIp to scope access to approved IP ranges and aws:VpceOrgID to require that requests come through a VPC endpoint belonging to your organization, you can enforce that S3 access only happens from expected network paths, even when credentials are valid.

There's a deployment issue that trips up most teams applying aws:PrincipalOrgID broadly for the first time. AWS service principals, such as cloudtrail.amazonaws.com or config.amazonaws.com, don't carry an org ID the way IAM principals do. A blanket Deny if aws:PrincipalOrgID != your-org-id will also block CloudTrail, Config, and other services from accessing your S3 buckets, because the condition evaluates to null for service principals and a null condition key fails the check. The standard pattern to handle this is to structure the RCP so it denies access unless either aws:PrincipalOrgID matches your org or aws:PrincipalIsAWSService is true and aws:SourceOrgID matches your org. This way, human and application principals are scoped to your org, and AWS services acting on behalf of your accounts pass through, while AWS services acting on behalf of external accounts are still blocked.

aws:SourceOrgID handles this precisely. It applies to AWS service principals accessing S3 on your behalf, such as CloudTrail writing logs to a bucket, and checks that the service is acting on behalf of an account in your organization rather than any account globally. Without it, a misconfigured bucket is accessible to any AWS service acting as a service principal. With it, only AWS services acting on behalf of accounts in your organization are permitted.

Control Tower ships five managed RCP controls for S3. CT.S3.PV.2 requires Authorization-header authentication. CT.S3.PV.3 enforces a minimum TLS version of 1.3, which is stricter than the TLS 1.2 floor most data perimeter guidance assumes, so check your clients before you enable it. CT.S3.PV.4 requires that S3 resources are accessible only by IAM principals in the organization or by AWS service principals. CT.S3.PV.5 requires encryption in transit and CT.S3.PV.6 requires SSE-KMS on uploads. Network perimeter enforcement and confused deputy protection are outside what the managed control library covers and need to be written as custom RCPs.

Control Tower and RCPs

Control Tower's managed RCP controls are pre-built policies you can enable through the console or API without authoring JSON. They're also configurable: you can specify ExemptedPrincipalArns when a legitimate exception needs to be carved out, such as a third-party monitoring role that requires cross-account access. When managed controls launched in November 2024, there were nine of them, covering S3, STS, KMS, SQS, and Secrets Manager.

As of August 2026, no new managed controls exist for any service added to the Organizations RCP list since that launch. If you want RCP coverage for DynamoDB, CloudWatch Logs, ECR, Cognito, or OpenSearch Serverless in a Control Tower environment, the process is:

1. Enable the RCP policy type in your organization if you haven't already. It's not enabled by default. Without this step, there's nowhere to attach a custom RCP. You can verify and enable it in the AWS Organizations console under Policies, or via the AWS CLI with aws organizations enable-policy-type.
2. Author a custom RCP in JSON directly through the AWS Organizations console or API (not through the Control Tower control library).
3. Attach the policy at the appropriate level: root for organization-wide enforcement, or individual OUs if you need scoped coverage.
4. Build your own update and review process for that policy. Unlike managed controls, AWS won't version or update custom RCPs when the underlying service changes.

Custom RCPs and Control Tower managed controls require separate maintenance tracks. Managed controls are versioned by AWS; custom policies are owned by your team. If a service adds new API actions that your custom RCP doesn't cover, the policy silently stops providing complete coverage until someone updates it.

Two scoping limits apply regardless of which approach you're using. RCPs don't apply to resources in the management account, only in member accounts. Service-linked roles aren't governed by RCPs, so any AWS service operating through a service-linked role can act outside what an RCP would otherwise restrict. AWS managed KMS keys and the kms:RetireGrant action are also outside RCP reach.

How RCPs Fit Into a Broader Perimeter Architecture

For the services RCPs cover, you have an enforcement guarantee that holds across every member account regardless of what resource-based or IAM policies say. For the services they don't cover, and for access patterns running through service-linked roles, that guarantee doesn't exist. The perimeter has to be constructed from resource policies, SCPs, and identity controls instead, which means it's more likely to drift, be misconfigured, or simply not get applied consistently across accounts.

Building a complete data perimeter means knowing which layer each control lives on and where the gaps are. Native helps organizations enforce architectural intent across their AWS environment through zones, boundaries, and baselines, connecting the controls already present to the policies behind them. Schedule a demo to see how that maps to your environment.

Frequently Asked Questions

Do RCPs apply to the management account?

No. RCPs only govern resources in member accounts. Resources in the management account aren't subject to any RCP you attach at the root or OU level, which means S3 buckets, KMS keys, and other supported services in the management account fall outside the organization-level ceiling RCPs provide. This is one reason most organizations keep resource usage in the management account minimal.

Do RCPs affect service-linked roles?

No. Service-linked roles are exempt from RCPs. An AWS service operating through a service-linked role can access your resources outside what an RCP would otherwise restrict. For services that rely heavily on service-linked roles, such as AWS Backup or AWS Config, this means RCPs don't provide the same perimeter coverage they do for human and application principals.

If AWS adds a new service to the RCP-supported list, do my existing RCPs automatically apply to it?

No. RCP coverage is explicit per service. An RCP statement that uses aws:PrincipalOrgID scoped to s3:* actions won't apply to DynamoDB once DynamoDB joins the supported list. Each service needs its own policy statement.

Can I use RCPs and SCPs together?

Yes, and for a complete data perimeter you need both. SCPs restrict what IAM principals in your organization can do; they work from the identity side. RCPs restrict what anyone can do with your resources, regardless of where the request originates; they work from the resource side. A request has to satisfy both to succeed. Using only SCPs leaves your resources exposed to external principals with their own valid credentials. Using only RCPs leaves your own principals unconstrained on actions you may not want them to take.

What happens when an RCP and a bucket policy conflict?

An explicit Deny in an RCP overrides any Allow anywhere else in the policy evaluation chain, including the bucket policy, an IAM identity policy, or a permission boundary. If an RCP denies an action, that action is blocked regardless of what the resource policy says.

It's worth understanding how RCPs are typically structured, because it affects how you reason about this. RCPs are usually authored as a Deny statement that fires unless a set of conditions is satisfied, rather than as an Allow list. A common pattern looks like: deny all S3 actions unless aws:PrincipalOrgID matches your org. This means the policy is silent by default and only activates when a request fails the condition. The implication is that "no applicable RCP exists for this service" means there's no org-level policy evaluation happening at all for that service. There's no RCP ceiling, not a permissive one. That distinction matters when you're mapping your perimeter coverage: a service without RCP support is ungoverned at the org layer, not governed permissively.