# Share your VPC subnets with other accounts Share a VPC subnet VPC subnet sharing allows multiple AWS accounts to create their application resources, such as Amazon EC2 instances, Amazon Relational Database Service (RDS) databases, Amazon Redshift clusters, and AWS 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 AWS 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 VPC subnets 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 VPC subnets using connectivity features, such as AWS PrivateLink, transit gateways, and VPC peering. For more information about the benefits of VPC subnet sharing, see [VPC sharing: A new approach to multiple accounts and VPC management](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/). There are quotas related to VPC subnet sharing. For more information, see [VPC subnet sharing](amazon-vpc-limits.md#vpc-share-limits). **Topics** + [ # Shared subnet prerequisites ](vpc-share-prerequisites.md) + [ # Working with shared subnets ](vpc-sharing-share-subnet-working-with.md) + [ # Billing and metering for owner and participants ](vpc-share-billing.md) + [ # Responsibilities and permissions for owners and participants ](vpc-share-limitations.md) + [ # AWS resources and shared VPC subnets ](vpc-sharing-service-behavior.md) # Shared subnet prerequisites This section contains prerequisites for working with shared subnets: + The accounts for the VPC owner and participant must be managed by AWS Organizations. + You must enable resource sharing in the AWS RAM console from the management account for your organization. For more information, see [Enable resource sharing within AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) in the *AWS RAM User Guide*. + You must create a resource share. You can specify the subnets to share when you create the resource share, or add the subnets to the resource share later on using the procedure in the next section. For more information, see [Create a resource share](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create) in the *AWS RAM User Guide*. # Working with shared subnets This section describes how to work with shared subnets in the AWS console and AWS CLI. **Topics** + [ ## Share a subnet ](#vpc-sharing-share-subnet) + [ ## Unshare a shared subnet ](#vpc-sharing-stop-share-subnet) + [ ## Identify the owner of a shared subnet ](#vpc-sharing-view-owner) ## Share a subnet You can share non-default subnets with other accounts within your organization as follows. In addition, you can share security groups across AWS Organizations. For more information, see [Share security groups with AWS Organizations](security-group-sharing.md). **To share a subnet using the console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Subnets**. 1. Select your subnet and choose **Actions**, **Share subnet**. 1. Select your resource share and choose **Share subnet**. **To share a subnet using the AWS CLI** Use the [create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html) and [associate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/associate-resource-share.html) 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 AWS account might not have the same location as `us-east-1a` for another AWS 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.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/availability-zone-mapping.png) ## 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. AWS 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.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Subnets**. 1. Select your subnet and choose **Actions**, **Share subnet**. 1. Choose **Actions**, **Stop sharing**. **To unshare a subnet using the AWS CLI** Use the [disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html) 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.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Subnets**. The **Owner** column displays the subnet owner. **To identify a subnet owner using the AWS CLI** Use the [describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html) and [describe-vpcs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpcs.html) commands, which include the ID of the owner in their output. # Billing and metering for owner and participants This section contains billing and metering details for those who own the shared subnet and for those working with the shared subnet: + In a shared VPC, each participant pays for their application resources including Amazon EC2 instances, Amazon Relational Database Service databases, Amazon Redshift clusters, and AWS Lambda functions. Participants also pay for data transfer charges associated with inter-Availability Zone data transfer as well as data transfer over VPC peering connections, across internet gateways, and across AWS Direct Connect gateways. + VPC owners pay hourly charges (where applicable), data processing and data transfer charges across NAT gateways, virtual private gateways, transit gateways, AWS PrivateLink, and VPC endpoints. In addition, public IPv4 addresses used in shared VPCs are billed to VPC owners. For more information about public IPv4 address pricing, see the **Public IPv4 Address** tab on the [Amazon VPC pricing page](https://aws.amazon.com/vpc/pricing/). + Data transfer within the same Availability Zone (uniquely identified using the AZ-ID) is free irrespective of account ownership of the communicating resources. # Responsibilities and permissions for owners and participants This section includes details about the responsibilities and permissions for those who own the shared subnet (owner) and for those who are using the shared subnet (participant). ## Owner resources Owners are responsible for the VPC resources that they own. 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, Route 53 Resolver endpoints, internet gateways, NAT gateways, virtual private gateways, and transit gateway attachments. ## Participant resources Participants are responsible for the VPC resources that they own. Participants can create a limited set of VPC resources in a shared VPC. For example, participants can create network interfaces and security groups, and enable VPC flow logs for the network interfaces that they own. The VPC resources that a participant creates count against the VPC quotas in the participant account, not the owner account. For more information, see [VPC subnet sharing](amazon-vpc-limits.md#vpc-share-limits). ## VPC resources The following responsibilities and permissions apply to VPC resources when working with shared VPC subnets: **Flow logs** + Participants can create, delete, and describe flow logs for network interfaces that they own in a shared VPC subnet. + Participants cannot create, delete, or describe flow logs for network interfaces that they do not own in a shared VPC subnet. + Participants cannot create, delete, or describe flow logs for a shared VPC subnet. + VPC owners can create, delete, and describe flow logs for network interfaces that they do not own in a shared VPC subnet. + VPC owners can create, delete, and describe flow logs for a shared VPC subnet. + VPC owners cannot describe or delete flow logs created by a participant. **Internet gateways and egress-only internet gateways** + Participants cannot create, attach, or delete internet gateways and egress-only internet gateways in a shared VPC subnet. Participants can describe internet gateways in a shared VPC subnet. Participants cannot describe egress-only internet gateways in a shared VPC subnet. **NAT gateways** + Participants cannot create, delete, or describe NAT gateways in a shared VPC subnet. **Network access control lists (NACLs)** + Participants cannot create, delete, or replace NACLs in a shared VPC subnet. Participants can describe NACLs created by VPC owners in a shared VPC subnet. **Network interfaces** + Participants can create network interfaces in a shared VPC subnet. Participants cannot work with network interfaces created by VPC owners in a shared VPC subnet in any other way, such as attaching, detaching, or modifying the network interfaces. Participants can modify or delete the network interfaces in a shared VPC that they created. For example, participants can associate or disassociate IP addresses with the network interfaces that they created. + VPC owners can describe network interfaces owned by participants in a shared VPC subnet. VPC owners cannot work with network interfaces owned by participants in any other way, such as attaching, detaching, or modifying the network interfaces owned by participants in a shared VPC subnet. **Route tables** + Participants cannot work with route tables (for example, create, delete, or associate route tables) in a shared VPC subnet. Participants can describe route tables in a shared VPC subnet. **Security groups** + Participants can work with (create, delete, describe, modify, or create ingress and egress rules for) security groups that they own in a shared VPC subnet. Participants can work with security groups created by VPC owners if [the VPC owner shares the security group with the participant](security-group-sharing.md). + Participants can create rules in the security groups that they own that reference security groups that belong to other participants or the VPC owner as follows: account-number/security-group-id + Participants can't launch instances using the default security group for the VPC because it belongs to the owner. + Participants can't launch instances using non-default security groups that are owned by the VPC owner or other participants unless the security group is [shared with them](security-group-sharing.md). + VPC owners can describe the security groups created by participants in a shared VPC subnet. VPC owners cannot work with security groups created by participants in any other way. For example, VPC owners can't launch instances using security groups created by participants. **Subnets** + Participants cannot modify shared subnets or their related attributes. Only the VPC owner can. Participants can describe subnets in a shared VPC subnet. + VPC owners can share subnets only with other accounts or organizational units that are in the same organization from AWS Organizations. VPC owners can't share subnets that are in a default VPC. **Transit gateways** + Only the VPC owner can attach a transit gateway to a shared VPC subnet. Participants can't. **VPCs** + Participants cannot modify VPCs or their related attributes. Only the VPC owner can. Participants can describe VPCs, their attibutes, and the DHCP option sets. + VPC tags and tags for the resources within the shared VPC are not shared with the participants. + Participants can associate their own security groups with a shared VPC. This allows the participant to use the security group with Elastic network interfaces they own in the shared VPC. # AWS resources and shared VPC subnets The following AWS services support resources in shared VPC subnets. For more information, follow the links to the corresponding service documentation. + [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Shared_subnets) + [AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared) + [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html#ec2-shared-VPC-subnets) + [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html) + Amazon ElastiCache (Redis OSS) + [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/mount-fs-diff-account-same-vpc.html) + [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/network-reqs.html#network-requirements-shared) + Elastic Load Balancing + [Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html#register-targets-shared-subnets) + [ Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html#prerequisites) + [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-targets-shared-subnets) + [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-clusters-in-a-vpc.html#emr-vpc-shared-subnet) + [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/shared-vpc.html) + AWS Lambda + Amazon MQ running Apache MQ (not Rabbit MQ) + Amazon MSK + AWS Network Manager + [AWS Cloud WAN](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-vpc-attachment.html#cloudwan-vpc-attachments-shared-subnets) + [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations) + [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations) + Amazon OpenSearch Service + [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#interface-endpoint-shared-subnets)† + [Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Shared_subnets) + [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/rs-shared-subnet-vpc.html) + [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html) + [Amazon SageMaker Unified Studio](https://docs.aws.amazon.com/sagemaker-unified-studio/latest/adminguide/create-domain-sagemaker-unified-studio-quick.html) + [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/working-with-transit-gateways.html#transit-gateway-shared-subnets) + [AWS Verified Access](https://docs.aws.amazon.com/verified-access/latest/ug/verified-access-endpoints.html#shared-vpc) + Amazon VPC + [Peering](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html#vpc-peering-limitations) + [Traffic Mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-network-limitations.html) + [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-target-group.html#target-group-shared-subnets) † You can connect to all AWS services that support PrivateLink using a VPC endpoint in a shared VPC. For a list of services that support PrivateLink, see [AWS services that integrate with AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) in the *AWS PrivateLink Guide*. This list is intended to include all services that support launching resources in shared VPC subnets. Despite our best efforts, there might be services that support launching resources in shared VPC subnets but are not listed here. We encourage you to submit documentation feedback if you have questions.