How do I migrate my Database resources to another region?

If you are migrating data from the Middle East (UAE) Region (me-central-1), then you might experience increased error rates as we continue making progress with restoration efforts. For additional information about recovery efforts and service updates that impact your AWS accounts, see the AWS Personal Health Dashboard. For assistance with this event, contact AWS Support through the AWS Management Console or the AWS Support Center.

This is part of a series of articles that provide general guidance on migrating resources form one Region to another. It covers the following services:

• Amazon Aurora
• Amazon DynamoDB
• Amazon ElastiCache
• Amazon Redshift
• Amazon Relational Database Service (Amazon RDS)

For general guidance and a full list of domain and service-specific migration guides, see How do I migrate my resources to another region?

How do I migrate my Database resources to another region using a logical dump? compliments the snapshot based approach used to migrate some of the services in this article.

For other domains, see the following resources:

• How do I migrate my Security, Identity and Compliance resources to another region?
• How do I copy an EBS Snapshot to another region using coldsnap and the EBS Direct APIs?
• How do I migrate my Compute and Container resources to another region?
• How do I migrate my Networking and Content Delivery resources to another region?
• How do I migrate my Storage resources to another region?
• How do I migrate my Application Integration resources to another region?

Amazon Aurora

Migrate Amazon Aurora to Another Region

• Aurora Global Database is the preferred migration method, supporting asynchronous replication typically under 1 second with up to 10 secondary regions. See Amazon Aurora Global Database introduces support for up to 10 secondary Regions
• KMS keys are region-specific and cannot be transferred between regions - encrypted snapshots must be re-encrypted with a KMS key in the target region
• You need appropriate KMS permissions (kms:Decrypt in the source region, kms:Encrypt and kms:GenerateDataKey* in the target region) in both regions
• Aurora also supports the same snapshot copy and restore, cross-region read replica promotion, and logical dump workflows available for RDS
• Review Encrypting Amazon Aurora resources for encryption requirements

Fail Over Using Aurora Global Database

Use this workflow if you have an Aurora Global Database with a secondary cluster in the target region. This is ideal for disaster recovery with fast failover and low-latency reads.

1. Add an AWS Region to an Aurora global database if a secondary cluster does not already exist in the target region
2. Initiate a managed failover for an Amazon Aurora global database to promote the secondary cluster in the target region
3. Update application connection strings to use the new cluster endpoint in the target region

Copy Encrypted Snapshot and Restore in Target Region

Use this workflow to copy a KMS-encrypted Aurora snapshot to the target region and restore it.

1. Verify the encryption status of your database using the RDS Console or AWS CLI.
2. Create or identify a symmetric KMS key in the target region for re-encryption. See Creating keys. To list existing keys: aws kms list-aliases --region eu-central-1
3. Ensure your IAM role has the required KMS permissions (kms:DescribeKey, kms:CreateGrant, kms:Decrypt, kms:Encrypt, kms:ReEncrypt*, kms:GenerateDataKey*) on keys in both regions. See Key policies in AWS KMS
4. Copy the encrypted snapshotto the target region, specifying the target region KMS key using the --kms-key-id parameter.
5. Restore the database in the target region.
6. Update application connection strings, environment variables, and DNS records to use the new database endpoint

Troubleshoot KMS Encryption Issues

Use this workflow if you encounter KMS-related errors during snapshot copy or restore.

1. For "You are not authorized to perform this operation" errors: verify the KMS key policy allows your IAM role, check IAM permissions include required KMS actions, and ensure the RDS service principal has access to the KMS key
2. For "The snapshot copy has been failed" errors: verify the source snapshot is accessible, check the KMS key exists in the target region, and confirm cross-region permissions are configured
3. For "Invalid KMS key" errors: ensure the KMS key ARN is from the target region (not source), verify the key is enabled and not pending deletion, and check the key is a symmetric encryption key
4. Review the Troubleshooting AWS KMS guide for additional diagnostics

---

Amazon DynamoDB

Key Considerations and Preparation

• DynamoDB on-demand backups are same-region only; use AWS Backup or Export to S3 for cross-region migration
• Global tables provide ongoing multi-region replication but are not a one-time migration tool
• Point-in-time recovery (PITR) must be enabled on the source table before using Export to S3
• KMS keys are regional; re-encrypt with a key in the destination region if using customer-managed keys
• DynamoDB backups can be copied to cross account with AWS Backup but both accounts should belong to the same organization in the Organizations service
• DynamoDB Streams records are retained for 24 hours; plan export/import within that window if keeping tables in sync
• Restores always create a new table; you cannot restore into an existing table

