VPC Sharing Overview

What Is VPC Sharing?

VPC sharing allows multiple accounts to create and manage cloud resources, such as ECSs, load balancers, and RDS instances, in one VPC. With Resource Access Manager (RAM), you can share subnets in a VPC with one or more accounts so you can centrally manage resources in multiple accounts. This helps you improve resource management efficiency and reduce O&M costs.

The following describes how you can share subnets among several accounts, as shown in Figure 1.

Account A: IT management account of the enterprise and the owner of the VPC and subnets.
Account A creates a VPC and four subnets and shares these subnets with other accounts. Account A creates resources in Subnet-01.
Account B: service account of the enterprise and the principal of the shared subnet. Account B creates resources in Subnet-02.
Account C: service account of the enterprise and the principal of the shared subnet. Account C creates resources in Subnet-03.
Account D: service account of the enterprise and the principal of the shared subnet. Account D creates resources in Subnet-04.

Figure 1 Application scenario

The subnets of the owner and those of the principals are in the same VPC, so resources in these subnets can communicate with each other by default. However, if the resources in the subnets are associated with different security groups, the resources are isolated from each other. If you want the resources to communicate with each other, you need to add security group rules by referring to Adding a Security Group Rule.

For example, to allow ECSs in accounts A and B to communicate with each other, you need to add inbound rules to their security groups and set the source to the security group in the other account.

Advantages

For basic IT systems of financial enterprises and large enterprises, resources are managed by multiple accounts based on permissions. The following problems may arise from time to time:

There are multiple accounts, such as network accounts, security accounts, and service accounts. This makes cross-account resource O&M hard and time-consuming.
The cross-account network configurations result in a complex networking structure, hard user operations, and low efficiency.

To deal with these problems, you can share subnets with multiple accounts. You can organize accounts in an orderly and centralized manner based on organization structure or business model.

You can create subnets in a VPC under an account and share the subnets with principals. In this way, principals do not need to create VPCs and subnets. Fewer resources and simplified network architecture improves management efficiency and reduces costs.
If there are VPCs in different accounts, VPC peering connections are required for mutual communications among VPCs. With VPC sharing, different accounts can create resources in one VPC. This eliminates the need for configuring VPC peering connections and simplifies the network structure.
Resources can be centrally managed in one account, which helps enterprises configure service security policies in a centralized manner and better monitor and audit resource usage for higher security.

Process for Sharing a Subnet

Before sharing a subnet, you need to enable the RAM service in your account. For details, see Resource Access Manager User Guide.

As the owner of VPC subnets, you can share the subnets with other accounts. Principals need to accept the sharing requests before they use the subnets. Figure 2 shows the process of sharing a subnet.

Figure 2 Process for sharing a subnet

You can share a subnet on the RAM or VPC console. For details, see Table 1.

**Table 1** The process for sharing a subnet
Method	Description	Reference
Method 1	Creating a resource share to share a subnet The owner locates the subnet to share and clicks its name. On the Resource Share tab, the owner can click Create Share to go to the RAM console and create a resource share. Select the subnet to share. Select permissions to grant to principals on the shared subnet. Specify one or more principals who can use the shared subnet. On the RAM console, principals accept or reject the resource share. If principals accept the resource share, they can use the shared subnet. If principals do not want to use the shared subnet, they can leave the resource share. If principals reject the resource share, they cannot use the subnet.	Owner: Creating a Resource Share Principals: Responding to a Resource Sharing Invitation Leaving a Resource Share
Method B	Using an existing resource share to share a subnet The owner locates the subnet to share and clicks its name. On the Resource Share tab, select an existing resource share and add the subnet to it. On the RAM console, principals accept or reject the resource share. If principals accept the resource share, they can use the shared subnet. If principals do not want to use the shared subnet, they can leave the resource share. If principals reject the resource share, they cannot use the subnet.	Owner: Sharing a Subnet with Other Accounts Principals: Responding to a Resource Sharing Invitation Leaving a Resource Share

Operation Permissions on a Shared Subnet

The owner and principals of a shared subnet have different operation permissions on the subnet and associated resources. For details, see Table 2.

