What is AWS Cross-Account Access?

Definition

AWS Cross-Account Access is the practice of allowing principals in one AWS account to access resources in another AWS account. AWS supports this through several mechanisms — most commonly IAM role assumption, resource-based policies, and AWS Resource Access Manager (RAM) — under the umbrella of AWS Organizations for governance.

In simple terms:

Cross-account access lets you split workloads, environments, and data across many AWS accounts while still letting the right principals reach the right resources.

---

Why Cross-Account Matters

• Multi-account architecture is best practice for blast-radius limitation, billing, and isolation.
• Almost every AWS organization runs dozens to thousands of accounts.
• Sharing workloads, data, audit access, and operations across accounts requires safe cross-account patterns.
• Misconfigured cross-account access is a top source of unintended exposure.

---

Cross-Account Mechanisms

1. IAM Role Assumption

The dominant pattern.

• Source account principal calls sts:AssumeRole on a role in target account.
• Trust policy in target account defines who can assume.
• External ID (for third-parties) prevents Confused Deputy.

2. Resource-Based Policies

Some services support resource-based policies that grant access to principals in other accounts:

• S3 bucket policies.
• KMS key policies.
• SNS / SQS / Lambda / API Gateway resource policies.
• Glue Data Catalog policies.
• Secrets Manager resource policies.

3. AWS Resource Access Manager (RAM)

Share specific resources (subnets, transit gateways, license configs, etc.) across accounts in your Organization.

4. AWS Organizations Features

• SCPs apply across accounts.
• Organization-wide CloudTrail with member accounts.
• AWS Backup / Config aggregators spanning accounts.

---

Common Cross-Account Patterns

Centralized Logging

Application accounts ship CloudTrail / VPC Flow Logs / app logs to a logging account S3 bucket. Bucket policy allows write from each app account.

Centralized Security

A security account assumes audit roles in each member account to read CloudTrail, Config, GuardDuty, Security Hub, etc.

Shared Services

A shared services account hosts AD/DNS/CICD; member accounts consume via cross-account role assumption.

Production / Non-Production Separation

Engineers have full access in non-prod, but only role-assumed read or limited write in prod.

Cross-Org Vendor Access

A vendor's account assumes a role in your account to perform their service. Always with external ID.

---

Trust Policy Examples

Internal (within Organization)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:role/SecAuditRole" },
    "Action": "sts:AssumeRole"
  }]
}

Vendor (with External ID)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::VENDOR-ACCOUNT:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "your-unique-external-id" }
    }
  }]
}

Org-Scoped

"Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" } }

---

Resource Policy Example: Cross-Account S3

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:role/AppRole" },
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::shared-data/*"
  }]
}

---

Common Risks

• Trust policies allowing Principal: "*" — anyone anywhere.
• Missing external ID in third-party trust → Confused Deputy.
• Resource policies with broad principals — public exposure.
• Cross-account access without aws:PrincipalOrgID scoping.
• Stale cross-account roles for ex-vendors.
• Excessive cross-account role permissions (Administrator for "convenience").
• Untracked role-assumption chains.
• Wildcards in trust policy ARNs.

---

Real-World Examples

1. Confused Deputy

A vendor role trusted vendor's account without external ID. Anyone using that vendor's service could trigger access to your account.

2. Public S3 via Cross-Account Mistake

Bucket policy intended for cross-account read accidentally listed Principal: "*". Public exposure of data lake.

3. Centralized Audit Done Right

Security account assumes AuditRole in every member account; trust policy scoped via aws:PrincipalOrgID so only org-internal principals can assume; CloudTrail in target accounts logs all activity.

4. Stale Vendor Role

Vendor was decommissioned 2 years ago; cross-account role in your account still trusts them. Vendor's old credentials could still be used.

---

Best Practices

1. Use IAM roles with AssumeRole for cross-account access.
2. External ID for all third-party trust.
3. aws:PrincipalOrgID condition for internal cross-account.
4. Tight resource policies — exact ARNs, no *.
5. SCPs to enforce baseline guardrails (e.g., deny public S3).
6. Block Public Access at S3 account level.
7. IAM Access Analyzer to detect unintended public/cross-account access.
8. Quarterly review of trust relationships and resource policies.
9. Decommission stale cross-account access with vendor offboarding.
10. CloudTrail centralization for cross-account visibility.
11. Tag cross-account roles with vendor / purpose.

---

Checklist

• Multi-account architecture documented (workload, security, log, sandbox accounts)?
• Cross-account access via roles, not IAM users?
• External IDs for third-party trust?
• Org-internal cross-account scoped via aws:PrincipalOrgID?
• Resource policies precise; no broad principals?
• IAM Access Analyzer enabled?
• SCPs enforce guardrails?
• Centralized CloudTrail covering all accounts?
• Quarterly trust policy review?
• Vendor offboarding removes cross-account access?

---

How Forestall Helps

Forestall maps cross-account access across your entire AWS Organization:

• Trust graph (who can assume what).
• Resource-policy graph (who can access what).
• Cross-account exposure findings (public, broad, missing conditions).
• Stale or risky cross-account roles.
• Privileged paths that cross account boundaries.

---

Frequently Asked Questions

Should I use one or many AWS accounts?

Many. Multi-account is best practice for blast radius, billing, and operational separation.

Can I share resources across accounts without trust?

Yes — AWS RAM shares specific resources (subnets, etc.) without IAM trust patterns.

How do I handle vendor cross-account?

IAM role with strict trust + external ID + read-only permissions where possible. Document and rotate.

What's aws:PrincipalOrgID?

A condition key that limits access to principals in your AWS Organization. Strongly recommended for cross-account inside the org.

How do I detect cross-account exposure?

IAM Access Analyzer + Forestall + S3 Block Public Access + manual review.

---

Conclusion

Cross-account access is essential to a healthy multi-account AWS architecture and a frequent source of misconfiguration. Use IAM role assumption with tight trust policies, external IDs for vendors, organization-scoping for internal sharing, and IAM Access Analyzer to surface unintended exposure. With continuous monitoring of cross-account trust and resource policies, multi-account stays a strength rather than a sprawling risk.