Share VPC Subnets Across AWS Accounts with Resource Access Manager – SAP-C02 Study Guide

Purpose of This Lesson

AWS Resource Access Manager (AWS RAM) can share VPC subnets from one AWS account with other accounts in the same AWS Organization. This allows multiple accounts to deploy resources into centrally managed network infrastructure without duplicating VPCs or configuring VPC peering.

A common design is to use a central networking or management account as the VPC owner and allow workload accounts to launch resources into selected shared subnets.

Key Concepts

Shared VPC ownership model

A shared VPC has two account roles:

• VPC owner account: Owns the VPC and its subnets, and creates the AWS RAM resource share.
• Participant account: Uses the shared subnet to deploy its own resources.

The participant account does not become the owner of the VPC or subnet. It receives access to deploy supported resources into the shared subnet while the owner retains control of the underlying network infrastructure.

AWS RAM and AWS Organizations

To share a subnet with accounts in an organization:

1. Enable sharing with AWS Organizations in the AWS RAM settings.
2. Create a resource share in the VPC owner account.
3. Select the subnet or subnets to share.
4. Select accounts, organizational units, or the organization as the principals allowed to use the share.
5. Allow the resource share to finish associating before using it from the participant account.

Organization-based sharing avoids the need to manage individual invitations for accounts within the organization, depending on the selected sharing configuration.

What participants can do

A participant can generally create, manage, and delete resources that it owns in the shared subnet. For example, the participant can launch an EC2 instance into the subnet and manage that instance through its own account.

The participant cannot manage resources owned by the VPC owner or change the shared network foundation. This separation supports centralized network governance and decentralized application ownership.

Connectivity between accounts

Resources launched by different accounts into the same shared subnet use private IP addresses from the subnet’s CIDR range. They can communicate through the VPC networking path when security controls permit it.

For example, ICMP connectivity between two EC2 instances requires appropriate inbound rules in the security groups attached to both instances. A successful private-IP ping demonstrates network reachability, but it does not by itself prove that all application ports are permitted.

Security groups remain important

Sharing a subnet does not automatically allow traffic between resources. Security groups still control instance-level traffic.

For bidirectional ICMP testing:

• Add an inbound ICMP rule to the security group attached to the first instance.
• Add a corresponding rule to the security group attached to the second instance.
• Use the subnet CIDR or a narrower source range where appropriate.
• Confirm that network ACLs and operating-system firewalls also allow the traffic.

A security group created in the participant account can protect resources owned by that participant, while owner-created security groups and other account-owned resources remain subject to ownership boundaries.

Architecture Decision Guide

Requirement	Recommended approach	Why
Centralize VPC and subnet administration across multiple accounts	Use a shared VPC with AWS RAM	The network account owns the VPC while workload accounts deploy resources into approved subnets
Allow accounts to use a subnet without giving them network administration rights	Share only the required subnet through AWS RAM	Participants can use the subnet but do not own the underlying VPC infrastructure
Connect independently owned VPCs	Use VPC peering, Transit Gateway, or another inter-VPC connectivity design	A shared subnet is not a replacement for connectivity between separate VPCs
Keep workloads isolated by account while using common networking	Use AWS Organizations, shared subnets, and account-specific security controls	Account ownership remains separate even though the network is centrally managed
Permit communication between instances in the same shared subnet	Configure security groups, network ACLs, and host firewalls	Subnet sharing alone does not authorize traffic
Give a participant control of the VPC or route tables	Do not use shared VPC as the access model	The participant is a consumer of the shared network, not its owner

Exam-Relevant Takeaways

• AWS RAM is the service used to share supported resources, including VPC subnets, across AWS accounts.
• A shared VPC is owned by one account; other accounts are participants.
• The VPC owner must enable sharing with AWS Organizations before creating the organization-based resource share.
• Participants can launch supported resources, such as EC2 instances, into a shared subnet.
• Participants can manage resources they own but cannot view or modify resources owned by other participants or the VPC owner.
• Resources from different accounts in the same shared subnet can communicate using private IP addresses when security controls allow it.
• Security group rules must permit the required protocol and source. ICMP testing requires ICMP rules, not merely TCP or SSH rules.
• Sharing a subnet is different from VPC peering: shared VPCs place resources in the same VPC, while peering connects separate VPCs.
• Resource sharing may initially appear in an associating or pending state; verify that the share is fully associated before attempting deployment.

Common Exam Traps

• Confusing AWS RAM with VPC peering: RAM shares resources; it does not connect two independent VPCs.
• Assuming the participant owns the subnet: The VPC owner retains ownership and control of the VPC and subnet.
• Assuming subnet sharing bypasses security groups: Traffic still requires appropriate security group rules and may also be blocked by network ACLs or the operating system.
• Using public IP addresses for same-subnet communication: Instances in the same shared subnet should communicate through private IP addresses for internal traffic.
• Assuming all VPC administration is available to participants: Shared VPC participants do not receive unrestricted control over the network infrastructure.
• Forgetting the organization prerequisite: Organization-based sharing requires AWS RAM sharing with AWS Organizations to be enabled.
• Testing only one direction: Security groups are stateful, but a bidirectional connectivity test still requires that the relevant traffic and return path are permitted. Different protocols or independently initiated flows may require additional rules.
• Treating a shared subnet as an account boundary: The accounts remain separate for ownership and administration, but they use the same underlying subnet and network controls. Central governance must account for all participants.

