Son équipe gère le compte Account A, qui héberge un Transit Gateway, quelques subnets bien configurés, et le fameux reports-bucket. Une nouvelle équipe vient d'arriver avec son propre compte, Account B, et elle a besoin d'accéder à tout ça : déployer des instances dans les subnets d'Alice, lire des objets dans son bucket, router son trafic via son Transit Gateway.

Alice ouvre la documentation AWS et découvre qu'il existe au moins quatre mécanismes pour "partager entre comptes" : AWS RAM, les resource policies, les cross-account roles, et le VPC peering. Quatre mécanismes, quatre pages de doc différentes, et aucune qui explique clairement quand utiliser lequel.

C'est exactement ce qu'on va régler ici, avec un arbre de décision que vous pourrez réutiliser à chaque fois que la question se pose.

L'arbre de décision

La logique tient en une question d'entrée : qu'est-ce que Account B a besoin de faire, exactement ?

1. Ses ressources doivent communiquer au niveau réseau avec celles d'Account A (une instance dans B doit atteindre une base dans A) → c'est un problème de connectivité : VPC Peering, Transit Gateway ou PrivateLink.

2. Il doit utiliser une infrastructure qui vit dans Account A (déployer dans un subnet d'Alice, s'attacher à son Transit Gateway) → c'est un problème de partage d'infrastructure : AWS RAM.

3. Il doit appeler l'API d'une ressource d'Account A (lire un objet S3, déchiffrer avec une clé KMS, publier dans une queue SQS) → c'est un problème d'accès API : resource policy ou cross-account role. Trois familles de besoins, trois familles de solutions. Le reste de l'arbre affine à l'intérieur de chaque branche.

Branche 1 — Connectivité réseau

Si le besoin est que des ressources se parlent au niveau IP, aucun des mécanismes IAM ne vous aidera. Trois options selon la topologie :

• Deux VPC qui doivent se parler, point. → VPC Peering. Simple, gratuit en intra-région (hors data transfer), mais non transitif : si A est peeré avec B et B avec C, A ne voit pas C.

• Plusieurs VPC, plusieurs comptes, une topologie hub-and-spoke. → Transit Gateway. C'est le routeur central. Et détail intéressant : le TGW lui-même se partage entre comptes... via RAM. Les branches de l'arbre se rejoignent.

• Exposer un seul service, sans ouvrir tout le réseau. → PrivateLink. Account A expose un endpoint service, Account B crée un interface endpoint. Aucune table de routage partagée, surface d'attaque minimale.

Branche 2 — Partager l'infrastructure : AWS RAM

AWS Resource Access Manager permet à Account A de partager la ressource elle-même avec Account B. Pas une copie, pas un accès API : la ressource apparaît dans la console d'Account B comme si elle y vivait.

Le cas d'usage roi : les subnets partagés. Alice garde le contrôle du VPC (routing, NACLs, flow logs) dans Account A, et l'équipe d'Account B déploie ses instances dedans. Séparation nette entre l'équipe réseau et les équipes applicatives — le pattern de landing zone le plus propre que je connaisse.

Deux choses que la documentation ne met pas assez en avant :

1. RAM ne partage pas n'importe quoi. La liste des types supportés est précise : subnets, Transit Gateways, règles Route 53 Resolver, prefix lists, configurations License Manager, et quelques autres. Un bucket S3 ou une table DynamoDB ne se partagent pas via RAM. Si votre ressource n'est pas dans la liste, retournez à la branche 3.

2. Le partage intra-Organization doit être activé explicitement. C'est le piège dans lequel je suis tombé en montant le lab qui a inspiré cet article. Si Account A et Account B sont dans la même AWS Organization, le partage peut être automatique — pas d'invitation à accepter côté B. Mais seulement si quelqu'un a d'abord exécuté :

aws ram enable-sharing-with-aws-organization

Sans ça, même en intra-Org, chaque partage passe par le flux d'invitation manuel, et vous allez perdre vingt minutes à chercher pourquoi "ça ne marche pas". Vécu.

Branche 3 — Accès API : resource policy ou cross-account role ?

C'est ici que vivent les cas les plus fréquents : S3, KMS, SQS, SNS, Lambda, Secrets Manager. Deux mécanismes, et le choix entre les deux est plus structurant qu'il n'y paraît.

Option A — Resource policy

