Cross-account network sharing with AWS RAM
Sharing subnets with AWS Resource Access Manager (RAM) lets one infrastructure account own the VPC — its addressing, routing and gateways — while workload accounts launch resources into it. Member accounts get somewhere to deploy without the ability to alter the network.
This is a different model from transit gateway attachments, where each account has its own VPC. Shared subnets mean fewer VPCs, no inter-VPC routing to manage, and no cross-VPC data transfer charges — at the cost of a single blast radius and a central team that becomes a bottleneck for network change.
Components
Section titled “Components”- AWS Organizations
- AWS Resource Access Manager
- A VPC and its subnets, routing and gateways in the infrastructure account
- IAM roles and permissions in both
Prerequisites
Section titled “Prerequisites”- An AWS Organization with all features enabled.
- A dedicated infrastructure account for network management.
- Target accounts organised into the appropriate organizational units.
- Administrative access to both the management account and the infrastructure account.
Step 1: enable resource sharing in the organization
Section titled “Step 1: enable resource sharing in the organization”From the management account:
aws ram enable-sharing-with-aws-organizationStep 2: build the VPC in the infrastructure account
Section titled “Step 2: build the VPC in the infrastructure account”aws ec2 create-vpc --cidr-block 10.0.0.0/16
aws ec2 create-subnet --vpc-id <vpc-id> --cidr-block 10.0.1.0/24 \ --availability-zone eu-west-2aaws ec2 create-subnet --vpc-id <vpc-id> --cidr-block 10.0.2.0/24 \ --availability-zone eu-west-2bThen configure route tables, the internet gateway or NAT gateways, and any endpoints the workloads will need. Everything a member account depends on has to exist before the subnet is useful to it.
Step 3: create the resource share
Section titled “Step 3: create the resource share”From the infrastructure account:
aws ram create-resource-share \ --name "central-network-share" \ --resource-arns arn:aws:ec2:<region>:<account-id>:subnet/<subnet-id> \ --principals arn:aws:organizations::<management-account-id>:ou/<org-id>/<ou-id>Share individual subnets, not the VPC. Sharing per subnet is what lets you give the development OU the development subnets and nothing else.
Principals must be an account ID, an organization ARN, an organizational unit ARN, or a role or user ARN.
Step 4: verify in a member account
Section titled “Step 4: verify in a member account”- Open the VPC console in the member account.
- Look under Subnets for entries owned by another account.
- Confirm the expected subnets appear and are in the expected Availability Zones. Availability Zone names differ per account, so check the AZ ID rather than the name.
What each side can do
Section titled “What each side can do”Infrastructure account
- Full control of VPC configuration, routing, gateways and endpoints.
- Decides which subnets are shared and with whom.
- Sees all network resources in the VPC, including resources member accounts created.
Member accounts
- Can view the shared subnets and launch resources into them: EC2 instances, load balancers, RDS instances, Lambda functions with VPC access, ECS tasks.
- Can create and manage their own security groups.
- Cannot modify subnets, route tables, network ACLs or VPC endpoints.
- Cannot create VPC endpoints in a shared subnet — endpoints belong to the VPC owner.
A member account owns and pays for the resources it launches; the infrastructure account owns and pays for the VPC-level resources such as NAT gateways.
Practice
Section titled “Practice”- Tag consistently across accounts, so that resources in a shared subnet can be attributed to a team.
- Plan the address space for growth. A shared VPC that runs out of addresses is disruptive to extend, because every account’s workloads live in it.
- Record which subnet is allocated to which account or workload.
- Review resource shares periodically. A share left in place after a project ends is standing access.
- Monitor free IP addresses per subnet, and alarm before exhaustion.
- Turn on VPC flow logs centrally; member accounts cannot enable them on a shared subnet.
Security
Section titled “Security”- Security groups in a shared subnet are per account, so each team controls its own. A participant can reference another participant’s or the owner’s security group in its rules by qualifying the ID with the account number —
123456789012/sg-1a2b3c4d— but cannot modify a group it does not own. - Network ACLs are the infrastructure account’s, and apply to everyone in the subnet.
- Use service control policies to prevent member accounts from creating their own VPCs and bypassing the shared network, if that is the intent.
- Audit the resource share and the VPC configuration on the same schedule as any other production control.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Look at |
|---|---|
| Shared subnets do not appear in a member account | Organization sharing enabled? Account in the right OU? Share created with the right principal? |
| Cannot launch into a shared subnet | IAM permissions in the member account; security group configuration; free IP addresses in the subnet |
| Connectivity fails | Route tables in the infrastructure account; security group rules; network ACL rules |
| A member account cannot create a VPC endpoint | Expected — endpoints are created by the VPC owner |