How to Share VPC Subnets Across AWS Accounts with RAM?

SAP-C02 By islever Editorial Last updated

Architect network connectivity strategies. Design a multi-account AWS environment.

Short answer

BD Enable resource sharing from the AWS Organizations management account, then share infrastructure account VPC subnets through AWS RAM with the target OU.

Question

A company has many AWS accounts and uses AWS Organizations to manage all of them. A solutions architect must implement a solution that the company can use to share a common network across multiple accounts.
The company’s infrastructure team has a dedicated infrastructure account that has a VPC. The infrastructure team must use this account to manage the network. Individual accounts cannot have the ability to manage their own networks. However, individual accounts must be able to create AWS resources within subnets.
Which combination of actions should the solutions architect perform to meet these requirements? (Choose two.)
  1. Create a transit gateway in the infrastructure account.
  2. Enable resource sharing from the AWS Organizations management account. Correct Answer
  3. Create VPCs in each AWS account within the organization in AWS Organizations. Configure the VPCs to share the same CIDR range and subnets as the VPC in the infrastructure account. Peer the VPCs in each individual account with the VPC in the infrastructure account.
  4. Create a resource share in AWS Resource Access Manager in the infrastructure account. Select the specific AWS Organizations OU that will use the shared network. Select each subnet to associate with the resource share. Correct Answer
  5. Create a resource share in AWS Resource Access Manager in the infrastructure account. Select the specific AWS Organizations OU that will use the shared network. Select each prefix list to associate with the resource share.

Key Takeaways

This tests AWS RAM subnet sharing within Organizations, and the trap is replacing delegated subnet use with transit gateway routing or duplicate peered VPCs.

Sharing a common VPC network across many AWS accounts requires enabling AWS RAM resource sharing in Organizations and sharing the infrastructure account's specific subnets with the target OU. This page establishes that options B and D are correct because they centralize network management while letting member accounts launch resources in shared subnets.

Common mistake: The most common wrong answer is A: a transit gateway sounds like the natural cross-account networking tool, but it only routes traffic and cannot authorize an account to create resources in the infrastructure account's subnets.

Expert Analysis

Why the Answer Is Correct

The requirement is delegated subnet consumption, not just connectivity: the infrastructure account must own and manage the VPC, while individual accounts may only create resources in shared subnets. Option B is necessary because AWS RAM resource sharing with an AWS Organizations OU must first be enabled from the Organizations management account; otherwise the infrastructure account cannot share with the OU. Option D then creates the actual RAM resource share in the infrastructure account, scopes it to the target OU, and includes the specific subnets that consuming accounts can use. Together they satisfy centralized network management with least-privilege subnet use, and the shared subnet model is exactly AWS VPC sharing via AWS Resource Access Manager.

Why the Other Options Are Wrong

Option A is not required because a transit gateway provides routing between VPCs and on-premises networks; it does not let an account launch resources in another account's subnet, and the stem does not require VPC-to-VPC routing. Option C is wrong because duplicating VPCs with the same CIDR ranges and peering them creates separate networks that each account manages, directly violating the rule that individual accounts cannot manage their own networks. Option E is wrong because a prefix list is a set of CIDRs for routing or security group references, not a shareable subnet container, so it cannot grant resource-creation rights in the infrastructure VPC. Option B alone is only an Organizations-level enablement and Option D alone would fail if resource sharing were not enabled for the organization.

Community Comment Notes

Multiple learners converged on BD, including masetromain, who stated "I go with BD" and explained that the infrastructure account shares specific subnets so other accounts can create resources without managing networks. razguru likewise rejected the transit gateway because the scenario did not describe multiple VPCs needing routing. whenthan pointed to an AWS blog on VPC sharing as the relevant model, while Parimal1983's BE proposal focused on prefix lists, which does not meet the requirement to create resources inside shared subnets. The consensus supports treating this as AWS RAM subnet sharing, not a routing or prefix-list problem.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

Anchor on who must manage the network and what individual accounts need to do. If the infrastructure account owns the VPC and member accounts only launch resources in subnets, choose AWS RAM subnet sharing and remember to enable resource sharing at the Organizations management account first.

Frequently Asked Questions

Why is a transit gateway (A) not needed for sharing subnets across accounts?

