Building a Data Perimeter with Resource Control Policies and Declarative Policies

A data perimeter answers one brutal question: even if a valid IAM credential leaks, can an attacker move your data out of the org, or pull it in from somewhere you do not trust? Service Control Policies (SCPs) get you part of the way, but they are an identity-side control — they constrain your principals. They say nothing about a foreign or anonymous principal hitting your S3 bucket with a presigned URL, or one of your own roles writing to a bucket in someone else’s account. That gap is exactly where exfiltration lives, and it is the gap that has shown up in nearly every “leaked key → data gone” incident report of the last five years.

Resource Control Policies (RCPs), generally available since November 2024, close it: org-wide guardrails that attach to the resource side of a request and evaluate against whoever is calling — including principals from outside your organization and unauthenticated callers redeeming a presigned URL. Pair them with Declarative Policies to durably pin EC2 configuration (IMDSv2 required, no public AMIs, no public snapshots) and you have a perimeter that survives credential theft, console misconfiguration, and the intern who clicks “make public.” This guide builds all three — the identity perimeter (RCP), the resource perimeter (SCP), the network perimeter (VPC endpoints + aws:SourceVpce), and the durable EC2 baseline (declarative) — end to end, with the exact aws CLI, the JSON, the Terraform, and the CloudTrail pre-flight that keeps you from paging yourself at 2 a.m.

Everything assumes AWS Organizations with all features enabled and a real OU structure. If you are still in consolidated-billing-only mode, fix that first — RCPs, SCPs, and declarative policies all require all-features mode and none of them protect the management account. Because this is a reference you will return to mid-rollout, the policy-type matrix, the condition keys, the supported services, the error codes, and the symptom→cause→fix playbook are all laid out as scannable tables — read the prose once, then keep the tables open while you stage the waves.

What problem this solves

The pain is specific and it is expensive. You have spent years building a clean SCP layer, you feel governed, and then a CI/CD access key leaks from a build log. The key belongs to a legitimate org principal, so every identity-side control you own — every SCP — waves it through. The attacker mints a presigned S3 URL and pulls a customer dataset from a coffee-shop IP to a bucket in their account. Nothing in your guardrails fired, because nothing was watching the resource side of the request or the network it came from. The data is gone, the disclosure clock is running, and your post-incident review says “the credential was valid, the read was authorized” — which is true, and is the whole problem.

What breaks without a data perimeter: exfiltration via leaked keys (the read is authorized), exfiltration via your own roles writing to a foreign bucket (a malicious or compromised principal stages data outward), ingestion of poisoned data from buckets you do not trust, confused-deputy attacks where a foreign principal assumes one of your roles, and the slow-motion leak of accidentally-public AMIs and EBS snapshots that ride along when an account is shared too widely. Each of these is invisible to SCPs because SCPs only constrain your principals acting on resources within your policy’s reach.

Who hits this: any organization past ~20 accounts with real data in S3, credentials in Secrets Manager and KMS, cross-account role assumption, and third-party SaaS vendors (observability, CSPM, backup) with roles in your accounts. It bites hardest on regulated workloads (fintech, health, gov) where a single foreign-principal read is a reportable event, and on platform teams who think SCPs make them safe. The fix is almost never “tighten an IAM policy” — it is “put a guardrail on the resource side and the network side that holds regardless of who is calling.”

To frame the whole field before the deep dive, here is every perimeter dimension this article builds, the control that owns it, the condition key it leans on, and the attack it actually stops:

Learning objectives

By the end of this article you can:

• Explain precisely how RCPs differ from SCPs — resource side vs identity side, who each catches, and why both are required for a complete perimeter.
• Read the AWS authorization chain (identity policy AND every SCP AND every RCP AND the resource-based policy) and predict whether a given request is allowed or denied.
• Enable the RESOURCE_CONTROL_POLICY and DECLARATIVE_POLICY_EC2 policy types and author each of the four perimeter layers in JSON, aws CLI, and Terraform.
• Build the trusted-identities RCP that denies S3/STS/SQS/KMS/Secrets Manager to foreign principals while correctly exempting AWS service principals via aws:SourceOrgID and aws:PrincipalIsAWSService.
• Build the trusted-resources SCP (aws:ResourceOrgID) and the trusted-networks RCP (aws:SourceVpce with Null/IfExists guards) without locking out console or service traffic.
• Pin EC2 with a Declarative Policy — http_tokens: required (IMDSv2), image_block_public_access, snapshot_block_public_access, and a user-facing exception_message.
• Stage the rollout sandbox → non-prod → prod → root using a CloudTrail Lake pre-flight that finds every foreign-principal relationship before any deny goes live, and keep a break-glass path that is never subject to the perimeter.
• Carve out documented exceptions (AWS services, SaaS roles with sts:ExternalId, cross-org sharing) by ARN without ever weakening the baseline, and verify the perimeter holds with IAM Access Analyzer set to the organization zone of trust.

Prerequisites & where this fits

You should already understand AWS Organizations and SCPs: an OU (Organizational Unit) is a container of accounts, policies attach at root/OU/account and inherit downward, and SCPs are deny-by-default-overridable guardrails that filter what your principals may do. You should know IAM policy evaluation — that an explicit Deny always wins, that access requires an Allow somewhere, and what a resource-based policy (an S3 bucket policy, a KMS key policy, a role trust policy) is versus an identity policy. You should be comfortable running aws CLI with a management-account or delegated-admin profile and reading JSON.

