migration-database

name

migration-database

description

Cross-region migration for database services including Amazon Relational Database Service (Amazon RDS), Amazon Aurora, Amazon Redshift, and Amazon ElastiCache. Covers snapshot copy and restore, cross-region read replica promotion, cross-region automated backups, Aurora Global Database failover, AWS KMS re-encryption, native database dump fallback, Amazon Redshift cross-region snapshot copy, and ElastiCache Global Datastore failover.

Database Services Migration

Amazon Relational Database Service (Amazon RDS) Migration Guide

Security: Always ensure migrated resources meet or exceed the security configuration of the source resources. Refer to SECURITY.md for security requirements.

Moving Amazon RDS Instances to Another Region

Note: Skip option C for the affected region as it is not feasible.

Option A: If You Have Cross-Region Read Replicas

• Go to RDS Console in the replica's region. If you are not sure whether the Amazon RDS instance has a read replica, go to the RDS console in the source (primary instance) region. In the instance "Connectivity & security" → "Replication" section, the cross-region replica instance appears in the list for the target region.
• Select your read replica instance.
• Click Actions → Promote
• Click Promote read replica to confirm promotion
• Update application to use promoted instance
• After promotion, replication between the primary and replica instances is disconnected. You need to create a new (cross region)/replica from the new promoted instance.

Promoting a Read Replica

Option B: If the instance has cross-Region automated backups enabled

• Go to RDS Console in the source region, in to the instance “Maintenance & backup” tab“, navigate to "Backup” section and make sure “Replicate to Region“ and ”Replicated automated backup“ is not empty and confirm the instance has the cross-Region automated backups feature enabled and has backups replicated to the target region.
• You can use below CLI to confirm if the feature enabled

aws rds describe-db-instances \
  --db-instance-identifier yourInstance \
  --query 'DBInstances[0].DBInstanceAutomatedBackupsReplications' \
  --output json

• Go to RDS Console in the target region, In the “Automated backups” → “Replicated” section, find the instance you would like to restore.
• Click the instance name identified in the last step, then click Action → Restore to point in time.
• Fill in all the necessary information in the console page and start the restore.
• After restore complete, update the application configuration to use the new restored instance.

Using AWS CLI to perform the point in time restore

aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-automated-backups-arn "arn:aws:rds:us-east-1:123456789012:auto-backup:ab-L2IJCEXJP7XQ7HOJ4SIEXAMPLE" \
    --target-db-instance-identifier mytargetdbinstance \
    --restore-time 2020-10-14T23:45:00.000Z
    

Please note below limitations:

On RDS for SQL Server, option groups aren't copied. On RDS for Oracle, the following options aren't copied: NATIVE_NETWORK_ENCRYPTION, OEM, OEM_AGENT, and SSL.

Replicating automated backups to another AWS Region

Option C: Snapshot Copy + Restore

Create a DB snapshot of the source RDS instance, copy the snapshot to the target region, and restore a new DB instance from the copied snapshot.

Key considerations: * The DB snapshot must be compatible with the engine version available in the target region * Encryption keys (AWS KMS) are region-specific — re-encrypt snapshots when copying cross-region * Update connection strings, security groups, and parameter groups in the target region

Before You Start

Assess Your Current Situation: * Check if you have recent snapshots available * Identify your target recovery region * Verify you have necessary permissions in the target region * Document your current database endpoints for later updates

Understanding RDS Snapshots

Step 1: Identify Available Snapshots

Using AWS Console: * Navigate to RDS Console * Select source region (if accessible) * Click Snapshots in the left menu * Look for your database snapshots (automated or manual) * Note the most recent snapshot name

Using AWS CLI:

aws rds describe-db-snapshots \
  --region SOURCE-REGION \
  --db-instance-identifier YOUR-DB-NAME

Working with DB Snapshots

Step 2: Copy Snapshot to Target Region

Using AWS Console: * Go to RDS Snapshots * Select your snapshot * Click Actions → Copy Snapshot * Choose Destination Region * Enter a New DB Snapshot Identifier * If encrypted, select Target AWS KMS Key * Click Copy Snapshot * Monitor progress in target region console

