Working With Amazon RDS Snapshots: How They Work, Costs, and a 2026 Tutorial

An RDS snapshot is the safety net you reach for on your worst day, so it’s worth knowing exactly what it does and doesn’t cover before that day arrives.

The defaults have sharp edges. Automated snapshots disappear the moment you delete the instance. Copying a snapshot to a second region costs money and doesn’t happen on its own. And every restore spins up a brand new instance, never the original in place. None of that is a problem once you know it. It’s a nasty surprise if you don’t.

Here’s how RDS snapshots actually work, what they cost, how to create and copy them, and how to stop managing them by hand.

This is part of a series of posts on database backup methods.

What Is an RDS Snapshot?

An RDS snapshot is a point-in-time, storage-level backup of an entire Amazon RDS database instance. It captures the data and the instance configuration as they were at the moment the snapshot started.

Snapshots live in Amazon S3 that AWS manages for you, separate from your instance. You don’t browse that bucket, and you don’t restore a snapshot in place. Restoring always creates a new DB instance from the saved state, which you then point your application at.

For Amazon Aurora, the equivalent is a DB cluster snapshot, which captures the whole cluster rather than a single instance.

Automated vs Manual Snapshots

RDS gives you two kinds, and the difference matters most at deletion time.

	Automated snapshots	Manual snapshots
Who creates them	RDS, daily, during your backup window	You (console, CLI, API, or a tool)
Retention	0 to 35 days, then aged out	Until you delete them
Survive instance deletion?	No, unless you take a final snapshot	Yes
Support point-in-time recovery?	Yes, with transaction logs	No, restores to the snapshot moment only
Can you delete them manually?	No, RDS manages them	Yes, anytime

The trap lives in row three. Delete an RDS instance and its automated snapshots go with it. If you want a copy that outlives the instance, take a final snapshot on deletion or keep your own manual snapshots.

Automated snapshots also power point-in-time recovery. RDS pairs the daily snapshot with transaction logs, so you can restore to any second inside your retention window. Manual snapshots don’t do that. They restore to the exact moment they were taken.

RDS Snapshot vs Backup: What’s the Difference?

People use the words interchangeably, and mostly that’s fine. A snapshot is a type of backup. The distinction worth keeping straight is scope.

A snapshot is one mechanism: a full, storage-level copy of an instance at a point in time. A backup strategy is the bigger picture, how often you protect the database, how long you keep copies, where those copies live, and how you’d actually recover during a regional or account-level incident.

Snapshots are the building block. The strategy is what you build with them. If you’re working out that side of it (AWS Backup, DR, retention policy, cost), start with our guide to AWS Backup for RDS. This page stays on the snapshots themselves.

How RDS Snapshots Work Under the Hood

The first snapshot of an instance is a full copy. Every snapshot after that is incremental, saving only the blocks that changed since the last one. That keeps storage down and makes later snapshots faster to create.

Incremental doesn’t mean fragile. AWS handles the chaining, so any single snapshot restores to a complete, usable database even after you delete earlier ones in the chain.

Snapshots are tied to the region where they’re created. To protect against a regional event, you copy a snapshot to another region yourself. Same for another account. Neither happens automatically.

What RDS Snapshots Cost

Backup storage is free up to the size of your provisioned database storage in a region. Keep snapshots totaling more than your database size, and AWS bills the overage per GB-month.

So a 500 GB instance gets 500 GB of snapshot storage at no extra charge. Pile up months of manual snapshots past that line and the meter starts running. Cross-region copies are billed separately, including the data transfer to move them and the storage once they land.

This is where hoarding snapshots quietly gets expensive. Old manual snapshots nobody remembers taking are a common line item on a surprised AWS bill.

Tutorial: Creating a Manual RDS Snapshot

In the console:

1. Open the Amazon RDS console and go to Databases.
2. Select the DB instance you want to protect.
3. Choose Actions, then Take snapshot.
4. Give the snapshot a clear name (include the date and purpose, like orders-preupgrade-2026-08-04).
5. Choose Take snapshot.

The snapshot shows as creating, then available. Creating it doesn’t take the database offline for a Multi-AZ instance, since RDS snapshots the standby.

With the AWS CLI:

aws rds create-db-snapshot \

  --db-instance-identifier orders-prod \

  --db-snapshot-identifier orders-preupgrade-2026-08-04

For Aurora, snapshot the cluster instead:

aws rds create-db-cluster-snapshot \

  --db-cluster-identifier orders-aurora \

  --db-cluster-snapshot-identifier orders-aurora-2026-08-04

