Mastering Resource Sharing Across AWS Accounts

Resource sharing is a cornerstone of modern AWS architecture, enabling organizations to optimize costs, enhance security through segmentation, and simplify management across hundreds of accounts. This guide focuses on AWS Resource Access Manager (RAM) and AWS Organizations as the primary mechanisms for multi-account resource distribution.

---

Learning Objectives

By the end of this study guide, you should be able to:

• Explain the primary use cases for sharing AWS resources across accounts.
• Distinguish between Global and Regional shared resources.
• Identify the specific resources compatible with AWS Resource Access Manager (RAM).
• Describe the workflow for sharing resources both within and outside an AWS Organization.
• Understand how Service Control Policies (SCPs) influence resource access and governance.

Key Terms & Glossary

• AWS Resource Access Manager (RAM): A service that allows you to share your AWS resources with any AWS account or within your AWS Organization.
• Principal: The entity that receives the shared resource (e.g., an AWS account, an Organizational Unit (OU), or an entire Organization).
• Resource Share: A container in RAM that maps specific resources to specific principals.
• Management Account: The central account in an Organization that manages billing and administrative control.
• Member Account: An individual AWS account that is part of an Organization.
• Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization, acting as a guardrail.

The "Big Idea"

Instead of creating duplicate resources (like VPCs, Transit Gateways, or Route 53 Resolver Rules) in every individual account—which leads to "management sprawl" and increased costs—AWS allows you to build a resource once in a centralized provider account and share it. This transforms accounts from "isolated islands" into a collaborative ecosystem where networking and security infrastructure is unified while application workloads remain segmented.

Formula / Concept Box

Hierarchical Outline

1. AWS Resource Access Manager (RAM)
   • Centralization: Eliminates resource duplication.
   • Monitoring: Integrated with CloudWatch and CloudTrail for auditing.
   • Sharing Scopes:
     • Internal: Sharing within an Organization (automatic acceptance).
     • External: Sharing with Account IDs outside an Organization (requires handshake/invitation).
2. Resource Types
   • Global Resources: Accessible from any region (e.g., IAM roles, Route 53, CloudFront).
   • Regional Resources: Locked to the specific region of creation (e.g., Subnets, Transit Gateways).
3. Governance and Control
   • Service Control Policies (SCPs): Set maximum permissions; an empty SCP is an implicit DENY.
   • Handshakes: The multi-step process for account invitations to join an Organization.

Visual Anchors

Resource Sharing Workflow

AWS Organization Hierarchy

Definition-Example Pairs

• Shared Subnet: A VPC subnet owned by a central Networking account but shared with Application accounts.
  • Example: A Central IT team creates a VPC with standard security and shares subnets with the Marketing team so they can launch EC2 instances without managing the VPC themselves.
• Transit Gateway Sharing: Sharing a central hub to connect multiple VPCs.
  • Example: Using RAM to share a single Transit Gateway across 50 member accounts to enable inter-VPC communication without complex peering meshes.
• Route 53 Resolver Rules: Rules that dictate how DNS queries are forwarded.
  • Example: Sharing a rule that forwards all .internal queries to an on-premises DNS server across all accounts in a hybrid cloud environment.

Worked Examples

Problem: Sharing a Subnet via RAM

Scenario: You need to share a subnet in us-east-1 from Account A (Owner) to Account B (Participant).

1. Step 1: Enable Sharing: In the RAM Console of Account A, enable "Sharing with AWS Organizations" (if applicable).
2. Step 2: Create Resource Share: Define a name, select the specific Subnet as the resource type.
3. Step 3: Add Principals: Input the Account ID of Account B.
4. Step 4: Acceptance:
   • If in the same Org: Account B sees the subnet in their VPC console immediately.
   • If NOT in same Org: Account B must go to the RAM console and click "Accept Resource Share."
5. Result: Account B can now launch instances into that subnet, but cannot delete the subnet or change its CIDR block.

Checkpoint Questions

1. Who is responsible for the costs associated with a shared resource: the owner or the participant?
2. What is the main difference between sharing a resource with an account inside vs. outside your AWS Organization?
3. True or False: If an SCP denies S3 access, but a user has an IAM policy allowing it, the user can still access S3.
4. List three examples of Global AWS services.

▶Click to see answers

1. The Resource Owner account is responsible for the costs.
2. Within an Org, sharing is automatic; outside an Org, an invitation/handshake must be accepted.
3. False. An SCP acts as a guardrail; if it denies an action, no IAM policy can override it.
4. IAM, Route 53, CloudFront, WAF, or Shield.

Muddy Points & Cross-Refs

• The Visibility Trap: Even though a resource is "Global," it may show up in the AWS Console under us-east-1 (N. Virginia). This is a legacy UI behavior and does not mean the resource is limited to that region.
• VPC Sharing vs. VPC Peering:
  • VPC Peering connects two separate networks.
  • VPC Sharing allows multiple accounts to place resources into the same network.
• SCP Logic: Remember that an empty SCP is an implicit DENY. Always ensure the FullAWSAccess policy is attached to the root unless you are explicitly whitelisting services.

Comparison Tables

Sharing Scope Comparison

Resource Scope Comparison