AWS Networking: Multi-Account VPC Sharing & Resource Access Management

This guide covers the architecture and implementation of VPC sharing within an AWS Organization, focusing on centralized network management and resource efficiency.

Learning Objectives

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

• Explain the roles of Owner and Participant in a VPC sharing environment.
• Identify the prerequisites for enabling VPC sharing (AWS Organizations and RAM).
• Differentiate between VPC Sharing, VPC Peering, and Transit Gateway use cases.
• Describe how security groups and network ACLs operate across shared subnets.
• List the specific limitations and constraints of shared VPC architectures.

Key Terms & Glossary

• AWS Resource Access Manager (RAM): The service that enables the sharing of AWS resources (like subnets) between accounts within an organization.
• VPC Owner: The account that creates the VPC and owns the infrastructure (IGWs, NAT Gateways, Route Tables).
• Participant: An account within the same AWS Organization that has been granted access to subnets owned by the Owner.
• AWS Organizations: The central management service used to group accounts and enable features like consolidated billing and RAM sharing.
• PrivateLink: A service that provides private connectivity between VPCs, AWS services, and on-premises networks without exposing traffic to the public internet.

The "Big Idea"

In a traditional multi-account setup, every team manages their own VPC, leading to "VPC Sprawl." This results in duplicated costs for NAT Gateways, fragmented IP address management (IPAM), and complex peering meshes. VPC Sharing shifts the paradigm to a Shared Services Model. A central networking team manages the high-level infrastructure (the VPC "container"), while individual application teams (Participants) simply consume subnets to launch their resources. It decouples network administration from application deployment.

Formula / Concept Box

Permissions Matrix

Hierarchical Outline

1. Foundations of VPC Sharing
   • AWS Organizations: Must be enabled with all features turned on.
   • Resource Access Manager (RAM): The mechanism used to "push" subnets to other accounts.
2. Architecture & Roles
   • The Owner: Manages the IP CIDR, subnets, route tables, and gateways.
   • The Participant: Only sees the specific subnets shared with them; cannot see other subnets in the VPC.
3. Security Model
   • Security Groups: Participants create their own SGs; however, they cannot reference SGs from other accounts directly in rules.
   • Network ACLs: Controlled solely by the Owner; apply to all traffic in the subnet regardless of the account owning the resource.
4. Operational Constraints
   • Default VPCs: Cannot be shared.
   • Cross-Account Referencing: Participants cannot modify or delete resources owned by others.

Visual Anchors

Logic of VPC Sharing

Physical vs. Logical Separation

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, minimum width=3cm, minimum height=1cm, align=center}] \draw[dashed, thick] (-1,-1) rectangle (8,4); \node at (3.5, 3.5) {\textbf{Single VPC Infrastructure}};

\end{tikzpicture}

Definition-Example Pairs

• Centralized IPAM (Definition): Managing a single pool of IP addresses to prevent overlaps.
  • Example: A company uses a 10.10.0.0/16 range. Instead of giving 5 accounts their own /24, the networking team manages the whole /16 and shares specific subnets, ensuring no two teams accidentally use the same IPs.
• Resource Efficiency (Definition): Reducing costs by sharing expensive infrastructure components.
  • Example: Instead of paying $0.045/hour for 10 separate NAT Gateways ($324/month), the company uses 2 NAT Gateways in the Shared VPC and routes all participant traffic through them.

Worked Examples

Scenario: Deploying a Multi-Account Web App

Problem: You have a Network-Account and a Dev-Account. You want the Dev-Account to host EC2 instances without managing any routing.

1. Step 1 (Owner): In Network-Account, create a VPC (10.0.0.0/16) and a Private Subnet (10.0.1.0/24).
2. Step 2 (Owner): Open AWS RAM. Create a "Resource Share." Select the Subnet (10.0.1.0/24).
3. Step 3 (Owner): Add the AWS Organization ID or the specific Dev-Account ID as a principal.
4. Step 4 (Participant): In Dev-Account, go to the VPC Console. The subnet 10.0.1.0/24 will magically appear in the subnet list.
5. Step 5 (Participant): Launch an EC2 instance. In the Network Settings, select the shared subnet. The instance is now part of the central VPC.

Checkpoint Questions

1. Can a Participant account create a NAT Gateway in a shared subnet?
   • (Answer: No, only the Owner can manage gateways.)
2. What happens if two participants in the same shared subnet have overlapping Security Group rules?
   • (Answer: Nothing. Security Groups are account-local; they only apply to the resources within that specific account.)
3. Is it possible to share a VPC with an account outside of your AWS Organization?
   • (Answer: No, VPC sharing requires AWS Organizations.)

Muddy Points & Cross-Refs

[!WARNING] Security Group Referencing: A common point of confusion is that you cannot reference a Security Group ID from the Owner account in a Participant account's Security Group rule. You must use IP CIDR ranges for cross-account traffic control within the same VPC.

• Cross-Ref: For connecting VPCs that cannot be shared (e.g., due to different regions or organizations), see the study guide on VPC Peering or Transit Gateway.

Comparison Tables