Using AWS CLI:

Security: Use --kms-key-id to encrypt snapshot copies with an AWS KMS key in the target region. If the source snapshot is unencrypted, add --kms-key-id to encrypt during copy.

aws rds copy-db-snapshot \
  --region TARGET-REGION \
  --source-db-snapshot-identifier arn:aws:rds:SOURCE-REGION:123456789012:snapshot:YOUR-SNAPSHOT-NAME \
  --target-db-snapshot-identifier YOUR-SNAPSHOT-NAME-copy \
  --source-region SOURCE-REGION \
  --kms-key-id arn:aws:kms:TARGET-REGION:123456789012:key/TARGET-KEY-ID

Limitations:

Depending on the AWS Regions involved and the amount of data to be copied, a cross-region snapshot copy can take hours to complete. In some cases, there might be a large number of cross-region snapshot copy requests from a given source region. In such cases, Amazon RDS might put new cross-region copy requests from that source region into a queue until some in-progress copies complete. No progress information is displayed about copy requests while they are in the queue. Progress information is displayed when the copy starts.

Copying a DB Snapshot

Step 3: Restore Database in Target Region

For Standard RDS Instances:

Using AWS Console: * Navigate to RDS Console in your target region * Click Snapshots → Select your copied snapshot * Click Actions → Restore Snapshot * Configure the following: * DB Instance Identifier: Choose a new name * DB Instance Class: Match your original or adjust as needed * VPC: Select appropriate VPC in target region * Subnet Group: Select or create subnet group * Public Access: No (recommended) * VPC Security Groups: Select appropriate security groups * Multi-AZ: Yes (recommended for production) * Click Restore DB Instance

Using AWS CLI:

aws rds restore-db-instance-from-db-snapshot \
  --region TARGET-REGION \
  --db-instance-identifier YOUR-NEW-DB-NAME \
  --db-snapshot-identifier YOUR-SNAPSHOT-NAME-copy \
  --db-subnet-group-name your-subnet-group \
  --vpc-security-group-ids sg-xxxxxxxxx \
  --db-instance-class db.r5.large \
  --multi-az

Restoring from a DB Snapshot

Option D: Engine-Native Database Backup During Regional Impairments

When AWS control plane APIs are unavailable but database connectivity remains intact, use native database tools to create backups and transfer them to another region, bypassing all AWS APIs.

Prerequisites: * Identify a machine with network access to the database endpoint: * EC2 instance in the same VPC * Bastion host with connectivity * Local machine via VPN or Direct Connect.

Backup Approach:

MySQL: * Use mysqldump with --single-transaction flag * Creates consistent backup without locking tables * Pipe output through gzip for compression * Captures all databases, routines, triggers, and events. If database size is big, use mydumper/myloader for faster performance.

PostgreSQL: * Use pg_dumpall to capture complete system state * Includes all databases, roles, and tablespaces * Provides single consistent snapshot * Compress output with gzip.

Security: Enforce TLS encryption for all database connections by specifying --ssl-mode=REQUIRED for MySQL or sslmode=require for PostgreSQL. Encrypt dump files at rest before transfer (e.g., pipe through gpg --encrypt). Securely delete local dump files after successful upload to S3.

SQL Server: If the Amazon RDS for SQL Server instance has the native backup and restore option by using the SQLSERVER_BACKUP_RESTORE option group, then you can perform SQL server native backup by using stored procedure msdb.dbo.rds_backup_database, the backup is stored in the specified S3 bucket location. Alternatively, you can use SQL server bcp command to export data from the RDS SQL server instance.

Oracle: Use Oracle data pump(expdp, DBMS_DATAPUMP) or export (exp) utilities to export Oracle data to a dump file and import it into another Oracle database.

Transfer Methods:

Direct to S3 (Preferred): * Copy compressed dump directly to S3 bucket in unaffected region * Use aws s3 cp - s3://bucket/backup.sql.gz syntax * No intermediate storage required * Customer responsibility: Before copying, verify the target S3 bucket has Block Public Access enabled, default encryption configured (SSE-KMS recommended for database backups), a bucket policy enforcing TLS-only access, versioning enabled for backup retention, and access logging configured for audit trails

