Cloud Provider Requirements
When using your own cloud account, Couchbase Capella requires permissions and resource capacity for your cloud provider account to connect to your cloud, and for ongoing operations, for example, deploying clusters.
|
This information is for anyone still using Couchbase Server 6.6, hosted in their own cloud provider’s VPC. It does not apply to Couchbase 7.0, hosted in Couchbase’s VPC and fully managed for you. For further information contact Couchbase. The easiest way to get started with Capella, our fully managed DBaaS, is hosting in Couchbase’s Cloud. |
Amazon Web Services (AWS)
Couchbase Capella supports deploying clusters on Amazon Web Services (AWS) using your own AWS account.
Supported AWS Regions
| The following tables only show AWS region support for deploying clusters using your own AWS account. Capella’s fully-managed DBaaS option supports a different set of AWS regions which are found on the Amazon Web Services (AWS) reference page. |
All of the following AWS regions are supported by Couchbase Capella when deploying clusters using your own AWS account.
| AWS Region | Location |
|---|---|
|
US East (N. Virginia) |
|
US East (Ohio) |
|
US West (Oregon) |
|
Canada (Central) |
| AWS Region | Location |
|---|---|
|
EU (Frankfurt) |
|
EU (Ireland) |
|
EU (London) |
|
EU (Paris) |
|
EU (Stockholm) |
| AWS Region | Location |
|---|---|
|
Asia Pacific (Singapore) |
|
Asia Pacific (Sydney) |
|
Asia Pacific (Tokyo) |
|
Asia Pacific (Seoul) |
|
Asia Pacific (Mumbai) |
Required AWS Permissions
When using Capella with your own AWS account, the following AWS permissions are required for Capella and your AWS account each time you perform any of the following:
-
Establish a connection to your cloud account.
-
Manage the cloud connection.
-
Create, deploy, operate, and remove clusters when the connection is active.
Verify your AWS account has the required permissions before you connect clouds and deploy clusters.
-
To ensure security is maintained, the following permissions are required for Couchbase users to regularly rotate the access keys, and are locked to the user that is created by the CloudFormation stack:
iam:DeleteAccessKey iam:ListAccessKeys iam:DeleteUser
-
The following permissions are required to create a user with access keys and a group, and are used by Capella to manage IaaS in the cloud account, for example, managing the lifecycle of a cluster:
iam:AddUserToGroup iam:CreateUser
-
The following permissions are required to create the networking infrastructure in a VPC, and are locked to the VPC:
ec2:AuthorizeSecurityGroupEgress ec2:AuthorizeSecurityGroupIngress ec2:CreateRoute ec2:DeleteRouteTable ec2:DeleteSecurityGroup ec2:RevokeSecurityGroupEgress ec2:RevokeSecurityGroupIngress ec2:UpdateSecurityGroupRuleDescriptionsEgress ec2:UpdateSecurityGroupRuleDescriptionsIngress ec2:RunInstances
-
The following permissions are locked to the CloudFormation stack:
cloudformation:DeleteStack cloudformation:DescribeStackEvents cloudformation:DescribeStackResources cloudformation:DetectStackDrift cloudformation:DetectStackResourceDrift cloudformation:GetTemplate cloudformation:ListStackResources cloudformation:UpdateStack
-
The following permissions are required to store the Terraform state for all the cloud and cluster deployments. They are also used to store backups, and are locked to the main S3 bucket:
s3:AbortMultipartUpload s3:DeleteObject s3:DeleteObjectTagging s3:DeleteObjectVersion s3:DeleteObjectVersionTagging s3:GetObject s3:GetObjectAcl s3:GetObjectLegalHold s3:GetObjectRetention s3:GetObjectTagging s3:GetObjectVersion s3:GetObjectVersionAcl s3:GetObjectVersionTagging s3:ListMultipartUploadParts s3:PutObject s3:PutObjectAcl s3:PutObjectLegalHold s3:PutObjectRetention s3:PutObjectTagging s3:PutObjectVersionAcl s3:PutObjectVersionTagging s3:RestoreObject s3:DescribeJob s3:UpdateJobPriority s3:UpdateJobStatus
-
The following permissions are required to store logs and support-related information about a connected cloud and cluster. These permissions are locked to the support bucket:
s3:AbortMultipartUpload s3:DeleteObject s3:DeleteObjectTagging s3:DeleteObjectVersion s3:DeleteObjectVersionTagging s3:GetObject s3:GetObjectAcl s3:GetObjectLegalHold s3:GetObjectRetention s3:GetObjectTagging s3:GetObjectVersion s3:GetObjectVersionAcl s3:GetObjectVersionTagging s3:ListMultipartUploadParts s3:ListBucket s3:ListBucketVersions s3:PutObject s3:PutObjectAcl s3:PutObjectLegalHold s3:PutObjectRetention s3:PutObjectTagging s3:PutObjectVersionAcl s3:PutObjectVersionTagging s3:RestoreObject s3:DescribeJob s3:UpdateJobPriority s3:UpdateJobStatus
-
The following permissions are required to remove a user only from the Capella IAM group created via CloudFormation:
iam:RemoveUserFromGroup iam:DeleteGroup iam:DeleteGroupPolicy
-
The following permissions are required to create Auto Scaling groups which contain the worker nodes for the EKS cluster:
autoscaling:AttachInstances autoscaling:CreateAutoScalingGroup autoscaling:CreateLaunchConfiguration autoscaling:CreateOrUpdateTags autoscaling:DeleteAutoScalingGroup autoscaling:DeleteLaunchConfiguration autoscaling:DeleteTags autoscaling:Describe* autoscaling:DetachInstances autoscaling:SetDesiredCapacity autoscaling:UpdateAutoScalingGroup autoscaling:SuspendProcesses autoscaling:DescribeLaunchConfigurations
-
The following permissions are required to create the networking infrastructure in a VPC (Routing Tables, Subnets, Internet Gateway, NAT Gateway) and the EC2 instances under the Auto Scaling group:
ec2:DescribeVpcs ec2:DescribeSubnets ec2:DescribeNetworkInterfaces ec2:DescribeAvailabilityZones ec2:AllocateAddress ec2:AssignPrivateIpAddresses ec2:Associate* ec2:AttachInternetGateway ec2:AttachNetworkInterface ec2:CreateDefaultSubnet ec2:CreateDhcpOptions ec2:CreateEgressOnlyInternetGateway ec2:CreateInternetGateway ec2:CreateNatGateway ec2:CreateNetworkInterface ec2:CreateRouteTable ec2:CreateSecurityGroup ec2:CreateSubnet ec2:CreateTags ec2:CreateVolume ec2:CreateVpc ec2:DeleteDhcpOptions ec2:DeleteEgressOnlyInternetGateway ec2:DeleteInternetGateway ec2:DeleteNatGateway ec2:DeleteNetworkInterface ec2:DeleteRoute ec2:DeleteSubnet ec2:DeleteTags ec2:DeleteVolume ec2:DeleteVpnGateway ec2:Describe* ec2:DetachInternetGateway ec2:DetachNetworkInterface ec2:DetachVolume ec2:Disassociate* ec2:ModifySubnetAttribute ec2:ModifyVpcAttribute ec2:ModifyVpcEndpoint ec2:ReleaseAddress ec2:UpdateSecurityGroupRuleDescriptionsEgress ec2:UpdateSecurityGroupRuleDescriptionsIngress ec2:CreateLaunchTemplate ec2:CreateLaunchTemplateVersion ec2:DeleteLaunchTemplate ec2:DeleteLaunchTemplateVersions ec2:DescribeLaunchTemplates ec2:DescribeLaunchTemplateVersions ec2:GetLaunchTemplateData ec2:ModifyLaunchTemplate
-
The following permissions are required to create the EKS clusters under the VPC and appropriately tag the resource:
eks:CreateCluster eks:DeleteCluster eks:DescribeCluster eks:UpdateClusterVersion eks:ListClusters eks:TagResource eks:UpdateClusterConfig eks:DescribeUpdate
-
The following permissions are required to attach roles to all the EC2 instances so they have access to other AWS resources:
iam:AddRoleToInstanceProfile iam:AttachRolePolicy iam:CreateInstanceProfile iam:CreatePolicy iam:CreatePolicyVersion iam:DeletePolicyVersion iam:CreateRole iam:CreateServiceLinkedRole iam:GetServiceLinkedRoleDeletionStatus iam:DeleteInstanceProfile iam:DeletePolicy iam:DeleteRole iam:DeleteRolePolicy iam:DeleteServiceLinkedRole iam:DetachRolePolicy iam:GetInstanceProfile iam:GetPolicy iam:GetPolicyVersion iam:GetRole iam:GetRolePolicy iam:List* iam:PassRole iam:PutRolePolicy iam:RemoveRoleFromInstanceProfile iam:UpdateAssumeRolePolicy iam:TagRole iam:UntagRole iam:ListInstanceProfilesForRole iam:ListAttachedRolePolicies
-
The following permissions are required to encrypt each cluster with its own KMS key:
kms:GetPublicKey kms:Decrypt kms:UpdateKeyDescription kms:GetKeyPolicy kms:GenerateDataKeyWithoutPlaintext kms:Verify kms:ListResourceTags kms:ReEncryptFrom kms:GetParametersForImport kms:DescribeCustomKeyStores kms:ListKeys kms:GetKeyRotationStatus kms:Encrypt kms:ScheduleKeyDeletion kms:ListAliases kms:ReEncryptTo kms:DescribeKey kms:CreateKey kms:UntagResource kms:TagResource kms:GetPublicKey kms:Decrypt kms:UpdateKeyDescription kms:GetKeyPolicy kms:GenerateDataKeyWithoutPlaintext kms:Verify kms:ListResourceTags kms:ReEncryptFrom kms:GetParametersForImport kms:DescribeCustomKeyStores kms:ListKeys kms:GetKeyRotationStatus kms:Encrypt kms:ScheduleKeyDeletion kms:ListAliases kms:ReEncryptTo kms:DescribeKey kms:CreateKey kms:UntagResource kms:TagResource
-
The following permissions are required so that Terraform can save the state of connected clouds and deployed clusters:
s3:ListAllMyBuckets
Required AWS Quotas
This section describes the AWS quotas and limits that can affect the proper functioning of Couchbase Capella in your AWS account. You should verify that the current quotas set for your account can accommodate your expected usage of Capella, and make any necessary increases to those quotas before connecting clouds and deploying clusters.
VPCs per Region
It is recommended that you increase your AWS account’s quota for VPCs per Region (the default quota is five).
Each connected cloud creates one VPC in a given Region. This means that if you keep the default quota, then the maximum number of connected clouds you can have in each Region is four. (This is assuming that you aren’t running any other VPCs in the Region and have not deleted the default VPC.)
If you try to connect a new cloud in a Region that has already reached its VPC quota, then the connection will fail. (Note that existing, successfully connected clouds will not be affected if you reach the VPC quota in a Region.)
To increase your AWS account’s quota for VPCs per Region, you will need to open a support case with AWS to request a service limit increase. Ensure that you request a quota that can accommodate the maximum number of connected clouds (as well as any other VPCs) that you plan to have in a given Region of the same AWS account.
VPC Elastic IP Addresses per Region
It is recommended that you increase your AWS account’s quota for VPC Elastic IP addresses per Region (the default quota is five).
Capella requires three Elastic IP addresses (EIPs) per connected cloud. This means that if you keep the default quota, you may encounter errors when connecting more than one cloud per Region. (This is assuming that you are not running any other VPCs that are consuming more of the EIP quota.)
To increase your AWS account’s quota for VPC EIPs per Region, you will need to open a support case with AWS to request a service limit increase. Ensure that you request a quota that can accommodate the maximum number of connected clouds (as well as any other VPCs) that you plan to have in a given Region of the same AWS account. Since three VPC EIPs are required per connected cloud, a convenient way to calculate this quota is to take your VPCs per Region quota, and multiply it by three. So if your VPCs per Region quota is 20, then you should request that your VPC EIPs per Region be increased to 60.
Classic Load Balancers per Region
It is recommended that you increase your AWS account’s quota for Classic Load Balancers per Region (the default quota is 20).
Capella requires n+1 Classic Load Balancers per cluster, where n is the number of nodes in the cluster. This means that if you keep the default quota, the maximum number of clusters you can have in a single Region, across all connected clouds, is ten 1-node development clusters, or five 3-node production clusters.
To increase your AWS account’s quota for Classic Load Balancers per Region, you will need to request a service quota increase. Ensure that you request a quota that can accommodate the maximum number of clusters and nodes that you plan to have in a given Region of the same AWS account. It’s recommended that you err on the side of having a higher quota than you think you might need in case you encounter unforeseen events that require you to rapidly scale out clusters and/or deploy your own resources that require Classic Load Balancers.
Additional AWS Requirements
AWS Security Token Service (STS) must be active for the Region you select. If STS is not active, the CloudFormation stack will still deploy, but Capella will fail to connect to it.
Microsoft Azure
Couchbase Capella supports deploying clusters on Microsoft Azure when using your own Azure account.
Supported Azure Regions
The following Azure regions are supported by Couchbase Capella when deploying clusters using your own Azure account. Clusters hosted with Couchbase’s cloud account cannot use Azure at this time.
| Azure Region | Location |
|---|---|
|
Iowa, USA |
|
Virginia (East US) |
|
Virginia, USA |
|
Washington State, USA |
| Azure Region | Location |
|---|---|
|
Paris, France |
|
Ireland |
|
London, England, UK |
|
Netherlands |
|
Frankfurt, Germany |
| Azure Region | Location |
|---|---|
|
Tokyo, Japan |
|
Singapore |
Required Azure Permissions
Microsoft Azure uses role-based access controls with built-in role assignments to manage your cloud account and connection. Roles control which users can access and manage Azure resources. Roles also control which Azure resources are accessed.
The following table describes the users and role-based access controls that are required for a customer’s Azure tenant account and Couchbase Capella:
| User | Purpose | Built-in Role | Scope | Microsoft Azure Help |
|---|---|---|---|---|
Couchbase Cloud Service Principal |
Manage Couchbase in Customer Tenant |
Contributor |
Resource Group |
|
Couchbase Cloud Managed Identity |
Backup and Restore Storage Blob Authentication |
Storage Blob Data Contributor |
Resource Group |
For an overview about required permissions for assigning users to Azure role-based access controls, and role assignments to access Azure resources, see Role-Based Access Control Overview in the Microsoft Azure Help. To assign users, see Assigning an Azure Role.