AWS Architecture Guide

Resource Policies, Permission Boundaries, and Cross-Account Access

Goal

Extend the IAM model to cases where permissions span accounts and where architects need stronger safety rails.

This section builds around one durable idea:

AWS access control becomes clearer when each control layer has a distinct job: who may assume, what they may do, and how far delegation may go.

The Short Version

By this point in the chapter, we already have three important ideas:

  • identity-based policies describe what an identity may do,

  • trust policies describe who may assume a role,

  • and temporary credentials are the preferred way to carry access.

This section adds three more control layers:

  • resource-based policies let the resource declare who may access it,

  • permission boundaries cap what delegated identities may ever receive,

  • and cross-account access uses trust plus scoped permissions so accounts do not need duplicate local users.

Think of them like this:

Trust policy:          Who may enter?
Permission policy:    What may they do after entry?
Permission boundary:  What is the maximum delegation ceiling?
Resource policy:      Does the target resource also trust this caller?

When a Resource Policy Is the Right Tool

Identity-based policies answer, "What can this identity do?"

Resource-based policies answer, "Who can access this resource?"

AWS documentation notes that resource-based policies attach directly to resources such as S3 buckets, SQS queues, KMS keys, VPC endpoints, DynamoDB tables, and IAM role trust policies. They can grant access to principals in the same account or in other accounts.

This matters most when the resource itself is the trust boundary. Examples include:

  • an S3 bucket shared with another account,

  • an SQS queue that accepts messages from a specific producer,

  • a KMS key that must trust particular principals,

  • or a role whose trust policy must name who can assume it.

Within the same account, AWS generally evaluates identity-based and resource-based permissions together, and an explicit deny still overrides an allow.

What Permission Boundaries Actually Solve

Permission boundaries are often misunderstood. They do not grant day-to-day access. AWS defines them as a managed policy that sets the maximum permissions an identity-based policy can grant to a user or role.

That makes them a delegation tool.

They are useful when a platform or security team wants to let another team create or manage roles, but only inside an approved ceiling.

For example:

  • a development team may create application roles,

  • but those roles must stay inside an allowed service set,

  • must not create new IAM administrators,

  • and must not escape the approved operating model.

The boundary helps enforce that ceiling even if someone later attaches a broader identity-based policy.

The important caution is that a boundary is not a replacement for review, SCPs, or account design. It is one layer in a larger safety model.

Cross-Account Access Without Shared Credentials

Cross-account access is where these ideas become concrete.

The clean AWS pattern is usually:

  1. Create a role in the target account.

  2. Configure the trust policy to trust a specific principal or account from the source side.

  3. Attach permission policies to the role so the assumed session gets only the required actions.

  4. If needed, use resource-based policies on target resources to further restrict access.

This is better than creating duplicate IAM users in every account or sharing long-lived credentials between teams.

AWS documentation for cross-account roles is explicit about the intent: users in one account assume a specific role in another account rather than maintaining separate local users everywhere.

Example: Central Platform Team and Workload Accounts

Imagine a central platform team managing deployment standards across many workload accounts.

The platform team needs:

  • a deployment role in each workload account,

  • trust scoped to the platform automation path,

  • permissions limited to the resources it should manage,

  • and confidence that workload teams cannot create unrestricted new roles.

At the same time, workload teams need enough freedom to create application roles for their services.

One practical design is:

  • cross-account deployment roles for the platform automation path,

  • permission boundaries on delegated role creation inside workload accounts,

  • resource-based policies only where a resource must explicitly trust an external principal,

  • and SCPs at the organization layer for broader account-wide guardrails.

Each control layer keeps a separate job. That separation is what keeps the model understandable.

Common Mistakes

  • Using resource-based policies and identity-based policies as if they were interchangeable.

  • Treating permission boundaries as if they grant access on their own.

  • Replacing account strategy and SCPs with permission boundaries alone.

  • Trusting an entire external account when the design really needs a smaller trusted principal set or stronger conditions.

  • Sharing credentials across accounts instead of using role assumption.

If Someone Asks You

How do resource policies, boundaries, and cross-account roles fit together?

A good answer is:

Identity-based policies describe what an identity may do. Resource-based policies let the target resource trust named principals directly. Permission boundaries cap what delegated users or roles can ever receive. Cross-account access usually combines a trusted role in the target account with scoped permissions and, when needed, resource policies on the resource itself.

What to Remember

Strong IAM design assigns each control layer one clear job instead of piling overlapping permissions together.

Questions to Check Understanding

  1. When is a resource-based policy the right tool?

  2. What does a permission boundary limit?

  3. Why is cross-account role assumption usually cleaner than sharing credentials?

Further Study