Automating AWS RDS snapshot copy with cross-region lifecycle policies
Amazon RDS removes much of the operational work involved in database backups, but a snapshot stored in the same AWS Region does not provide full disaster recovery protection. A regional outage, configuration mistake, or compromised account can affect both the production database and its recovery points.
A cross-Region copy policy creates an independent recovery path. AWS Backup can orchestrate scheduled RDS backups, copy them to another Region, retain them for a defined period, and expire them automatically. This is more consistent than relying on an administrator to copy snapshots after every change window.
For Australian organisations, the design often needs to account for data residency, recovery time objectives, and the distance between locations. A Sydney workload might use Melbourne as its secondary Region, while a Perth-based business may also consider network latency, application dependencies, and the cost of moving data across the country.
Choose the right RDS protection model
RDS provides automated backups and manual snapshots, but these have different operational purposes. Automated backups support point-in-time recovery within the configured retention window. Manual snapshots remain until they are deleted, making them useful for release milestones, migrations, and long-term retention.
Cross-Region automated backup replication is available for selected RDS engines and can be suitable when the requirement is continuous protection of a database instance. AWS Backup is often a better fit for central policy management across RDS, EBS, DynamoDB, and other supported services. It provides backup plans, vaults, tagging rules, copy actions, and lifecycle controls from one service.
The choice should follow the recovery design rather than the convenience of a particular console screen. A database with a low recovery point objective may need automated backup replication, while a reporting database with a daily recovery point could use an AWS Backup schedule and cross-Region copy rule.
Build the backup plan and vault structure
Start by creating a backup vault in the primary Region and another in the recovery Region. Use separate customer-managed AWS Key Management Service keys where encrypted snapshots are involved. The destination key policy must allow the AWS Backup service and the appropriate backup role to encrypt copied recovery points.
A practical AWS Backup plan might run every four hours for operational recovery, retain local copies for fourteen days, and copy each recovery point to a second Region. The copy rule can retain the remote snapshot for ninety days or longer, depending on regulatory and business requirements. Tags such as Environment=Production, Application=Payments, and BackupTier=Critical make resource selection and audit reporting easier.
For stronger isolation, place the destination vault in a separate AWS account. Vault Lock can help enforce an immutable retention period, reducing the chance that an administrator or compromised credential can delete recovery points early. This is especially useful where ransomware protection is part of the design.
Define cross-Region lifecycle behaviour
A lifecycle policy should specify when a recovery point expires and, where supported, when it transitions to cold storage. Retention is measured from the creation of the recovery point, so teams should verify how the source backup and copied backup are timed. The destination copy must remain available for the full period required by the recovery plan.
Cold storage can reduce long-term backup costs, but it may introduce a minimum storage duration and retrieval charges. Check current AWS Backup support and pricing for the selected RDS engine before applying the setting broadly. A policy that looks inexpensive on paper can become costly if snapshots are frequently deleted, restored, or retrieved before the minimum period ends.
The lifecycle should also reflect compliance requirements. For example, a financial services workload might retain daily copies for seven years, while a development database may need only seven days. Avoid keeping every snapshot indefinitely “just in case”; uncontrolled retention increases spend and makes recovery testing harder.
Automate deployment with Terraform or the AWS CLI
Infrastructure as code makes backup configuration repeatable across accounts and Regions. A Terraform implementation commonly defines the backup vault, KMS key, IAM role, backup plan, selection rules, and copy lifecycle in one repository. Provider aliases allow the primary and destination Regions to be managed from the same configuration.
The AWS CLI is useful for smaller environments and troubleshooting. Commands such as aws backup list-recovery-points-by-backup-vault and aws backup describe-copy-job help confirm whether recovery points exist and whether copy jobs completed successfully. CloudTrail records changes to backup plans, vaults, keys, and snapshot operations.
Use tags or explicit resource selections rather than relying on a manually maintained list of DB instance identifiers. This allows a newly deployed production instance to receive protection automatically. In a Melbourne or Sydney environment, schedule backups in UTC while documenting the equivalent AEST or AEDT time so local operations teams know when a copy window runs.
Monitor failures and test the recovery path
A successful backup job does not prove that the database can be restored. Create CloudWatch alarms or EventBridge rules for failed backup jobs, failed copy jobs, expired credentials, missing KMS permissions, and vault access errors. Send notifications to the same incident channel used for infrastructure alerts rather than leaving failures buried in the AWS console.
Regular restore tests should create a temporary RDS instance from a cross-Region snapshot. Validate engine version, parameter groups, subnet groups, security groups, Secrets Manager integration, DNS records, and application connectivity. A runbook can then record the elapsed time from selecting the recovery point to accepting application traffic.
Teams operating across Australia may need to test access from Sydney, Melbourne, Brisbane, and remote sites where network paths differ. A database restore is only useful if the application, identity services, and monitoring systems can also operate from the recovery Region. The principles are similar to those used in a VMware stretched cluster: recovery dependencies must be documented and exercised, not assumed.
Control security, cost, and operational access
Grant the backup role only the permissions required to discover protected resources, create recovery points, copy snapshots, and use the relevant KMS keys. Deny destructive actions against the destination vault wherever practical. Cross-account backup ownership and vault policies should be reviewed alongside the organisation’s broader AWS landing-zone controls.
Estimate storage, snapshot copy, KMS, and inter-Region data transfer costs before enabling the policy for large databases. RDS snapshot copies can be substantial, and retained copies across Sydney and Melbourne accumulate quickly. Cost allocation tags and AWS Budgets provide early warning when a policy selects more resources than expected.
Keep the final procedure concise enough for an on-call engineer to follow during a 2 am incident. Include the destination account and Region, approved recovery point, restore command or console path, credentials procedure, validation checks, and escalation contacts. Clear documentation matters as much as the lifecycle rule when production services need to return safely. A small mindful reset can help during stressful incident work, but the technical runbook should remain the authoritative recovery guide.