SSH Transfer (Fallback): * Transfer via ssh to remote host if AWS CLI unavailable * Use ssh user@host "cat > backup.sql.gz" to stream data * Requires accessible remote server in healthy region

Data Restore:

MySQL: mysqldump utility export the database data as readable SQL scripts and is executable in the MySQL instance. You can login to the healthy RDS MySQL instance and run the exported dump files to restore the data into the new instance.

PostgreSQL: use pg_restore command to restore to a healthy RDS PostgreSQL instance.

SQL Server: Use msdb.dbo.rds_restore_database to restore the SQL server native backups. If exported with the bcp command, then use bcp command to import to a new healthy Amazon RDS for SQL Server instance.

Oracle: Import the data pump backup to RDS Oracle using impdp, DBMS_DATAPUMP accordingly. Use the imp utility to import if exp was used to export the data.

---

RDS (Aurora) Migration Guide

Option A: Aurora Global Database (Recommended for Low Latency)(Skip for the affected region unless there is already a secondary in another region)

Aurora Global Database allows a single Amazon Aurora cluster to span multiple regions, with asynchronous replication that typically achieves sub-second latency in optimal network conditions. This is ideal for: * Disaster recovery with fast failover * Low-latency reads in secondary regions * "Follow the Sun" use cases

Supports up to 10 secondary regions.

Adding an AWS Region to an Aurora Global Database

Aurora Global Database Supports Up to 10 Secondary Regions

Option B: Restore from Snapshot (Aurora Clusters)(Skip for the affected region unless there is already a snapshot in another region)

Using AWS Console: * Go to RDS Console in target region * Click Snapshots → Select your Aurora snapshot * Click Actions → Restore Snapshot * Configure: * DB Cluster Identifier: New cluster name * Engine Version: Match original * VPC & Subnet Group: Select appropriate values * Security Groups: Configure access * Click Restore DB Cluster * After cluster is created, add instances: * Click your cluster name * Click Actions → Add Reader * Configure instance class and settings

Using AWS CLI:

aws rds restore-db-cluster-from-snapshot \
  --region TARGET-REGION \
  --db-cluster-identifier YOUR-NEW-CLUSTER-NAME \
  --snapshot-identifier YOUR-SNAPSHOT-NAME-copy \
  --engine aurora-mysql \
  --db-subnet-group-name your-subnet-group \
  --vpc-security-group-ids sg-xxxxxxxxx

Add cluster instance:

aws rds create-db-instance \
  --region TARGET-REGION \
  --db-instance-identifier YOUR-NEW-CLUSTER-NAME-instance-1 \
  --db-cluster-identifier YOUR-NEW-CLUSTER-NAME \
  --db-instance-class db.r5.large \
  --engine aurora-mysql

Restoring Aurora from Snapshot

Update Application Connections

Once your database is available in the new region:

Get New Endpoint: * Console: RDS → Databases → Click your database → Connectivity & Security tab * CLI: aws rds describe-db-instances --region TARGET-REGION --db-instance-identifier YOUR-DB-NAME

Update Application Configuration: * Update database connection strings * Update environment variables * Update configuration files * Restart application services

Update DNS (if using Route 53): * Go to Route 53 Console * Select your hosted zone * Update CNAME record to point to new endpoint * Set low TTL (60 seconds) for quick propagation

Connecting to a DB Instance

Verify and Test

Before switching production traffic: * Test database connectivity from application servers * Verify data integrity (check recent records) * Test read/write operations * Confirm security group rules allow necessary access * Verify backup configuration in new region * Check monitoring and alerting is configured

Special Considerations for KMS-Encrypted Databases

If your RDS database uses AWS KMS encryption, additional steps are required for cross-region recovery.

Understanding AWS KMS Key Limitations

• AWS KMS keys are region-specific and cannot be transferred between regions
• Encrypted snapshots must be re-encrypted with an AWS KMS key in the target region
• You need appropriate AWS KMS permissions in both source and target regions

Encrypting Amazon RDS Resources

Step 1: Verify Encryption Status

