When you delete an RDS database instance, manual snapshots are retained unless you explicitly delete them. If the source instance is gone but the snapshot remains, you continue paying snapshot storage with no running database attached — the RDS equivalent of an orphaned EBS snapshot.
Parsivex flags manual snapshots whose source DB instance identifier no longer appears in your account inventory, are at least 7 days old (to avoid flagging snapshots taken just before an intentional migration or deletion), and have status available.
Before you delete
- Confirm the snapshot is not required for disaster recovery, compliance retention, or audit obligations.
- Check internal runbooks and backup policies — teams sometimes keep manual snapshots after instance teardown for a defined retention window.
- Unlike EBS snapshots, AWS does not provide a native API to verify whether an RDS snapshot is referenced by another resource (there is no AMI-style cross-reference). Coordinate with the team that owned the database before deleting.
- Deletion is irreversible — restore to a new instance is only possible while the snapshot exists.
Paid plans include remediation scripts with a delete-db-snapshot command. AWS RDS does not support --dry-run for snapshot deletion — review the command carefully before running it.
What triggers this finding
A manual RDS snapshot whose source database instance no longer exists in the account.
Typical fix
Delete snapshots that are no longer required for compliance or disaster recovery.
Example savings
Roughly $0.095/GB-month — scales with snapshot size (e.g. a 100 GB snapshot costs about $9.50/month).
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
Snapshots that never expire, on storage that is never free
Two properties of RDS manual snapshots combine to make this finding a slow leak rather than a one-off cost.
The first is that manual snapshots have no retention period. Automated backups are governed by a retention window and are deleted with their instance; a manual snapshot has no expiry field at all, and AWS will keep it until somebody issues a delete. A snapshot taken in a hurry before a decommission in 2022 is still there, still billing, and nothing in the platform will ever prompt about it.
The second is that a manual snapshot is a full backup of the source volume, not a member of an incremental chain. This is the sharpest difference from the orphaned EBS snapshot case, where twenty snapshots of one volume share their unchanged blocks and the total is far smaller than the sum of the parts. Ten manual RDS snapshots of the same database are ten full copies. It also makes the estimate here far more trustworthy: Parsivex prices the snapshot at its source instance's allocated storage multiplied by $0.095 per GB-month, and for a full backup that is close to what AWS actually charges.
The free allowance is the third piece, and it is the reason orphans cost more than they look. AWS gives an RDS instance backup storage equal to 100% of its provisioned storage at no charge — but that allowance belongs to the instance. When the instance is deleted, the allowance goes with it, and the snapshots that were previously absorbed by it start billing from the first gigabyte. A pile of snapshots that cost nothing while the database was alive becomes a line item the moment it is torn down.
Listing manual snapshots
aws rds describe-db-snapshots --snapshot-type manual \
--query 'DBSnapshots[].[DBSnapshotIdentifier,DBInstanceIdentifier,AllocatedStorage,SnapshotCreateTime,Status]' \
--output table
Cross-reference the DBInstanceIdentifier column against your live instances:
aws rds describe-db-instances \
--query 'DBInstances[].DBInstanceIdentifier' --output text
Any snapshot whose source identifier is missing from the second list, is available, and is at least 7 days old is what Parsivex reports. Automated snapshots are never included — they are managed by the retention policy and cannot be deleted individually anyway.
Identifiers that lie about lineage
The detector matches on the source instance identifier, which is a string rather than a durable reference, and several ordinary operations break the link without deleting anything.
- Renamed instances. Renaming a database changes its identifier. Every snapshot taken under the old name now points at an instance that no longer exists by that name, while the database itself is alive and serving traffic.
- Cross-region and cross-account copies. A copied snapshot carries the source identifier from wherever it came from. A deliberate disaster-recovery copy sitting in a second region is orphaned by definition and will be reported on every scan.
- Region scope. Parsivex evaluates the region it is scanning. A snapshot whose source instance lives in another region has no local match.
- Pre-upgrade rollback points. A snapshot taken before a major version upgrade, kept in case the upgrade needs reverting, where the original instance was replaced rather than upgraded in place.
- Retention and legal hold. The most common case by far: the database was decommissioned and the snapshot is the deliberate record of it, held under a policy nobody has written into a tag.
Because there is no equivalent of the AMI cross-reference that guards EBS snapshots, none of this can be checked automatically. Tagging snapshots with an owner and a review date at the moment they are taken is the only thing that makes the decision cheap later.
Deletion, and the one alternative
delete-db-snapshot is irreversible, and restoring is the only way to read a snapshot's contents — you cannot mount it, inspect it, or restore it into an existing instance. A restore always produces a new database with a new endpoint, sized from the snapshot's allocated storage, and it bills as a running instance from the moment it starts. Verifying that a snapshot contains what you think it does is therefore not free, which is exactly why so many of these accumulate unexamined.
There is no cold tier to fall back on. RDS has no equivalent of EBS Snapshot Archive, so a snapshot cannot be moved to cheaper storage in place — the choices are keep it at $0.095 per GB-month or delete it.
Where the data must be retained but will realistically never be restored, exporting the snapshot to Amazon S3 is the genuine middle path. The export writes the database contents as Parquet into a bucket you control, where it can sit under S3 lifecycle rules at a fraction of snapshot storage pricing and remain queryable through Athena. The trade is that the result is no longer a restorable database — recovering an instance from it means rebuilding rather than restoring. For a compliance archive that is usually the right shape; for a rollback point it is not.