Your RDS instance is usually the last thing you want to explain in an incident review. It holds the data the business actually runs on, and the backups feel handled right up until the moment you need to bring a database back in a different region, or a different account, faster than the default daily window allows.
That gap between “backups are running” and “I can recover the way I need to” is where most RDS backup strategies quietly break. It comes up constantly with teams running production databases on RDS: the native tools cover the easy case and leave the hard one to you.
Here’s how AWS backs up RDS, where the native approach runs out of road, and how to close the gaps.
This is part of a series of posts on database backup methods.
What Is Amazon RDS, and Why Backup Matters
Amazon RDS is AWS’s managed relational database service. It runs MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora, and it handles patching, failover, and the underlying infrastructure so your team doesn’t have to.
Managed doesn’t mean protected. AWS runs the service. You still own the data, the recovery plan, and the consequences of getting it wrong. RDS sits under applications where an hour of lost transactions is a real number on a real invoice, so the backup question is less “are snapshots running” and more “can I meet my RTO and RPO when a whole region or account is the problem.”
What AWS Gives You Natively
RDS ships with two backup mechanisms before you add anything on top.
Automated backups. RDS takes a daily snapshot during your backup window and captures transaction logs through the day. Together they give you point-in-time recovery (PITR) to any second inside your retention period, which maxes out at 35 days. Delete the instance and, by default, the automated backups go with it.
Manual snapshots. You (or a script) trigger a full snapshot that lives until you delete it. These survive instance deletion and are what you copy around for longer retention or cross-region durability. For the mechanics of creating, copying, sharing, and pricing snapshots, see our guide to working with Amazon RDS snapshots.
For a single database in a single account, that covers a lot. The trouble starts when your recovery requirements cross a region, an account, or a retention boundary.
How AWS Backup Integrates with RDS
AWS Backup is the central service AWS points you to for policy-based management across services. Here’s the workflow for RDS.
When a backup runs through AWS Backup, it checks for existing RDS automated backups. If one exists, it creates an incremental snapshot by copying the most recent automated backup with the copy-db-snapshot operation. If none exists, it takes a fresh snapshot with create-db-snapshot. The first snapshot is always full, and later ones are incremental, which keeps storage cost down.
One thing to watch: your AWS Backup window can’t overlap the backup window RDS sets for its own automated backups, or the jobs collide.
Where Native RDS Backup Leaves You Exposed
AWS Backup centralizes management, and it’s a real step up from hand-rolled scripts. But several limits show up fast once you have production databases and a DR requirement.
Instance-level only. AWS Backup treats an RDS backup as a full DB snapshot of the whole instance. There’s no per-database backup or restore inside an instance, and no native SQL Server differential or transaction-log backup through AWS Backup. If you need granular, engine-native restores, the native path won’t give them to you.
Cross-account is painful. RDS automated backups don’t cross account boundaries at all. Getting a recoverable copy into a separate account (the thing you actually want when ransomware or a compromised account is the scenario) means AWS Organizations setup, backup vaults, KMS key sharing, and copy jobs you build and babysit yourself.
Cross-region adds cost and moving parts. Copying snapshots to a second region for DR is doable, but you own the automation, the lifecycle, and the bill for every copy sitting in every region.
Retention and PITR are boxed in. Automated-backup retention caps at 35 days, and PITR only works inside that window and inside the source region. Longer retention means manual snapshots you manage on your own.
Snapshots aren’t immutable by default. A snapshot an attacker (or a bad script) can delete isn’t a recovery plan. Building genuinely isolated, tamper-resistant copies is on you.
RDS Backup Best Practices
The fundamentals still matter regardless of tooling.
- Turn on automated backups and set retention to match your recovery needs, not the default.
- Schedule backup windows during low-activity periods so the I/O hit lands when it’s cheapest.
- Copy snapshots to a second region so a regional event doesn’t take your only copy with it.
- Keep at least one copy in a separate account so an account-level compromise can’t reach every backup.
- Test restores on a schedule. A snapshot you’ve never restored is a guess, not a backup.
- Take manual snapshots before risky changes (major version upgrades, schema migrations).
- Match retention to your compliance obligations, and document it.
Most of these are easy to say and tedious to run by hand across a fleet. That’s the real problem N2W solves.
How N2W Protects RDS
N2W runs as software inside your own AWS account and drives backup and recovery through native AWS APIs. It’s agentless for RDS, and your data never leaves your account. Here’s what that looks like in practice.
Policy-based backup and retention. You build a backup policy that includes your RDS databases, both standard RDS and RDS Custom. The policy sets how often backups run, how many generations to keep, how long to retain them, and whether N2W makes DR copies. One policy can cover RDS alongside your EC2, EBS, Aurora, and Redshift resources, so the whole environment follows the same schedule instead of a pile of per-service settings.
High-frequency schedules. N2W can run snapshot backups as often as every 60 seconds, so you’re not locked to a single daily automated-backup window when the workload needs a tighter RPO.
Restore with full control over the target. When you recover an RDS database, N2W restores from the snapshot and lets you set the important knobs at restore time:
- DB instance ID and instance class
- Storage type and provisioned IOPS
- Multi-AZ or single-AZ
- Subnet group and port
- DB parameter group
- Public accessibility
- Which AWS credentials and account to restore into
So you can recover to a right-sized instance in the right network, not just a clone of the original.
Cross-region and cross-account DR. With DR enabled, N2W copies RDS snapshots to other regions, and with the right license and setting, to other accounts. That’s the RDS recovery case native backups can’t do on their own, handled by policy instead of by a script you maintain. (When you restore into a different account, make sure the destination subnet groups exist first, or the job fails.)
Aurora and RDS Custom support. Aurora is covered, including AWS’s behavior of copying resource tags onto snapshots. RDS Custom recovery is supported too, with a bit of extra IAM permission setup.
Immutable, air-gapped copies. N2W can land copies in storage you own with S3 Object Lock enabled, in a separate account or region, so a copy exists that a compromised production account can’t reach or delete. True air-gap here means cross-account or cross-cloud isolation, not a second copy sitting next to the first.
Lower storage cost. By archiving incrementally to cheaper tiers in your own account (S3, Glacier, Wasabi) with lifecycle automation, N2W cuts backup storage cost by up to 92% versus keeping everything in standard snapshots.
Disaster recovery testing – by automating restore validation, DR drills, and metadata recovery, N2W allows you to coordinate multi-target recovery scenarios for both Amazon RDS databases alongside EC2 instances and other AWS resources .
A couple of honest edges worth knowing: recovering a PostgreSQL RDS database from S3 won’t restore user passwords (an AWS limitation), so the database comes back under the RDS admin login and you reset the rest. And some private MySQL user metadata may not carry over on an S3 restore. Neither affects normal database use, but you should know before you plan a restore runbook around it.
Where N2W Wins vs the Alternatives
Against native AWS Backup, the difference is cross-account and cross-region DR copies by policy, immutable copies in storage you control, tighter backup frequency, and real storage savings, without building and maintaining the plumbing yourself.
Against the big suites like Veeam, Rubrik, and Commvault, N2W’s edge is cloud-native specificity and cost. It’s purpose-built for AWS and Azure, runs entirely inside your account, and doesn’t carry the licensing weight or general-purpose sprawl of tools that started on-premises. If your problem is protecting cloud databases well and cheaply, that focus shows up in both the setup time and the invoice.
N2W isn’t an on-prem VMware replacement, and it’s honest about the snapshot model it’s built on. What it does is take the RDS recovery scenarios that native tooling makes you assemble by hand and turn them into a policy you set once.
Related content: Read our guide to RDS snapshots vs AWS Backup.
Frequently asked questions
RDS gives you automated daily backups with point-in-time recovery and on-demand manual snapshots. For cross-region, cross-account, or higher-frequency protection, you add a tool like AWS Backup or N2W that manages snapshots and DR copies by policy.
PITR comes from RDS automated backups, which recover to any second within your retention window (up to 35 days) in the source region. AWS Backup manages snapshot-level backups on top of that, but PITR itself stays bound to that window and region.
RDS automated backups run once daily. With N2W’s policy scheduling, you can run RDS snapshot backups as often as every 60 seconds when the workload needs a tighter RPO.
Yes. RDS automated backups don’t cross accounts on their own, but N2W (with DR enabled) copies RDS snapshots to other regions, and with the right license to other accounts, driven by policy.
Keep a copy in storage you own with S3 Object Lock enabled, in a separate account or region. N2W automates that copy and the lock, so an isolated, tamper-resistant backup exists outside your production account.
Yes to both. Aurora is supported (including AWS copying resource tags onto snapshots), and RDS Custom recovery is supported with some additional IAM permissions.
Protect RDS the Way You Actually Need To
Native RDS backups are fine until recovery has to cross a region, an account, or a retention limit. N2W handles those cases by policy: high-frequency backups, restore-time control over the target instance, automated cross-region and cross-account DR, and immutable copies in storage you own, all from one console inside your AWS account.
