Cross-Account Access & Resource Sharing
Overview
In enterprise AWS environments, resources often need to be shared across multiple accounts. AWS provides two primary mechanisms for cross-account access: IAM roles with trust policies for temporary access, and AWS Resource Access Manager (RAM) for long-term resource sharing.
Understanding when to use each approach is critical for the SAA-C03 exam. IAM roles provide fine-grained, temporary access control, while RAM simplifies sharing of supported AWS resources without duplicating them across accounts.
Key Decision
IAM Roles: Best for temporary access, API calls, and fine-grained permissions AWS RAM: Best for long-term sharing of supported resources (VPCs, Transit Gateways, etc.) without duplication
Exam questions often present scenarios where you must choose between IAM roles, resource-based policies, and RAM. RAM is the answer when sharing VPC subnets, Transit Gateways, or Route 53 Resolver rules across accounts in an organization.
Architecture Diagram
Key Concepts
Cross-Account Access with IAM Roles
IAM Role-Based Access
IAM roles enable temporary, on-demand access to resources in another account.
How It Works:
- Target account creates role with trust policy
- Source account grants permission to assume the role
- User/application assumes the role and receives temporary credentials
- Credentials expire automatically
Best For:
- API/CLI access to another account
- Temporary elevated permissions
- Programmatic cross-account operations
- Fine-grained permission control
AWS Resource Access Manager (RAM)
AWS RAM
AWS RAM enables long-term sharing of supported resources without duplicating them.
How It Works:
- Owner account creates a resource share
- Specifies resources and principals (accounts, OUs, organization)
- Within Organizations: Access is automatic
- Outside Organizations: Invitation must be accepted
- Shared resources appear natively in consumer account consoles
Best For:
- VPC subnet sharing (centralized VPC model)
- Transit Gateway sharing
- Route 53 Resolver rules
- License Manager configurations
- Long-term, persistent resource access
Shareable Resources via RAM
Common RAM Shareable Resources
| Service | Resource Type | Use Case |
|---|---|---|
| Amazon VPC | Subnets | Centralized VPC, shared networking |
| Amazon VPC | Transit Gateways | Hub-and-spoke network topology |
| Amazon VPC | Prefix Lists | Shared IP address management |
| Route 53 | Resolver Rules | Centralized DNS resolution |
| AWS License Manager | License Configurations | Centralized license management |
| AWS Glue | Data Catalogs, Databases | Shared data lake access |
| Amazon Aurora | DB Clusters | Cross-account database cloning |
| AWS Outposts | Outpost Resources | Shared on-premises infrastructure |
| EC2 | Capacity Reservations | Shared compute capacity |
How It Works
Method 1: IAM Role-Based Cross-Account Access
Step 1: Create Role in Target Account
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::SOURCE-ACCOUNT-ID:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "unique-external-id"
}
}
}
]
}Step 2: Attach Permissions Policy to Role
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::shared-bucket",
"arn:aws:s3:::shared-bucket/*"
]
}
]
}Step 3: Grant AssumeRole Permission in Source Account
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::TARGET-ACCOUNT-ID:role/CrossAccountRole"
}
]
}Method 2: Resource-Based Policies
Some AWS services support resource-based policies that directly grant cross-account access:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CrossAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::OTHER-ACCOUNT-ID:root"
},
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
}
]
}Services Supporting Resource-Based Policies
| Service | Resource | Policy Name |
|---|---|---|
| Amazon S3 | Buckets | Bucket Policy |
| Amazon SQS | Queues | Queue Policy |
| Amazon SNS | Topics | Topic Policy |
| AWS KMS | Keys | Key Policy |
| AWS Lambda | Functions | Function Policy |
| Amazon ECR | Repositories | Repository Policy |
| AWS Secrets Manager | Secrets | Resource Policy |
Method 3: AWS RAM Resource Sharing
Creating a Resource Share
# Create resource share
aws ram create-resource-share \
--name "SharedVPCSubnets" \
--resource-arns arn:aws:ec2:us-east-1:123456789012:subnet/subnet-abc123 \
--principals arn:aws:organizations::123456789012:ou/o-abc123/ou-def456 \
--permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionSubnet
# List resource shares
aws ram get-resource-shares --resource-owner SELF
# View shared resources
aws ram list-resources --resource-owner SELFRAM Within AWS Organizations
Organization Integration
When sharing within AWS Organizations:
- No invitations required - Access is automatic
- Share with entire org or specific OUs - No need to list individual accounts
- Enable organizational sharing - Must be enabled in RAM settings
- Trusted access - Enable RAM trusted access in Organizations
Use Cases
Use Case 1: Centralized VPC Architecture
Scenario: Network team manages VPCs, application teams need subnets.
Solution: Use RAM to share VPC subnets with application accounts.
Centralized VPC Benefits
- Single VPC managed by network team
- Shared subnets used by multiple accounts
- Centralized control over network configuration
- Reduced IP address waste - No duplicate VPCs needed
- Simplified connectivity - All workloads in same VPC
Use Case 2: Transit Gateway Sharing
Scenario: Multiple accounts need connectivity to on-premises data center.
Solution: Network account owns Transit Gateway, shares via RAM.
Use Case 3: Third-Party Vendor Access
Scenario: External vendor needs access to S3 bucket for data processing.
Solution: IAM role with external ID to prevent confused deputy problem.
Use Case 4: Centralized DNS
Scenario: Central DNS team manages Route 53 Resolver rules.
Solution: Share Resolver rules via RAM to all accounts in organization.
Best Practices
Cross-Account Best Practices
- Use External ID for Third-Party Access - Prevents confused deputy attacks
- Prefer RAM for Long-Term Sharing - Simpler management, native console access
- Use Organizations Integration - Automatic sharing, no invitations needed
- Apply Least Privilege - Grant minimum necessary permissions
- Audit with CloudTrail - Log all cross-account access
- Use Managed Permissions in RAM - Define precise access controls
- Require MFA for Sensitive Roles - Add condition to trust policies
Choosing the Right Method
When to Use Each Method
| Scenario | Recommended Method | Why |
|---|---|---|
| Temporary API access to another account | IAM Role (AssumeRole) | Temporary credentials, fine-grained control |
| Share VPC subnets with multiple accounts | AWS RAM | Native sharing, no duplication |
| Grant S3 access to specific external account | S3 Bucket Policy | Direct resource-based policy |
| Share Transit Gateway across organization | AWS RAM | Centralized network sharing |
| CI/CD pipeline deploying to production account | IAM Role (AssumeRole) | Temporary deployment credentials |
| Share Route 53 Resolver rules | AWS RAM | DNS centralization |
| Lambda in Account A triggers Lambda in Account B | Resource Policy + IAM Role | Cross-account invocation |
Common Exam Scenarios
Exam Scenarios
| Scenario | Solution | Key Point |
|---|---|---|
| Network team manages VPCs, app teams need access | RAM subnet sharing | Centralized VPC model |
| External vendor needs temporary S3 access | IAM role with External ID | Prevents confused deputy |
| Share Transit Gateway with 50 accounts | RAM with organization sharing | No need to list each account |
| Account A Lambda needs to write to Account B DynamoDB | IAM role assumption | Temporary credentials for API calls |
| Centralize Route 53 DNS across organization | RAM Resolver rule sharing | DNS centralization |
| Share Aurora cluster for cloning | RAM Aurora sharing | Cross-account database cloning |
| Development account needs read-only prod access | IAM role with read permissions | Least privilege cross-account |
Common Pitfalls
Pitfall 1: Not Using External ID
Mistake: Granting cross-account role access to third parties without External ID.
Why it's dangerous:
- Confused deputy attack possible
- Malicious actor could trick service into accessing your resources
- Common vulnerability in multi-tenant architectures
Correct Approach:
- Always require External ID in trust policy for third-party access
- Generate unique, unpredictable External IDs
- Share External ID securely with trusted party only
Pitfall 2: Using RAM Without Organization Integration
Mistake: Sharing resources via RAM without enabling Organizations integration.
Why it matters:
- Requires manual invitations for each account
- Cannot share with OUs directly
- More operational overhead
Correct Approach:
- Enable RAM trusted access in AWS Organizations
- Enable sharing within organization in RAM settings
- Share with OUs instead of individual accounts
Pitfall 3: Overly Broad Trust Policies
Mistake: Using "Principal": {"AWS": "*"} in trust policies.
Why it's dangerous:
- Any AWS account could assume the role
- Defeats purpose of cross-account security
- Major security vulnerability
Correct Approach:
- Specify exact principal ARNs
- Use conditions (External ID, source account)
- Limit to specific users/roles, not entire accounts
Pitfall 4: Duplicating Resources Instead of Sharing
Mistake: Creating duplicate VPCs, Transit Gateways in each account.
Why it matters:
- Increased cost and complexity
- IP address exhaustion
- Difficult to maintain consistency
- Network connectivity challenges
Correct Approach:
- Use centralized network architecture
- Share resources via RAM where supported
- Single source of truth for network resources
Test Your Knowledge
Which AWS service is used to share VPC subnets across accounts without duplication?
What is the purpose of External ID in cross-account role trust policies?
When sharing resources via RAM within AWS Organizations, what happens?
A company wants development teams to deploy resources into shared VPC subnets managed by the network team. What is the BEST approach?
Related Services
Quick Reference
RAM CLI Commands
# Create resource share
aws ram create-resource-share --name <name> --resource-arns <arns> --principals <principals>
# List your resource shares
aws ram get-resource-shares --resource-owner SELF
# List resource shares shared with you
aws ram get-resource-shares --resource-owner OTHER-ACCOUNTS
# Accept resource share invitation
aws ram accept-resource-share-invitation --resource-share-invitation-arn <arn>
# List shared resources
aws ram list-resources --resource-owner SELF
# Delete resource share
aws ram delete-resource-share --resource-share-arn <arn>
# Enable sharing with Organizations
aws ram enable-sharing-with-aws-organizationCross-Account Access Comparison
Method Comparison
| Aspect | IAM Roles | Resource Policies | AWS RAM |
|---|---|---|---|
| Access Type | Temporary | Permanent | Permanent |
| Credential Type | STS temporary | Caller credentials | Caller credentials |
| Setup Complexity | Medium | Low | Low |
| Supported Resources | All (via API) | Select services | Select resources |
| Organization Integration | Manual | Manual | Automatic |
| Console Access | Switch role | Direct | Native appearance |
| Best For | API access, temp elevation | Simple sharing | VPC, TGW, persistent sharing |