Copying RDS snapshots across regions is surprisingly less about disaster recovery (DR) and more about enabling sophisticated data portability and versioning strategies.
Let’s see this in action. Imagine we have a us-east-1 RDS instance, my-prod-db, and we want a copy in us-west-2 for testing or a secondary region.
First, we initiate the copy from the primary region:
aws rds copy-db-snapshot --source-db-snapshot-identifier arn:aws:rds:us-east-1:123456789012:snapshot:my-prod-db-2023-10-27-10-00 --target-db-snapshot-identifier my-prod-db-us-west-2-copy-2023-10-27 --region us-east-1 --kms-key-id arn:aws:kms:us-east-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
(Note: You’d replace arn:aws:rds:us-east-1:123456789012:snapshot:my-prod-db-2023-10-27-10-00 with your actual snapshot ARN, and the KMS key ID is crucial if your source snapshot is encrypted. If it’s unencrypted, you can omit the --kms-key-id flag here and specify a KMS key in the target region when restoring.)
The copy-db-snapshot command initiates an asynchronous operation. The snapshot data is not directly streamed across regions; instead, RDS orchestrates the creation of a new snapshot in the target region, referencing the underlying data. This is key to understanding the cost and performance implications.
Once the copy is complete in us-west-2, you can verify it:
aws rds describe-db-snapshots --db-snapshot-identifier my-prod-db-us-west-2-copy-2023-10-27 --region us-west-2
The output will show the snapshot details in us-west-2, including its status, creation time, and storage size. You can then restore this snapshot to a new RDS instance in us-west-2:
aws rds restore-db-instance-from-db-snapshot --db-instance-identifier my-test-db-us-west-2 --db-snapshot-identifier my-prod-db-us-west-2-copy-2023-10-27 --db-instance-class db.r5.large --region us-west-2 --publicly-accessible
This process allows you to spin up a fully functional replica of your database in a different AWS region. The primary use cases are:
- Disaster Recovery (DR): In the event of a regional outage, you can restore from the cross-region snapshot to a new RDS instance in a healthy region. This provides a recovery point objective (RPO) determined by the frequency of your snapshot copies.
- Data Portability: Migrating data between regions is simplified. You can copy a snapshot to a new region and then restore it, effectively moving your database.
- Testing and Development: Create isolated copies of production data in a separate region for performance testing, application development, or staging environments without impacting the primary production instance.
- Auditing and Compliance: Maintain historical data copies in different geographical locations for long-term retention or compliance requirements.
The underlying mechanism involves RDS taking the source snapshot, making it available for copying, and then creating a new snapshot in the target region. If the source snapshot was encrypted, you must provide a KMS key ARN for the target region during the copy-db-snapshot operation. This key is used to encrypt the new snapshot in the target region. If the source was unencrypted, you can choose to encrypt the copy in the target region by specifying a KMS key for that region. This cross-region encryption is a critical security consideration.
The most surprising aspect is how AWS handles the data transfer. It’s not a direct, real-time replication stream. Instead, RDS leverages its internal infrastructure to make the snapshot data available in the target region. This means the copy operation’s duration is influenced by factors like snapshot size, network throughput between AWS regions (which is managed by AWS), and the load on both the source and target RDS services. You’re essentially creating a new, independent snapshot in the destination, not just a pointer to the original.
When you copy an encrypted snapshot, the KMS key used in the source region is not directly used in the target region. You specify a KMS key that exists in the target region for the new snapshot. AWS handles the decryption of the source snapshot data using its source region KMS key and then re-encryption using the specified target region KMS key. This ensures that the data at rest in the target region is encrypted with keys managed within that region.
The next logical step after mastering cross-region snapshot copies is to automate this process using AWS Lambda and CloudWatch Events to ensure your DR or portability strategy is consistently applied.