Using Export to S3 and Import from S3

Use this method for a one-time migration of a DynamoDB table to another region. This approach does not consume read capacity on the source table.

1. Enable point-in-time recovery in DynamoDB on the source table
2. Requesting a table export in DynamoDB to an S3 bucket in the destination region
3. In the destination region, Import the data into a new table from the exported S3 data pointing to the S3 location

Using AWS Backup for Cross-Region Copy

Use this method when you want to leverage AWS Backup for a managed cross-region backup and restore workflow.

1. Creating backups of DynamoDB tables with AWS Backup in the source region
2. Copying a backup of a DynamoDB table with AWS Backup to the destination region
3. Restoring a backup of a DynamoDB table from AWS Backup in the destination region

Using DynamoDB On-Demand Backup and Restore (Same Region)

Use this for same-region table recovery or cloning. On-demand backups cannot be copied cross-region without AWS Backup.

1. Backing up and restoring DynamoDB tables with DynamoDB: How it works to create an on-demand backup
2. Restoring a DynamoDB table from a backup to a new table in the same region

Using Point-in-Time Recovery (Same Region)

Use this to restore a table to any second within the last 35 days. Useful for recovering from accidental writes or deletes.

1. Enable point-in-time recovery in DynamoDB on the source table
2. Restoring a DynamoDB table to a point in time to create a new table with data from the chosen timestamp

Using Global Tables for Ongoing Replication

Use this for continuous multi-region replication with active-active read/write capability. Not a one-time migration tool.

1. Tutorials: Creating global tables by adding a replica in the destination region
2. Choose between Multi-Region Eventual Consistency (MREC) or Multi-Region Strong Consistency (MRSC) based on your application requirements
3. Monitor replication status in the DynamoDB console under the Global tables tab

---

Amazon ElastiCache

Key Considerations and Preparation

• ElastiCache clusters are regional; both ElastiCache and S3 APIs must be available in the source and target regions
• For disaster recovery, consider using Global Datastores for near-instant failover to a target region via Using global datastores (console)
• Migration time depends on cluster size and data set
• Schedule backups during low-traffic hours to minimize performance impact on node-based clusters (serverless caches have no backup performance impact)
• Clusters with data tiering enabled cannot export backups to S3
• Review the backup constraints before starting in Snapshot and restore

Backup and Export from the Source Region

Create a manual backup and export it to an S3 bucket in the source region.

1. Take a manual backup of your cluster using Taking manual backups
2. Create an Amazon S3 bucket with ACLs enabled in the same region as the cluster using Creating a general purpose bucket
3. Grant ElastiCache access to the S3 bucket using Exporting a backup
4. Export the ElastiCache backup from the console, which stores a .rdb backup file in the S3 bucket, using Exporting a backup

Restore in the Target Region

Copy the backup to the target region and seed a new cluster from it.

1. Create a new S3 bucket in the target region and grant ElastiCache access using Exporting a backup
2. Copy the backup files from the source bucket to the target bucket using Copying, moving, and renaming objects
3. Create a new cluster in the target region by seeding it with the .rdb file from the target S3 bucket using Seeding a new node-based cluster with an externally created backup

---

Amazon Redshift

Key Considerations

• KMS-encrypted clusters require a snapshot copy grant configured in the destination region before enabling cross-region copy
• Restoring from a snapshot creates a new cluster; you cannot restore into an existing cluster
• Tables created with the BACKUP NO parameter are excluded from snapshots on non-RA3 clusters
• Existing zero-ETL integrations and data shares must be recreated or reconfigured after restoring in a new region
• Cluster relocation across Availability Zones is supported only for RA3 instance types and preserves the cluster endpoint
• We recommend you follow Implement disaster recovery with Amazon Redshift

Cross-Region Snapshot Copy for Nonencrypted Clusters

Use this method to migrate an unencrypted Redshift provisioned cluster to another region using automated or manual snapshot copies.

1. Configuring cross-Region snapshot copy for a nonencrypted cluster by enabling cross-region copy and selecting the destination region
2. Restoring a cluster from a snapshot in the destination region using the copied snapshot
3. Update all clients and applications to use the new cluster endpoint, or use a CNAME record to simplify future failovers

Cross-Region Snapshot Copy for AWS KMS-Encrypted Clusters

Use this method when your Redshift cluster is encrypted with AWS KMS. A snapshot copy grant must be configured in the destination region.

