How to Share VPC Subnets Across AWS Accounts with RAM?
Answer
Correct answer: B, D — Enable resource sharing from the AWS Organizations management account, then share infrastructure account VPC subnets through AWS RAM with the target OU.
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.)
Community Insight
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.
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.
Community Discussion (68 comments)
SuketuWT
👍 1
Selected: BD
Enabling resource sharing will allow to implement sharing of infra with other users through their subnets.
aszd
👍 4
Selected: BD
❌ 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
princajen
👍 1
Selected: BD
RAM sharing across AWS Organizations (must be enabled once). d. is how you share subnets so other can deploy resources into the VPC without managing networking.
Curious76
👍 1
Selected: AD
A. Create a transit gateway in the infrastructure account. AWS Transit Gateway allows multiple accounts to connect to a single shared network efficiently. AWS Resource Access Manager (RAM) lets the infrastructure team share subnets with other accounts.
unbornfroyo
👍 1
Selected: AD
✅ A. Transit Gateway in Infrastructure Account A transit gateway (TGW) allows centralized, scalable network connectivity between VPCs across accounts. Hosting the TGW in the infrastructure account ensures centralized control of routing and traffic flow, while allowing other accounts to connect through attachments. ✅ D. RAM Share of Subnets Use AWS Resource Access Manager (RAM) in the infrastructure account to share subnets with specific AWS accounts or OUs in the organization. This allows other accounts to launch resources (like EC2 instances) into shared subnets without being able to modify the network itself.
Kirkster
👍 1
Selected: BD
The transit gateway is a red herring. Creating a resource share and then sharing out subnets is described in this AWS blog: https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/ To those who say there are multiple VPCs (one in each account), read the question more carefully - it never says that. It merely says that users in the other accounts need to be able to deploy resources to the shared subnets.
_KBM
👍 1
Selected: AD
A. Create a transit gateway in the infrastructure account. A transit gateway allows the infrastructure account to centralize the network and connect multiple VPCs across accounts. It serves as the backbone for communication between the accounts. 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), you can share the subnets of the infrastructure account's VPC with other accounts in the organization, enabling individual accounts to create resources in those subnets while centralizing network management in the infrastructure account.
wem
👍 1
Selected: AD
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.
Heman31in
👍 1
Selected: AD
Without Step A (transit gateway), the solution would lack a central mechanism for connecting VPCs across accounts, which is essential for a shared network. D because: AWS Resource Access Manager (RAM) allows you to share VPC subnets across accounts. By creating a resource share for specific subnets and associating it with the appropriate organizational units (OUs), individual accounts can launch resources in the shared subnets while the infrastructure account retains network control.
TariqKipkemei
👍 1
Selected: BD
Enable resource sharing from the AWS Organizations management account then, 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.
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.
SkyZeroZx
👍 1
Selected: BD
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.
sreed77
👍 4
Selected: BD
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.
cnethers
👍 1
I would go BD When you share a subnet using AWS Resource Access Manager (RAM) with another AWS account, the resources within that shared subnet can communicate with each other and with the resources in the account that owns the subnet. However, for outbound network connectivity to other VPCs, on-premises networks, or the internet, you need to set up additional networking components.
cnethers
👍 1
2. Inter-VPC Communication: o If the resources in the shared subnet need to communicate with resources in another VPC (either within the same AWS account or in a different AWS account), you can use VPC Peering or a Transit Gateway. o VPC Peering: Establish a peering connection between the VPCs and update the route tables accordingly. o Transit Gateway: Create a Transit Gateway, attach both VPCs to the Transit Gateway, and configure the necessary route tables and Transit Gateway route tables.
cnethers
👍 1
3. On-Premises Connectivity: o If the resources in the shared subnet need to communicate with an on-premises network, you can use AWS Direct Connect or a Site-to-Site VPN. o These connections can be routed through a Transit Gateway for more scalable and manageable network architecture.
cnethers
👍 1
Here's a breakdown of different scenarios and the required setup: 1. Internet Access: o If you need resources in the shared subnet to access the internet, ensure that the subnet is a public subnet with an associated Internet Gateway (IGW) and appropriate route table entries. o The account that owns the VPC will typically manage the IGW and the route tables.
shaaam80
👍 3
Selected: BD
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).
Sin_Dan
👍 1
How do you think the Accounts got subnets without VPCs?
severlight
👍 2
Selected: BD
I don't see the way you can share a prefix list.
mattfaz
👍 1
https://docs.aws.amazon.com/vpc/latest/userguide/sharing-managed-prefix-lists.html
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.
AlbertS82
👍 3
Selected: BD
B&D is the only correct answer
atirado
👍 4
Selected: BD
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
8693a49
👍 1
Subnets cannot be shared
8693a49
👍 1
Selected: AE
Voting A & E
amministrazione
👍 1
B. Enable resource sharing from the AWS Organizations management account. 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.
Chris_W_1234
👍 1
Not true. You can delete the default VPC in an account. The scenario mentions there is only one VPC, the one in the infra account, and that VPC gets shared with the other, "regular" accounts.
Kirkster
👍 1
In this case, there is actually only one VPC - the one in the infrastructure account. Users in other accounts deploy to subnets in that account, as those subnets are shared using resource sharing, as outlined in this blog: https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/
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.
8693a49
👍 1
I meant to say AE, but I can't edit the post now.
rapatajones
👍 1
Selected: BE
B E correta
rapatajones
👍 1
BE com certeza
gofavad926
👍 1
Selected: BD
BD, as mentioned in other comments
GibaSP45
👍 3
Selected: BE
https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html
abeb
👍 1
BE is good
senthilsekaran
👍 1
B & D correct
ansgohar
👍 1
Selected: BD
I go with B & D
srs27
👍 2
Do you really need Management account to share the resources among the accounts? I doubt.
dimitry_khan_arc
👍 1
Selected: BD
B & D are most relevant
whenthan
👍 4
Selected: BD
https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/
cattle_rei
👍 1
Selected: BD
BD is the most correct, the rest are distractors
cattle_rei
👍 1
BD seems the most correct
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.
NikkyDicky
👍 1
Selected: BD
it's BD
Parimal1983
👍 4
Selected: BE
Using prefix list we can simplify routing tables instead of sharing individual subnet of the VPCs. Need to enable resource sharing at organization.
lxrdm
👍 1
When you go into RAM and create a resource share, you can only select a subnet to share.
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.
rtguru
👍 1
I go with A&D
karma4moksha
👍 1
BD, agreed. A is wrong because if you share the network , there are no multiple networks and hence no gateway needed.
Maja1
👍 2
Selected: BD
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html
mfsec
👍 3
Selected: BD
BD is correct
mKrishna
👍 1
ANS: A & C. Option B is not required because AWS Organizations is already being used to manage the accounts. Resource sharing needs to be enabled, but this can be done by creating a resource share. Option D and E both involve creating a resource share in AWS Resource Access Manager (RAM), but they are not the correct solution for this scenario. Option D is specific to subnets, option E is specific to prefix lists, which are used for IP address ranges. Since VPCs are being used in this scenario, options D and E are not applicable.
newtrojan
👍 3
AWS orgs doesnt allow sharing by default https://docs.aws.amazon.com/ram/latest/userguide/security-disable-sharing-with-orgs.html
kiran15789
👍 2
wouldnt "Select each prefix list to associate with the resource share." will be use to do then go with selecting each subnet
Ajani
👍 1
Q: A solution to share a common network across multiple accounts -A because you need a way to route traffic, its either this or vpc peering(not mentioned) -Dor E Because a you can use RAM to share a subnet or prefixes. I am leaning towards E bcos a prefix will be more efficient. e.g. rather than share a /24 subnet. I will share a /16 prefix.(network summarization)
masssa
👍 4
Anwer is BD. https://aws.amazon.com/jp/premiumsupport/knowledge-center/vpc-share-subnet-with-another-account/
masssa
👍 1
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html
zozza2023
👍 1
Selected: BD
B & D seems to be the correct answers
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.
skashanali
👍 1
Selected: BD
Ans A doesn't make sense. You also need to enable sharing with AWS Organizations within Resource Access Manager service to share the subnet. https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs
Untamables
👍 2
Selected: BD
AWS Resource Access Manager can share subnets with other AWS accounts. https://docs.aws.amazon.com/ram/latest/userguide/shareable.html
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'
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
8693a49
👍 4
There are multiple VPCs because each account must have at least one.
masetromain
👍 29
Selected: BD
I go with BD
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.
robertohyena
👍 3
B & D https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →