AWS RDS backs up daily by default; a tested restore is separate

The workload

A managed database that loses data — from a bad deploy, a bug that deletes rows, or an operator mistake — needs a way back to a known-good state, and testing that path before it is needed is different work from turning a setting on. AWS's documentation on RDS automated backups describes the mechanism: RDS snapshots storage during a backup window and separately uploads transaction logs, letting a database be restored to any point within a retention window the operator sets. Turning the feature on is a setting; verifying the backup can actually be restored is the separate task this documentation does not perform for you.

What the documents show

AWS's CLI reference for creating a DB instance states, verified, that the backup-retention-period parameter has a 'Default: 1' with 'Constraints: Must be a value from 0 to 35' — a database created without an explicit setting retains one day of backups, far short of the 35-day maximum, unless raised. The user-guide backup page states, verified, that RDS 'saves the automated backups of your DB instance according to the backup retention period that you specify' and 'you can recover your DB instance to any point in time during the backup retention period.' A page on restoring to a point in time states, verified, that 'RDS uploads transaction logs for DB instances to Amazon S3 every five minutes,' making recovery to a specific moment, not just the last snapshot, possible; restoring creates a new DB instance rather than modifying the source.

The operating cost

RDS backup storage up to the database's size is included at no extra charge on most instance classes, per AWS's separate pricing page; storage beyond that, and snapshots kept after deletion, are billed there instead. The higher cost is labor: the documentation distinguishes a backup from a verified restore only by describing the mechanism, not by testing it, so someone still has to periodically run an actual restore and confirm the result is usable, work no setting here automates.

The stop condition

Neither document claims an automated backup equals a tested restore. This is an editorial stop condition: the backup workload is complete for a given release, not permanently, once retention is raised above the 1-day default to match how far back the business needs to recover, and once a real point-in-time restore has run against a non-production target with the result confirmed correct — a task that should repeat, since a restore that worked once can silently break after a schema change.

• Has the backup retention period been raised above AWS's default of 1 day, and does it match how far back this business actually needs to recover?
• When was a restore from an automated backup last actually attempted, not just assumed to work?
• Who is responsible for running that test, and how often does it actually happen?

AWS's own documentation is specific about what its backup mechanism guarantees — a retained, restorable point-in-time image, on a default and maximum window it states directly — and equally specific, by omission, about what it does not do: prove a restore actually works before the day it is needed.