Lecture 257: VPC Sharing
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：15:23
- 来源：Udemy Lecture 43420594
- Slide 数量：8
- 画面切换：02:36、04:06、05:21、06:40、07:31、09:53、11:47
扫描说明
逐条读取了 Transcript 面板中的 237 条英文 cue，并按播放器进度同步全长约 15:23 的视频。依据 RAM/Organizations 前提、Shared VPC Architecture、Benefits、Shared vs Dedicated Subnet、AZ ID、Transit Gateway/Permission/Billing 与 Console Workflow 划分为 8 个小节。8 张截图来自真实课程 Slide 或 AWS Console 演示，统一为 1364×770。讲义补充了 Owner/Participant 的准确权限边界，并说明共享的是 Non-default Subnet；NAT Gateway/VPC Endpoint 的复用来自共享 VPC 的 Routing/DNS，不是把这些资源对象直接通过 RAM 分享给参与者。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. VPC Owner 通过 AWS RAM 共享 Non-default Subnet，Participant 在同一 VPC 部署资源
时间范围：00:00–02:36
总结 / Summary
中文
VPC Sharing 让同一 AWS Organization 内的多个 Account 使用一个集中管理的 VPC。Owner Account 创建 VPC/Subnet，并通过 AWS Resource Access Manager（RAM）把一个或多个 Non-default Subnet 分享给 Account、OU 或 Organization；Participant 在这些 Subnet 中创建自己拥有的 EC2、RDS、ECS/EKS 等受支持资源。需要由 Organizations Management Account 启用 RAM Trusted Access；可再委派 RAM Administrator。不能分享 Default Subnet，也不能分享 Default VPC 中的 Subnet。Owner 最好是专用 Network Account，而不是把网络资源放在 Organizations Management Account。
English
VPC sharing lets multiple accounts in the same AWS Organization use one centrally managed VPC. The owner account creates the VPC and subnets and uses AWS Resource Access Manager to share one or more non-default subnets with accounts, OUs, or the organization. Participants create supported resources such as EC2, RDS, ECS, or EKS in those subnets and own those resources. The Organizations management account must enable RAM trusted access and may delegate RAM administration. Default subnets and subnets in a default VPC cannot be shared. The owner should normally be a dedicated network account, not the Organizations management account.
Transcript
00:00 Hi.
00:01 Welcome to this lecture that is VPC sharing.
00:03 Now we have added this lecture recently because as per students feedback, we found that there could
00:09 be some questions which are related to the VPC sharing.
00:12 Now so far we talked about various networking features, for example VPC peering connections or transit
00:19 gateways.
00:19 But then there is also this feature of VPC through which you can share the same VPC with other AWS account.
00:27 And then those AWS accounts can launch their resources in the same VPC.
00:32 So in this lecture let's try to understand all the features of VPC sharing and then when to use this
00:38 feature.
00:39 Right now another thing to note that it is AWS organizational feature.
00:44 That means VPC sharing can be enabled only within the AWS accounts which are part of same AWS organization.
00:52 So multiple AWS account in an AWS organization can share a VPC to launch their own resources.
01:00 So account B can launch EC2 instance in the VPC, which is created by account A that is the VPC sharing.
01:07 Now in this case, there is the account which owns the VPC called as owner, and there are other accounts
01:07 which share the VPC are called the participant accounts.
01:15 Now, in order to enable the VPC sharing, you have to enable that feature at the AWS organization level.
01:15 And you can do that through AWS Organization Management account.
01:15 And I will shortly show you how to do that.
01:33 Once you enable this setting, then in the owner account you can create your VPC and additional resources,
01:39 for example subnets.
01:41 And then using the Resource Access Manager that is Ram.
01:44 You can share that subnet with other AWS accounts.
01:49 So for that you create a resource share.
01:51 And once you create this resource share, you can share it with other AWS account or different organization
01:59 units within the organization or with entire AWS organization.
02:03 In that case, that VPC or subnet will be available for all other AWS accounts.
02:10 So you can have this level of sharing within your AWS organization.
02:16 And finally, important thing to understand that you cannot share the default VPC.
02:21 So you know that in all AWS regions, AWS creates a default VPC.
02:26 But then VPC sharing cannot happen with the default VPC.
02:30 For that, you have to create your own custom VPC, and then you can share your VPC with other accounts.
2. Owner 管 Network Foundation，Participant 管自己的 Workload Resource
时间范围：02:36–04:06
总结 / Summary
中文
Owner 管理 VPC CIDR、Subnet、Route Table、NACL、Internet/NAT Gateway、Transit Gateway Attachment、Gateway Endpoint 等 Network Foundation；Participant 不能修改这些共享对象，只能在获共享的 Subnet 中创建、查看和删除自己拥有的 Workload Resource。Security Group 通常由创建它的 Account 管理；Shared VPC 内可按规则引用其他 Account 的 Security Group，但必须使用正确的 Account/SG 标识并满足服务支持。虽然 IAM Ownership 分离，Data Plane 仍在同一 VPC，需用 SG、NACL、Route 与 Firewall 设计隔离。
English
The owner manages VPC CIDRs, subnets, route tables, network ACLs, internet and NAT gateways, transit gateway attachments, gateway endpoints, and other network foundations. Participants cannot modify those shared objects; they create, view, and delete workload resources they own in shared subnets. A security group is generally managed by the account that created it, and accounts in a shared VPC can reference another account's security group where supported using the correct account and security-group identifiers. IAM ownership is separated, but the data plane remains one VPC, so isolation still requires security groups, NACLs, routes, and firewalls.
Transcript
02:36 Now essentially that's the crux of this lecture.
02:39 So if you just understand this I think this is good to answer a lot of questions.
02:43 But here let's try to understand more about VPC sharing architectures and some pros and cons so that
02:50 if there are any deeper questions you can answer those questions.
02:54 So with respect to the architecture, you could have multiple AWS accounts which are part of same AWS
02:59 organization.
03:00 And here you can see that in every AWS account there is a dedicated VPC.
03:05 But with VPC sharing you don't need to do that.
03:09 Rather, you can just have one VPC in the owner account.
03:12 And then you can additionally create the subnets which are shared across all these accounts using the
03:17 Resource Access Manager.
03:19 Now all these three accounts can launch their resources, for example EC2 instances or RDS databases
03:26 or redshift cluster in the same private subnet.
03:29 So you don't have to have VPCs in other AWS accounts.
03:33 But the question is what's the benefit of this?
03:35 Right.
03:36 So of course, the benefit is you don't have to have those many VPCs and those many subnets in all accounts.
03:42 And there are additional cost related benefits as well.
03:46 For example, here, instead of having three Nat gateways in every account, you just have one Nat gateway.
03:52 Similarly, there could be other resources.
03:54 For example, you could have VPC endpoints and any other resources which you can now share with all
04:01 other AWS accounts.
04:03 So cost wise as well, this is a good approach.
3. 共享 VPC 减少 CIDR/Connectivity Sprawl，并集中复用 Egress 与 Endpoint
时间范围：04:06–05:21
总结 / Summary
中文
相较每个 Application Account 各建 VPC，共享模式减少 VPC、Peering/TGW Attachment 与重叠 CIDR 数量，提高 IPv4 Utilization，并把 Network Team 与 Application Team 的职责分开。集中 NAT Gateway、Inspection、DNS、Transit Connectivity 与 VPC Endpoint 可降低重复建设。这里的“共享 NAT/Endpoint”是 Participant Workload 通过 Owner 管理的 Subnet Route/DNS 使用它们，并非 RAM 把 NAT Gateway 或 Endpoint Resource 的管理权分享出去。集中化也会扩大 Failure Domain，成本与可用性必须按 AZ 设计。
English
Compared with a VPC per application account, sharing reduces VPCs, peering or transit-gateway attachments, and overlapping CIDRs, improves IPv4 utilization, and separates network-team from application-team duties. Central NAT gateways, inspection, DNS, transit connectivity, and VPC endpoints can reduce duplication. Reusing NAT or endpoints means participant workloads use owner-managed routing and DNS; RAM does not grant participants management of NAT gateways or endpoint resources. Centralization also enlarges the failure domain, so cost and availability must be designed per Availability Zone.
Transcript
04:06 Now quickly, what are the benefits of sharing the VPC?
04:09 As I said, it simplifies your design.
04:11 You don't need to have those many VPCs in every account.
04:15 So fewer managed VPCs.
04:17 It avoids the Cidr overlap problem.
04:20 It also provides you some segregation of duties.
04:23 For example, the owner account could be owned by the networking team and all the development or application
04:29 team can share the same VPC.
04:31 So networking team controls what resources needs to go there and which subnets to be shared with the
04:37 application accounts.
04:39 And it gives you better control over your IPv4 addresses.
04:43 And you fully utilize your Cidr ranges because you don't have to allocate Cidr range separately in the
04:50 participant accounts.
04:52 Finally, you can have the reuse of your resources, for example Nat gateways or VPC endpoints, which.
04:59 Saves you a lot of cost.
05:01 And finally, if you design your architecture such that in all the AWS account, you use the same availability
05:07 zone when you share that subnet.
05:10 In that case, you also avoid the inter AZ data transfer cost.
05:14 And I'll quickly explain about this in more detail.
05:17 So these are the benefits of sharing the VPC.
4. 同一 Shared Subnet 提高地址利用率，但带来 Noisy Neighbor 与大 Blast Radius
时间范围：05:21–06:40
总结 / Summary
中文
把同一 Subnet 同时分享给多个 Account，所有 Participant 从同一 CIDR Pool 消耗 IP，地址利用率高、Subnet 数量少。但任一团队大量创建 ENI/Pod/Instance 都可能耗尽可用 IP，形成 Noisy Neighbor；共同 Route Table/NACL/Network Path 的错误也同时影响所有 Workload。应设置 Quota/Monitoring、预留容量，并通过不同 Environment/Tier/AZ 的 Subnet 与 Security Control 限制影响范围。共享 Subnet 并不天然提供 Tenant Isolation。
English
Sharing the same subnet with multiple accounts makes all participants consume one CIDR pool, improving utilization and reducing subnet count. However, a team creating many ENIs, pods, or instances can exhaust addresses and become a noisy neighbor, while an error in a shared route table, NACL, or network path affects every workload. Use quotas, monitoring, reserved capacity, and separate environment, tier, or AZ subnets with security controls to limit impact. A shared subnet does not inherently provide tenant isolation.
Transcript
05:21 Now with respect to the architecture there are typically two patterns you will see when you share the
05:26 VPC.
05:27 So here as you can see there are four different accounts.
05:30 And there is an owner account here which has the Nat gateways in a public subnet and then some VPC endpoints.
05:37 And now you want to share this with all other AWS accounts.
05:41 So what you can do is you can create private subnets inside the owner VPC.
05:46 And then this subnets can be shared with all other AWS accounts.
05:50 So this is kind of one of the approach where one subnet is shared with all other AWS accounts.
05:57 So there are pros and cons of this approach.
05:59 Of course the pros is that you are using your IP addresses effectively.
06:04 Right.
06:05 But there are some cons.
06:06 For example noisy neighbor problem.
06:09 What if this account D launches more resources in the same subnet and it exhausts all the private IP
06:16 addresses?
06:17 In that case, the other accounts will not be able to launch their resources.
06:21 So that's called noisy neighbor problem.
06:24 Similarly there is a higher blast radius.
06:27 So say there is some problem with the route table.
06:29 Somebody removes the route table entry for this private subnet.
06:32 In that case all the resources in this subnet will be affected at the same time.
06:37 So higher blast radius is there.
5. 每 Account Dedicated Subnet 提高 Isolation，却牺牲 CIDR Utilization
时间范围：06:40–07:31
总结 / Summary
中文
另一模式是在同一 Owner VPC 中为每个 Participant Account 分配 Dedicated Subnet。这样 IP Consumption、Route/NACL Change 与故障更容易按账号隔离，也便于 Chargeback、Quota 和 Application Ownership；代价是更多 Subnet/Route Table、预先切分 CIDR，以及空闲地址不能被其他 Account 自动借用。实践常按 Account × AZ 创建 Subnet，而不是只按 Account 创建一个 Subnet，以同时满足 High Availability 与清晰的 Fault Boundary。
English
An alternative allocates dedicated subnets in the owner VPC to each participant account. IP consumption, route or NACL changes, and failures are easier to isolate by account, and chargeback, quotas, and application ownership are clearer. The tradeoff is more subnets and route tables, up-front CIDR partitioning, and stranded addresses that other accounts cannot automatically borrow. Designs commonly create subnets by account and AZ rather than one subnet per account, preserving high availability and clear fault boundaries.
Transcript
06:40 Right.
06:40 So another approach is instead of sharing the same subnet with all the accounts at the same time, you
06:46 rather create a dedicated subnet for every account.
06:49 So this will look something like this.
06:51 Now for account B you are creating a dedicated subnet.
06:55 Similarly you are doing for account C and account D.
06:58 Now there is no problem of the noisy neighbor and you have better control over this subnets.
07:04 But again there is some problem which is like low IP address utilization.
07:08 Right.
07:09 Because you have to create as many subnets now and every subnet would need their Cidr.
07:14 So there is always a trade off whether you go with the first design or the second design.
07:20 But you just should know that there are these different patterns through which you can share your subnets
07:25 across different AWS accounts.
07:27 So I hope that is clear right now.
6. 跨账号对齐用 AZ ID，而不是 us-east-1a 等 Account-specific AZ Name
时间范围：07:31–09:53
总结 / Summary
中文
同一物理 Availability Zone 在不同 Account 中可能显示为不同 AZ Name；AZ ID（例如 use1-az1）才是跨账号稳定标识。共享 Subnet 时实际 AZ 已由 Owner 决定，但 Participant 规划同 AZ Resource、EBS、Load Balancer Node 或依赖其他 VPC 时，应以 AZ ID 对齐。Egress 也应优先使用同 AZ NAT Gateway/Inspection Endpoint：跨 AZ 到集中 NAT 会产生 Cross-AZ Data Transfer、额外延迟，并把单 AZ 故障扩大。最稳妥模式是在每个使用 AZ 部署 Egress，再让该 AZ 的 Subnet Route 指向本 AZ Target。
English
The same physical Availability Zone may have different AZ names in different accounts; the AZ ID, such as use1-az1, is the stable cross-account identifier. A shared subnet's actual AZ is chosen by the owner, but participants should align by AZ ID when planning same-AZ resources, EBS, load-balancer nodes, or dependencies in another VPC. Egress should also prefer a same-AZ NAT gateway or inspection endpoint: crossing AZs adds transfer cost and latency and enlarges a single-AZ failure. A resilient pattern deploys egress in every used AZ and routes each subnet to its local target.
Transcript
07:31 I had also talked about some inter AC data transfer costs.
07:34 Now when you create the subnet share, basically you have to make sure that you are using the same availability
07:41 zone across these different AWS accounts.
07:44 Because if you don't do that, then if there is any data transfer between these resources across different
07:50 accounts, there will be data transfer cost because they are crossing the AZ boundary.
07:54 And for that, there is one important thing to understand.
07:57 Whenever you talk about the AZ, for example, US East one a this AZ may be different for another account
08:05 in the same region.
08:07 Now what do I mean by that?
08:08 So here for example, this is US East one region.
08:11 And if there are three AZS.
08:13 So in account a US east one A could be this AZ.
08:17 But for account B US east, one A could be a different AZ.
08:21 And why AWS will do that.
08:24 This is because probably AWS want to make sure that the resources are created evenly across all the
08:30 AZS.
08:30 Otherwise, if all the customers of AWS will launch all their resources in, say, US East one A all
08:36 the time, then this will be the populated AZ, right?
08:40 And that's where this mapping is created.
08:42 So with respect to the VPC sharing, if you are sharing your subnet with other accounts, you make sure
08:48 that you use the same AZ ID rather.
08:51 Right.
08:52 So along with the AZ name there is also AZ id.
08:56 Now this AC id is constant across different AWS account.
09:01 They mean the same AZ.
09:03 So always look at the AZ id instead of AZ name when you share your VPC.
09:10 So that is one thing that you should know while you share your subnets.
09:15 So this avoids that inter AZ data transfer cost.
09:18 Now just to show you again there is this Nat gateway and there is this private subnet.
09:23 Now all these instances are using the same Nat gateway for the egress traffic.
09:29 And if this Nat gateway is in different AZ then this resources here.
09:33 Then all these accounts will pay for that data transfer cost across AZ.
09:38 So if this Nat gateway is in this acid, then all these resources should also be created in the same
09:46 AZ it.
09:47 So that's where it will save you inter AZ data transfer cost.
09:51 So I hope that is clear.
7. VPC Sharing 解决同一 VPC 的 Multi-account Ownership，Transit Gateway 连接不同 VPC/On-premises
时间范围：09:53–11:47
总结 / Summary
中文
VPC Sharing 不是 Transit Gateway 的替代品：前者让多个 Account 在同一 VPC 的 Shared Subnet 部署资源，后者连接多个 VPC、VPN、Direct Connect/On-premises，并通过 Route Table 实现分段与集中 Inspection。可按 Business Unit 建一个 Shared VPC，再由 TGW 连接各 Business Unit。Billing 以 Resource Ownership 与 Meter 为准：Participant 支付自己创建的 Workload 及适用 Data Transfer，Owner 支付自己拥有的 NAT/Endpoint/TGW 等网络资源费用；具体 Processing/Transfer Charge 应用 CUR 验证。SCP 可限制 RAM Share/Network API，但不能代替 SG/Route 的 Data-plane Security。
English
VPC sharing does not replace Transit Gateway. Sharing lets multiple accounts deploy into subnets of one VPC, while Transit Gateway connects separate VPCs, VPNs, and Direct Connect or on-premises networks and supports segmentation and centralized inspection through route tables. A business unit can use one shared VPC and connect business-unit VPCs through a transit gateway. Billing follows resource ownership and specific meters: participants pay for workloads they create and applicable data transfer, while the owner pays for owner-created NAT, endpoint, transit, and other network resources; verify exact processing and transfer charges with Cost and Usage Reports. SCPs can restrict RAM and network APIs but do not replace data-plane security.
Transcript
09:53 Right now you might have a question around is it a replacement for Transit Gateway.
09:58 So.
09:59 Answer is no.
10:00 Actually, the purpose is different here, right?
10:02 You can use both VPC sharing and the transit gateway at the same time.
10:07 For example, in a given business unit you can just have one VPC.
10:11 And all the development teams can use the same VPC.
10:14 But when it comes to communication between these business units at that time, you can connect these
10:20 different VPCs using the transit gateway.
10:22 Likewise.
10:23 And further, this transit gateway can be extended to your on premise network over a Rd or, you know,
10:29 VPN connection.
10:31 So you can use all these features at the same time.
10:34 So this is just one kind of architecture that you can design using both VPC sharing and the transit
10:42 gateway.
10:43 Right.
10:43 So I think those are the essential things that you should know for your exam.
10:48 And additionally I have also provided some kind of permission models as in what permission the VPC owner
10:56 has and what permission VPC participants are.
10:59 So I'll just recommend that you just go through this list once so that if any questions come around
11:05 this, then you know the answer.
11:08 Similarly, there are billing related things that you should know.
11:11 For example, who pays for what.
11:13 And typically data transfer cost will be paid by the participant and the resource cost.
11:17 For example, Nat gateway per hour running cost or VPC endpoint per hour running cost will be paid by
11:23 the VPC owner.
11:25 And there are some best practices with respect to.
11:27 If you want to control with which account you can share this resource or not.
11:32 You can do that using the AWS organization controls, for example, service control policies or also
11:39 called as SCP, and also using the Resource Access Manager.
11:43 So these are few additional things that you should be knowing.
8. Console Workflow：启用 RAM Trusted Access → Share Subnet → 选择 Principal/Permission → Participant Launch
时间范围：11:47–15:23
总结 / Summary
中文
流程是：在 Organizations Management Account 启用 RAM 与 Organizations 的资源共享；在 Owner/Delegated Admin 创建 Resource Share，Resource Type 选择 ec2:Subnet，添加 Non-default Subnet，使用 AWS Managed 或 Customer Managed Permission，并选择 Account/OU/Organization Principal；组织内 Sharing 通常无需 Invitation Acceptance。Participant 随后在 VPC/EC2 Console 看见 Shared VPC/Subnet，并可在其中 Launch 自有 Resource。RAM Permission 定义可对 Shared Resource 做什么，Participant IAM 还必须允许相应 Create 操作；两者缺一不可。
English
The workflow is to enable RAM sharing with Organizations in the management account, then create a resource share in the owner or delegated administrator account, select the ec2:Subnet resource type and a non-default subnet, associate an AWS managed or customer managed permission, and choose account, OU, or organization principals. Organization sharing normally does not require invitation acceptance. Participants then see the shared VPC and subnet and can launch resources they own. The RAM permission defines actions on the shared resource, while participant IAM must also allow the relevant create operation; both are required.
Transcript
11:47 Now, before we wrap this lecture, I just want to quickly show you in AWS console where you enable
11:53 the resource sharing.
11:55 So let's quickly do that.
11:56 So I am in my AWS management account of AWS organization.
12:00 And then I have multiple accounts.
12:02 So what you have to do is you have to go to Resource Access Manager.
12:06 That is Ram.
12:08 And here there are settings for example here and it says enable the sharing of the AWS organization.
12:17 And you have to change this setting.
12:20 Now once you do that then you have to go to your main account.
12:23 So this is my main account for example.
12:26 And I go to my VPC.
12:28 So this is my management account.
12:30 And then I have few VPCs.
12:32 So I have to choose the Non-default VPC.
12:34 For example this demo VPC which I might have created earlier.
12:39 And then I can say share the subnet.
12:41 Now so far we haven't created any sharing.
12:45 So we have to use the resource share which takes us to the AWS Resource Access Manager.
12:51 And here I will say share my subnet.
12:56 That's the name of my subnet.
12:59 And then what are the type of the resource.
13:01 So it's a subnet.
13:03 And then which subnet we want to share which is this.
13:06 And within that subnet if there are many resources for example if you select EC2 there could be additional
13:12 things that you want to share.
13:13 But here it is just a subnet.
13:15 So we have to select that and say next.
13:20 And here what all the actions that you want to allow other accounts to do on this subnet.
13:27 Right.
13:27 So as of now we are saying that we'll go with the default.
13:32 And here do you want to share with account or a particular user in the account.
13:37 So we want to do that with particular AWS account within the organization.
13:41 And you can also select the organization structure.
13:45 So I have this another AWS account within the same organization.
13:49 And I want to use that principal ID to share my subnet.
13:54 So I say next and I just create the resource share.
13:59 Now this will take maybe a couple of minutes for this resource share to be created.
14:05 And then I should have this subnet available in my target account which was this account.
14:12 So I'm pausing this video for a minute and I'll come back.
14:16 Okay, so I am now in my different account.
14:19 You can see this account number.
14:21 And now if I go into the same region that is Mumbai I see two VPCs.
14:25 Now I to be honest did not create this second VPC.
14:29 And you can also see this account owner which is my management account, which means I have also access
14:37 to now this another subnet which comes from this this account.
14:41 Right.
14:42 So this VPC and it clearly also says shared here right now if you go to the EC2 instance then you can
14:49 select that VPC and this subnet to launch your resource.
14:53 And this is how you create the subnet share.
14:55 So I hope that is clear.
14:57 Now with that we'll stop for this lecture.
14:59 So the point is you can share your VPC with other AWS account.
15:03 And it provides you a lot of benefits like right usage of your IP addresses.
15:08 And you can also save some cost with respect to the resources like VPC endpoints or Nat gateways.
15:14 And of course uh also intra data transfer charges.
15:18 Right.
15:19 So that's it.
15:20 Thanks for watching and stay tuned.
整讲总结 / Overall Summary
中文
VPC Sharing 的考试重点是同一 Organization、RAM Trusted Access、Owner/Participant、Non-default Subnet、权限与计费归属、Shared vs Dedicated Subnet Trade-off，以及 AZ ID。Owner 管 VPC Network Foundation，Participant 管自己的 Workload；共享 VPC 减少 CIDR 与连接复杂度，但没有自动隔离，也不替代 Transit Gateway。
English
VPC sharing exam priorities are a common organization, RAM trusted access, owner and participant roles, non-default subnets, permission and billing ownership, shared-versus-dedicated subnet tradeoffs, and AZ IDs. The owner manages the network foundation while participants manage their workloads. Sharing reduces CIDR and connectivity complexity, but it does not provide automatic isolation and does not replace Transit Gateway.
返回顶部 ↑