AWS Resource Sharing Across Environments

This guide covers the architectural patterns, tools, and security considerations for sharing resources across multiple AWS accounts and environments, a core competency for the SAP-C02 exam.

Learning Objectives

• Evaluate the trade-offs between different resource isolation levels (Account, VPC, Subnet).
• Differentiate between IAM Role Delegation and AWS Resource Access Manager (RAM).
• Design cross-account access strategies using sts:AssumeRole.
• Implement AWS RAM for supported resource types across an Organization.
• Identify when resource sharing requires an invitation versus when it is immediate.

Key Terms & Glossary

• AWS Organizations: An account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage.
• Organizational Unit (OU): A container for accounts within an organization. OUs can also contain other OUs.
• Blast Radius: The potential area of impact from a security incident or operational failure. High isolation (multi-account) minimizes this radius.
• STS (Security Token Service): A web service that enables you to request temporary, limited-privilege credentials for users.
• Principal: An entity in AWS that can perform actions and access resources (e.g., IAM User, Role, or AWS Account).

The "Big Idea"

In modern cloud architecture, isolation is the default, and sharing is the exception. AWS provides a hierarchy of boundaries (from Organizations down to Subnets) to limit the blast radius. Sharing resources across these boundaries requires a deliberate choice between Access Delegation (IAM-based) and Resource Sharing (RAM-based), balancing security with operational efficiency.

Formula / Concept Box

Hierarchical Outline

1. Organizational Structures
   • AWS Organization: The top-level entity representing the business.
   • Organizational Units (OUs): Logical groupings (e.g., "Production", "Development").
   • AWS Accounts: The primary security and billing boundary.
2. Resource Isolation
   • Blast Radius Control: Separating workloads across accounts limits impact.
   • VPC Isolation: Regional virtual networks that block cross-VPC traffic by default.
3. Cross-Account Sharing Methods
   • IAM Access Delegation: Utilizing sts:AssumeRole for identity-based access.
   • AWS Resource Access Manager (RAM): Centralized sharing for specific resource types (e.g., Subnets, Transit Gateways).

Visual Anchors

AWS Organization Hierarchy

IAM Role Delegation Flow

\begin{tikzpicture}[node distance=2cm, auto] \draw[thick] (0,0) rectangle (3,2) node[pos=.5] {Account A (Resource)}; \draw[thick] (6,0) rectangle (9,2) node[pos=.5] {Account B (User)}; \draw[->, thick] (6, 1) -- (3, 1) node[midway, above] {sts:AssumeRole}; \draw[dashed] (1.5, -0.5) -- (1.5, 0) node[below] {RoleA permissions}; \draw[dashed] (7.5, -0.5) -- (7.5, 0) node[below] {UserB permissions}; \end{tikzpicture}

Definition-Example Pairs

• IAM Role Delegation: Providing a user in one account permissions to act as a role in another account.
  • Example: A centralized Security account needs to run Amazon Inspector scans on a Production account; the Security user assumes a CrossAccountAudit role in Production.
• VPC Sharing (via RAM): Allowing multiple accounts to create resources (like EC2) into a centrally managed VPC/Subnet.
  • Example: A central Network account manages VPCs and subnets, sharing them with Business Unit accounts to ensure all traffic follows corporate routing rules.

Worked Examples

Example 1: Cross-Account S3 Access via IAM

Scenario: User B in Account 2222 needs to upload files to an S3 bucket in Account 1111.

1. Account 1111: Create a role named S3UploadRole with a trust policy allowing arn:aws:iam::2222:root.
2. Account 1111: Attach an S3 write policy to S3UploadRole.
3. Account 2222: Attach a policy to User B allowing sts:AssumeRole on arn:aws:iam::1111:role/S3UploadRole.
4. Action: User B calls AssumeRole, receives temporary credentials, and uses them to write to the S3 bucket.

Example 2: Subnet Sharing via RAM

Scenario: Sharing a private subnet across an OU.

1. Org Management: Enable "Resource Sharing" in the AWS Organizations console.
2. Owner Account: In AWS RAM, create a Resource Share, select the Subnet, and specify the OU ID as the principal.
3. Consumer Accounts: No invitation is needed. The subnet appears in their VPC console as if it were local, though they cannot modify the subnet's CIDR or properties.

Checkpoint Questions

1. What is the main advantage of using an AWS Account as an isolation boundary compared to a VPC?
2. True or False: AWS RAM can be used to share any AWS resource type.
3. If you share a resource with an account outside your AWS Organization using RAM, what must the target account do before they can access it?
4. Which IAM policy (Identity or Trust) defines who is allowed to assume a role?

Muddy Points & Cross-Refs

• Invitation Logic: Learners often forget that sharing within an Organization is silent/immediate, while sharing outside requires an invitation. This is a common exam trick.
• RAM vs. Resource-Based Policies: While S3 buckets use resource-based policies, they are not shared via RAM. Always check the supported resource list for RAM.
• Cross-Ref: For deeper networking sharing (Transit Gateways, VPC Peering), refer to Chapter 2: Designing Networks for Complex Organizations.

Comparison Tables