AWS Services
Cross-Account Access Patterns
Understand AWS cross-account access using IAM roles, resource policies, AWS Organizations, SCP guardrails, KMS key policies, external IDs, centralized logging, and SAA-C03 traps.
After this, you will understand
Cross-account access becomes easier once learners stop looking for one magic policy and draw both account boundaries.
Cross-account access usually needs one side to trust or expose a resource, and the other side to grant its principal permission to use that path.
Learners add permissions in the caller account but forget the target account owns the role, bucket, queue, topic, or KMS key.
Draw source account, target account, principal, trust policy or resource policy, caller IAM permission, KMS key policy, and organization guardrails.
Think before readingWhy is cross-account S3 access often a two-sided permission problem?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Cross-account IAM roles
- Trust policies
- Resource policies
- External IDs
- Centralized logging accounts
- Multi-account AWS Organizations
- KMS cross-account access
- Vendor access
- Confused deputy risk
- SAA-C03 cross-account traps
1. Plain-English Mental Model
Cross-account access means the principal and the resource do not live behind the same account boundary.
There are two common shapes.
The first shape is role assumption:
Account A principal -> assumes role in Account B -> acts with Account B role permissions
The second shape is resource policy access:
Account A principal -> calls resource in Account B -> Account B resource policy allows it
Both shapes require trust from the target side and permission from the caller side.
2. Why This Service Exists
Serious AWS environments become multi-account environments.
Security teams may own central logging accounts. Workload teams may own app accounts. Network teams may own shared networking accounts. Vendors may need limited access. CI/CD systems may deploy into workload accounts. Analytics teams may read data from production-owned buckets.
Cross-account access exists to connect these accounts without collapsing all workloads into one account.
For SAA-C03, cross-account scenarios appear in central CloudTrail logging, S3 data sharing, KMS encrypted data, third-party access, multi-account governance, IAM Identity Center access, Organizations guardrails, and secure partner file ingest.
The exam usually tests whether you can identify which account owns the trust decision.
3. The Naive Approach And Where It Breaks
The naive approach is to create IAM users in every account and share access keys.
That creates long-lived credentials, weak audit, painful rotation, and unclear ownership.
Another naive approach is to add an IAM policy in the caller account and assume that grants access to resources in another account. The caller's account cannot unilaterally grant access to a resource it does not own.
Another mistake is to make a bucket public for cross-account sharing. That solves access by destroying the boundary.
The right design uses explicit cross-account trust through roles or resource policies, with least privilege and auditability.
4. Core Primitives
A cross-account role lives in the target account. Its trust policy allows a principal from another account to assume it. Its permissions policies define what the assumed role can do.
The caller also needs permission to call sts:AssumeRole on that role.
A resource policy lives on the target resource and can allow principals from another account. S3 bucket policies, SQS queue policies, SNS topic policies, Lambda permissions, KMS key policies, and role trust policies are common examples.
An external ID is a condition value used in some third-party role assumption patterns to reduce confused deputy risk.
AWS Organizations can centralize accounts and attach SCPs, but SCPs do not grant cross-account access.
KMS key policies are critical for encrypted cross-account resources.
5. Architecture Use Cases
Use cross-account roles for human or automation access into workload accounts:
central CI account -> assumes deploy role in app account
security account -> assumes audit role in workload account
workforce user -> IAM Identity Center permission set -> account role session
Use resource policies for service or data access without assuming a role:
central logging bucket policy allows CloudTrail delivery
SQS queue policy allows SNS topic from another account
S3 bucket policy allows analytics account role to read a prefix
Lambda resource policy allows EventBridge rule from another account
Use external ID when a third-party vendor assumes a role in your account.
Use KMS key policies when the shared data is encrypted with customer managed keys.
Use SCPs to prevent dangerous actions in member accounts, but still grant access through IAM or resource policies.
7. Security Model
Cross-account security is about trust direction.
For role assumption:
target account role trust policy -> who can assume
target account role permissions -> what the session can do
caller account IAM policy -> who can call sts:AssumeRole
For resource policy access:
target resource policy -> which external principal can access
caller account IAM policy -> principal is allowed to make the request
For encrypted resources, add:
KMS key policy -> external account or principal can use the key
caller IAM policy -> caller can use the key ARN
Avoid broad account-root trust unless you understand that the trusted account can delegate to its own principals. Prefer specific role ARNs or strong conditions where possible.
Use CloudTrail to audit role assumption and resource access.
8. Reliability And Resilience
Cross-account access can fail because either side changes.
A caller role may lose sts:AssumeRole. A target role trust policy may change. A bucket policy may add a deny condition. A KMS key may be disabled. An SCP may block the action. An external ID may be mistyped. A service role may be deleted.
Centralized logging and security accounts are reliability-critical. If a bucket policy or KMS key policy blocks log delivery, incident evidence may disappear.
Test cross-account paths after policy changes. Use CloudTrail and service-specific delivery status where available.
For disaster recovery, ensure target accounts and Regions have the roles, resource policies, and KMS keys required to restore.
9. Performance And Scaling
Role assumption adds STS calls but is not normally a performance bottleneck. Applications should cache temporary credentials according to SDK behavior instead of assuming a role on every user request.
Cross-account access scales poorly when every account builds unique one-off trust patterns.
Use standard role names, permission sets, OU structures, account vending patterns, and infrastructure as code to keep trust relationships consistent.
Resource policies can grow large. Access points, prefix design, and separate buckets can make large shared datasets easier to govern.
At organization scale, centralize audit and drift detection so cross-account access does not become invisible.
10. Cost Model
Cross-account IAM itself has no direct charge.
Costs appear in services: CloudTrail data events, S3 requests and transfer, KMS requests, replication, log storage, Security Hub aggregation, and operational overhead.
Cross-account architecture can reduce cost by centralizing shared services and audit accounts, but it can also create data transfer and KMS costs.
The highest cost is usually risk: shared access without clear ownership can expose data or break recovery.
Least privilege and clear account boundaries are cost controls.
12. SAA-C03 Exam Signals
"Third-party vendor needs access to your account" points to cross-account role with external ID where appropriate.
"Central security account audits workload accounts" points to cross-account roles or Organizations-integrated service administration.
"Bucket in Account B must be read by role in Account A" points to caller IAM permission plus bucket policy or role assumption design.
"Encrypted cross-account S3 object cannot be read" points to KMS key policy plus S3 permissions.
"Centrally restrict what accounts can do" points to SCPs, not cross-account role trust alone.
"Avoid long-term credentials across accounts" points to roles and temporary credentials.
13. Common Exam Traps
Do not create IAM users in every account for workforce access.
Do not share access keys with vendors.
Do not forget the caller side needs permission to assume a target role.
Do not forget the target side owns the trust policy or resource policy.
Do not forget KMS key policy for encrypted cross-account access.
Do not use public bucket access as a substitute for cross-account authorization.
Do not assume SCPs grant access. They only constrain what can be granted.
Do not ignore external ID in third-party confused-deputy scenarios.
15. Related Topics
Review AWS Account Model, IAM Users vs Roles, IAM Policy Types And Evaluation Traps, Secure Cross-Account CloudTrail Logging, and Landing Zone Guardrails For Multi-Account AWS.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.