Amazon Relational Database Service Requirements and Considerations

Before you protect your Amazon services using Cohesity DataProtect as a Service, ensure you have met the prerequisites and reviewed the considerations.

For information on the supported cloud regions where you can back up this source, see Supported Workloads and Cloud Regions.

Check Firewall Ports

Ensure that the ports listed in the Amazon Web Services (AWS) section in the Firewall Ports topic are open to allow communication between the Cohesity SaaS Connector(s) and AWS environment.

Account Requirements

To register your AWS account, run the CloudFormation Template (CFT) and add permissions to the IAM user.

The tables below list the permissions used by Cohesity in your AWS account. You do not need to add these permissions manually (except the IAM User Permissions to Execute CFT), as they are automatically added when you run the CFT provided by Cohesity during your AWS account registration with the Cohesity DataProtect as a Service and SiteContinuity services.

IAM User Permissions to Execute CFT

To register an AWS account with the Cohesity DataProtect as a Service, you need to run the CloudFormation Template on the AWS console. Ensure the IAM user you use has the following permissions to run the CloudFormation Template and to create and view the stack:

Ensure to add these permissions manually.

  • cloudformation:CreateChangeSet

  • cloudformation:CreateStack

  • cloudformation:CreateUploadBucket

  • cloudformation:DeleteStack

  • cloudformation:DescribeStackEvents

  • cloudformation:DescribeStackResources

  • cloudformation:DescribeStacks

  • cloudformation:GetTemplate

  • cloudformation:GetTemplateSummary

  • cloudformation:ListStackResources

  • cloudformation:ListStacks

  • cloudformation:UpdateStack

  • iam:AddRoleToInstanceProfile

  • iam:AttachRolePolicy

  • iam:CreateInstanceProfile

  • iam:CreateRole

  • iam:DeleteInstanceProfile

  • iam:DeleteRole

  • iam:DeleteRolePolicy

  • iam:DetachRolePolicy

  • iam:GetInstanceProfile

  • iam:GetRole

  • iam:GetRolePolicy

  • iam:PassRole

  • iam:PutRolePolicy

  • iam:RemoveRoleFromInstanceProfile

  • iam:TagRole

  • lambda:AddPermission

  • lambda:CreateFunction

  • lambda:DeleteFunction

  • lambda:InvokeFunction

  • lambda:RemovePermission

  • s3:CreateBucket

  • s3:GetObject

  • s3:ListBucket

  • s3:PutObject

  • s3: PutBucketPublicAccessBlock

Permissions for Amazon Relational Database Service (RDS) Data Protection

You do not need to add these permissions manually, as they are automatically added when you run the CFT.

Resource

Permissions

 Reason

ec2

ec2:DescribeAvailabilityZones

ec2:DescribeInstances

ec2:DescribeKeyPairs

ec2:DescribeRegions

ec2:DescribeReservedInstancesOfferings

ec2:DescribeSecurityGroups

ec2:DescribeSubnets

ec2:DescribeVolumes

ec2:DescribeVpcs

 Required for AWS source registration, and discover the resources present in the account, which will be used for backups. Also needed for recovery to provide list of options to choose from.

ec2:CreateVolume

ec2:CreateTags

ec2:DescribeTag

ec2:DescribeVolumeAttribut

ec2:DescribeVolumes

ec2:DescribeInstances

ec2:AttachVolume

ec2:DeleteVolume

ec2:DetachVolume

ec2:ModifyVolume

 Required for attaching and detaching volumes of Amazon RDS database to SaaS Connectors during the Amazon RDS ingest backup.

iam

iam:SimulatePrincipalPolicy

 SimulatePricipalPolicy is needed to ensure that the required actions are allowed on the IAM role we created as part of the Cloud Formation template.

kms*

kms:CreateGrant

kms:DescribeKey

kms:ListAliases

 KMS permissions are needed to read data of an encrypted database at the time of backup, as well as write encrypted data to the recovered database. Describe permissions are needed so we can list & identify keys associated with database instances.

rds

rds:AddTagsToResource

rds:CopyDBClusterSnapshot

rds:CopyDBSnapshot

rds:CreateDBClusterSnapshot

rds:CreateDBInstance

rds:CreateDBSnapshot

rds:DeleteDBClusterSnapshot

rds:DeleteDBSnapshot

rds:DescribeDBClusterSnapshots

rds:DescribeDBClusters

rds:DescribeDBInstances

rds:DescribeDBParameterGroups

rds:DescribeDBSnapshots

rds:DescribeDBSubnetGroups

rds:DescribeOptionGroups

rds:ModifyDBClusterSnapshotAttribute

