AWS Advanced Networking: Mastering VPC Sharing

Learning Objectives

After studying this guide, you should be able to:

• Explain the role of AWS Resource Access Manager (RAM) and AWS Organizations in VPC sharing.
• Differentiate between the responsibilities of a VPC Owner and a VPC Participant.
• Identify the primary cost and operational advantages of sharing subnets across accounts.
• Evaluate when to use VPC Sharing versus VPC Peering or Transit Gateway.
• Recognize specific limitations, such as the prohibition on sharing default VPCs.

Key Terms & Glossary

• VPC Owner: The account that creates the VPC and owns the infrastructure (subnets, route tables, gateways).
• VPC Participant: An account within the same AWS Organization that has been granted access to subnets within the owner's VPC.
• Resource Access Manager (RAM): The service used to define and manage the sharing of AWS resources (like subnets) across accounts.
• Implicit Routing: The behavior within a shared VPC where resources in different subnets (owned by different accounts) can communicate via the local VPC route by default.

The "Big Idea"

In a traditional multi-account strategy, every team manages their own VPC, leading to a "sprawl" of NAT Gateways, Interface Endpoints, and complex peering meshes. VPC Sharing flips this model by allowing a central networking team to manage the "pipes" (IP space, routing, egress) while application teams simply "plug in" their resources (EC2, RDS) to a shared, high-density environment. It treats the network as a common utility rather than a per-project overhead.

Formula / Concept Box

Hierarchical Outline

• I. Foundational Requirements
  • AWS Organizations: Must be enabled; sharing is restricted to accounts within the same org.
  • Resource Access Manager (RAM): The mechanism used to share subnets (not the whole VPC).
• II. Functional Mechanics
  • Subnet Selection: Owners share specific subnets, not the entire CIDR block.
  • Resource Isolation: Participants see only the shared subnets and can only interact with resources they own or that are explicitly allowed via Security Groups.
• III. Advantages of Sharing
  • Efficiency: Larger, high-density VPCs lead to better IP address utilization.
  • Cost Savings: Centralized NAT Gateways and VPC Endpoints reduce duplicate hourly charges.
  • Security: Centralized control over NACLs and IGW/VGW configuration.
• IV. Constraints
  • No Default VPCs: You cannot share the default VPC or its subnets.
  • Security Group Ownership: Participants cannot use Security Groups owned by the VPC owner or other participants.

Visual Anchors

The Sharing Process

Architectural Topology

\begin{tikzpicture}[node distance=2cm] \draw[thick, color=orange] (0,0) rectangle (8,5); \node at (4, 4.7) {\textbf{Shared VPC (Owner Account)}};

\draw[dashed] (0.5, 0.5) rectangle (3.5, 3.5); \node at (2, 3.2) {\small Shared Subnet A}; \node[draw, fill=blue!10] (ec2) at (2, 1.5) {\small EC2 (Acct 1)};

\draw[dashed] (4.5, 0.5) rectangle (7.5, 3.5); \node at (6, 3.2) {\small Shared Subnet B}; \node[draw, fill=green!10] (rds) at (6, 1.5) {\small RDS (Acct 2)};

\draw[<->, thick, color=red] (ec2) -- (rds) node[midway, above] {\small Local Routing}; \end{tikzpicture}

Definition-Example Pairs

• Resource Consolidation: The practice of using one resource to serve multiple accounts.
  • Example: Instead of five accounts each paying ~$32/month for their own NAT Gateway, all five share one NAT Gateway in the VPC Owner account, saving ~$128/month in fixed costs.
• Cross-Account Security Group Referencing: Although you cannot use another account's SG, you can reference it in rules.
  • Example: A Participant Account's Web Server SG can have an inbound rule allowing traffic from the Owner Account's Load Balancer SG, even though they live in different accounts.

Worked Examples

Scenario: The Overlapping IP Crisis

Problem: A company has 10 accounts, each with a VPC using 10.0.0.0/16. They now need to interconnect them, but VPC Peering is impossible due to CIDR overlap.

Solution using VPC Sharing:

1. Consolidate: Create one large VPC in a Networking Hub account with a massive CIDR (e.g., 10.100.0.0/15).
2. Segment: Create subnets for "Production," "Testing," and "Shared Services."
3. Distribute: Use RAM to share the "Production" subnet with Account A and Account B.
4. Migrate: Teams move their workloads into these shared subnets. Since they are in the same VPC, they use the same non-overlapping IP space, resolving the conflict and enabling direct private communication.

Checkpoint Questions

1. Can a VPC Participant modify the Route Table of a shared subnet? (No, only the Owner can manage infrastructure components).
2. What happens to data transfer costs between two EC2 instances in different accounts but the same Availability Zone in a shared VPC? (It is free, just like a standard VPC).
3. True or False: You can share a VPC with an account outside of your AWS Organization. (False; RAM sharing for VPC subnets requires AWS Organizations).

Muddy Points & Cross-Refs

• Confusion with Peering: Remember that Peering connects two different VPCs (separate routing tables, separate quotas). Sharing allows multiple accounts to live inside one VPC.
• Security Group Limitations: A common "gotcha" is trying to assign an SG owned by the VPC Owner to a Participant's EC2 instance. This will fail. Participants must create their own SGs within their own accounts, even if those SGs are associated with the shared subnets.
• Cross-Ref: For complex scenarios where sharing isn't enough (e.g., connecting to on-premises), see the Transit Gateway section.

Comparison Tables