This sits at the top of the governance and identity track. It assumes the org foundation from AWS Organizations: SCP Guardrails and Delegated Admin and the landing-zone shape from AWS Control Tower: Multi-Account Landing Zone. It builds directly on IAM evaluation order from IAM Fundamentals: Users, Roles, Policies, Evaluation and the least-privilege patterns in IAM Least Privilege and Permission Boundaries. The network leg leans on VPC Deep Dive: Subnets, Routing, IGW, NAT, Endpoints and AWS PrivateLink: Service Provider and Consumer Cross-Account. The cross-account exception pattern is covered in depth in IAM Cross-Account Roles, External ID, Confused Deputy, Session Policies.

A quick map of who owns and confirms each perimeter leg during a rollout, so you pull the right person into the room:

Core concepts

Five mental models make every later policy obvious.

Authorization is an intersection, and Deny always wins. A request to AWS is allowed only if it survives every applicable policy and no policy denies it. Adding RCPs extends the chain on the resource side:

Request allowed  =  identity policy (or resource-based policy) ALLOW
                AND  every SCP from root to account   (no DENY)
                AND  every RCP from root to account   (no DENY)   <- resource side, ANY caller
                AND  the resource-based policy on the target     (no DENY)

A single Deny anywhere in that chain kills the request, no matter how many Allows exist. RCPs and SCPs are deny-only: they can never grant access, only remove it from whatever was otherwise permitted.

SCPs watch the caller; RCPs watch the resource. An SCP evaluates against the principal making the call — it can only constrain principals inside your org. An RCP evaluates against the resource being acted on, for any caller, including a principal from a foreign org or an anonymous caller redeeming a presigned URL. “My principals on trusted resources” (SCP) versus “trusted identities on my resources” (RCP) is the first fork in every perimeter decision.

The baseline allows everything; you layer additive denies. RCPs start from an implicit RCPFullAWSAccess policy that allows all actions on all resources, exactly like FullAWSAccess for SCPs. You never grant in an RCP — you attach Deny-with-condition statements on top of that baseline. Detach the baseline and you break access org-wide, so never do that; author additive denies instead.

The management account is exempt — keep data out of it. Neither SCPs nor RCPs apply to the management account’s own principals or resources, even when attached at the root. A workload or bucket living in the management account is outside your perimeter. This is also your break-glass anchor: a role in the management account is, by definition, never filtered by the perimeter.

The supported-service list is small and deliberate. At GA, RCPs support exactly S3, STS, SQS, KMS, and Secrets Manager — the precise set of services that hold or broker your data and credentials. That is not a limitation to lament; it is the realistic exfiltration surface. Lock those five on the resource side and you have closed the doors attackers actually walk through.

The hard limits and quotas that shape how you author and attach these policies — hit one of these mid-rollout and the error is cryptic, so know them up front:

The vocabulary in one table

Pin down every moving part before the deep sections. The glossary repeats these for lookup; this is the mental model side by side:

RCPs vs SCPs: closing the resource-side gap

The mental model that matters most: a request is authorized only if it survives the intersection of every applicable policy, and RCPs add a brand-new term to that intersection on the resource side. SCPs evaluate against the principal making the call; RCPs evaluate against the resource being acted on, regardless of who the caller is — including principals from outside your organization and anonymous callers. That is the entire point, and it is the one thing to internalize before writing a line of JSON.

Here is the full side-by-side. Read every row — the differences are exactly where the perimeter logic lives:

Two consequences shape everything below, and both are easy to get wrong:

RCPs start from an implicit RCPFullAWSAccess baseline that allows everything, exactly like FullAWSAccess for SCPs. You layer deny-with-condition statements on top. If you detach the baseline you break access org-wide, so never do that — author additive denies instead.

The management account is exempt from both SCPs and RCPs. Attaching at the root does not protect the management account’s own resources. Keep workloads and data out of it, and use a management-account role as your break-glass path.

The supported-service list is small but deliberately chosen — it is precisely the set of services that hold or broker data and credentials. Here is what each supported service contributes to the perimeter and the headline action you most want to govern:

A note on why STS is the highest-leverage line in the whole perimeter: role assumption is the front door to nearly every privilege-escalation and lateral-movement path. Denying assumption of your roles by foreign principals shuts a class of confused-deputy attacks at the resource boundary, before any downstream permission even comes into play. If you only had room for one RCP statement, it would be the sts:AssumeRole deny.

The three trust dimensions

A data perimeter is the cross-product of three statements that should all be true for every legitimate request. Miss one corner and you have a perimeter with a hole in it:

1. Trusted identities — only principals from my org touch my resources (aws:PrincipalOrgID), enforced by RCP.
2. Trusted resources — my principals only touch resources in my org (aws:ResourceOrgID), enforced by SCP.
3. Trusted networks — requests only come from my expected networks (aws:SourceVpce, aws:SourceVpc, aws:SourceIp), enforced by RCP + VPC endpoint policy.

RCPs own the trusted-identities-on-my-resources corner. SCPs own my-principals-on-trusted-resources. VPC endpoint policies and aws:SourceVpce conditions own trusted networks. Map every control you write back to one of these cells, or you are adding noise. The mapping is worth memorizing as a grid:

The condition keys you will lean on, what each means, and where it shines — get the semantics exactly right because a wrong key is a silent hole:

The IfExists operator suffix deserves its own note, because it is the single most common cause of accidental lockouts. Here is how each operator behaves when the key is absent from the request — the difference between a clean perimeter and a 2 a.m. page:

Enable RCPs and author the identity perimeter

RCPs are a policy type you turn on at the root, then attach. Enable it from the management account (or a delegated Organizations admin). First find the root, then enable the type:

# Find the root ID
ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text)

# Enable the Resource Control Policy type on the org
aws organizations enable-policy-type \
  --root-id "$ROOT_ID" \
  --policy-type RESOURCE_CONTROL_POLICY

