Amazon DynamoDB Requirements and Considerations

Before you protect your DynamoDB using Cohesity Cloud Protection 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.

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 Cloud Protection Service.

IAM User Permissions to Execute CFT

To register an AWS account with the Cohesity Cloud Protection 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 DynamoDB Data Protection

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

Resource

Permissions

 Reason
IAM iam:PassRole  
 

kms:CreateGrant

kms:DescribeKey

kms:Decrypt

kms:Encrypt

kms:ListAliases

kms:ListKeys

 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. Described permissions are needed for listing and identifying keys associated with database instances.
 

dynamodb:BatchWriteItem

dynamodb:DeleteItem

dynamodb:GetItem

dynamodb:PutItem

dynamodb:Query

dynamodb:RestoreTableToPointInTime

dynamodb:Scan

dynamodb:UpdateItem

dynamodb:CreateTable

dynamodb:UpdateTable

dynamodb:DescribeContinuousBackups

dynamodb:DescribeExport

dynamodb:DescribeImport

dynamodb:DescribeTable

dynamodb:ExportTableToPointInTime

dynamodb:ImportTable

dynamodb:ListTables

dynamodb:ListTagsOfResource

dynamodb:TagResource

dynamodb:UpdateContinuousBackups

 These permissions are required for backing up and recovering Amazon DynamoDB tables.
 

s3:CreateBucket

s3:GetBucketLocation

s3:PutBucketTagging

s3:DeleteBucket

s3:AbortMultipartUpload

s3:DeleteObject

s3:GetBucketVersioning

s3:GetObject

s3:GetObjectTagging

s3:GetObjectVersion

s3:ListBucket

s3:ListBucketMultipartUploads

s3:ListMultipartUploadParts

s3:PutObject

s3:PutObjectTagging

  
 

glue:CreateJob

glue:TagResource

glue:DeleteJob

glue:StartJobRun

glue:GetJobRun

  
 

logs:DescribeLogGroups

logs:CreateLogGroup

logs:CreateLogStream

logs:DescribeLogStreams

logs:GetLogEvents

logs:PutLogEvents

  

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

Considerations

Review and understand the following limitations and known issues before protecting Amazon DynamoDB tables:

  • General Protection Limitations

    • Tables in Amazon DynamoDB can be protected across all regions in your AWS account.

    • During recovery, you can restore Amazon DynamoDB tables to their original region. However, the restore operation fails if another table with the same name already exists in that region.

    • To restore a table using its original name, you must first manually delete the existing table. Then, perform the recovery without specifying any prefix or suffix for the table name.

  • Restore Method Behavior and Priority

    When a restore is initiated, Cohesity attempts recovery using the AWS Point-in-Time Recovery (PITR) method first. If PITR is unavailable, Cohesity falls back to the snapshot-based restore method.

    Capabilities and limitations differ between the two methods:

    • PITR Restore

      • Supports restoring both Local Secondary Indexes (LSIs) and Global Secondary Indexes (GSIs) within the 35-day PITR window.

      • Restore is supported only to the original AWS account where the backups were created.

      • Cross-region and cross-account restores are not supported using PITR.

    • Snapshot-Based Restore

      • Does not support restoring Local Secondary Indexes (LSIs).

      • Cross-region and cross-account restores are supported.

      • Used automatically when PITR is unavailable.

  • Global Tables

    • Global tables are recovered as local tables.

    • After restore, you must manually reconfigure the table as a global table.

    • This behavior applies only to EVENTUAL CONSISTENCY Global Tables.

    • Backup strategy: Perform the backup from any one of the regions participating in the global table.

    • Restore strategy: Restore the table to the desired region, then manually configure the global table.

  • Index Restore Considerations

    • Tables with Global Secondary Indexes (GSIs) may take longer to restore because indexes are recreated during recovery.

    • Restore of Local Secondary Indexes (LSIs) is not supported when using snapshot-based protection. This limitation applies only to snapshot restores and not to PITR restores. This is an AWS consideration for importing DynamoDB tables from Amazon S3.

  • Large Table Backup and Restore Considerations

    For DynamoDB tables larger than 2.5 TB:

    • The default Max task DPUs per account must be increased in the AWS region where the AWS Glue job runs.

    • The increase is required on:

      • The AWS side (AWS Glue DPU quota)

      • The Cohesity side (cluster G-flag configuration)

    Contact Cohesity Support for assistance with increasing the DPU limits on both the AWS and Cohesity sides.

    For Large Restores (15 TB or Larger)

    • AWS does not natively support restores of 15 TB or larger.

    • Before attempting a restore of this scale, you must contact AWS Support to request an increase to the import size limit.

  • AWS Charges

    For protected DynamoDB tables, the following AWS charges may apply:

    • AWS Glue job costs: For data transformation and movement during backup or recovery.

    • Export table costs: For exporting table data to S3.

    • Egress costs: For data transferred out of AWS.

  • Point-in-Time Recovery (PITR) Considerations

    • Cohesity enables PITR for Amazon DynamoDB tables, allowing restoration to any specific point within the past 35 days.

    • PITR is available only when restoring to the original AWS account.

    • After unprotecting a DynamoDB table, you must manually disable PITR to avoid unnecessary retention and associated AWS costs.

    • Manually turning off PITR after a full backup breaks the backup chain. Subsequent incremental backups cannot run until a new full backup is completed.

  • DynamoDB Version Limitation

    • Restoring a backup taken from a higher DynamoDB version to a lower version is not supported.

  • Cross-Region and Cross-Account Restore Summary

    Restore Method

    Same Region

    		 Cross Region Cross Account
    PITR Supported Not Supported Not Supported
    Snapshot Supported Supported Supported