AWS Architecture Series #35 — The seven gates every AWS request passes through

Business Challenge

A platform team at a payments company introduces permissions boundaries. The goal is ordinary and sensible: developers can create IAM roles for their own services, but cannot create a role more powerful than themselves. The boundary policy is written, attached to the developer role, and reviewed by two people. It is correct.

Within a day, three pipelines fail. One cannot write to an S3 bucket it has written to for a year. One cannot decrypt with a KMS key whose key policy explicitly names it. One fails only in the production account, with the same code and the same role definition that works in staging.

The team starts debugging the way most teams do — by reading the identity policy, deciding it looks fine, and then adding permissions until something works. Two of the three pipelines are eventually fixed by granting broader access than they had before the boundary was introduced. The control meant to reduce privilege has increased it.

Nothing here is a bug. Every one of those three failures is the documented behaviour of a different gate, and the three gates are not the same kind of thing. The team was treating six policy types as one undifferentiated pile of permissions, and there is no way to debug that pile without knowing the order AWS reads it in.

Architecture

AWS documents the evaluation as an ordered pipeline, not a set. A request starts in a known state and passes through gates in a fixed sequence. The order is not a mnemonic somebody invented; it is the order the enforcement code runs, and the consequences of the ordering are what make certain combinations behave unintuitively.

The starting state is deny

AWS's wording is worth taking literally: by default, all requests are implicitly denied with the exception of the AWS account root user, which has full access. Permission is not a property a principal has; it is a conclusion reached by a policy statement, for one request, at one moment. Nothing carries over.

This is why "the role has S3 access" is an imprecise sentence that causes real confusion. The role has an identity policy containing a statement that will allow certain S3 actions on certain resources when no other gate objects. That is a much weaker claim, and the difference is where the three broken pipelines live.

Gate 1: the deny sweep runs before anything else

Before AWS decides whether anything allows the request, it looks across every applicable policy — SCPs, RCPs, resource-based, identity-based, boundaries and session policies alike — for a statement with "Effect": "Deny" that matches. One match anywhere ends the evaluation immediately with a final decision of Deny.

An explicit deny overrides an explicit allow, and no later gate can reverse it. There is no precedence between policy types at this stage and no notion of a more-specific policy winning. This is the single most useful property in the whole model, because it makes an explicit Deny the only construct in IAM that is genuinely unconditional.

Gates 2 and 3: the two organisation-level ceilings

Service control policies and resource control policies are both Organizations guardrails, and they are frequently described as a pair. They act on opposite ends of the request.

Gate 4: the resource-based policy, and why it is not symmetric

Within a single account, identity-based and resource-based policies combine as a union: the resulting permissions are the union of the permissions of the two types. An allow in either is sufficient. This is the opposite of every other combination in the model, and it is the reason a bucket policy can grant access that the role's own identity policy never mentions.

It goes further, and this is the part that surprises people. If a resource-based policy grants permission directly to an IAM role session ARN or an IAM user ARN, then an implicit deny in an identity policy, a permissions boundary or a session policy does not affect the outcome. Permission granted directly to a session is not filtered by the ceilings that would otherwise apply.

Name the role ARN instead and the behaviour changes: a resource-based policy that grants to a role ARN is still limited by an implicit deny in a permissions boundary or session policy. Two policies that read almost identically, one naming arn:aws:iam::111122223333:role/app and one naming arn:aws:sts::111122223333:assumed-role/app/session, pass through different gates.

Gates 5, 6 and 7: identity, boundary, session

The identity-based policy is the one most teams write and the only one many teams know exists. If nothing in it allows the action, the request is implicitly denied here.

The permissions boundary is a ceiling attached to the entity, and it intersects: the resulting permissions are the intersection of the two categories. It cannot grant. A boundary allowing s3:* gives nobody S3 access; it merely declines to remove it.

The session policy applies only when the principal is a role session or a federated user, and is passed at the moment credentials are minted. It is the most commonly forgotten gate precisely because it is not attached to anything you can list later — it lives in the AssumeRole call that created the session.

Why This Architecture Holds Up

It converts "why is this denied" into a finite checklist

Access debugging without the ordering is unbounded: any of six policy types might be responsible, and the natural move is to broaden whichever one you can edit. With the ordering, there are seven places to look and they have a sequence. The three broken pipelines in the opening resolve immediately once each is attributed to its gate — the S3 failure to a boundary intersection, the KMS failure to a key policy that granted to a role ARN rather than a session, the production-only failure to an SCP that exists in one account and not the other.

It tells you which policy is even capable of fixing the problem

Only gates 4 and 5 can grant. That single fact removes most of the wasted work in access debugging. If an SCP is the reason, no amount of identity policy will help; if a boundary is the reason, the fix is a boundary change or a different role, not a broader grant. Teams that do not know this reliably end up granting more than they started with, because they keep widening the one policy they have permission to edit until the symptom disappears.

The asymmetry between deny and allow is a design tool

An explicit Deny is the only unconditional construct available. Everything else is contingent — an allow can be removed by four different ceilings, a resource policy can be overridden by an SCP, a boundary can be replaced. This is why guardrails that must genuinely hold are written as explicit denies with narrow conditions rather than as narrow allows, and why an SCP with a Deny on cloudtrail:StopLogging is worth more than any number of carefully scoped grants.

Cross-account is the same pipeline, run twice

There is no separate cross-account algorithm to learn. AWS performs two evaluations, one in each account, and the request is allowed only if both evaluations return a decision of Allow. The trusted account evaluates the identity policy and the things that limit it; the trusting account evaluates the resource policy and the things that limit it. Both must independently reach Allow.

Key Architecture Decisions

What each gate can and cannot do

Reference: a guardrail that holds at gate 1

An SCP written as an explicit deny with a condition exception. The Deny is evaluated in the first sweep, so no identity policy, resource policy or boundary in any member account can reverse it — while the condition keeps a named break-glass role usable.

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

Note what this does not do: it grants nobody the ability to manage CloudTrail. The break-glass role still needs an identity policy allowing those actions. The SCP has only declined to remove a permission that something else must still grant — which is the defining property of every gate except 4 and 5.

Closing Thought

Most IAM debugging difficulty comes from a single missing distinction: the difference between a policy that grants and a policy that declines to remove. Five of the seven gates only ever subtract. Written down that way it is obvious; encountered at 2am against a pipeline that worked yesterday, it is not, and the instinct is always to add permissions to the one policy you can edit.

The ordering is worth learning as an ordering rather than as a list of policy types, because the surprising behaviours are all consequences of position. Resource-based policies behave asymmetrically because they sit ahead of the three narrowing gates. Explicit denies are absolute because the sweep runs first. Cross-account requires agreement from both sides because the pipeline runs twice. None of that is arbitrary once the sequence is in view.

The practical test for any access control you design: which gate is it, and can that gate say yes? If the answer is that it cannot grant — an SCP, an RCP, a boundary, a session policy — then it is a ceiling, and a ceiling with nothing underneath it protects an empty room. Pair it with the grant that it is bounding, and check that the grant cannot arrive by a route the ceiling does not cover.

Official AWS Reference

• AWS Documentation — How AWS enforcement code logic evaluates requests to allow or deny access
• AWS Documentation — Policy evaluation logic
• AWS Documentation — Cross-account policy evaluation logic
• AWS Documentation — Resource control policies (RCPs)
• AWS Documentation — Quotas and service limits for AWS Organizations
• AWS Documentation — IAM and AWS STS quotas