Using AWS Console: * Go to RDS Console * Select your database * Check Configuration tab for Encryption status * Note the AWS KMS key ID if encrypted

Using AWS CLI:

aws rds describe-db-instances \
  --region SOURCE-REGION \
  --db-instance-identifier YOUR-DB-NAME \
  --query "DBInstances[0].[StorageEncrypted,KmsKeyId]"

Step 2: Create or Identify AWS KMS Key in Target Region

Option A: Create New AWS KMS Key * Go to AWS KMS Console in target region * Click Create key * Select Symmetric key type * Choose Encrypt and decrypt usage * Add alias (e.g., rds-recovery-key) * Define key administrators * Define key users (include RDS service) * Review and create

Option B: Use Existing AWS KMS Key

List available AWS KMS keys in target region:

aws kms list-aliases --region TARGET-REGION

Creating AWS KMS Keys

Step 3: Grant AWS KMS Permissions

Verify your IAM role/user has these AWS KMS permissions in both regions. Each permission serves a specific purpose: kms:Decrypt in the source region allows reading encrypted snapshot data, while kms:Encrypt and kms:GenerateDataKey in the target region enable re-encryption with the new key.

Required Permissions:

kms:DescribeKey
kms:CreateGrant
kms:Decrypt (source region)
kms:Encrypt (target region)
kms:ReEncryptFrom
kms:ReEncryptTo
kms:GenerateDataKey

Sample IAM Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:DescribeKey",
        "kms:CreateGrant",
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:ReEncryptFrom", "kms:ReEncryptTo",
        "kms:GenerateDataKey"
      ],
      "Resource": [
        "arn:aws:kms:SOURCE-REGION:123456789012:key/SOURCE-KEY-ID",
        "arn:aws:kms:TARGET-REGION:123456789012:key/TARGET-KEY-ID"
      ]
    }
  ]
}

KMS Key Policies

Step 4: Copy Encrypted Snapshot with Re-encryption

Using AWS Console: * Go to RDS Snapshots in source region * Select your encrypted snapshot * Click Actions → Copy Snapshot * Choose Destination Region * Enable encryption (checked by default for encrypted snapshots) * Select Target AWS KMS Key from dropdown (your target region key) * Enter New DB Snapshot Identifier * Click Copy Snapshot

Using AWS CLI:

aws rds copy-db-snapshot \
  --region TARGET-REGION \
  --source-db-snapshot-identifier arn:aws:rds:SOURCE-REGION:123456789012:snapshot:YOUR-SNAPSHOT-NAME \
  --target-db-snapshot-identifier YOUR-SNAPSHOT-NAME-copy \
  --kms-key-id arn:aws:kms:TARGET-REGION:123456789012:key/TARGET-KEY-ID \
  --source-region SOURCE-REGION

Important: The --kms-key-id must be a KMS key ARN from the target region.

Copying an Encrypted Snapshot

Step 5: Restore with Target Region AWS KMS Key

When restoring the database, it automatically uses the AWS KMS key from the copied snapshot. No additional encryption parameters needed.

Using AWS Console: * Follow standard restore process (Step 3 above) * Encryption settings are inherited from snapshot

Using AWS CLI:

aws rds restore-db-instance-from-db-snapshot \
  --region TARGET-REGION \
  --db-instance-identifier YOUR-NEW-DB-NAME \
  --db-snapshot-identifier YOUR-SNAPSHOT-NAME-copy \
  --db-subnet-group-name your-subnet-group \
  --vpc-security-group-ids sg-xxxxxxxxx \
  --db-instance-class db.r5.large

Troubleshooting AWS KMS Issues

Error: "You are not authorized to perform this operation" * Verify KMS key policy allows your IAM role * Check IAM permissions include required AWS KMS actions * Verify that the Amazon RDS service principal has access to the AWS KMS key

Error: "The snapshot copy has been failed" * Verify source snapshot is accessible * Check AWS KMS key exists in target region * Confirm cross-region permissions are configured

Error: "Invalid KMS key" * Verify AWS KMS key ARN is from target region (not source) * Verify key is enabled and not pending deletion * Check key is symmetric encryption key