Account A attache une policy directement sur la ressource, qui autorise un principal d'Account B :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccountBRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:role/analytics-role"
      },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports-bucket/*"
    }
  ]
}

Rappel de l'épisode précédent : c'est le double opt-in. Cette resource policy côté A ne suffit pas — il faut aussi que le principal côté B porte une identity policy qui autorise s3:GetObject sur ce bucket. Les deux comptes doivent dire oui.

Le point clé de la resource policy : le principal d'Account B garde sa propre identité. Il appelle l'API en son nom, avec ses propres credentials.

Option B — Cross-account role

Account A crée un rôle avec une trust policy qui autorise Account B à l'assumer :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "alice-reports-2026" }
      }
    }
  ]
}

Le principal d'Account B appelle sts:AssumeRole, récupère des credentials temporaires, et agit désormais en tant que rôle d'Account A. Il change de casquette.

Comment choisir entre les deux

La question déterminante n'est pas technique, elle est d'audit : quelle identité voulez-vous voir dans CloudTrail ?

Avec une resource policy, les événements CloudTrail montrent le principal d'Account B, avec son identité d'origine. Traçabilité directe : on sait exactement qui dans l'autre compte a touché la ressource.

Avec un cross-account role, les événements montrent le rôle d'Account A. L'identité d'origine existe dans la session (le champ sts:AssumeRole est logué côté B), mais reconstituer "qui a fait quoi" demande de croiser les trails des deux comptes. Sur un audit de sécurité, cette différence n'est pas un détail.

Règle pratique :

• Accès ciblé à une ressource précise, traçabilité maximale → resource policy.

• Accès large à plusieurs services, ou le service ne supporte pas les resource policies (EC2, la plupart des appels de management) → cross-account role.

Le tableau récapitulatif

Le takeaway

RAM partage l'infrastructure, les policies partagent l'accès, les rôles partagent l'identité.

Si vous ne retenez qu'une ligne de cet article, c'est celle-là. La prochaine fois qu'un collègue demande "comment on donne accès au compte B ?", commencez par demander à quoi — la réponse tombe toute seule.

Vous structurez une organisation multi-comptes et vous voulez vérifier que vos accès cross-account ne sont pas une passoire ? Les prochains articles de la série creuseront les patterns de gouvernance — abonnez-vous pour ne pas les rater.

Here's each method, its trade-offs, and a simple rule for choosing.

The big split first

Before the details, one distinction explains everything:

• ACLs and bucket policies let the outsider reach in while keeping their own identity. Access still requires both sides to agree (the caller's identity policy and the bucket's grant).

• IAM roles let the outsider become an insider. They assume a role that lives in Account B and act as a local B identity from then on.

Keep that in mind and the rest falls into place.

1. ACL — the legacy option

ACLs grant access to another account using its canonical ID, directly on the bucket or object.

Pros

• Simple for one narrow case: granting another account blunt access to specific objects.

Cons

• Coarse-grained — only crude permissions (READ, WRITE, FULL_CONTROL). No conditions, no fine-grained actions.

• AWS now recommends turning ACLs off (Object Ownership → "Bucket owner enforced," the default since April 2023).

Verdict: Avoid for new work. You'll meet ACLs in old tutorials and inherited buckets, not in anything you'd build today.

2. Bucket policy — the everyday choice

A single resource policy attached to the bucket, naming the other account's principal.

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111111111111:user/Alice" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::accountB-bucket/*"
}

Pros

• Clean and centralized — one document on the bucket controls who gets in.

• Supports conditions (IP, encryption, MFA) and fine-grained actions.

• Easy to read and audit.

Cons

• S3-only. It doesn't help if the other account also needs DynamoDB, SQS, etc.

• Still requires the caller's identity policy to allow the action on their side.

Verdict: The default for straightforward S3 sharing. If the job is "let Account A read/write this bucket," reach for this first.

3. IAM role — the heavyweight

Account B creates a role with a trust policy naming Account A. Alice calls sts:AssumeRole, gets temporary credentials, and operates as that role inside B.

Pros

• The most powerful and flexible option — works for any service, not just S3.

• Temporary credentials (auto-expiring), clean CloudTrail trail of who assumed what.

• Great when the external party needs broad or ongoing access.

Cons

• More moving parts: a role, a trust policy, and sts:AssumeRole permission on the caller's side.

• Overkill if all you need is access to a single bucket.

Verdict: Use when access spans multiple services, needs to be temporary, or when you want the external account's users to behave like local ones.

Quick decision guide

The one-line takeaway

Bucket policy for everyday S3 sharing, IAM role when the need is bigger than one bucket, and ACL only when history forces your hand. Reach for the simplest tool that fits — and that's almost never the ACL.

Part of a series where I break down AWS concepts as I learn them. Follow along if clear, no-fluff explanations are your thing.

Building A is where Alice works. Building B is across the street, owned by a different company, full of vaults she'd love to peek inside. Alice wants to walk over and read a file from one of B's vaults.

Common sense says she needs two things to pull this off:

1. Her own company has to let her leave the building on this errand.

2. The other company has to let her in.

That's it. That's the entire AWS cross-account model. Hold onto the two-buildings picture and the rest is just paperwork.

The rule, in one line

For a principal in Account A to touch a resource in Account B, A must allow the request out, and B must allow it in. Both. Always.

AWS people say it as "allowed from A, and allowed into B." Same thing. Two doors, both must open.

Door 1: "Allowed from A"

This is Alice's identity policy — the badge clipped to her, issued by her own company. It says she's permitted to make this kind of trip.

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::buildingB-vault/*"
}

No badge, no errand. Even if Building B leaves its front door wide open, Alice never makes it out of her own lobby.

Door 2: "Allowed into B"

This is Building B's policy — set by B's owners, deciding who they'll buzz in. In AWS this is the resource policy on the thing being accessed (an S3 bucket, a KMS key, a queue), and the giveaway is the Principal field naming exactly who's welcome.

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111111111111:user/Alice" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::buildingB-vault/*"
}

B is saying, by name: "Alice from across the street? Yeah, let her in."

Open both doors and Alice walks straight through. Close either one and she gets the AWS equivalent of a polite security guard's hand on her chest: AccessDenied.

The twist that trips everyone up

Here's where it gets interesting — and where most people's mental model quietly breaks.

Inside one building, the rule is an OR. If Alice wants a file from a vault in her own Building A, she only needs one yes — either her badge allows it, or the vault's own policy welcomes her. Either door is enough, because it's all one company.

Between buildings, the rule flips to an AND. Now she needs both yeses — her badge to leave, and B's policy to enter. One missing door is a hard stop.

So crossing the street raises the bar from "somebody said yes" to "everybody said yes." That single shift from OR to AND is the whole concept. If you remember nothing else, remember that.

The "wait, he only did one door!" moment

You'll hit a tutorial that attaches only a bucket policy — just Door 2 — and access works anyway. For a second it looks like the two-door rule is a lie.

It isn't. Look at who the policy lets in. It's almost always a principal like iamadmin — an administrator who already carries AdministratorAccess. That admin badge already grants s3:* on everything, which means Door 1 was open before the tutorial even started. The instructor only had to add the second door because the first was already wide open.

Swap that admin for a fresh user with an empty badge, attach the same bucket policy, and watch it fail instantly. The rule was never broken — one door was just already unlocked off-screen.

The takeaway

Cross-account access is a handshake, not a handout. Two independent parties, two separate policies, both saying yes:

• Door 1 (from A) — the caller's identity policy lets them out.

• Door 2 (into B) — the resource policy lets them in.

Same building? One yes will do. Across the street? It takes two.

Now go open both doors.

Enjoyed this? I'm writing up AWS concepts as I work through them — clear explanations, no hand-waving. Follow along if that's your thing.

You're not alone. AWS has six distinct policy types, and they all look like nearly identical JSON. The difference isn't in how they're written — it's in where they attach and what job they do in the evaluation pipeline.

In this article I'll break down all six, give you a concrete JSON example of each, and leave you with a mental model that actually sticks. To keep things tangible, every example revolves around the same character: a developer named Alice, in account 111122223333, who wants to read from an S3 bucket called reports-bucket.

Let's go.

First, the one rule that governs everything

Before the policy types, you need the evaluation logic, because it explains why each type behaves the way it does. For a request inside a single account, AWS asks three questions in order:

1. Is there an explicit Deny? → If yes, denied. Full stop. No appeals.

2. Is there an Allow? → If yes (and no deny), allowed.

3. Is there nothing at all? → Denied by default. This is the implicit deny.

Summarized: explicit Deny → Allow → implicit Deny.

Keep this in your head. Every policy type below is just a different place where an Allow or a Deny can live.

A quick map of the six types

Here's the whole landscape in one table. If you remember nothing else, screenshot this.

The single most important insight in this whole table: only two types actually grant permissions — identity policies and resource policies. Everything else can only restrict. They are ceilings, not grants. A permission boundary that "allows" s3:* doesn't give you anything — it just refuses to take s3:* away.

Now let's look at each one.

1. Identity policy — "What can this identity do?"

This is the one you'll write most often. It attaches directly to an IAM user, group, or role, and it lists what that identity is allowed to do.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::reports-bucket",
        "arn:aws:s3:::reports-bucket/*"
      ]
    }
  ]
}

Attach this to Alice and she can now list and read the bucket. Notice what's missing: there's no Principal field. Why? Because the principal is implicit — it's whoever this policy is attached to. The policy travels with the identity.

By default, a freshly created IAM identity can do nothing. Identity policies are what bring it to life.

💡 Identity policies come in three flavors: AWS managed (prebuilt, like ReadOnlyAccess), customer managed (you write them, reuse them across identities — best practice), and inline (embedded in one identity, die with it). Prefer customer managed for anything non-trivial.

2. Resource policy — "Who can access this resource?"

A resource policy attaches to the resource itself — an S3 bucket, a KMS key, an SQS queue, a Lambda function. It looks at access from the opposite direction: instead of "what can Alice do," it says "who is allowed to touch me."

Here's the bucket policy on reports-bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAliceRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:user/Alice"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::reports-bucket/*"
    }
  ]
}

The dead giveaway that you're looking at a resource policy is the Principal field. Identity policies don't have one; resource policies require one — because the resource has to say who it's granting access to.

The superpower of resource policies is cross-account access. A bucket in account B can directly grant a user in account A, with no policy needed in B for that user. This is the foundation of most cross-account patterns in AWS.

3. SCP (Service Control Policy) — the account-wide ceiling

SCPs live at the AWS Organizations level. You attach them to an Organizational Unit or an account, and they set the maximum set of permissions anyone in that account can ever have.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RegionLock",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "eu-west-1"
        }
      }
    }
  ]
}

This says: "Anyone in this account — including admins — can only operate in eu-west-1." Alice could be carrying AdministratorAccess and she still couldn't launch a thing in us-east-1.

The critical thing to internalize: SCPs never grant permissions. If an SCP "allows" S3, that doesn't give anyone S3 access — they still need an identity policy for that. The SCP just defines the outer boundary of what's possible in the account. It's a filter, not a faucet.

4. Permission boundary — the per-identity ceiling

A permission boundary does for a single identity what an SCP does for a whole account: it caps the maximum. You attach it to a specific user or role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MaxAllowed",
      "Effect": "Allow",
      "Action": ["s3:*", "ec2:Describe*"],
      "Resource": "*"
    }
  ]
}

Attach this to Alice and her effective permissions become the intersection of her identity policy and this boundary. If her identity policy grants iam:CreateUser, the boundary silently blocks it — iam isn't in the ceiling. She can only ever act within s3:* and ec2:Describe*, no matter what her identity policy claims.

The killer use case is safe delegation. You can let a junior dev create their own IAM roles, while a permission boundary (enforced with a condition) guarantees that every role they create inherits the same cap. You hand out the power to create without handing out the power to escalate. They can build roles all day; none of them can ever be more powerful than the boundary.

5. Session policy — the one-session ceiling

A session policy is the most ephemeral of the bunch. It's passed inline at the moment you call sts:AssumeRole, and it only applies to that single temporary session. It's stored nowhere permanently.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ThisSessionReadOnly",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::reports-bucket/*"
    }
  ]
}

Imagine Alice assumes a role that normally allows s3:*. If she's running a script and wants a safety net, she can pass this session policy to downscope that session to read-only on one bucket. Same role, deliberately narrowed for one task.

Like SCPs and boundaries, a session policy can only restrict, never expand. You can't pass a session policy that grants more than the role already has.

6. Explicit Deny — the override that lives everywhere

Here's the twist: "explicit Deny" isn't really its own policy type. It's a "Effect": "Deny" statement that can live inside any of the five types above. I'm listing it separately because it behaves so differently that it's worth treating as its own concept.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BlockDeletion",
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::reports-bucket/*"
    }
  ]
}

If this statement exists anywhere in the chain, Alice cannot delete objects from reports-bucket — even if ten other policies grant her s3:*. An explicit Deny is absolute. It's the emergency brake of the entire IAM system, and it's evaluated first for exactly that reason.

Putting it all together

So how do these six interact when a real request comes in? AWS walks them in a fixed order, and the request must survive the whole gauntlet:

1. Explicit Deny anywhere → denied instantly.

2. SCPs → if they exist and don't allow it → denied.

3. Resource policies → if one allows it → ✅ done, allowed (the cross-account shortcut).

4. Permission boundaries → if one exists and doesn't allow it → denied.

5. Session policies → if one exists and doesn't allow it → denied.

6. Identity policies → if one allows it → ✅ allowed. Otherwise → implicit deny.

Notice the asymmetry, because it's the whole point:

• Identity and resource policies are the only two doors marked ✅ allow.

• SCPs, boundaries, and session policies are walls — they can only say no or step aside.

• Explicit Deny trumps all of them.

The one-sentence takeaway

If you walk away with a single sentence, make it this:

Two policy types grant (identity + resource); three policy types cap (SCP, boundary, session); and an explicit Deny beats them all.

Once that clicks, the rest of IAM stops feeling like a wall of identical JSON and starts feeling like a system you can actually reason about.

Thanks for reading. If this helped, I'm publishing more AWS deep-dives as I work through my Solutions Architect Professional prep — feel free to follow along.

It's one of the most misunderstood concepts in AWS IAM — and the misunderstanding has real consequences when you start delegating role creation across a team. Here's the correct mental model, and the use case that makes it click.

The mental model most engineers get wrong

When developers first encounter Permission Boundaries, the intuition is to read them as an additional allow layer: "this defines what the identity can also do."

That intuition is wrong, and it's the root of most broken IAM designs I've seen.

The correct model is the opposite:

A Permission Boundary doesn't grant any permissions. It defines the maximum permissions that an identity-based policy can ever grant.

It's a ceiling. Not a floor. Not an additive layer. A hard cap.

If an IAM user has an identity policy that says Allow s3:*, but a Permission Boundary that says max = s3:GetObject, the effective permissions are just s3:GetObject. The boundary didn't grant GetObject — the identity policy did. The boundary simply refused to let the rest of s3:* through.

The formula:

Effective permissions = Identity Policy ∩ Permission Boundary

Both must allow the action. The boundary alone allows nothing.

The use case that makes it click: delegating role creation

The textbook definition doesn't stick until you see the real problem Permission Boundaries solve.

Picture a growing AWS team. Developers constantly need IAM roles for their Lambda functions, EC2 instances, and CI/CD pipelines. The admin becomes the bottleneck. The obvious move: give developers iam:CreateRole and iam:AttachRolePolicy so they can self-serve.

The problem is immediate. A developer with iam:CreateRole + iam:AttachRolePolicy can create a role with AdministratorAccess attached. Privilege escalation in one API call. The entire account is exposed.

This is exactly what Permission Boundaries were designed to solve.

The pattern:

1. Define a Permission Boundary policy — call it DeveloperBoundary — listing the maximum permissions any role created by a developer is allowed to have. Read/write on specific S3 buckets, invoke specific Lambdas, write to specific DynamoDB tables. No IAM admin, no billing, no organization access.

2. Grant developers permission to create and manage roles — with a condition: any role they create must have DeveloperBoundary attached as its Permission Boundary.

The condition in the delegated policy:

{
  "Effect": "Allow",
  "Action": [
    "iam:CreateRole",
    "iam:AttachRolePolicy",
    "iam:PutRolePolicy"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DeveloperBoundary"
    }
  }
}

Now the developer can create as many roles as they need. They can attach AdministratorAccess to those roles if they want — it doesn't matter. The boundary caps the effective permissions at whatever DeveloperBoundary allows. The escalation path is closed.

This is where Permission Boundaries stop being abstract and become the only clean answer.

Three things that look alike but do different jobs

Most IAM confusion comes from mixing up three mechanisms that share JSON syntax but serve different purposes:

• IAM policies — grant permissions to an identity.

• Permission Boundaries — cap the maximum permissions an identity-based policy can grant. Grant nothing on their own.

• SCPs (Service Control Policies) — also a ceiling, but applied at the AWS Organization level, across entire accounts. Cap what anyone in the account can do, including the root user.

All three can deny. Only IAM policies grant. Mixing these up is how teams end up with mysterious AccessDenied errors that take half a day to debug.

Two takeaways

1. Permission Boundaries are a delegation tool, not a personal restriction. You rarely put a boundary on your own admin user. You put boundaries on identities you want to give bounded freedom to.

2. If you can't articulate what a feature doesn't do, you don't fully understand it. "Permission Boundaries set max permissions" is the textbook answer. Designing the delegation pattern above requires the deeper distinction — that the boundary grants nothing, ever.