AWS Multi-Account Networking: Organizations & RAM

This guide covers the implementation of routing and connectivity across multiple AWS accounts, focused on AWS Resource Access Manager (RAM) and AWS Organizations to simplify complex hybrid architectures.

Learning Objectives

After studying this guide, you should be able to:

• Explain the role of AWS Organizations and Organizational Units (OUs) in resource governance.
• Configure AWS Resource Access Manager (RAM) to share subnets, Transit Gateways, and Route 53 Resolver rules.
• Differentiate between VPC Sharing and Transit Gateway connectivity patterns.
• Implement cross-account DNS resolution using shared Route 53 resources.

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 receiving the shared resource (e.g., an AWS account ID, an OU, or an entire Organization).
• Resource Share: The container in RAM that holds the resources you want to share and the principals you want to share them with.
• Managed Permissions: A set of rules in RAM that define exactly what actions a principal can perform on a shared resource.
• Organizational Unit (OU): A container for accounts within an AWS Organization used to apply hierarchical policies.

The "Big Idea"

In a modern enterprise, managing networking per-account is unscalable. The "Big Idea" is to move from isolated silos to a centralized governance model. By using AWS RAM and Organizations, a central "Network Account" can own and manage expensive or complex infrastructure (like Direct Connect Gateways or Transit Gateways) and share them out to "Spoke Accounts," reducing cost, complexity, and the blast radius of configuration errors.

Formula / Concept Box

Hierarchical Outline

1. AWS Organizations Foundation
   • Consolidated Billing: Single payment point for all accounts.
   • Service Control Policies (SCPs): Guardrails to restrict what networking actions can be taken (e.g., preventing the creation of Internet Gateways).
2. AWS RAM Mechanics
   • Integration: Must enable "Resource Sharing with AWS Organizations" in the RAM settings.
   • Acceptance: Sharing within an Organization is seamless; sharing with external accounts requires a manual invitation acceptance.
3. Multi-Account Connectivity Patterns
   • VPC Sharing: Centrally managed subnets; participants own their own EC2/RDS instances.
   • Transit Gateway (TGW): A regional virtual router; scales better for hundreds of accounts.
   • PrivateLink: Sharing specific services across accounts without VPC peering.

Visual Anchors

The Hub-and-Spoke Model

Shared VPC Architecture

\begin{tikzpicture}[node distance=2cm] \draw[thick, blue, dashed] (0,0) rectangle (6,4) node[pos=0.5, above=1.5cm] {\textbf{Central Shared VPC (Network Account)}}; \draw[fill=green!10] (0.5,0.5) rectangle (2.5,2.5) node[pos=0.5] {\textbf{Subnet A}}; \draw[fill=green!10] (3.5,0.5) rectangle (5.5,2.5) node[pos=0.5] {\textbf{Subnet B}}; \node[draw, fill=orange!20] at (1.5,1.5) {App 1 (Acct A)}; \node[draw, fill=purple!20] at (4.5,1.5) {App 2 (Acct B)}; \end{tikzpicture}

Definition-Example Pairs

• VPC Sharing: A feature where the VPC owner shares subnets with other accounts.
  • Example: A Central IT team creates a VPC with standard security groups and shares the private subnets with the Marketing team. The Marketing team can launch EC2 instances into those subnets, but they cannot delete the VPC or modify the NACLs.
• Conditional Forwarding (DNS): Directing specific DNS queries to specific resolvers based on the domain name.
  • Example: Configuring a Route 53 Resolver Rule to forward all queries for corp.internal to an on-premises DNS server via RAM-shared Resolver endpoints.

Worked Examples

Scenario: Sharing a Transit Gateway with an OU

Goal: Connect a new Spoke Account to the corporate network without giving the Spoke Account admin access to the TGW.

1. Central Account: Navigate to AWS RAM > Create Resource Share.
2. Resource Selection: Select the Transit Gateway resource.
3. Principals: Select the OU ID (e.g., ou-1234-5678) from the AWS Organization tree.
4. Permissions: Select AWSRAMDefaultPermissionTransitGateway.
5. Spoke Account: The TGW now appears in the VPC console under "Transit Gateway Attachments." The Spoke Account admin creates a VPC Attachment.
6. Central Account: Accepts the attachment (if auto-accept is not enabled) and associates it with a TGW Route Table.

Checkpoint Questions

1. Does AWS RAM incur extra costs? (Answer: No, the service is free, though the shared resources like TGW attachments still incur their standard hourly rates).
2. In VPC Sharing, who pays for data transfer? (Answer: The account that owns the resource generating the traffic pays for the data transfer).
3. Can you share a Route 53 Private Hosted Zone (PHZ) with RAM? (Answer: No. You share the Resolver Rules via RAM, but PHZs are shared by authorizing the VPC association from the PHZ owner account).

Muddy Points & Cross-Refs

• VPC Peering vs. TGW: Use Peering for low-latency, high-bandwidth (100Gbps) between a few VPCs. Use TGW for a hub-and-spoke model when managing 10+ VPCs.
• VPC Sharing vs. Peering: VPC Sharing is for tight integration (resources in the same subnet). Peering is for connecting separate networks.
• Cross-Reference: For security implications of multi-account networking, see Task 4.1: Network Security & Compliance.

Comparison Tables