# Terraform equivalent — enable both policy types on the org
resource "aws_organizations_organization" "this" {
  feature_set = "ALL"
  enabled_policy_types = [
    "SERVICE_CONTROL_POLICY",
    "RESOURCE_CONTROL_POLICY",
    "DECLARATIVE_POLICY_EC2",
  ]
}

Now the core control: deny any access to S3, STS, SQS, KMS, and Secrets Manager resources unless the calling principal belongs to my org or the call is made by an AWS service on my behalf. The two exception conditions are critical — without them you break replication, AWS service integrations, and a long tail of legitimate cross-service traffic.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceOrgIdentityPerimeter",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*",
        "sts:AssumeRole",
        "sts:AssumeRoleWithSAML",
        "sts:AssumeRoleWithWebIdentity",
        "sqs:*",
        "kms:*",
        "secretsmanager:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "o-abc123def4",
          "aws:SourceOrgID": "o-abc123def4"
        },
        "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
      }
    }
  ]
}

Why each piece is the way it is — this is the part teams copy without understanding and then debug for a week:

Attach it — and start at a sandbox OU (covered in the rollout section), never the root:

# Create the policy, capture its ID, attach to the sandbox OU first
RCP_ID=$(aws organizations create-policy \
  --name "rcp-identity-perimeter" \
  --type RESOURCE_CONTROL_POLICY \
  --content file://rcp-identity-perimeter.json \
  --query 'Policy.PolicySummary.Id' --output text)

aws organizations attach-policy \
  --policy-id "$RCP_ID" \
  --target-id ou-root-sandbox01

resource "aws_organizations_policy" "identity_perimeter" {
  name    = "rcp-identity-perimeter"
  type    = "RESOURCE_CONTROL_POLICY"
  content = file("${path.module}/rcp-identity-perimeter.json")
}

resource "aws_organizations_policy_attachment" "identity_perimeter_sandbox" {
  policy_id = aws_organizations_policy.identity_perimeter.id
  target_id = "ou-root-sandbox01" # promote to non-prod → prod → root in waves
}

The actions to enumerate per service, and the trade-off between the broad wildcard and a tight list, so you choose deliberately:

The resource side of trusted resources (SCP)

RCPs stop the world from reaching in. To stop your principals from reaching out — exfiltrating to a bucket in an attacker’s account — you need an SCP keyed on aws:ResourceOrgID. RCPs cannot express this because the target resource is foreign and outside your policy’s reach; only an identity-side SCP on your principals can constrain where they write.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessToForeignResources",
      "Effect": "Deny",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "sqs:SendMessage",
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:ResourceOrgID": "o-abc123def4"
        },
        "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
      }
    }
  ]
}

This is the pair to the RCP: together they assert “my principals only touch my resources, and my resources are only touched by my principals.” Exempt the AWS service principal again, or you will break things like Systems Manager pulling a public patch baseline (which legitimately lives outside your org). The two policies are mirror images — keep them straight with this table:

What each layer cannot do alone — the reason you need both, stated as a coverage matrix:

A subtle reason this SCP must be tightly scoped to a few actions rather than s3:*: an over-broad aws:ResourceOrgID deny on all S3 actions can catch s3:ListAllMyBuckets and other account-level calls where aws:ResourceOrgID is absent, and with StringNotEqualsIfExists that is fine — but if you ever drop the IfExists, every such call denies. Enumerate the data-plane actions you actually mean.

Trusted networks with VPC endpoints and aws:SourceVpce

Identity trust alone is not enough: a leaked long-lived key for one of your roles still belongs to your org, so aws:PrincipalOrgID passes cleanly. The network dimension is what catches it — that stolen key is being used from the open internet, not from inside your VPC. This is the leg that actually stops the presigned-URL-from-a-coffee-shop scenario.

Enforce it in two layers. First, on the VPC endpoint policy for the S3 gateway/interface endpoint, restrict to your org so the endpoint itself cannot be used as a tunnel to foreign buckets:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EndpointOrgScopeOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:ResourceOrgID": "o-abc123def4" }
      }
    }
  ]
}

Second, layer an RCP that denies S3 data-plane calls unless they arrive through an approved endpoint or from an expected network. Use ...IfExists so console and AWS-service paths that legitimately lack these keys are not collateral damage:

{
  "Sid": "EnforceNetworkPerimeterS3",
  "Effect": "Deny",
  "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "*",
  "Condition": {
    "StringNotEqualsIfExists": {
      "aws:SourceVpce": ["vpce-0a1b2c3d4e5f", "vpce-9z8y7x6w5v4u"]
    },
    "BoolIfExists": {
      "aws:PrincipalIsAWSService": "false",
      "aws:ViaAWSService": "false"
    },
    "Null": { "aws:SourceVpce": "false" }
  }
}

The Null check on aws:SourceVpce set to false means “this condition only applies when the request actually traversed a VPC endpoint” — combined with the service exemptions, it avoids denying console traffic that never had a VPCE in the first place. Tune the exact keys to your topology; the principle is to fail closed only for traffic you genuinely expect to be endpoint-bound.

The network condition keys, what each catches, and the guard each needs — the difference between a tight net and a self-inflicted outage:

A decision table for which network key to reach for, given your topology:

Durable EC2 controls with Declarative Policies

SCPs and RCPs deny actions. Declarative Policies are a different animal: they set a baseline service configuration that the service itself enforces and reports, and the setting persists even as AWS ships new APIs. For EC2 they are the cleanest way to mandate IMDSv2 and kill public sharing across the entire org — including future accounts — without writing a deny for every relevant action and chasing every new API AWS releases.

Enable the policy type, then attach a declarative policy that requires IMDSv2 on instance launch and blocks public AMI and public EBS snapshot sharing:

