Share your VPC with other accounts - Amazon Virtual Private Cloud
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

Share your VPC with other accounts

VPC sharing allows multiple Amazon Web Services accounts to create their application resources, such as Amazon EC2 instances, Amazon Relational Database Service (RDS) databases, Amazon Redshift clusters, and Amazon Lambda functions, into shared, centrally-managed virtual private clouds (VPCs). In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from Amazon Organizations. After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.

You can share your VPCs to leverage the implicit routing within a VPC for applications that require a high degree of interconnectivity and are within the same trust boundaries. This reduces the number of VPCs that you create and manage, while using separate accounts for billing and access control. You can simplify network topologies by interconnecting shared Amazon VPCs using connectivity features, such as Amazon PrivateLink, transit gateways, and VPC peering. For more information about the benefits of VPC sharing, see VPC sharing: A new approach to multiple accounts and VPC management.

Shared VPCs prerequisites

You must enable resource sharing from the management account for your organization. For information about enabling resource sharing, see Enable sharing with Amazon Organizations in the Amazon RAM User Guide.

Share a subnet

You can share non-default subnets with other accounts within your organization. To share subnets, you must first create a Resource Share with the subnets to be shared and the Amazon accounts, organizational units, or an entire organization that you want to share the subnets with. For information about creating a Resource Share, see Creating a resource share in the Amazon RAM User Guide.

To share a subnet using the console

  1. Open the Amazon VPC console at https://console.amazonaws.cn/vpc/.

  2. In the navigation pane, choose Subnets.

  3. Select your subnet and choose Actions, Share subnet.

  4. Select your resource share and choose Share subnet.

To share a subnet using the Amazon CLI

Use the create-resource-share and associate-resource-share commands.

Map subnets across Availability Zones

To ensure that resources are distributed across the Availability Zones for a Region, we independently map Availability Zones to names for each account. For example, the Availability Zone us-east-1a for your Amazon account might not have the same location as us-east-1a for another Amazon account.

To coordinate Availability Zones across accounts for VPC sharing, you must use an AZ ID, which is a unique and consistent identifier for an Availability Zone. For example, use1-az1 is the AZ ID for one of the Availability Zones in the us-east-1 Region. Use AZ IDs to determine the location of resources in one account relative to another account. You can view the AZ ID for each subnet in the Amazon VPC console.

The following diagram illustrates two accounts with different mappings of Availability Zone code to AZ ID.


          Two accounts with different mappings of Availability Zone code to AZ ID.

Unshare a shared subnet

The owner can unshare a shared subnet with participants at any time. After the owner unshares a shared subnet, the following rules apply:

  • Existing participant resources continue to run in the unshared subnet. Amazon managed services (for example, Elastic Load Balancing) that have automated/managed workflows (such as auto scaling or node replacement) may require continuous access to the shared subnet for some resources.

  • Participants can no longer create new resources in the unshared subnet.

  • Participants can modify, describe, and delete their resources that are in the subnet.

  • If participants still have resources in the unshared subnet, the owner cannot delete the shared subnet or the shared-subnet VPC. The owner can only delete the subnet or shared-subnet VPC after the participants delete all the resources in the unshared subnet.

To unshare a subnet using the console

  1. Open the Amazon VPC console at https://console.amazonaws.cn/vpc/.

  2. In the navigation pane, choose Subnets.

  3. Select your subnet and choose Actions, Share subnet.

  4. Choose Actions, Stop sharing.

To unshare a subnet using the Amazon CLI

Use the disassociate-resource-share command.

Identify the owner of a shared subnet

Participants can view the subnets that have been shared with them by using the Amazon VPC console, or the command line tool.

To identify a subnet owner using the console

  1. Open the Amazon VPC console at https://console.amazonaws.cn/vpc/.

  2. In the navigation pane, choose Subnets. The Owner column displays the subnet owner.

To identify a subnet owner using the Amazon CLI

Use the describe-subnets and describe-vpcs commands, which include the ID of the owner in their output.

Manage VPC resources

Owners and participants are responsible for the VPC resources that they own.

Owner resources

VPC owners are responsible for creating, managing, and deleting the resources associated with a shared VPC. These include subnets, route tables, network ACLs, peering connections, gateway endpoints, interface endpoints, Amazon Route 53 Resolver endpoints, internet gateways, NAT gateways, virtual private gateways, and transit gateway attachments.

VPC owners cannot modify or delete resources created by participants, such as EC2 instances and security groups. VPC owners can view the details for the network interfaces and security groups that are attached to participant resources, to facilitate troubleshooting and auditing. VPC owners can create flow log subscriptions for the VPC, its subnets, and its network interfaces.

Participant resources

Participants can create, manage, and delete resources in a shared VPC. Participants own the resources that they create in the VPC, such as EC2 instances, Amazon RDS databases, and Elastic Load Balancing load balancers.

Participants can view the details of resources that the VPC owners are responsible for, such as route tables and network ACLs, but they can't modify them. Participants can't view or modify resources that belong to other participant accounts. Participants can create flow log subscriptions only for the network interfaces that they own.

Participants can reference security groups that belong to other participants or the owner as follows:

account-number/security-group-id

Participants cannot directly associate one of their private hosted zones with the shared VPC. A participant that needs to control the behavior of a private hosted zone associated with the VPC can use of the following solutions:

Billing and metering for the owner and participants

In a shared VPC, each participant pays for their application resources including Amazon EC2 instances, Amazon Relational Database Service databases, Amazon Redshift clusters, and Amazon Lambda functions. Participants also pay for data transfer charges associated with inter-Availability Zone data transfer, data transfer over VPC peering connections, and data transfer through an Amazon Direct Connect gateway. VPC owners pay hourly charges (where applicable), data processing and data transfer charges across NAT gateways, virtual private gateways, transit gateways, Amazon PrivateLink, and VPC endpoints. Data transfer within the same Availability Zone (uniquely identified using the AZ-ID) is free irrespective of account ownership of the communicating resources.

Limitations

The following limitations apply to working with VPC sharing:

  • Owners can share subnets only with other accounts or organizational units that are in the same organization from Amazon Organizations.

  • Owners cannot share subnets that are in a default VPC.

  • Participants cannot launch resources using security groups that are owned by other participants that share the VPC, or the VPC owner.

  • Participants cannot launch resources using the default security group for the VPC because it belongs to the owner.

  • Owners cannot launch resources using security groups that are owned by other participants.

  • When participants launch resources in a shared subnet, they should make sure they attach their security group to the resource, and not rely on the default security group. Participants cannot use the default security group because it belongs to the VPC owner.

  • Participants cannot create Route 53 Resolver endpoints in a VPC that they do not own. Only the VPC owner can create VPC-level resources such as inbound endpoints.

  • VPC tags, and tags for the resources within the shared VPC are not shared with the participants.

  • Only a subnet owner can attach a transit gateway to the shared subnet. Participants cannot.

  • Participants can create Application Load Balancers and Network Load Balancers in a shared VPC, but they cannot register targets running in subnets that were not shared with them.

  • Only a subnet owner can select a shared subnet when creating a Gateway Load Balancer. Participants cannot.

  • Service quotas apply per individual account.