Replicate across regions
Clusters replicated across regions include a minimum of 3 nodes across 3 regions, providing region-level fault tolerance. You can add or remove nodes in increments of 1 per region (each region has the same number of nodes).
Preferred region
You can optionally designate one region in the cluster as preferred. The preferred region handles all read and write requests from clients.
Designating one region as preferred can reduce the number of network hops needed to process requests. For lower latencies and best performance, set the region closest to your application as preferred. If your application uses a smart driver, set the topology keys to target the preferred region.
When no region is preferred, YugabyteDB Managed distributes requests equally across regions. You can set or change the preferred region after cluster creation.
Regardless of the preferred region setting, data is replicated across all the regions in the cluster to ensure region-level fault tolerance.
You can enable follower reads to serve reads from non-preferred regions.
In cases where the cluster has read replicas and a client connects to a read replica, reads are served from the replica; writes continue to be handled by the preferred region.
Features
Multi-region replicated clusters include the following features:
- Replicated synchronously across 3 to 7 regions.
- No limit on cluster size - choose any cluster size based on your use case.
- Horizontal and vertical scaling - add or remove nodes and vCPUs, and add storage to suit your production loads.
- VPC networking required.
- Automated and on-demand backups.
- Available in all regions.
- Enterprise support.
Prerequisites
- Multi-region clusters must be deployed in VPCs. Create a VPC for each region where you want to deploy the nodes in the cluster. Refer to VPC network overview.
- By default, clusters deployed in VPCs do not expose any publicly-accessible IP addresses. Unless you enable Public Access, you can only connect from resources inside the VPC network. Refer to VPC network overview.
- A billing profile and payment method. Refer to Manage your billing profile and payment method.
Create a multi-region replicated cluster
To create a multi-region replicated cluster, on the Clusters page, click Add Cluster, and choose Dedicated to start the Create Cluster wizard.
The Create Cluster wizard has the following pages:
General Settings
Set the following options:
- Cluster Name: Enter a name for the cluster.
- Provider: Choose a cloud provider.
- Database Version: Dedicated clusters are deployed using a stable release. If you have arranged a custom build with Yugabyte, it is also be listed here.
Cluster Setup
Select Multi-Region Deployment and set the following options.
Select data distribution mode
Set Data Distribution to Replicate across regions.
Select the Fault tolerance for the cluster, as follows:
- Resilient to 1 region outage; requires a minimum of 3 nodes across 3 regions.
- Resilient to 2 region outages; requires a minimum of 5 nodes across 5 regions.
- Resilient to 3 region outages; requires a minimum of 7 nodes across 7 regions.
Clusters can be scaled in increments of 1 node per region; for example, a cluster with fault tolerance of 2 regions can be scaled in multiples of 5 nodes, one per region.
Select regions and node size
Regions: For each region, choose the following:
- the region where the nodes will be located.
- the VPC in which to deploy the nodes. Only VPCs using the selected cloud provider and available in the selected region are listed. For AWS clusters, choose a separate VPC for each region. For GCP clusters, the same VPC is used for all regions. VPCs must be created before deploying the cluster. Refer to VPC networking.
- The number of nodes to deploy in the regions. Each region has the same number of nodes.
Preferred region: Optionally, assign one region as preferred to handle all reads and writes.
Node size: Enter the number of virtual CPUs per node, disk size per node (in GB), and disk input output (I/O) operations per second (IOPS) per node (AWS only). You must choose the regions before you can set the node size.
The node throughput will be scaled according to the IOPS value. For large datasets or clusters with high concurrent transactions, higher IOPS is recommended. As disk IOPS is capped by vCPU, your vCPU and IOPS should be scaled together. Reference your current read and write IOPS performance for an estimation.
Clusters replicated across regions support both horizontal and vertical scaling; you can change the cluster configuration and preferred region after the cluster is created. Refer to Scale and configure clusters.
Monthly total costs for the cluster are based on the number of vCPUs and estimated automatically. + Usage refers to any potential overages from exceeding the free allowances for disk storage, backup storage, and data transfer. For information on how clusters are costed, refer to Cluster costs.
Network Access
Trusted IP Addresses
YugabyteDB Managed only allows access to clusters from trusted IP addresses. For applications in peered VPCs to be able to connect, you need to add the CIDR of the peered VPC to the cluster IP allow list. You can also assign IP allow lists to your cluster any time after the cluster is created.
You can add IP addresses using any combination of the following options.
Option | Description |
---|---|
Add Current IP Address | Creates an allow list using the public IP address of your computer and adds it to the cluster IP allow list. |
Add Peered VPC Networks | Only available for clusters being deployed in a VPC. VPCs must be peered, and the peering connection active for the peered networks to be added to the IP allow list. Choose Add All Peered Networks to create an IP allow list from every network peered with the cluster VPC, and add it to the cluster. Choose Add Individual Peered Networks to select specific peered networks to add to the cluster IP allow list. |
Add Existing IP Allow List | Choose from a list of IP allow lists already created for your account. |
Create New IP Allow List | Create a new IP allow list and manually enter the CIDR and public IP addresses. |
Enable Public Access for this Cluster - To connect to a cluster deployed in a VPC from a public IP address (including your current address), you must enable Public Access for the cluster. When enabled, a public IP address is added to each region of the cluster. You can view the private and public host addresses under Connection Parameters on the cluster Settings > Infrastructure tab.
Private Service Endpoint
For clusters in AWS and Azure, you can connect your cluster to your application VPC using a private link. To do this, you add a private service endpoint (PSE) to each region in your cluster.
You can also add PSEs after your cluster is created.
To use a private link for network isolation and security, choose Create Private Service Endpoint, then add security principals. A security principal is a cloud provider account with permissions to manage endpoints. In AWS, this would be Amazon resource names, and in Azure, Subscription IDs.
After the cluster is created, you still need to complete the private link setup by adding an endpoint on your application VPC for each region in your cluster, and linking them to the PSEs on your cluster.
For more information, refer to Private service endpoints.
Security
In addition to the volume encryption that YugabyteDB Managed uses to encrypt your data, you can enable YugabyteDB encryption at rest (EAR) for clusters. When enabled, your YugabyteDB cluster (including backups) is encrypted using a customer managed key (CMK) residing in a cloud provider Key Management Service (KMS).
To use a CMK to encrypt your cluster, make sure you have configured the CMK in AWS KMS, Azure Key Vault, or Google Cloud KMS. Refer to Prerequisites.
To use a CMK, select the Enable cluster encryption at rest option and set the following options:
-
KMS provider: AWS, Azure, or GCP.
-
For AWS:
- Customer managed key (CMK): Enter the Amazon Resource Name (ARN) of the CMK to use to encrypt the cluster.
- Access key: Provide an access key of an IAM identity with permissions for the CMK. An access key consists of an access key ID and the secret access key.
-
For Azure:
- The Azure tenant ID, the vault URI (for example,
https://myvault.vault.azure.net
), and the name of the key. - The client ID and secret for an application with permission to encrypt and decrypt using the CMK.
- The Azure tenant ID, the vault URI (for example,
-
For GCP:
- Resource ID: Enter the resource ID of the key ring where the CMK is stored.
- Service Account Credentials: Click Add Key to select the credentials JSON file you downloaded when creating credentials for the service account that has permissions to encrypt and decrypt using the CMK.
Database Credentials
The database admin credentials are required to connect to the YugabyteDB database that is installed on the cluster.
You can use the default credentials generated by YugabyteDB Managed, or add your own.
For security reasons, the database admin user does not have YSQL superuser privileges, but does have sufficient privileges for most tasks. For more information on database roles and privileges in YugabyteDB Managed, refer to Database authorization in YugabyteDB Managed clusters.
After the cluster is provisioned, you can add more users and change your password.
Download the credentials, and click Create Cluster.
Important
Save your database credentials. If you lose them, you won't be able to use the database.After you complete the wizard, the Clusters page appears, showing the provisioning of your new cluster in progress.
When the cluster is ready, the cluster Overview tab is displayed.
You now have a fully configured YugabyteDB cluster provisioned in YugabyteDB Managed with the database admin credentials you specified.