**Table 2** Operation permissions on a shared subnet and associated resources
Role	When a Share Is Accepted	When a Share Is Stopped	When the Principals Leave a Share
Owner	Has operation permissions listed in Table 3. Cannot modify or delete resources created by principals, such as ECSs, load balancers, and RDS instances. Views the information such as the IP address and ID of the resource created by principals on the IP Addresses tab of the shared subnet.	Uses, deletes, and manages all the resources in the VPC. If principals have resources in the subnet, the owner cannot delete the shared subnet or the VPC where the shared subnet belongs after the share is stopped.	Uses, deletes, and manages all the resources in the VPC. If principals have resources in the subnet, the owner cannot delete the shared subnet or the VPC where the shared subnet belongs after the principals leave the share.
Principal	Has operation permissions listed in Table 3. Create resources, such as ECSs, load balancers, and RDS instances, in the shared subnets. Views the information such as the IP address and ID of the resource created by themselves on the IP Addresses tab of the shared subnet.	Uses the existing resources created by themselves, but cannot create resources in the shared subnet.	Uses the existing resources created by themselves, but cannot create resources in the shared subnet.

The owner and principals of a shared subnet have different operation permissions on the subnet and associated resources. For details, see Table 3.

**Table 3** Operation permissions on a shared subnet and associated resources (sharing)
Resource	Owner	Principal
VPC	Has all operation permissions on the VPC of a shared subnet.	Only can view the VPC that the shared subnet belongs to, but cannot perform any operations on the VPC.
Subnet	Has all operation permissions on the shared subnet and can view the virtual IP addresses and network interfaces in the shared subnet.	Only can view the shared subnet, but cannot: Modify the subnet. Delete the subnet. Add, modifying, and delete subnet tags. Can assign virtual IP addresses and network interfaces in the subnet.
Route table	Has all operation permissions on the route table.	Cannot create a route table in the VPC that the shared subnet belongs to. Can view the route table associated with the shared subnet and the routes in the route table, but cannot perform any operations on the route table or the routes.
Network ACL	Has all operation permissions on the network ACL.	Can view the network ACL associated with the shared subnet, but cannot perform any operation on the network ACL. Cannot associate the owner's network ACL with their own subnets.
Security group	Can create their own security groups. Only has the operation permissions on their own security groups and cannot perform any operations on the security groups of the principals. For security groups associated with resources in a shared subnet, the owner can add rules to their own security groups and can set Source of the rules to the security groups of the principals. For example, in the shared Subnet-X: The owner has created ECS-X with security group Sys-X associated. Principal A has created ECS-A with security group Sys-A associated. Principal B has created database RDS-B with security group Sys-B associated. The owner can add rules with Source set to Sys-A or Sys-B to security group Sys-X.	Can create their own security groups. Only has the operation permissions on their own security groups and cannot perform any operations on the security groups of the owner or other principals. For security groups associated with resources in a shared subnet, a principal can add rules to their own security groups and can set Source of the rules to the security groups of the owner or other principals. For example, in the shared Subnet-X: The owner has created ECS-X with security group Sys-X associated. Principal A has created ECS-A with security group Sys-A associated. Principal B has created database RDS-B with security group Sys-B associated. Principal A can add rules with Source set to Sys-X or Sys-B to security group Sys-A.
IP address group	IP address groups are independent of each other. Owners can create an IP address group and associate it with their own security groups.	IP address groups are independent of each other. Principals can create an IP address group and associate it with their own security groups.
VPC flow log	Can create a flow log with Resource Type set to VPC or Subnet. Traffic on all network interfaces of the principal in the shared subnet will be recorded in this flow log. Can create a flow log with Resource Type set to NIC. Traffic on all network interfaces of the owner will be recorded in this flow log.	Can create a flow log with Resource Type set to NIC. Traffic on all network interfaces of the principal will be recorded in this flow log.
VPC peering connection	Selects the VPC with subnets shared with other accounts to create a VPC peering connection.	Cannot select the VPC with subnets shared with other accounts to create a VPC peering connection.
NAT gateway	Creates and manages NAT gateways in the shared subnet.	Cannot create NAT gateways in the shared subnet.
VPN gateway	Creates and manages VPN gateways in the shared subnet.	Cannot create VPN gateways in the shared subnet.
Enterprise router	Attaches the VPC with subnets shared with other accounts to an enterprise router.	Cannot attach the VPC with subnets shared with other accounts to an enterprise router.
Enterprise switch	Creates and manages enterprise switches in the shared subnet.	Cannot create enterprise switches in the shared subnet.
Direct Connect connection	Creates and manages Direct Connect connections in the shared subnet.	Cannot create Direct Connect connections in the shared subnet.
Cloud connection	Loads the VPC with subnets shared with other accounts to a cloud connection.	Cannot load the VPC with subnets shared with other accounts to a cloud connection.
VPC endpoint	Creates and manages VPC endpoints in the shared subnet.	Cannot create VPC endpoints in the shared subnet.
Tag	Adds and manages tags in the shared subnet.	Cannot add tags in the shared subnet.

Billing

You only need to pay for the resources (such as ECSs, load balancers, and RDS instances) you create in the shared subnets. For details, see the billing description of each cloud resource.