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.
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.
You configure AWS by completing the fields of the page shown in the following illustration:
Provider name is an internal tag used for organizing cloud providers.
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:
- Directly provide your AWS Access Key ID and Secret Key.
- Attach an IAM role to the YugabyteDB Anywhere VM in the EC2 tab. For more information, see Deploy the YugabyteDB universe using an IAM role.
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. Currently, this information must be the same across all the regions you choose to 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.
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.
You can customize your network, including the virtual network. YugabyteDB Anywhere allows you to create a new or select an existing VPC.
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. Note that Use AWS Time Sync must be disabled during the universe creation; otherwise Don’t set up NTP will be overridden.
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 choose to use YugabyteDB Anywhere to configure, own, and manage a full cross-region deployment of Virtual Private Cloud (VPC), YugabyteDB Anywhere will generate a YugabyteDB-specific VPC in each selected region, then interconnect them, as well as the VPC in which YugabyteDB Anywhere was deployed, using VPC Peering. This mode also sets up all other relevant subcomponents in all regions, such as Subnets, Security Groups, and Routing Table entries.
You have an option to provide the following:
A custom classless inter-domain routing (CIDR) block for each regional VPC. If not provided, YugabyteDB Anywhere will choose defaults, aiming to not overlap across regions.
A custom Amazon Machine Image (AMI) ID to use in each region. For a non-exhaustive list of options, see Ubuntu 18 and Oracle 8 support. If you do not provide any values, a recent AWS Marketplace CentOS AMI is used.
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 8 support. If you do not provide any values, a recent AWS Marketplace CentOS AMI is used.
If you choose to provide your own VPC information, you will be responsible for having preconfigured networking connectivity. For single-region deployments, this might simply 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 Tutorial: Creating a VPC with Public and Private Subnets for Your Clusters in the AWS documentation.
Ubuntu 18 and Oracle 8 support
In addition to CentOS, YugabyteDB Anywhere allows you to bring up universes on the following host nodes:
- Ubuntu 18.04, which requires Python 2 or later installed on the host, as well as the provider created with a custom AMI and custom SSH user.
- Oracle 8, which requires the provider created with a custom AMI and custom SSH user, assumes that gtar or gunzip is present on the host AMI, and uses the firewall-cmd client to set default target
ACCEPT. YugabyteDB Anywhere support for Oracle 8 has the following limitations:
- Only Red Hat Linux-compatible kernel is supported to allow port changing. There is no support for Unbreakable Enterprise Kernel (UEK).
- Systemd services are not supported.
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 Marketplace CentOS 7 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:
If that is the case, click Accept Terms and wait for the page to switch to a successful state. Once the operation completes, or if you previously subscribed and accepted the terms, you should see the following:
Now, you are ready to create a YugabyteDB universe on AWS.