A TGW routes traffic between VPCs but does not grant accounts permission to launch resources in another account's subnets; the requirement is delegated subnet use via AWS RAM.

Why must resource sharing be enabled in the Organizations management account?

AWS RAM sharing with an OU requires resource sharing enabled at the organization level; without it, the infrastructure account's resource share cannot target the OU.

More SAP-C02 FAQ →

Discussion 68 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 68

  1. masetromain 👍 29
    I go with BD
  2. masetromain 👍 16
    Step B is needed because it enables the organization to share resources across accounts. Step D is needed because it allows the infrastructure account to share specific subnets with the other accounts in the organization, so that the other accounts can create resources within those subnets without having to manage their own networks.
  3. razguru 👍 12
    A - Doesn't seem correct as the question didnt state multiple VPs, so transit gateway is not relevant. I will go with B & D
  4. sreed77 👍 4
    Option B allows the infrastructure team to manage the network in the infrastructure account. It also allows individual accounts to create AWS resources within subnets. This is done by creating a resource share in AWS Resource Access Manager (RAM) in the infrastructure account. The resource share is then associated with the specific AWS Organizations OU that will use the shared network. The subnets are then associated with the resource share. Option D is also necessary because it allows the infrastructure team to control who has access to the shared network. This is done by assigning permissions to the resource share. Here are the steps involved in implementing this solution: Create a resource share in RAM in the infrastructure account. Select the specific AWS Organizations OU that will use the shared network. Select each subnet to associate with the resource share. Assign permissions to the resource share.
  5. atirado 👍 4
    Option A - Does not assist with allowing OUs to create resources in the subnets Option B - Allows sharing resources across the entire organization Option C - This option does not work as a way to share subnets because it creates multiple VPCs and subnets in the accounts rather than allowing managing resources in shared subnets Option D - Directly shares the subnets Option E - Does not assist because it only shares pre-built CIDR blocks rather than subnets
