Cross-Account Resource Sharing with AWS RAM - Sharing VPC Subnets and Transit Gateways
Learn how to share VPC subnets and Transit Gateways across accounts to centralize IP address space management and reduce VPC peering connections.
Overview of RAM
RAM (Resource Access Manager) is a service that shares AWS resources across multiple accounts. In multi-account environments, each account owns its own resources, but one configuration option is to share network resources (VPC subnets, Transit Gateways), DNS resources (Route 53 Resolver rules), and security resources (Network Firewall policies) across accounts. Sharing through RAM means that each account does not have to create the same resource again. Shared resources are directly referenced and used from consumer accounts without cross-account IAM role switching or API call relay, providing a native operational experience. Resource ownership remains with the sharing account, and consumer accounts receive only usage permissions.
VPC Subnet Sharing
VPC subnet sharing is a pattern where a network account owns the VPC and subnets, and workload accounts create resources (EC2, RDS, Lambda, ECS tasks) within the shared subnets. Each account does not need its own VPC, and the IP address space is not split up by account. Since the network account centrally manages CIDR blocks, the network account can work with IPAM (IP Address Manager) to allocate addresses without overlaps. Security groups remain independent per account, so network isolation between accounts is maintained even within shared subnets. However, NACLs (Network ACLs) operate at the subnet level and are managed only by the owner account. Resources in shared subnets can communicate directly via private IP with other resources in the same VPC without requiring VPC peering or Transit Gateway.
Shareable Resources and Design Patterns
Resources shareable through RAM include VPC subnets, Transit Gateways, Route 53 Resolver rules, License Manager configurations, Aurora DB clusters, CodeBuild projects, AWS Network Firewall policies, Verified Access groups, IPAM pools, Capacity Reservations, and Outposts. Sharing within an Organization is automatically approved, while sharing with accounts outside the Organization requires invitation-based approval. RAM Managed Permissions provide fine-grained control over operations allowed for recipient accounts (read-only, create-enabled, associate-enabled). Creating custom managed permissions allows defining more restricted access levels than defaults.
Organizations Integration and Automation
RAM integrates with AWS Organizations to automate resource sharing at the OU (Organizational Unit) level. When sharing within Organizations is enabled, consumer accounts automatically gain access to resources without invitation approval. When a new account is added to an OU, it automatically receives access to resources shared with that OU. Combined with CloudFormation StackSets, this can automate new account creation, OU placement, resource share configuration, and initial resource deployment. Combining Service Control Policies (SCP) with RAM sharing policies provides organization-level control over which resources are shared with which OUs. Usage of RAM shared resources can be audited via CloudTrail, tracking who accessed which resources.
Design Best Practices and Pitfalls
A VPC subnet sharing design allocates subnet CIDR sizes with sufficient headroom. Since multiple accounts create resources in the same subnet, IP address exhaustion affects all accounts. Depending on workload scale, a /24 (256 addresses) is not enough, so one configuration option is to allocate a /20 to /22 range. A common pitfall is that removing a resource share is blocked if consumer accounts still have resources (such as ENIs) in the shared subnet. You inventory the resources in the subnet before removing a share. For Transit Gateway sharing, route table design determines how communication is controlled. Communication between workload accounts is allowed or blocked through route table associations, so you plan the segmentation requirements first. Additionally, RAM shares are configured per region, so you create separate Resource Shares in each region for multi-region deployments.
Comparison with VPC Peering
VPC subnet sharing and VPC peering both enable cross-account network connectivity, but differ in architectural philosophy. VPC peering has each account owning its own VPC with peering connections for mutual routing. Full-mesh connectivity across 10 accounts requires 45 peering connections, and the route table settings to manage increase as well. VPC subnet sharing consolidates the VPC itself into one, eliminating the need for peering for cross-account communication. However, with VPC subnet sharing, subnet-level NACLs are shared across all accounts, so VPC peering or Transit Gateway is needed when different NACLs per account are required. Comparing with Transit Gateway, a RAM-shared Transit Gateway provides hub-and-spoke connectivity at low cost, but Transit Gateway data processing charges (per-GB billing) accrue based on cross-account traffic volume, so for high-volume communication, one configuration option is VPC subnet sharing.
RAM Pricing
RAM itself incurs no additional charges. Costs depend on the usage of shared resources by recipient accounts. With VPC subnet sharing, resources created by recipient accounts (EC2, RDS) are billed to the recipient account. With Transit Gateway sharing, attachment fees (per-attachment hourly billing) and data processing fees (per-GB billing) are charged to the recipient account. For Route 53 Resolver rule sharing, sharing the rules is free, but the Resolver endpoint ENI charges are billed to the owner account. You audit resource shares regularly and remove shares that are no longer needed.
Summary
RAM is a service for efficiently sharing resources in multi-account environments. VPC subnet sharing centralizes IP address space management and reduces VPC peering connections. Transit Gateway sharing consolidates network connectivity. Organizations integration enables OU-level automatic sharing, CloudFormation StackSets automates the configuration, and CloudTrail audits shared resource access. If you set subnet CIDR sizing plans and resource inventory procedures in advance, you can avoid blocks during share removal.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS Resource Access Manager official page
- AWS Organizations official page
- Amazon VPC official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.