rds:ModifyDBSnapshotAttribute

rds:RestoreDBClusterFromSnapshot

rds:RestoreDBClusterToPointInTime

rds:RestoreDBInstanceFromDBSnapshot

rds:RestoreDBInstanceToPointInTime

These permissions are required to register the AWS account on Cohesity BaaS with the IAM role which got created by the Cloud Formation template. Once the source is registered on BaaS, describe permissions are needed so Cohesity can identify resources present in the account, which will be used for backups as well as at the time of recovery we use this information to provide a list of options to choose from.

Cohesity creates snapshots of the Amazon RDS & Aurora instances while backing up and storing the different database instance attributes and tags. While recovering the database instance, Cohesity creates DB instance/cluster, it also attaches the original tags. Cohesity requires the delete snapshots permissions to delete the expired/old snapshots it creates during the backup. We need to modify snapshot attributes permission so that we can share the snapshot across accounts if cross-account recovery is attempted.

RestoreDBInstanceToPointInTime and RestoreDBClusterToPointInTime is needed to do the point in time recoveries.

*If you want to use a KMS key belonging to a different AWS account, then perform the steps described in the AWS documentation.

Permissions for Amazon S3 Data Protection

You do not need to add these permissions manually, as they are automatically added when you run the CFT.

Resource

Permissions

 Reason

S3

s3:GetBucketLocation

s3:GetBucketNotification

s3:GetBucketOwnershipControls

s3:GetBucketTagging

s3:GetBucketVersioning

s3:GetInventoryConfiguration

s3:GetObject

s3:GetObjectAcl

s3:GetObjectTagging

s3:GetObjectVersion

s3:GetObjectVersionAcl

s3:GetObjectVersionTagging

s3:ListAllMyBuckets

s3:ListBucket

s3:PutBucketNotification

s3:PutInventoryConfiguration

s3:PutObject

s3:PutObjectAcl

s3:PutObjectTagging

s3:PutObjectVersionAcl

 These permissions are required for the backup and recovery of Amazon S3 objects.

iam

iam:SimulatePrincipalPolicy

 SimulatePricipalPolicy is needed to ensure that the required actions are allowed on the IAM role we created as part of the Cloud Formation template.

kms*

kms:CreateGrant

kms:DescribeKey

kms:ListAliases

kms:GenerateDataKey

 KMS permissions are needed to read data of an encrypted database at the time of backup, as well as write encrypted data to the recovered database. Describe permissions are needed so we can list & identify keys associated with database instances.
Events events:DeleteRule events:PutTargets events:RemoveTargets These permissions are required for capturing the incremental changes on the S3 buckets.
Glue

glue:DeleteJob
glue:GetJobRun
glue:StartJobRun
glue:UpdateJob

These permissions are required for sorting the inventory report. The sorted inventory report is then used to back up the Amazon S3 objects to the Cohesity DataProtect as a Service.
SQS sqs:CreateQueue
sqs:TagQueue
sqs:DeleteMessage sqs:DeleteQueue
sqs:GetQueueUrl
sqs:PurgeQueue sqs:ReceiveMessage sqs:SetQueueAttributes 		These permissions are required for capturing the incremental changes on the Amazon S3 buckets.

Considerations

  • Amazon Aurora cluster is recovered with at most one reader.

  • Cohesity does not support the auto-protect of Amazon RDS instances with different database types. Auto-protect of an Amazon RDS instance is supported only if the databases on the Amazon RDS instance are of the same type.

  • Cohesity does not support cross region-cross account recovery of Amazon RDS instance encrypted with default KMS key.

  • Cohesity does not support point-in-time recovery (PITR) of Amazon RDS instances or databases.

  • If you are recovering encrypted RDS instance(s) to Same AWS Account-Different AWS Region, you must create a KMS encryption key in the target AWS account & region with the same alias name as the KMS encryption key used to encrypt the source RDS instance(s).

  • If you are performing cross region - cross account recovery of an Amazon RDS instance encrypted with a customer-managed key, then ensure:

    • The source account's KMS key alias is available in both the source and destination regions of the destination account.

      For example, if A1 is the source account and R1 is the source region of the Amazon RDS instance you want to recover, and A2 is the destination account with R2 as the destination region, make sure that the key alias from A1 is available in both R1 and R2 of A2.

    • The source account’s KMS key alias can be accessed by the destination account. For this, you must grant the necessary permissions to the KMS key alias.

      The option group from the source account is available in both the source and destination regions of the destination account.

      For example, if A1 is the source account and R1 is the source region of the Amazon RDS instance, and A2 is the destination account with R2 as the destination region, ensure the option group from A1 is available in both R1 and R2 of the A2.