AWS Resource Access Manager

Share resources you own with other AWS accounts instead of building a copy in each one.

Verified against AWS documentation · 2026-09-09

Key facts

01Create once, share many — the owning account keeps full ownership and control, consumers just get access
02A resource share = the resources + the principals (accounts, OUs, whole org, some IAM roles/users) + a managed permission
03Inside your organization sharing is automatic once enabled; outside it, the other account must accept an invitation
04Limits: shares are Region-scoped (global resources live in us-east-1); subnets share only inside your own org, and default subnets can't be shared at all

Phrases and scenarios that point here.

"Share across accounts", "without duplicating resources", "centrally managed", "create once, use everywhere"
Many accounts need to launch into one central VPC → RAM-shared subnets, not a VPC per account
One Transit Gateway, Resolver rule, or private CA used org-wide → RAM
Sharing with an account outside the organization → invitation must be accepted first

Grouping accounts, consolidated billing, SCP guardrails → AWS Organizations
Letting a person or app in another account act with your permissions → IAM cross-account role + STS

01A central networking account owns the VPC and shares subnets — each app team launches EC2, RDS, and Lambda from their own account into one VPC the network team patches once
02One Transit Gateway shared org-wide, so a brand-new account gets on-prem and inter-VPC connectivity on day one without its own VPN or Direct Connect
03Route 53 Resolver rules shared from a DNS account, so every account resolves internal hostnames the same way instead of each keeping a copy that quietly drifts
04A private CA in the security account shared to app accounts, so teams issue their own internal TLS certs without anyone passing around root key access
05EC2 Capacity Reservations or Dedicated Hosts bought in one account and shared, so whichever team needs the capacity this week can actually launch into it

01RAM itself is free — no charge for the service, for creating resource shares, or for the act of sharing
02You still pay normal service pricing for whatever you shared, and the bill lands on the account that owns it
03Shared VPC subnets split the bill: participants pay for their own EC2/RDS/Lambda, the VPC owner pays NAT gateway, VPC endpoint, transit/virtual private gateway data processing, and public IPv4 addresses
04Sharing is usually a cost win — one NAT gateway or interface endpoint replaces one per account, and traffic between accounts inside the same AZ of a shared VPC is free
05Billing surprise: if a Capacity Reservation share fails, instances aimed at that reservation launch as plain On-Demand and quietly cost more