You wrote the data perimeter. Can you prove it holds?

A data perimeter is one of the strongest preventive controls AWS offers: always-on guardrails that ensure only trusted identities reach your trusted resources, and only from networks you expect. You build it from service control policies, resource control policies, and VPC endpoint policies, and AWS publishes a full set of example policies to start from. You can write every one of them and attach them across your organization. None of that answers the question that matters at audit time: does the perimeter actually hold? Is there a principal, a resource, or a network path that still slips through? Writing the guardrail and proving it holds are two different jobs.

Three perimeters, six questions

AWS frames the data perimeter as three boundaries, each enforced in two directions. The identity perimeter: only trusted identities can access your resources, and only trusted identities are allowed from your network. The resource perimeter: your identities can access only trusted resources, and only trusted resources can be reached from your network. The network perimeter: your identities can reach resources only from expected networks, and your resources can be reached only from expected networks. Six control objectives, enforced with three policy types — SCPs on the identity side, RCPs on the resource side, and endpoint policies on the network side.

Trusted has precise definitions. Trusted identities are the principals in your accounts, plus AWS services acting on your behalf. Trusted resources are the resources your accounts own. Expected networks are your VPCs and on-premises ranges. The example policies express those definitions with organization IDs, account lists, VPC IDs, and corporate IP ranges — the values you substitute in when you deploy them.

Why writing it is not proving it

A deployed perimeter is not one policy. It is an SCP at one organizational unit, an RCP at another, an endpoint policy on each VPC, a resource policy on the buckets that predate RCP support, and a web of conditions and exception tags threaded through all of them. The guardrails interact, they span every account in the organization, and several of them turn on values that exist only at request time — the source VPC, the source IP, a principal tag, a resource tag. Reading two hundred policy statements does not tell you who actually slips through the seams where they meet.

This is the same wall the conditional-access label runs into: a scanner that reads policies at rest sees the conditions but cannot resolve them, so the cross-cutting result comes back as conditional rather than as a list. The way through is to stop reading the policies and start asking the perimeter questions as queries — evaluating the whole chain, across accounts, with the runtime values supplied.

Prove each boundary with a query

Take the boundaries one at a time and pair each with the question that proves it. Start with the identity perimeter — only trusted identities should reach your resources. The proof is the empty result to its inverse: every principal that can read a sensitive bucket, filtered to those whose account is outside your organization.

readers = who-can(
    action: "s3:GetObject"
    resource: var:sensitive-buckets
)

readers where self.account() not in var:org-accounts

The resource perimeter is the mirror image of that query — your own identities reaching a resource outside the organization — proven the same way, with the populations flipped. The network perimeter is a different shape: it turns on a condition, the source network, so it becomes a parameter. Pin a source that is not one of your VPCs and ask who still gets through.

who-can(
    action: "s3:GetObject"
    resource: var:sensitive-buckets
    env: {"aws:sourcevpc": "vpc-untrusted"}
)

The governance trap: who can leave the perimeter?

The example policies carve out exceptions with tags — a principal tagged dp:exclude:identity is exempt from the identity perimeter, dp:exclude from all of it. That is a deliberate and necessary feature. It is also the biggest blind spot in the perimeter, because the exception is only as strong as control over the tag. A principal that can set dp:exclude on itself can walk straight out of every boundary you built. The AWS governance policy examples exist precisely to lock those tags down, which makes the audit question simple: who can write them?

perimeter-admins = principals where self.Tags has (
    self.Key == "team" & self.Value == "admin"
)

taggers = who-can(
    action: "iam:TagRole"
    resource: roles
)

taggers where self not in perimeter-admins

What the perimeter does not cover

Two honest boundaries. First, a data perimeter is a set of IAM authorization controls — AWS is explicit that it does not cover network traffic inspection or encryption, and neither does evaluating it. Proving the authorization side holds is not the same as proving a packet cannot leave; the network and data controls AWS keeps separate are still yours to run. Second, the perimeter inherits the health of your fundamentals — account structure, tagging discipline, change management. A query proves that the policies you have evaluate the way you intend; it cannot invent a guardrail you never wrote.

The takeaway

A data perimeter is the rare control that is genuinely preventive — it stops the access instead of alerting on it afterward. That is exactly why it is worth proving rather than assuming. You already did the hard part of writing the policies. Turn each boundary into the question it is meant to answer, evaluate it across the whole organization, and read the verdict: empty, or the precise list of what still gets through.