aws organizations enable-policy-type \
  --root-id "$ROOT_ID" \
  --policy-type DECLARATIVE_POLICY_EC2

{
  "ec2_attributes": {
    "exception_message": {
      "value": "Blocked by org data-perimeter declarative policy. Contact #cloud-platform."
    },
    "instance_metadata_defaults": {
      "http_tokens": { "value": "required" }
    },
    "image_block_public_access": {
      "state": { "value": "block_new_sharing" }
    },
    "snapshot_block_public_access": {
      "state": { "value": "block_all_sharing" }
    }
  }
}

What this buys you over a stack of SCP denies — and why declarative is the right tool here specifically:

Declarative vs SCP-deny for the same EC2 outcome — the head-to-head that explains the choice:

The headline wins: http_tokens: required forces IMDSv2 as the account default, neutering the SSRF-to-credential-theft path behind multiple high-profile breaches — new instances inherit it with no per-instance config. image_block_public_access and snapshot_block_public_access make accidental public AMI/snapshot sharing structurally impossible. exception_message is surfaced to the user on a block, so the failure is self-documenting. Attach to the sandbox OU first, verify with the service-state APIs, then promote:

# Verify the declarative policy actually took effect at the service layer
aws ec2 get-image-block-public-access-state --region ap-south-1
aws ec2 get-snapshot-block-public-access-state --region ap-south-1
aws ec2 get-instance-metadata-defaults --region ap-south-1

Staged rollout without locking yourself out

This is where teams either succeed or page themselves at 2 a.m. The discipline is simple to state and easy to skip: build the OU shape so you can roll forward, not just out. Attach to a leaf sandbox OU, then a non-prod OU, then prod, then root last. Org policy inheritance is cumulative, so a deny that is correct at the root is the last thing you attach, never the first.

Root                         <- attach RCP/SCP here LAST, after weeks of evidence
 |- OU Sandbox  (1 account)  <- attach FIRST, break things here on purpose
 |- OU NonProd               <- second wave
 |- OU Prod                  <- third wave
 |- OU Security              <- exempt or test in isolation

The wave plan as a table — what you attach where, what you watch, and the go/no-go gate for promoting:

Gather evidence before you deny anything. RCPs and SCPs have no audit-only mode, so you simulate the deny with a CloudTrail query first. Find any request in the last 90 days that your perimeter would have blocked — i.e., access to your resources by a principal whose org ID is not yours:

-- CloudTrail Lake: would the identity perimeter have broken anything?
SELECT eventTime, eventSource, eventName,
       userIdentity.arn AS principal,
       userIdentity.accountId AS caller_account,
       sourceIPAddress
FROM cloudtrail_event_data_store
WHERE eventSource IN ('s3.amazonaws.com', 'sts.amazonaws.com',
                      'kms.amazonaws.com', 'secretsmanager.amazonaws.com')
  AND userIdentity.accountId NOT IN (SELECT account_id FROM my_org_accounts)
  AND userIdentity.principalId != 'AWSService'
  AND eventTime > timestamp '2026-03-01 00:00:00'
ORDER BY eventTime DESC;

Every row is a relationship you must explicitly allowlist (next section) before the deny goes live. Zero rows in the sandbox after a soak period is your green light to promote. The pre-flight queries you should run, one per perimeter leg:

Keep an out-of-band break-glass role in the management account that is, by definition, never subject to RCPs or SCPs. If a perimeter policy ever wedges your delegated admin, that is your way back in. Test it before wave 1, not during an incident.

Exceptions: AWS services, SaaS roles, cross-org sharing

A real perimeter has documented holes. Manage them as named exceptions, not by weakening the baseline — the moment you relax the baseline “just for this vendor,” you have lost the perimeter.

AWS service principals — already handled by the aws:PrincipalIsAWSService / aws:SourceOrgID conditions in the identity RCP. Resist the urge to add per-service Sids; the generic exemption is more robust as AWS adds services.

Third-party SaaS roles — a vendor (observability, CSPM, backup) assumes a role in your account from their account, so aws:PrincipalOrgID will not match. Do not punch a hole in the RCP. Instead, scope the role trust policy precisely with the vendor’s account and the sts:ExternalId they issued you, and carve that single role out of the RCP by ARN:

{
  "Sid": "AllowVendorWithExternalId",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::210987654321:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "kloudvin-prod-7f3a9c2e" }
  }
}

To keep the RCP intact while permitting this single foreign principal, add an ArnNotLike carve-out for that role to the RCP’s deny condition so the vendor role is the only external ARN allowed through:

"Condition": {
  "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-abc123def4" },
  "ArnNotLikeIfExists": {
    "aws:PrincipalArn": "arn:aws:iam::*:role/vendor/ObservabilityIngest"
  },
  "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
}

Cross-org data sharing — when you genuinely share a bucket with a partner org, scope it to their org ID via aws:PrincipalOrgID on the bucket policy and add their org to a dedicated, reviewed allowlist in the RCP. Never relax to Principal: "*" without a condition.

The exception catalogue — every legitimate hole, how to scope it, and the wrong way teams do it:

The condition operators you’ll use for carve-outs, and exactly what each matches:

Architecture at a glance

The diagram traces a request as it actually flows through the perimeter, left to right, and pins each failure/control onto the exact hop where it bites. Read it as the path a call takes: a caller — which may be one of your principals inside a VPC, a foreign principal, or an anonymous client redeeming a presigned URL — sends an API request. Before it ever reaches your data, it passes the network perimeter (the VPC endpoint and the aws:SourceVpce RCP that fails closed if the call did not come through an approved endpoint), then the identity perimeter (the resource-side RCP checking aws:PrincipalOrgID, which rejects any caller from outside your org while exempting AWS service principals via aws:SourceOrgID), and only then reaches the protected data plane — S3, STS, KMS, SQS, and Secrets Manager. Running alongside, the resource perimeter SCP watches the outbound direction so your own principals cannot write to a foreign bucket, and the declarative EC2 baseline sits to the side pinning IMDSv2 and blocking public AMIs and snapshots on every account, present and future.