Take one before any risky change: a major version upgrade, a schema migration, a big data load. It’s the cheapest insurance you’ll buy all week.

Copying and Sharing Snapshots

Copy to another region for disaster recovery:

aws rds copy-db-snapshot \

  --source-db-snapshot-identifier arn:aws:rds:us-east-1:111122223333:snapshot:orders-preupgrade-2026-08-04 \

  --target-db-snapshot-identifier orders-preupgrade-dr \

  --source-region us-east-1 \

  --region us-west-2

If the snapshot is encrypted, the destination region needs its own KMS key, which you pass with –kms-key-id.

Share with another account by modifying the snapshot’s attributes to add the target account ID. Two things to know: automated snapshots can’t be shared directly (copy them to a manual snapshot first), and sharing an encrypted snapshot means sharing access to the KMS key that encrypted it.

One hard rule: don’t make a snapshot public unless it holds nothing you’d mind the whole internet reading. Public means public.

Best Practices for Managing RDS Snapshots

1. Take a manual snapshot before every risky change. Upgrades and migrations are exactly when you want a clean rollback point.
2. Always take a final snapshot when deleting an instance. Otherwise the automated ones vanish with it.
3. Copy critical snapshots to a second region. A regional event shouldn’t be able to reach your only copy.
4. Keep at least one copy in a separate account so an account compromise can’t delete every snapshot.
5. Prune old manual snapshots on a schedule. They don’t age out on their own, and they’re billing you.
6. Name snapshots so the name explains itself. Date and purpose beats snapshot-3.
7. Test a restore now and then. A snapshot you’ve never restored is a hope, not a recovery plan.

Most of this is simple to say and tedious to do by hand across a fleet of databases. That’s the part worth automating.

Automating RDS Snapshots with N2W

Managing snapshot policies by hand gets risky as your database count grows. A missed schedule, an unpruned pile of old snapshots, a DR copy nobody set up. N2W runs inside your own AWS account and takes that work off your plate.

Schedule snapshots with policies. Set frequency, how many generations to keep, and retention once, and N2W runs it. You can snapshot as often as every 60 seconds when a workload needs a tight recovery point, well past the single daily automated window.

Archive to cheaper storage. N2W can move snapshot data incrementally to lower-cost tiers in your own account (S3, Glacier, or Wasabi), which cuts backup storage cost by up to 92% versus keeping everything as standard snapshots.

Copy across regions and accounts automatically. DR copies to another region, and with the right license to another account, run by policy instead of by a script you maintain.

Restore what you actually need. Pick the specific databases to recover from a backup, each from its chosen snapshot, and set the target at restore time: instance class, storage type and IOPS, Multi-AZ, subnet group, port, parameter group, and public access. You can restore into a different account or region for DR. One caveat worth knowing: restoring from outside a VPC into a VPC subnet group works, but the reverse doesn’t.

Make copies immutable. Land snapshots 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 delete.

No scripts, no cron jobs to babysit, no forgotten snapshots on the bill.

RDS Snapshot Retention Options

RDS gives you several ways to control how long backups remain available. Automated backups can be retained for up to 35 days and support point-in-time recovery. Manual snapshots remain until you delete them, making them useful for longer-term retention, compliance, or preserving a database before a major change.

For longer or more flexible retention, N2W can automate snapshot schedules and lifecycle policies across your RDS environments. This makes it easier to keep the right daily, weekly, or monthly recovery points without relying on manual cleanup. It can also help move backup data to lower-cost storage for longer-term retention.

Test RDS Backups Before You Need Them

A backup isn’t much use if you don’t know whether you can restore it successfully. Regularly restore RDS snapshots into a test environment and verify that the database is accessible, the data is consistent, and the application can actually use it. AWS supports restoring manual snapshots into new DB instances, making this practical to test.

N2W can automate recovery testing so teams don’t have to manually restore snapshots and validate them each time. Scheduled testing helps catch backup or configuration problems before a real outage, while also giving teams a repeatable recovery process to rely on.

Frequently Asked Questions

Stop Managing Snapshots by Hand

Snapshots are a solid safety net, right up until managing them across a fleet becomes its own job. N2W automates the schedule, the retention, the cross-region and cross-account DR copies, and the archiving that keeps cost down, all from one console inside your AWS account.

Try N2W free. You can even import and archive any existing RDS snapshots for immediate cost savings.

Related content: Read our guide to RDS snapshots vs AWS Backup.