Configure the AWS cloud provider

You can configure Amazon Web Services (AWS) for YugabyteDB using YugabyteDB Anywhere. If no cloud providers have been configured yet, the main Dashboard page prompts you to configure at least one cloud provider.

Prerequisites

To run YugabyteDB nodes on AWS, you need to supply your cloud provider credentials on the YugabyteDB Anywhere UI. YugabyteDB Anywhere uses the credentials to automatically provision and deprovision YugabyteDB instances. A YugabyteDB instance includes a compute instance, as well as attached local or remote disk storage.

Configure AWS

You configure AWS by completing the fields of the page shown in the following illustration:

AWS Empty Provider

Provider name

Provider name is an internal tag used for organizing cloud providers.

Credentials

In order to deploy YugabyteDB nodes in your AWS account, YugabyteDB Anywhere requires access to a set of cloud credentials which can be provided in one of the following ways:

SSH key pairs

In order to be able to provision Amazon Elastic Compute Cloud (EC2) instances with YugabyteDB, YugabyteDB Anywhere requires SSH access. The following are two ways to provide SSH access:

  • Enable YugabyteDB Anywhere to create and manage Key Pairs. In this mode, YugabyteDB Anywhere creates SSH Key Pairs across all the regions you choose to set up and stores the relevant private key part of these locally in order to SSH into future EC2 instances.
  • Use your own existing Key Pairs. To do this, provide the name of the Key Pair, as well as the private key content and the corresponding SSH user. This information must be the same across all the regions you provision.

If you use YugabyteDB Anywhere to manage SSH Key Pairs for you and you deploy multiple YugabyteDB Anywhere instances across your environment, then the AWS provider name should be unique for each instance of YugabyteDB Anywhere integrating with a given AWS account.

Hosted zones

Integrating with hosted zones can make YugabyteDB universes easily discoverable. YugabyteDB Anywhere can integrate with Amazon Route53 to provide managed Canonical Name (CNAME) entries for your YugabyteDB universes, which will be updated as you change the set of nodes to include all relevant ones for each of your universes.

VPC setup

You can customize your network, including the virtual network, as follows:

  • Select an existing Virtual Private Cloud (VPC).
  • Create a new VPC. Note that this option is considered beta and is not recommended for production use cases, as creating a new VPC can silently fail if there are any classless inter-domain routing (CIDR) conflicts. For example, the following will result in a silent failure:
    • Configure more than one AWS cloud provider with different CIDR block prefixes and selecting the Create a new VPC option.
    • Creating a new VPC with an CIDR block that overlaps with any of the existing subnets.

NTP setup

You can customize the Network Time Protocol server, as follows:

  • Select Use provider’s NTP server to enable cluster nodes to connect to the AWS internal time servers. For more information, consult the AWS documentation such as Keeping time with Amazon time sync service.
  • Select Manually add NTP Servers to provide your own NTP servers and allow the cluster nodes to connect to those NTP servers.
  • Select Don't set up NTP to prevent YugabyteDB Anywhere from performing any NTP configuration on the cluster nodes. For data consistency, ensure that NTP is correctly configured on your machine image.

Global deployment

For deployment, YugabyteDB Anywhere aims to provide you with easy access to the many regions that AWS makes available globally. To that end, YugabyteDB Anywhere allows you to select which regions to which you wish to deploy and supports two different ways of configuring your setup, based on your environment: YugabyteDB Anywhere-managed configuration and self-managed configuration.

YugabyteDB Anywhere-managed configuration

If you use YugabyteDB Anywhere to configure, own, and manage a full cross-region deployment of Virtual Private Cloud (VPC), YugabyteDB Anywhere generates a YugabyteDB-specific VPC in each selected region, then interconnects them, as well as the VPC in which YugabyteDB Anywhere is deployed, using VPC peering. This mode also sets up all other relevant sub-components in all regions, such as subnets, security groups, and routing table entries.