The numbered badges mark the five places this perimeter most commonly fails or fires: a network-RCP false-deny on console traffic that lacked a VPCE (badge 1), the identity-RCP rejecting a foreign or presigned-URL caller (badge 2 — the win condition), an over-broad deny accidentally blocking an AWS service principal because aws:SourceOrgID was omitted (badge 3), the resource-SCP catching an exfiltration write to a foreign org (badge 4), and the declarative baseline flipping an IMDSv1 instance to IMDSv2-required (badge 5). The whole method is in that path: every request must clear network trust and identity trust before it touches data, your principals are simultaneously fenced from foreign resources, and the EC2 fleet is pinned to a safe baseline that survives new APIs. Follow the arrows and you can see precisely why a leaked key replayed from a coffee shop returns AccessDenied while S3 replication to your DR org keeps flowing.

Real-world scenario

Meridian Pay, a fintech platform team, ran roughly 180 accounts with a clean SCP layer and felt well-governed — until a red-team engagement exfiltrated a customer dataset using a leaked CI/CD access key. The key, scraped from a verbose build log, generated an S3 presigned URL, and the data was pulled from a coffee-shop IP to an attacker-controlled bucket in a foreign account. The SCPs did nothing: the key was a legitimate org principal and the read was authorized. The board asked the one question that mattered — “if this were real, what stops it?” — and the honest answer was nothing we have today.

The constraint was brutal, because Meridian Pay’s data plane was a web of legitimate cross-account flows: a central data lake read by twelve consumer accounts, three SaaS integrations (observability, CSPM, and a backup vendor) with roles in production, and — the killer — S3 replication to a DR account in a separate org mandated by their regulator for blast-radius isolation. A blunt aws:PrincipalOrgID deny would have taken down the DR replication and all three SaaS integrations on day one, turning a security improvement into a self-inflicted outage and a failed audit.

They solved it with a layered RCP plus a network deny, rolled through the OU waves over three weeks. The DR-org replication was handled by adding the DR org’s ID to the StringNotEquals OR set so cross-org replication kept flowing; the three SaaS roles were carved out by ARN with sts:ExternalId on their trust policies; and the presigned-URL exfil path was killed by the network RCP — a presigned URL carries the signer’s identity, but the redemption came from outside any VPC endpoint, so aws:SourceVpce failed closed:

{
  "Sid": "DenyDataReadOutsideOrgAndNetwork",
  "Effect": "Deny",
  "Principal": "*",
  "Action": ["s3:GetObject"],
  "Resource": "*",
  "Condition": {
    "StringNotEqualsIfExists": {
      "aws:PrincipalOrgID": ["o-abc123def4", "o-dr9876fedc5"],
      "aws:SourceOrgID": "o-abc123def4"
    },
    "Null": { "aws:SourceVpce": "false" },
    "StringNotEqualsIfExists": {
      "aws:SourceVpce": ["vpce-0a1b2c3d4e5f"]
    },
    "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
  }
}

The CloudTrail Lake pre-flight surfaced exactly four foreign-principal relationships — the DR org, and the three vendor roles. All four were allowlisted before go-live; the rollout caused zero production incidents. The same leaked key, replayed by the red team post-deployment from the same coffee-shop IP, returned AccessDenied — the presigned URL was valid, the signer was a real org principal, but the redemption came from no trusted endpoint and the network RCP failed it closed.

The incident-to-fix arc as a timeline, because the order is the lesson:

The lesson on their wall afterward: “SCPs govern your people. A perimeter governs everyone — including the attacker holding your own key.”

Advantages and disadvantages

The RCP-plus-declarative model both closes the resource-side gap and introduces real operational weight. Weigh it honestly before you commit an org to it:

The model is right for any org past ~20 accounts with real data, credentials, cross-account flows, and a regulatory or risk reason to assume credentials will leak. It bites hardest on teams without a CloudTrail Lake / Athena pre-flight habit (they break things), teams that conflate SCP and RCP semantics (they write redundant or wrong policies), and orgs that treat exceptions as one-time rather than reviewed. Every disadvantage is manageable — but only with the staged rollout, the pre-flight, and the break-glass path this article insists on.

Hands-on lab

Stand up a minimal identity perimeter on a sandbox OU, prove a foreign-style read is denied, and tear it down. This is free — Organizations policies cost nothing; you pay only for any test data you create. Run with a management-account or delegated-admin profile.

Step 1 — Capture the org and root IDs.

ORG_ID=$(aws organizations describe-organization --query 'Organization.Id' --output text)
ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text)
echo "Org: $ORG_ID  Root: $ROOT_ID"

Expected: an o-xxxxxxxxxx org ID and an r-xxxx root ID.

Step 2 — Enable the RCP policy type (idempotent; ignore “already enabled”).

aws organizations enable-policy-type \
  --root-id "$ROOT_ID" --policy-type RESOURCE_CONTROL_POLICY 2>/dev/null || true
aws organizations describe-organization \
  --query 'Organization.AvailablePolicyTypes' --output table

Expected: a row showing RESOURCE_CONTROL_POLICY with status ENABLED.

Step 3 — Create a sandbox OU (or reuse one) and note its ID.

OU_ID=$(aws organizations create-organizational-unit \
  --parent-id "$ROOT_ID" --name "sandbox-perimeter-lab" \
  --query 'OrganizationalUnit.Id' --output text)