Troubleshooting KMS

---

Amazon Redshift Migration Guide

Cross-Region Migration Strategy for Amazon Redshift

Migration Approach: Cross-Region Snapshot Copy

The recommended approach uses Amazon Redshift's cross-region snapshot feature to perform the migration with minimal data loss and within a defined maintenance window.

Step-by-Step Migration Process

Phase 1: Pre-Migration Setup

1. Enable Cross-Region Snapshot Copy

• Navigate to your Redshift cluster in the AWS console
• Click Actions → Configure cross-region snapshot
• Select your destination region (e.g., eu-west-1)
• Configure retention period for snapshots
• This creates automated snapshot copies to the destination region

2. Take Multiple Manual Snapshots

• Create manual snapshots before cutover deadline
• This helps minimize data loss during migration
• Snapshots are stored in Amazon S3 and can be transferred to the destination region

Phase 2: Snapshot Copy Process

Configuration Details:

• Source: Your current AWS region
• Destination: Target AWS region
• Method: Cross-region snapshot copy with encryption support

If your cluster uses AWS KMS encryption, follow the KMS-encrypted cluster configuration process.

Phase 3: Restore in Target Region (Cutover Window)

1. Restore from Cross-Region Snapshot

• In the destination region, restore a new cluster from the latest snapshot
• The new cluster has the same endpoint structure
• Configure cluster parameters (node type, number of nodes, VPC settings)

2. Validation & Testing

• Verify data integrity and completeness
• Test application connectivity
• Validate query performance

3. DNS/Endpoint Update

• Update application connection strings to point to the new cluster in the target region
• The endpoint maintains consistency for minimal application changes

Key Considerations

• Snapshot Size & Transfer Time: Large clusters take longer to snapshot and transfer across regions
• Network Transfer Costs: Cross-region data transfer incurs charges
• Maintenance Window: Plan for adequate time based on cluster size
• Incremental Snapshots: Use multiple snapshots leading up to cutover to minimize final data sync time

Additional Resources

• docs.aws.amazon.com/redshift/latest/mgmt/serverless-backup-copy.html
• aws.amazon.com/blogs/big-data/implement-disaster-recovery-with-amazon-redshift/

Step-by-Step Guide: Moving Amazon Redshift Cluster to Another AZ (Same Region)

Prerequisites

• Verify that you have appropriate IAM permissions to modify Redshift clusters
• Identify your target Availability Zone in your current region
• Plan a maintenance window (though relocation is designed for minimal disruption)

Method 1: Using AWS Console

Step 1: Access the Redshift Console

• Sign in to the AWS Management Console
• Navigate to Amazon Redshift at console.aws.amazon.com/redshiftv2/
• Verify that you're in the correct region

Step 2: Select Your Cluster

• From the navigation menu, choose Provisioned clusters dashboard
• Click on Clusters
• Select your cluster from the list

Step 3: Enable Relocation

• Click the Actions dropdown menu
• Select Modify
• Scroll to the Availability zone section
• Check the box for Enable relocation (or "Availability zone relocation")
• Review the modification summary

Step 4: Apply Changes

• Choose when to apply: Apply immediately or Apply during next maintenance window
• Click Modify cluster to confirm

Step 5: Monitor the Relocation

• The cluster status changes to "modifying"
• Monitor the Events tab for relocation progress
• Once complete, verify the new AZ in cluster details

Additional Resources

• docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-recovery.html

---

ElastiCache Migration Guide

There is no direct lift and shift method, moving an existing cluster to a new region or AZ involves the creation of a new cluster and seeding it with the data from the source cluster. For the clusters in the impaired region, you are not able to take snapshots for the clusters due to API unavailability, please create new clusters in other regions as replacement.

Option 1: Using Global Datastore (Skip this option unless customer has already set up global datastore with a secondary cluster in other regions)

Unless you make use of Global Data Replication, in which case you can simply failover/promote a new primary cluster in the target region, allowing a secondary region to take over read/write capabilities within seconds.

AWS CLI command:

aws elasticache failover-replication-group \
   —global-replication-group-id <The name of the Global datastore> \
   —primary-region <The AWS Region of the primary cluster> \  
   —primary-replication-group-id  <The name of the primary replication group>

Option 2: Backup + Restore (Skip this option for the affected region):

1. Take a manual backup of your cluster
2. Create an Amazon S3 bucket in the same region as the cluster. Configure the bucket with Block Public Access enabled, default encryption (SSE-KMS recommended), a bucket policy enforcing TLS-only access, versioning enabled for backup retention, and access logging configured. Use a bucket policy to grant ElastiCache service principal access instead of ACLs.
3. Grant ElastiCache access to the S3 Bucket
4. Export the ElastiCache Backup from the Console. This stores a .rdb backup file in the S3 bucket you just created
5. Create a new S3 bucket in the target region with the same security configuration (Block Public Access enabled, default encryption with SSE-KMS, a bucket policy enforcing TLS-only access, versioning enabled, and access logging configured). Use a bucket policy to grant ElastiCache access to the bucket
6. Copy the backup files from the source bucket to the target bucket
7. You can now create a new cluster in the target region by seeding it with the .rdb file from the target S3 bucket

Total time for the backup and restore Keep in mind that overall time for completion of the entire migration of a cluster depends on the size of the data set. This is because the size determines the time taken to complete the backup creation, the export to S3, the copy from source S3 bucket to destination S3 bucket, and the time taken to create the new cluster which involves seeding the backup data.

This can only be estimated based on actual tests and if we were to take an example of a manual backup with a 5 minute backup completion time - that could result in 5-10 minute export, 5-10 minute S3 copy, and another 10-15 minute new cluster creation with seeding.

Total estimated time for completion would be 25-40 minutes, excluding the time it would take to prepare the migration which includes creating S3 buckets and configuring their permissions.

Rollback plan With this migration procedure, there is minimal impact to the existing configuration (performance overhead during the backup creation), but the original cluster still responds to requests throughout the process and as such, a rollback in any event of failure would simply involve switching the endpoint URL in your application to the source configuration where the original infrastructure still exists.

Downsides Since the original cluster remains active throughout the migration, there would only be downtime during the cutover process. The amount of downtime is determined by the applications ability to handle disruption and a switch in endpoint URLs, as well as its ability to handle a small discrepancy between current data and that of the most recent backup.

Thus, it is recommended to perform the migration during a period of least utilization/traffic. You would also need to prepare for any unforeseen difficulties that may occur as a result of the migration - purely related to the application handling the changes.

Verification strategy - data consistency Before moving workload to the new cluster, you can review the cluster data by accessing it via an EC2 instance in the same VPC. This way, you can verify data consistency and confirm that key components are accessible and ready for use. Keep in mind the small data discrepancy due to the time gap between backup creation and cutover, you may even consider manually replacing any new data that was added during this time.

You could also look into ways of preparing for this. For example, delaying any major data mutations/additions, or scripting those changes so that they can easily be replicated on the new cluster.

Testing and troubleshooting It may be worthwhile anticipating additional overhead in terms of testing and troubleshooting access patterns and connectivity across components. You might consider configuring an EC2 instance or EKS deployment in a way that most of these tests can be done prior to cutover to facilitate a smooth migration.

Data Classification and Security

Before migrating databases, classify data sensitivity:

• Regulated data (PII, PHI, PCI): Require encryption at rest and in transit, audit logging, and access controls matching or exceeding source region configuration
• Business-critical data: Require encrypted snapshots, cross-region backup verification, and documented RTO/RPO
• Development/test data: Standard encryption practices apply

Error Handling for CLI Commands

Validate AWS CLI outputs before proceeding to dependent steps:

SNAPSHOT_STATUS=$(aws rds describe-db-snapshots \
  --db-snapshot-identifier YOUR-SNAPSHOT-COPY \
  --region TARGET-REGION \
  --query 'DBSnapshots[0].Status' --output text 2>&1)

if [[ "$SNAPSHOT_STATUS" != "available" ]]; then
  echo "ERROR: Snapshot not available. Status: $SNAPSHOT_STATUS"
  exit 1
fi