Real-World Engineer Notes

• Use a dedicated networking account as the VPC owner rather than a general-purpose management account when building a larger multi-account landing zone.
• Share only the subnets required by each workload. Separate public, private application, and data subnets according to security and routing requirements.
• Document which account owns each security group, route table, subnet, and other network resource. Ownership affects who can modify or delete it.
• Prefer narrow security group source ranges or references over broad subnet-wide rules when the application allows it. An ICMP rule from an entire subnet is useful for a lab but may be too permissive for production.
• Validate route tables, network ACLs, security groups, instance operating-system firewalls, and IAM permissions independently when troubleshooting connectivity.
• Consider the blast radius of shared network infrastructure. A route-table, NAT gateway, or network ACL change made by the VPC owner can affect multiple participant accounts.
• Confirm service and resource compatibility with shared subnets before standardizing the design. Not every AWS resource supports deployment into a shared VPC or shared subnet.

Quick Reference Summary

• Service: AWS Resource Access Manager (AWS RAM)
• Resource shared: VPC subnet
• Owner: Account containing the VPC and subnet
• Consumer: Participant account in the AWS Organization
• Prerequisite: Enable sharing with AWS Organizations
• Participant capability: Deploy and manage its own supported resources
• Participant limitation: Cannot administer the owner’s VPC and subnet resources
• Internal connectivity: Private IP addresses within the shared VPC/subnet
• Traffic controls: Security groups, network ACLs, routes, and host firewalls
• Not equivalent to: VPC peering or Transit Gateway connectivity between separate VPCs

Flashcards

1. Q: Which AWS service shares a VPC subnet across AWS accounts?

A: AWS Resource Access Manager (AWS RAM).

1. Q: Which account owns a shared VPC subnet?

A: The account that owns the VPC containing the subnet.

1. Q: What is the role of a participant account?

A: It can deploy and manage its own supported resources in the shared subnet.

1. Q: Can a participant modify the VPC owner’s subnet or route tables?

A: No. The participant does not receive ownership of the shared network infrastructure.

1. Q: What must be enabled before sharing subnets with accounts in an AWS Organization?

A: Sharing with AWS Organizations in AWS RAM.

1. Q: Can EC2 instances owned by different accounts communicate privately in a shared subnet?

A: Yes, provided routes and security controls permit the traffic.

1. Q: Does AWS RAM subnet sharing automatically allow ICMP traffic?

A: No. Security groups, network ACLs, and host firewalls must allow ICMP.

1. Q: How is a shared VPC different from VPC peering?

A: A shared VPC lets accounts deploy into subnets of one VPC; VPC peering connects two separate VPCs.

1. Q: What IP address type should instances use for communication within the shared subnet?

A: Private IP addresses.

1. Q: What does the VPC owner control in a shared VPC design?

A: The underlying VPC and subnet infrastructure, including centralized network configuration and governance.

Practice Questions

Question 1

A company has a networking account and several application accounts in one AWS Organization. The networking team must own the VPC, while application teams need to launch EC2 instances into selected private subnets without gaining permission to administer the VPC. Which solution best meets the requirement?

A. Create VPC peering connections between the networking account and each application account.
B. Share the required subnets from the networking account using AWS RAM.
C. Create duplicate VPCs in each application account and synchronize route tables.
D. Give application accounts AdministratorAccess in the networking account.

Correct answer: B

Explanation: AWS RAM shared VPCs allow a VPC owner account to share selected subnets with participant accounts. Participants can deploy supported resources while the owner retains control of the VPC infrastructure. VPC peering connects separate VPCs and does not let an account deploy resources into another account’s subnet.

Question 2

Two EC2 instances are deployed by different AWS accounts into the same shared subnet. The instances cannot ping one another using their private IP addresses. The route table is correct. What is the most likely next troubleshooting step?

A. Create a VPC peering connection.
B. Assign public IP addresses to both instances.
C. Review the inbound ICMP rules in the security groups attached to both instances.
D. Recreate the shared subnet in the participant account.

Correct answer: C

Explanation: Instances in a shared subnet can communicate over private IP addresses, but security groups must allow the required protocol and source. Network ACLs and host firewalls should also be checked if the security group configuration is correct.

Question 3

An account participating in a shared VPC attempts to modify the subnet’s route table and receives an authorization error. What explains this behavior?

A. Shared subnets support only IPv6 traffic.
B. The participant can launch resources but does not own the shared network infrastructure.
C. AWS RAM supports sharing only across different AWS Regions.
D. Route tables must be modified through EC2 Instance Connect.

Correct answer: B

Explanation: The VPC owner retains ownership and administrative control of the VPC, subnet, and associated network configuration. A participant manages resources it owns, not the owner’s shared network resources.

Question 4

An administrator creates an AWS RAM resource share for a subnet and immediately switches to the participant account, but the subnet is not yet available for deployment. What should the administrator verify first?

A. Whether the resource share has finished associating.
B. Whether the participant has created a NAT gateway.
C. Whether the subnet has been converted to a separate VPC.
D. Whether VPC peering is active.

Correct answer: A

Explanation: A newly created resource share may initially be in an associating or pending state. The subnet should be available to the participant after the share has completed association and the organization/account configuration is valid.