echo "Sandbox OU: $OU_ID"

Step 4 — Author the identity-perimeter RCP, substituting your org ID.

cat > /tmp/rcp-identity.json <<JSON
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "EnforceOrgIdentityPerimeter",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","sts:AssumeRole",
               "kms:Decrypt","secretsmanager:GetSecretValue"],
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "$ORG_ID",
        "aws:SourceOrgID": "$ORG_ID"
      },
      "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}
JSON

Step 5 — Create and attach the policy to the sandbox OU only.

RCP_ID=$(aws organizations create-policy \
  --name "rcp-lab-identity-perimeter" --type RESOURCE_CONTROL_POLICY \
  --content file:///tmp/rcp-identity.json \
  --query 'Policy.PolicySummary.Id' --output text)

aws organizations attach-policy --policy-id "$RCP_ID" --target-id "$OU_ID"
aws organizations list-policies-for-target \
  --target-id "$OU_ID" --filter RESOURCE_CONTROL_POLICY --output table

Expected: the attach succeeds and the list shows rcp-lab-identity-perimeter.

Step 6 — Prove it (conceptually) and read the CloudTrail evidence. From a sandbox-account principal, a read by your org principal still works (your org ID matches); a read attempted by a principal outside your org would be denied. Confirm what would fire:

# In CloudTrail (or CloudTrail Lake), a denied foreign read shows errorCode AccessDenied
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetObject \
  --max-results 5 --query 'Events[].CloudTrailEvent' --output text

Validation checklist — what each step proved, mapped to the real-world move:

Cleanup (no lingering cost, but tidy up).

aws organizations detach-policy --policy-id "$RCP_ID" --target-id "$OU_ID"
aws organizations delete-policy --policy-id "$RCP_ID"
aws organizations delete-organizational-unit --organizational-unit-id "$OU_ID"

Cost note. Organizations policies, OUs, and attachments are free. The only charges in this lab come from any S3/KMS test objects you create — pennies, and deleting them stops everything.

Common mistakes & troubleshooting

This is the playbook — the part you bookmark. First as a scannable table you can read mid-rollout, then the entries that bite hardest with full confirm-command detail.

The expanded form, with the full reasoning for the entries that cost the most hours:

1. Whole OU loses console and S3 access immediately after you attach the RCP. Root cause: You used StringNotEquals instead of StringNotEqualsIfExists. Many legitimate requests — console calls, some service paths — arrive without aws:PrincipalOrgID at all. With plain StringNotEquals, “key absent” is treated as “not equal to your org,” so the deny fires on everything. Confirm: CloudTrail shows AccessDenied on calls where aws:PrincipalOrgID is absent; the denied principals include your own console sessions. Fix: Change every StringNotEquals in the perimeter to StringNotEqualsIfExists. This is the single most common self-inflicted outage in RCP rollouts.

2. S3 replication or CloudTrail-to-bucket writes start failing after the identity RCP goes live. Root cause: You omitted aws:SourceOrgID from the exemption. When an AWS service (S3 replication, CloudTrail log delivery) acts on a resource you own, the call carries aws:SourceOrgID (your org) but not necessarily aws:PrincipalOrgID. Without exempting aws:SourceOrgID, the deny catches your own service traffic. Confirm: CloudTrail AccessDenied events with userIdentity.type = AWSService against your buckets, timed to the attach. Fix: List both aws:PrincipalOrgID and aws:SourceOrgID in the same StringNotEqualsIfExists block (an OR), so the deny fires only when both are foreign.

3. Console S3 access is denied after you add the network (aws:SourceVpce) RCP. Root cause: Console traffic never traverses a VPC endpoint, so aws:SourceVpce is absent — and your StringNotEqualsIfExists on aws:SourceVpce still fired because you forgot the Null guard, or the service exemptions. Confirm: Denied events originate from console sessions with no vpcEndpointId in the CloudTrail record. Fix: Add Null: {"aws:SourceVpce": "false"} (apply only when a VPCE was actually used) plus BoolIfExists exemptions for aws:PrincipalIsAWSService and aws:ViaAWSService. The network deny must fail closed only for traffic you expect to be endpoint-bound.

4. A SaaS vendor role can no longer assume into your account. Root cause: The vendor assumes from their account, so aws:PrincipalOrgID is foreign and the identity RCP’s sts:AssumeRole deny catches it — correctly, but you need this one exception. Confirm: CloudTrail AssumeRole with AccessDenied, source = the vendor’s account ID. Fix: Carve the specific role out with ArnNotLikeIfExists on aws:PrincipalArn, and require sts:ExternalId on that role’s trust policy so the carve-out is confused-deputy-safe. Never widen the org check.

5. The RCP attaches cleanly but denies nothing — the perimeter does not hold. Root cause: Either it is attached to an OU that does not contain the resources, or someone detached the implicit RCPFullAWSAccess baseline (or a typo means the Deny condition never matches). Confirm: aws organizations list-policies-for-target --filter RESOURCE_CONTROL_POLICY shows where it is attached; confirm RCPFullAWSAccess is still present alongside it. Fix: Attach at the OU/account that owns the resources; never detach the baseline; re-test with a deliberate foreign-style call.

6. Two foreign-org checks in separate statements over-block legitimate traffic. Root cause: You split aws:PrincipalOrgID and aws:SourceOrgID (or two partner org IDs) into separate Deny statements. Each statement denies independently, so the effective logic is “deny if foreign-by-principal OR deny if foreign-by-source” — an AND-of-denies that blocks service traffic the OR would have allowed. Confirm: Read the policy; you have two Deny blocks each with one key. Fix: Combine the keys into a single StringNotEqualsIfExists block — multiple keys in one block are an OR, which is what you want.

