docs/content/stable/yugabyte-cloud/cloud-basics/cloud-vpcs/cloud-vpc-intro.md
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:
| Provider | Secure private network | Add IPs to allow list | Smart driver load balancing | |
|---|---|---|---|---|
| Peering | AWS, GCP | Yes | Yes | Yes |
| Private link | AWS, Azure | Yes | No | No |
Deploying your cluster in a VPC has the following advantages:
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.
If you need additional VPCs, contact {{% support-cloud %}}.
When creating a VPC, you need to determine the following:
For AWS and Azure, you define a single region per 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 Aeon. 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.
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.
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. See Restrictions. | |
| Azure | You need to create a VPC in each region where the cluster is to be deployed. |
| Azure assigns the CIDR automatically. | |
| 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. |
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 Aeon, the size of the network is determined by the prefix length (the number after the /). YugabyteDB Aeon 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.
{{< tabpane text=true >}}
{{% tab header="AWS" lang="aws" %}}
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.
| Network Size
| (prefix length) | IP Addresses | IP addresses per subnet | Available IP addresses per subnet |
|---|---|---|---|
| /26 | |||
| /25 | |||
| /24 | 64 | ||
| 128 | |||
| 256 | 16 | ||
| 32 | |||
| 64 | 2-3 | ||
| 18-19 | |||
| 50-51 |
For more information, refer to Subnets for your VPC in the AWS documentation.
{{% /tab %}}
{{% tab header="GCP" lang="gcp" %}}
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 | | :--- | :--- | :--- | :--- | :--- | | GCP custom | /24 /25 /26 | 256 128 64 | In a GCP custom network, you customize the regions for the VPC and assign a range to each. | | GCP auto| /16 /17 /18 | 65536 32768 16384 | 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.
{{% /tab %}}
{{< /tabpane >}}
You can use the private IP addresses in the following ranges (per RFC 1918) for your VPCs:
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.
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:
YugabyteDB Aeon 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 Aeon reserves the following ranges for internal operations.
| Provider | Range |
|---|---|
| AWS | 10.3.0.0/16 |
| 10.4.0.0/16 | |
| GCP | 10.21.0.0/16 |