Help Center/ Virtual Private Cloud/ User Guide/ VPC Sharing/ VPC Sharing Overview
Updated on 2026-11-04 GMT+08:00
View PDF
Share

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 with 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 account A and account 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 improve management efficiency and reduce 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 What Is RAM?

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

  1. 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.
    1. Select the subnet to share.
    2. Select permissions to grant to principals on the shared subnet.
    3. Specify one or more principals who can use the shared subnet.
  2. 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.
  1. Owner: Creating a Resource Share
  2. Principals: Responding to a Resource Sharing Invitation

    Leaving a Resource Share

Method 2

Using an existing resource share to share a subnet

  1. 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.
  2. 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.
  1. Owner: Sharing a Subnet with Other Accounts
  2. 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 that the shared subnet belongs to 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 that the shared subnet belongs to after the principals leave the share.

Principal
  • Has operation permissions listed in Table 3.
  • Creates 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. The owner can also view the virtual IP addresses and network interfaces of principals in the shared subnet.
Only can view the shared subnet, but cannot:
  • Modify the subnet.
  • Delete the subnet.
  • Add, modify, 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.

Quotas

Table 4 lists the quotas of shared subnets. The quotas cannot be increased.
Table 4 Quotas

Item

Default Quota

Maximum number of subnet shares that a principal can receive

100

Maximum number of principals that a subnet can be shared with

100

VPC Sharing Configuration Examples

Suppose you have two types of workloads running on the cloud. One requires Internet access, while the other does not. To manage resources in a standard way, you can use account A as an IT management account to manage basic, public resources, such as VPCs, subnets, and route tables. You can share subnets in a VPC in account A with accounts B, C, and D, so the principals can create resources, such as ECSs, RDS instances, and load balancers, in the shared subnets. You can plan your VPC sharing by referring to Figure 3, and plan accounts and resources as described in Table 5.

Figure 3 VPC sharing planning diagram
Table 5 VPC sharing planning description

Account

Role

Description

Account A

Owner of the VPC and subnets
  • Creates a VPC and subnets and shares the subnets with other accounts.
  • Creates a NAT gateway, assigns EIP, and configures SNAT rules to enable Subnet-01 to connect to the Internet.

Account B

Principal of the shared subnet

Creates ECSs and RDS instances in Subnet-01 to deploy applications that can be accessed over the Internet.

Account C and account D

Principal of the shared subnet

Create ECSs, RDS instances, and load balancers in Subnet-02. These resources do not need to connect to the Internet.
Subnets in the same VPC can communicate with each other by default. However, if instances of different accounts are associated with different security groups, they are isolated from each other. If you want the resources to communicate with each other, you need to add security group rules to allow the communications.
  • Resources in account A are protected by security group Sg-A.
  • Resources in account B are protected by security group Sg-B.
  • Resources in account C are protected by security group Sg-C.
  • Resources in account D are protected by security group Sg-D.

To enable resources in account C and account D to communicate with each other, add inbound rules to security groups Sg-C and Sg-D.

Table 6 Allowing traffic between Sg-C and Sg-D

Security Group

Direction

Priority

Action

Type

Protocol & Port

Source

Sg-C

Inbound

1

Allow

IPv4

Specify the protocol and port as needed.

Example: Protocols/All

Security group: Sg-D

Sg-D

Inbound

1

Allow

IPv4

Specify the protocol and port as needed.

Example: Protocols/All

Security group: Sg-C

Constraints

Parent Topic: VPC Sharing