Error and API-exception reference

The exact error strings you will see — at the Organizations control plane when authoring/attaching, and at the data plane when the perimeter fires — with what each means and the move it calls for:

The CLI command reference

The commands you will reach for across the lifecycle — enable, author, attach, verify, roll back — in one place:

Best practices

Crisp, production-grade rules distilled from real rollouts:

• Never detach the RCPFullAWSAccess / FullAWSAccess baseline. Both are allow-all foundations; you only ever add deny statements on top.
• Use ...IfExists on every condition operator in the perimeter. The cost of forgetting it once is an OU-wide console lockout.
• Combine related foreign-org keys in one block (OR semantics). Splitting them into separate statements creates an AND-of-denies that over-blocks.
• Always exempt AWS service principals with aws:SourceOrgID and aws:PrincipalIsAWSService — the generic exemption is more robust than per-service Sids.
• Run the CloudTrail Lake pre-flight before every wave, scoped to that wave’s accounts. A prod-only foreign relationship will not appear in a sandbox scan.
• Attach sandbox → non-prod → prod → root, in that order. Root is last, after weeks of evidence, never first.
• Keep a break-glass role in the management account and test it before wave 1. The management account is inherently exempt — that is your safety net.
• Keep all data and workloads out of the management account. It is outside the perimeter; a bucket there is unprotected.
• Pair RCP and SCP — one for trusted identities on your resources, one for your principals on trusted resources. Neither alone is a perimeter.
• Add the network leg (aws:SourceVpce) for the presigned-URL / leaked-key-from-the-internet class. Identity trust alone passes a valid leaked key.
• Manage exceptions as named, reviewed carve-outs (ARN + sts:ExternalId), never by relaxing the baseline.
• Wire IAM Access Analyzer at the org zone of trust and drive external-access findings to zero-or-justified on a weekly cadence.
• Treat policies as code — version the JSON, review it, deploy via Terraform/pipeline, and diff the live attachment against the repo.

Security notes

The perimeter is the security control, but it has its own security properties to get right:

The defense-in-depth layering, from the credential outward — each layer assumes the one before it can fail:

The perimeter as an attacker would test it — each attack, the layer that catches it, and the single signal that proves the catch:

Cost & sizing

The good news on cost: the perimeter itself is free. AWS Organizations, SCPs, RCPs, declarative policies, OUs, and attachments carry no charge. What costs money is the evidence and verification machinery around them — and even that is modest. Here is what actually drives the bill:

A sizing rule of thumb: for an org of ~180 accounts, the dominant line is the CloudTrail Lake / Athena pre-flight, and even a 90-day, all-accounts scan of S3/STS/KMS/Secrets management events is typically single-digit dollars per query if you partition by date. The gateway VPC endpoint for S3 is free — prefer it over an interface endpoint for the network leg wherever your topology allows, and reserve paid interface endpoints for services that require them. The verification you should never cut to save cost is the per-wave pre-flight; a single missed foreign relationship that breaks production costs far more than the query.

Free-tier and always-free notes: Organizations and its policies are always free; the first CloudTrail trail of management events is free; IAM Access Analyzer external-access findings are free; gateway VPC endpoints are free. The only reliably-recurring spend is data-event capture and Lake/Athena scanning, both of which you control by scoping and partitioning.

Interview & exam questions

Mapped to AWS Certified Security – Specialty (SCS-C02) and Solutions Architect – Professional (SAP-C02), where data-perimeter and Organizations governance show up heavily.

1. What is the fundamental difference between an SCP and an RCP? An SCP evaluates against the principal making the request and can only constrain principals inside your organization. An RCP evaluates against the resource being acted on, for any caller — including principals from foreign orgs and anonymous callers. SCPs are the identity-side guardrail; RCPs are the resource-side guardrail. Both are deny-only and never grant.

2. A leaked, valid IAM key is used to read an S3 bucket via a presigned URL. Which control stops it, and why don’t SCPs? SCPs don’t, because the key is a legitimate org principal and the read is authorized — there is nothing on the identity side to deny. The network-perimeter RCP (aws:SourceVpce failing closed) stops it: the presigned URL’s redemption comes from outside any approved VPC endpoint, so the resource-side deny fires regardless of the valid signer.

3. Which services does RCP support at GA, and why those specifically? S3, STS, SQS, KMS, and Secrets Manager — the set of services that hold or broker data and credentials. Locking the resource side of exactly these closes the realistic exfiltration paths (object data, role assumption, queues, keys, secrets).

4. Why must you use StringNotEqualsIfExists rather than StringNotEquals in a perimeter deny? Because many legitimate requests arrive without the condition key (e.g., console calls with no aws:PrincipalOrgID). Plain StringNotEquals treats “key absent” as “not equal to your value,” firing the deny on legitimate traffic. IfExists skips the condition when the key is absent, so the deny only fires when the key is present and mismatched.

5. Your S3 replication breaks the moment the identity RCP attaches. What did you forget? The aws:SourceOrgID exemption (and/or aws:PrincipalIsAWSService). When an AWS service acts on a resource you own, the call carries aws:SourceOrgID (your org) but may lack aws:PrincipalOrgID. List both keys in the same StringNotEqualsIfExists block so the deny only fires when both are foreign.

6. What is a Declarative Policy and how does it differ from an SCP deny for enforcing IMDSv2? A declarative policy sets a durable service configuration baseline (e.g., http_tokens: required) that EC2 itself enforces and reports, and it persists even as AWS ships new launch APIs. An SCP deny on ec2:RunInstances with a metadata condition only blocks the actions you enumerate; declarative policy sets the default and survives new APIs, plus surfaces an exception_message.