Show 25 more comments
  1. aszd 👍 4
    ❌ Why A is not necessary in this scenario: A transit gateway is useful if: You have multiple VPCs to connect You need centralized routing between VPCs But in this scenario: The question only talks about sharing one VPC from the infrastructure account There's no requirement for VPC-to-VPC communication
  2. ptpho 👍 4
    I go with AD the company can use to share a common network across multiple accounts -> TGW in infras account Enable resource sharing is an optional to share all 'without having to enumerate each account'
  3. Parimal1983 👍 4
    Using prefix list we can simplify routing tables instead of sharing individual subnet of the VPCs. Need to enable resource sharing at organization.
  4. whenthan 👍 4
    https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/
  5. masssa 👍 4
    Anwer is BD. https://aws.amazon.com/jp/premiumsupport/knowledge-center/vpc-share-subnet-with-another-account/
  6. 8693a49 👍 4
    There are multiple VPCs because each account must have at least one.
  7. shaaam80 👍 3
    Answer - B & D. A is wrong. No TGW needed as customer has just 1 VPC. E is wrong - can't share resources via RAM using prefix lists. C is wrong - talks about creating VPCs with same CIDR ranges and VPC peering (not possible with overlapping CIDRs and not needed for this solution as there is just 1 VPC).
  8. newtrojan 👍 3
    AWS orgs doesnt allow sharing by default https://docs.aws.amazon.com/ram/latest/userguide/security-disable-sharing-with-orgs.html
  9. robertohyena 👍 3
    B & D https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html
  10. GibaSP45 👍 3
    https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html
  11. AlbertS82 👍 3
    B&D is the only correct answer
  12. mfsec 👍 3
    BD is correct
  13. 8693a49 👍 2
    Note that B says it enables sharing from the management account, but the infrastructure team must use the infrastructure account to manage the network", so there is nothing to share form the management account. Also, options D and E also enable resource sharing (you don't need to enable it from the management account, other accounts can enable resource sharing too). VPCs can't talk to each other by default. You need to do something to 'glue' them together in a larger network.
  14. 8693a49 👍 2
    You don't share a prefix list, you associate it with the shared resource (which here is a TGW). The way you do it is you add the prefixes to the route tables inside the account's VPCs. The prefixes will point towards the TGW. This makes the network traffic destined to other account go through the TGW into these accounts based on the TGW routing table. The TGW routing table can only be controlled from the infrastructure account.
  15. Sin_Dan 👍 2
    The correct answer is A and D. B is a wrong option. While AWS Organizations is required to manage multiple accounts, enabling resource sharing through AWS RAM is done in the infrastructure account (where the VPC resides), not in the AWS Organizations management account. Resource sharing is configured via RAM in the account that owns the resources, not through Organizations directly.
  16. Brightalw 👍 2
    Prefix lists ec2:PrefixList Create and manage prefix lists centrally, and share them with other AWS accounts or your organization. This lets multiple AWS accounts reference prefix lists in their resources, such as VPC security groups and subnet route tables. For more information, see Working with shared prefix lists in the Amazon VPC User Guide.
  17. Untamables 👍 2
    AWS Resource Access Manager can share subnets with other AWS accounts. https://docs.aws.amazon.com/ram/latest/userguide/shareable.html
  18. kiran15789 👍 2
    wouldnt "Select each prefix list to associate with the resource share." will be use to do then go with selecting each subnet
  19. srs27 👍 2
    Do you really need Management account to share the resources among the accounts? I doubt.
  20. Maja1 👍 2
    https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html
  21. severlight 👍 2
    I don't see the way you can share a prefix list.
  22. wem 👍 1
    The following steps will meet the requirements for sharing a common network managed from the infrastructure account across multiple AWS accounts, with the least operational complexity and in line with best practices: A. Create a transit gateway in the infrastructure account. A transit gateway allows centralized routing and connectivity between multiple VPCs across different AWS accounts. This approach enables the infrastructure account to control network management while allowing other accounts to use the shared network. D. Create a resource share in AWS Resource Access Manager in the infrastructure account. Select the specific AWS Organizations OU that will use the shared network. Select each subnet to associate with the resource share. Using AWS Resource Access Manager (RAM) to share subnets from the infrastructure account allows individual accounts to create resources within those subnets. This aligns with the requirement that individual accounts can create resources but not manage the network.
  23. Amir70 👍 1
    A. By creating a transit gateway in the infrastructure account, you establish a centralized hub for network connectivity. The transit gateway acts as a transit point for traffic between VPCs and accounts. C. Create VPCs in each individual AWS account within the organization and configure them to share the same CIDR range and subnets as the VPC in the infrastructure account. Then, peer the VPCs in each individual account with the VPC in the infrastructure account. This allows resources in the individual accounts to communicate over the shared network managed by the infrastructure team. By following these steps, the infrastructure team can maintain control over the network in the dedicated infrastructure account, while individual accounts can create resources within subnets and utilize the shared network. The transit gateway provides the connectivity between the VPCs in different accounts, enabling seamless communication and resource access.
  24. 8693a49 👍 1
    It's AD. To form a network between multiple accounts, each with their own VPCs, you can use VPC peering or Transit Gateway. But VPC peering is only suitable for a few acounts, and we have many, so we need to create a TGW (A). Then we need to associate it with the VPCs across all acounts, we do this through RAM, and we need to configure the route tables in all accounts to use the TGW, which is done through prefixes (D). See https://docs.aws.amazon.com/prescriptive-guidance/latest/integrate-third-party-services/architecture-3-1.html The question is a bit weird because the answer could allow accounts to manage the network inside their own VPCs, so probably some SCP policies are needed to prevent this. But the accounts cannot edit the TGW routing, so probably that's what they were trying to suggest.
  25. SkyZeroZx 👍 1
    The correct answers are D and B. D will allow the infrastructure team to create a resource share in AWS Resource Access Manager in the infrastructure account. This will allow them to share the VPC with the other accounts in the organization. B will enable resource sharing from the AWS Organizations management account. This is required to allow the resource share to be created. C is not necessary, as the resource share will allow the other accounts to create resources in the shared VPC. A is not necessary, as the resource share will allow the other accounts to connect to the shared VPC through the transit gateway. E is not necessary, as the resource share will allow the other accounts to create resources in the shared VPC without the need for prefix lists.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Cost-Effective Image Processing with SQS and S3 Lifecycle Policies

S-grade

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide