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. VPC networks provide more secure connections between resources because the network is inaccessible from the public internet and other VPC networks.

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 (unless you explicitly enable public access). Resources that can be included in the network fall into two categories:

• Peered application VPCs.
  • Your applications reside in one or more VPCs on the same cloud provider, and are connected to your cluster VPC using peering connections.
  • AWS and GCP only.
  • Required for smart load balancing features of YugabyteDB smart drivers.
  • You need to add the IP address of your peered application VPC to the cluster IP allow list.
• Privately linked services.
  • Your applications reside in one or more VPCs on the same cloud provider, and are connected to your cluster over a private link to a private service endpoint.
  • AWS and Azure only.
  • Smart load balancing features aren't supported. Smart driver falls back to upstream driver connection instead.
  • No need to add the IP address of your application to the cluster IP allow list.

Advantages

Deploying your cluster in a VPC 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.)

Pricing

There's no additional charge for using a VPC, peering, or private service endpoints. In most cases, using a VPC network will reduce your data transfer costs. VPCs are not supported for Sandbox clusters.

Note that using a private service endpoint with AWS PrivateLink or Azure Private Link does incur charges from the cloud provider in your own account. See AWS PrivateLink pricing or Azure Private Link pricing.

Limitations

• 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 create a maximum of 3 AWS VPCs per region.
• You can create a maximum of 3 Azure 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.

Prerequisites

When creating a VPC, you need to determine the following:

• The region for the VPC.
• The size of the VPC.

Choose the region for your VPC

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.

To avoid cross-region data transfer costs, deploy your VPC and cluster in the same region as the application VPC you intend peer or link.

Multi-region clusters

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.

Set the CIDR and size your VPC

The block of private IP addresses used to define your VPC is entered in CIDR notation.

In Azure, the CIDR range is selected for you when you create the VPC.

In AWS and GCP, 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, such as any application VPC you will peer, or other VPCs you have created.

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 /26 to /16. For typical applications, /25 is sufficient.

The number of available addresses and sizing recommendation depends on the cloud provider where you are deploying.

• AWS
• GCP

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)

Note that 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.

Restrictions

If you are using VPC peering, 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.

Next steps

• Peering connections
• Private service endpoints