1. Configuring cross-Region snapshot copy for an AWS KMS–encrypted cluster by enabling cross-region copy with a KMS grant in the destination region
2. Restoring a cluster from a snapshot in the destination region using the copied snapshot
3. Update all clients and applications to use the new cluster endpoint

Cross-Region Backup Copy for Redshift Serverless

Use this method to copy serverless snapshots and recovery points to another region for disaster recovery or migration.

1. Copying backups to another AWS Region by configuring cross-region backup on the serverless namespace
2. Restoring a serverless namespace from a snapshot in the destination region using the copied snapshot
3. Update all clients and applications to use the new serverless endpoint

Relocating a Cluster to Another Availability Zone

Use this method to move an RA3 provisioned cluster to a different Availability Zone within the same region. The cluster endpoint is preserved.

1. Relocating a cluster by enabling Availability Zone relocation on the cluster
2. Monitor the relocation progress in the cluster Events tab
3. Verify the new Availability Zone in the cluster details after relocation completes

---

Amazon Relational Database Service (Amazon RDS)

Migrate Amazon RDS to Another Region

• KMS keys are regional - if your DB instance is encrypted, create a KMS key in the target region before copying the snapshot and specify its ARN during the copy to re-encrypt. See Encrypting Amazon RDS resources
• DB subnet groups and security groups are regional and must be recreated in the target region before restoring the instance. See Working with a DB instance in a VPC
• Custom parameter groups are regional - export settings using describe-db-parameters and recreate in the target region
• Secrets Manager secrets are regional and must be migrated to the target region before updating your application. See AWS Secrets Manager replication and Replicate a secret to other Regions
• IAM roles are global but verify that monitoring and associated role policies do not contain hard-coded source region ARNs

Promote a Cross-Region Read Replica

Use this workflow if a cross-region read replica already exists in the target region. This is the fastest path with the least data loss.

1. Verify the replica is caught up with the primary
2. Promote the replica using promote-read-replica to make it a standalone DB instance
3. Point applications to the new endpoint in Route 53 or your connection strings (set TTL to 60 seconds before the change)
4. Migrate Secrets Manager secrets to the target region and update your application

Migrate Using Infrastructure as Code

Use this workflow when your RDS infrastructure is defined with CloudFormation, CDK, or Terraform.

1. Take a final snapshot using create-db-snapshot to minimize data loss
2. Copy the snapshot to the target region using copy-db-snapshot. For encrypted instances, specify the target region KMS key ARN to re-encrypt. See Copying a DB snapshot
3. Update the target region in your IaC configuration and update all region-specific ARNs (KMS keys, VPC IDs, subnet group names, security group IDs)
4. Redeploy the stack in the target region
5. Point applications to the new endpoint in Route 53 or your connection strings (set TTL to 60 seconds before the change) and confirm the DB instance is available and accepting connections
6. Migrate Secrets Manager secrets to the target region and update your application

Recreate RDS Instance Manually

Use this workflow if you do not have IaC or need to migrate your DB instance manually.

1. Export your instance configuration using describe-db-instances and custom parameter group settings using describe-db-parameters
2. Take a final snapshot using create-db-snapshot
3. Recreate regional dependencies in the target region: VPC and networking, DB subnet group using create-db-subnet-group, security groups, and custom parameter group using create-db-parameter-group and modify-db-parameter-group with the exported settings
4. Copy the snapshot to the target region using copy-db-snapshot. For encrypted snapshots, create a KMS key in the target region first and specify its ARN. See Copying a DB snapshot
5. Restore the DB instance using restore-db-instance-from-db-snapshot, applying the recreated configuration
6. Point applications to the new endpoint in Route 53 or your connection strings (set TTL to 60 seconds before the change) and confirm the DB instance is available and accepting connections
7. Migrate Secrets Manager secrets to the target region and update your application

Migrate Back to the Original Region

Use this workflow to return to the original region after the issue is resolved.

1. Take a snapshot of the DB instance in the target region using create-db-snapshot
2. Copy the snapshot back to the source region using copy-db-snapshot, specifying the source region KMS key ARN if encrypted. See Copying a DB snapshot
3. Restore the DB instance in the source region using restore-db-instance-from-db-snapshot
4. Recreate any regional dependencies that were removed or modified during the migration
5. Point applications back to the source region endpoint and confirm the DB instance is available and accepting connections

---

In collaboration with Nymus Booysen and Francesco Penta