VPC sharing for AWS resources
VPC sharing makes it so you can create AWS application resources, such as Amazon EC2 instances and other AWS services, in a shared, centrally-managed virtual private cloud (VPC). The account that owns the VPC (the owner) shares one or more subnets with other accounts (participants) that belong to the same AWS organization. This describes how you can create and use an Amazon Redshift cluster or Amazon Redshift Serverless workgroup in a shared VPC.
The benefits of VPC sharing include that you don't have to manage as many VPCs and it can help you simplify your network. The benefit specifically for Amazon Redshift administrators and users is that Redshift resources can operate productively in the shared VPC. For more information about VPC sharing, see Share your VPC with other accounts, which goes into more detail regarding the benefits of VPC sharing and how it works.
Amazon Redshift data-warehouse resources in a shared VPC
Firstly, it's important to understand that an Amazon Redshift cluster or an Amazon Redshift Serverless workgroup can't be made visible to participants in a shared subnet. But this doesn't preclude participants from working with the owner's database in a shared VPC. This is detailed more fully in the steps that follow.
Before you create a provisioned Amazon Redshift cluster or Serverless workgroup in a shared VPC, you must create a subnet group that you intend to use for Redshift resources. This should include the subnets from the shared VPC that you want to use. When you create a provisioned cluster, you must choose this subnet and also specify the shared VPC's security group. Similarly, when you create a Amazon Redshift Serverless workgroup and database, you have to specify the shared subnets and the security group you created in the shared VPC. You can make these selections in the console. These are the steps to perform to set up Redshift resources in the shared environment, after you configure subnets:
-
The VPC owner creates an Amazon Redshift cluster or Amazon Redshift Serverless workgroup, using a subnet in the shared VPC.
-
The VPC owner makes the cluster or workgroup available in a cross-VPC scenario. The steps are described in Working with Redshift-managed VPC endpoints in Amazon Redshift for a provisioned cluster or in Connecting to Amazon Redshift Serverless from an Amazon Redshift managed VPC endpoint for Amazon Redshift Serverless. By enabling cross-VPC availability, the database can be made available to users in the same AWS account, or in other accounts.
-
Conversely, by means of VPC sharing, an owner can share a subnet with a participant, and the participant can create an Amazon Redshift cluster or Amazon Redshift Serverless workgroup in the subnet. However, the owner in this case can't view an Amazon Redshift resource created by a participant. The cluster or workgroup must be made accessible by enabling cross-VPC availability, as described in the previous step.
Considerations for using Amazon Redshift resources in a shared VPC
Note the following behaviors regarding using Amazon Redshift in a shared subnet:
-
As detailed in the previous section, the VPC owner can't share an Amazon Redshift cluster or Amazon Redshift Serverless workgroup with a participant through VPC sharing. But the participant can create a cluster or Amazon Redshift Serverless workgroup in the owner's subnet. In this instance, Amazon Redshift isn't visible through VPC sharing to the owner.
-
The VPC owner can't view, update or delete an Amazon Redshift provisioned cluster or Amazon Redshift Serverless workgroup that the participant creates in the shared subnet.
-
There aren't permissions available to make it so another AWS account can access Amazon Redshift resources you create in the shared VPC.