VPC network overview
A virtual private cloud (VPC) is a virtual network that you can define in a cloud provider. After you create a VPC on a cloud provider, you can then connect it with other VPCs on the same provider. This is called peering. A VPC peering connection is a networking connection between two VPCs on the same cloud provider that enables you to route traffic between them privately, without traversing the public internet. VPC networks provide more secure connections between resources because the network is inaccessible from the public internet and other VPC networks.
In the context of YugabyteDB Managed, when a Yugabyte cluster is deployed in a VPC, it can connect to an application running on a peered VPC as though it was located on the same network; all traffic stays in the cloud provider's network. The VPCs can be in different regions.
A VPC is defined by a block of private IP addresses, entered in CIDR notation. In the context of your VPC network, each address is unique. A cluster deployed in a VPC can only be accessed from resources inside the VPC network.
Deploying your cluster in a VPC network has the following advantages:
- Lower network latency. Traffic uses only internal addresses, which provides lower latency than connectivity that uses external addresses.
- Better security. Your services are never exposed to the public Internet.
- Lower data transfer costs. By staying in the provider's network, you won't have any Internet data transfer traffic. (Same region and cross region overages may still apply. Refer to Data transfer costs.)
There's no additional charge for using a VPC. In most cases, using a VPC will reduce your data transfer costs. VPCs are not supported for Sandbox clusters.
- You assign a VPC when you create a cluster. You can't switch VPCs after cluster creation.
- You can't change the size of your VPC once it is created.
- You can't peer VPCs with overlapping ranges with the same application VPC.
- You can create a maximum of 3 AWS VPCs per region.
- You can create a maximum of 3 GCP VPCs.
- VPCs are not supported on Sandbox clusters.
If you need additional VPCs, contact Yugabyte Support.
Before setting up the VPC network, you'll need the following:
The CIDR block you want to use for your VPC.
- Refer to Set the CIDR and size your VPC.
The details of the application VPC you want to peer with.
Choose the region for your VPC
To avoid cross-region data transfer costs, deploy your VPC and cluster in the same region as the application VPC you are peering with.
For GCP, you have the choice of selecting all regions automatically, or defining a custom set of regions. If you use automated region selection, the VPC is created globally and assigned to all regions supported by YugabyteDB Managed. If you use custom region selection, you can choose one or more regions, and specify unique CIDR ranges for each; you can also add regions at a later date.
For AWS, you can only define a single region per VPC.
Each region in multi-region clusters must be deployed in a VPC. Depending on the cloud provider, you set up your VPCs in different configurations.
|Provider||Regional VPC setup|
|AWS||You need to create a VPC in each region where the cluster is to be deployed.
To deploy a multi-region cluster into those regional VPCs, ensure that the CIDRs of the VPCs do not overlap.
If you intend to peer different VPCs to the same application VPC, ensure that the CIDRs of the VPCs do not overlap.
|GCP Custom region selection||When creating the VPC, you provide network blocks for each region where you intend to deploy the cluster; each region of the cluster is deployed in the same VPC.
If you plan to expand your cluster into new regions in the future, add those regions to the VPC when you create the VPC; you can not expand into new regions after the VPC is created.
|GCP Automated region selection||Create a single global VPC and let GCP assign network blocks to every region; each region of the cluster is deployed in the same VPC.
GCP does not recommend auto mode VPC networks for production; refer to Considerations for auto mode VPC networks.
Set the CIDR and size your VPC
The block of private IP addresses used to define your VPC is entered in CIDR notation; because you can't resize a VPC once it is created, you need to decide on an appropriate size before creating it. You also need to ensure that the range doesn't overlap the range of addresses used by other resources in the network, namely the application VPC you will peer and other VPCs.
Ideally, you want the network to be as small as possible while accommodating potential growth. Calculate how many applications will be connecting to it, and estimate how that is expected to grow over time. Although you may want to create a large network to cover all contingencies, an over-sized network can impact network performance. If your traffic experiences spikes, you'll need to take that into account.
When entering the range for your VPC in YugabyteDB Managed, the size of the network is determined by the prefix length (the number after the
/). YugabyteDB Managed supports network sizes from
/16. For typical applications,
/25 is sufficient.
The number of available addresses and sizing recommendation depends on the cloud provider where you are deploying.
In AWS, you assign the range to a single region. If you need multiple regions, you create a separate VPC for each region.
Use at least
/25 for production deployments, and
/24 if deploying multiple clusters in a single VPC.
/26 should only be used for testing and development.
When sizing the VPC, you need to take into account that the address range is split into subnets, each in a separate availability zone, and that AWS reserves 5 addresses per subnet. A further 8 addresses are required by AWS when creating the load balancer (though typically only one or two addresses are used while running). If you enable public access on your cluster, then two load balancers are created, one for VPC peered connections, and one for public connections.
For example, in a size
/26 VPC, each subnet is size
/28, which is 16 addresses per subnet; 5 addresses are reserved by AWS, and 8 addresses are required to create a load balancer, which leaves only 3 usable addresses. This limits you to 3 nodes per zone in a
/26 VPC with the regular load balancer, and only 2 nodes if you want to enable public access.
|IP Addresses||IP addresses per subnet||Available IP addresses per subnet|
For more information, refer to Subnets for your VPC in the AWS documentation.
For a custom GCP network, a size of
/26 per region is sufficient for typical applications.
For an automatic GCP network, a minimum size of
/18 is recommended to have enough addresses to distribute among all the regions.
|Type||Network Size (prefix length)||IP Addresses||Notes|
|In a GCP custom network, you customize the regions for the VPC and assign a range to each.|
|In a GCP auto network, the range is split across all supported regions.|
For information on GCP custom and auto VPCs, refer to Subnet creation mode in the GCP documentation.
Private IP address ranges
You can use the private IP addresses in the following ranges (per RFC 1918) for your VPCs:
- 10.0.0.0 - 10.255.255.255 (10/8 prefix)
- 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
- 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Peered application VPCs also use addresses in these ranges. Once peered, you also need to add the addresses of the peered VPCs to your cluster IP allow list. Private IP addresses added to the cluster allow list that are not part of a peered network are ignored, and can't be used to connect to the cluster.
You can calculate ranges beforehand using IP Address Guide's CIDR to IPv4 Conversion calculator.
Addresses have the following additional restrictions:
VPC addresses can overlap with other VPCs, but not in the following circumstances:
- You want to use the VPCs for the same multi-region cluster in AWS. For example, if you have two VPCs in different regions with overlapping addresses, you won't be able to use both for deploying a multi-region cluster.
- You want to peer the VPCs to the same application VPC. For example, if you have two different VPCs with overlapping addresses, you won't be able to peer them with the same application VPC.
YugabyteDB Managed warns you when you enter an overlapping range.
Addresses can't overlap with the CIDR of the application VPC you intend to peer with.
YugabyteDB Managed reserves the following ranges for internal operations.