7. Why is the management account special in a data perimeter? Neither SCPs nor RCPs apply to the management account’s own principals or resources, even when attached at the root. So you must keep all data and workloads out of it — and you can use a management-account role as a break-glass path that is inherently exempt from the perimeter.

8. How do you allow a third-party SaaS vendor to assume a role without weakening the RCP? Scope the role’s trust policy to the vendor’s account plus a sts:ExternalId, then carve that specific role out of the RCP with ArnNotLikeIfExists on aws:PrincipalArn. The org check stays intact for everyone else; the vendor is the only foreign ARN allowed through, and ExternalId makes it confused-deputy-safe.

9. Why do you stage attachment sandbox → non-prod → prod → root rather than attaching at root first? Org policy inheritance is cumulative and there is no audit-only mode. A deny attached at the root applies everywhere immediately; if it is wrong it breaks the whole org. Attaching at a leaf sandbox OU first lets you break things safely, gather evidence, and promote only after a soak — root is the last step, not the first.

10. How do you find what a perimeter would break before attaching it? Run a CloudTrail Lake (or Athena) query over the last ~90 days for access to your resources by principals whose account ID is not in your org (excluding AWS service calls). Every row is a foreign-principal relationship you must explicitly allowlist before the deny goes live. Zero unexpected rows in the target scope is your go signal.

11. What does aws:ResourceOrgID enforce, and which policy type uses it? It identifies the org that owns the target resource. You use it in an SCP (identity side) to stop your principals from writing to or reading resources in a foreign org — the exfiltration-outward direction. An RCP cannot enforce it because the foreign resource is outside your policy’s reach.

12. If an RCP Deny and an S3 bucket policy Allow conflict, which wins? The Deny wins. RCPs are evaluated alongside resource-based policies, and an explicit Deny in any applicable policy overrides any Allow. This is precisely why an RCP can close a hole that a permissive bucket policy left open.

Quick check

1. SCPs evaluate against the ______ side of a request; RCPs evaluate against the ______ side.
2. Name the five services RCP supports at GA.
3. Why must perimeter denies use ...IfExists operators?
4. Which two condition keys exempt legitimate AWS-service-to-service traffic in the identity RCP?
5. Which perimeter leg stops a valid leaked key replayed from the open internet, and which key does it use?

Answers

1. Identity (principal / caller) side for SCPs; resource (target) side for RCPs.
2. S3, STS, SQS, KMS, and Secrets Manager.
3. Because many legitimate requests lack the condition key (e.g., console calls with no aws:PrincipalOrgID); without IfExists, “key absent” is treated as a mismatch and the deny fires on legitimate traffic, locking out whole OUs.
4. aws:SourceOrgID (service acting on a resource you own) and aws:PrincipalIsAWSService (service-linked / log-delivery calls carrying no org key).
5. The network-perimeter RCP, using aws:SourceVpce (with a Null/IfExists guard) — it fails closed when the request did not traverse an approved VPC endpoint, even though the leaked key’s org ID passes.

Glossary

• Data perimeter — the set of controls asserting that only trusted identities, from trusted networks, touch your resources, and your principals only touch trusted resources.
• SCP (Service Control Policy) — an Organizations deny-guardrail evaluated against the calling principal; constrains only your org’s principals.
• RCP (Resource Control Policy) — an Organizations deny-guardrail evaluated against the target resource, for any caller including foreign/anonymous; GA Nov 2024 for S3, STS, SQS, KMS, Secrets Manager.
• Declarative Policy — an Organizations policy that pins a durable service configuration baseline (e.g., EC2 IMDSv2, public-access blocks) that the service enforces and reports, persisting across new APIs.
• RCPFullAWSAccess — the implicit allow-all baseline RCP; you layer deny statements on top and never detach it.
• aws:PrincipalOrgID — condition key holding the org ID of the calling principal; used in RCPs to reject foreign callers.
• aws:ResourceOrgID — condition key holding the org ID owning the target resource; used in SCPs to stop writes to foreign resources.
• aws:SourceOrgID — condition key holding the org ID of the resource owner during an AWS-service call; used to exempt service-to-service traffic.
• aws:PrincipalIsAWSService — boolean condition key, true when the request is made by an AWS service principal; used to exempt service-linked calls.
• aws:SourceVpce — condition key holding the VPC endpoint ID the request traversed; the basis of the network-trust leg.
• sts:ExternalId — an agreed shared secret on a cross-account role-assumption; defends against the confused-deputy problem for SaaS vendors.
• Confused deputy — an attack where a trusted intermediary (e.g., a role) is tricked into acting on an attacker’s behalf; mitigated by ExternalId and resource-side perimeter checks.
• IMDSv2 — the session-token-protected EC2 Instance Metadata Service version; required via http_tokens: required to neutralize SSRF-to-credential-theft.
• Break-glass role — a tightly-scoped management-account role, inherently exempt from RCPs/SCPs, used to recover if a perimeter policy wedges your admins.
• CloudTrail Lake — a managed, queryable event data store used here for the pre-flight scan that finds foreign-principal relationships before any deny goes live.

Next steps

• Lock down the org foundation these policies attach to with AWS Organizations: SCP Guardrails and Delegated Admin.
• Stand up the multi-account landing zone that hosts the OU structure in AWS Control Tower: Multi-Account Landing Zone.
• Deepen the cross-account exception pattern (External ID, session policies) in IAM Cross-Account Roles, External ID, Confused Deputy, Session Policies.
• Wire continuous external-exposure detection with IAM Access Analyzer: Unused Access, Policy Generation, Custom Checks.
• Build the network leg properly with VPC Deep Dive: Subnets, Routing, IGW, NAT, Endpoints and AWS PrivateLink: Service Provider and Consumer Cross-Account.