You have an option to provide the following:

  • A custom CIDR block for each regional VPC. If not provided, YugabyteDB Anywhere chooses defaults, aiming to not overlap across regions.

  • A custom Amazon Machine Image (AMI) ID to use in each region.

    YugabyteDB Anywhere supports both x86 and ARM (aarch64) CPU architectures. See Supported operating systems and architectures for a complete list of supported operating systems. If you plan to deploy YugabyteDB on AWS Graviton-based EC2 instances, use a custom AMI certified for 64-bit ARM (arm64) architecture.

    If you don't provide an AMI ID, a recent x86 CentOS image is used. For additional information, see CentOS on AWS.

New Region Modal

To use automatic provisioning to bring up a universe on AWS Graviton, you need to pass in the Arch AMI ID of AlmaLinux or Ubuntu. Note that this requires a YugabyteDB release for Linux ARM, which is available through one of the release pages (for example, the current preview release). YugabyteDB Anywhere enables you to import releases via S3 or HTTP, as described in Upgrade the YugabyteDB software.

Self-managed configuration

You can use your own custom VPCs. This allows you the highest level of customization for your VPC setup. You can provide the following:

  • A VPC ID to use for each region.
  • A Security Group ID to use for each region. This is attached to all YugabyteDB nodes and must allow traffic from all other YugabyteDB nodes, even across regions, if you deploy across multiple regions.
  • A mapping of what Subnet IDs to use for each Availability Zone in which you wish to be able to deploy. This is required to ensure that YugabyteDB Anywhere can deploy nodes in the correct network isolation that you desire in your environment.
  • A custom AMI ID to use in each region. For a non-exhaustive list of options, see Ubuntu 18 and Oracle Linux 8 support. If you do not provide any values, a recent AWS Marketplace CentOS AMI is used.

Custom Region Modal

If you choose to provide your own VPC information, you will be responsible for having preconfigured networking connectivity. For single-region deployments, this might just be a matter of region or VPC local Security Groups. Across regions, however, the setup can get quite complex. It is recommended that you use the VPC peering feature of Amazon Virtual Private Cloud (Amazon VPC) to set up private IP connectivity between nodes located across regions, as follows:

  • VPC peering connections must be established in an N x N matrix, such that every VPC in every region you configure must be peered to every other VPC in every other region.
  • Routing table entries in every regional VPC should route traffic to every other VPC CIDR block across the PeeringConnection to that respective VPC. This must match the Subnets that you provided during the configuration step.
  • Security groups in each VPC can be hardened by only opening up the relevant ports to the CIDR blocks of the VPCs from which you are expecting traffic.
  • If you deploy YugabyteDB Anywhere in a different VPC than the ones in which you intend to deploy YugabyteDB nodes, then its own VPC must also be part of this cross-region VPC mesh, as well as setting up routing table entries in the source VPC (YugabyteDB Anywhere) and allowing one further CIDR block (or public IP) ingress rule on the security groups for the YugabyteDB nodes (to allow traffic from YugabyteDB Anywhere or its VPC).
  • When a public IP address is not enabled on a universe, a network address translation (NAT) gateway or device is required. You must configure the NAT gateway before creating the VPC that you add to the YugabyteDB Anywhere UI. For more information, see NAT and Creating a VPC with public and private subnets in the AWS documentation.

Limitations

If you create more than one AWS cloud provider with different CIDR block prefixes, your attempt to create a new VPC as part of your VPC setup will result in a silent failure.

Marketplace acceptance

If you did not provide your own custom AMI IDs, before you can proceed to creating a universe, verify that you can actually spin up EC2 instances with the default AMIs in YugabyteDB Anywhere.

While logged into your AWS account, navigate to the AWS site AlmaLinux OS 8 (x86_64) product and click Continue to Subscribe.

If you are not already subscribed and have not accepted the Terms and Conditions, then you should see the following message:

Marketplace accept

If that is the case, click Accept Terms and wait for the page to switch to a successful state. After the operation completes, or if you previously subscribed and accepted the terms, you should see the following:

Marketplace success

Now you are ready to create a YugabyteDB universe on AWS.