Configure backups and retention

Most of this capability is effectively free. RDS includes backup storage up to the size of the database at no charge and bills only the excess at a low rate, DynamoDB PITR adds a small per-gigabyte charge, and turning a public snapshot private costs nothing. The one place with a real, predictable price tag is extended Kinesis retention, which bills per shard-hour beyond the included 24 hours, but even there the number is usually single-digit to low-hundreds of dollars a month and is easy to forecast up front.

Frame each failing control as a risk position, not a cost saving. A production database with backups disabled, or a table with no PITR, is the cloud equivalent of cancelling the insurance to lower the premium: the line item goes down and the exposure goes up by orders of magnitude. The right response to a backup finding is almost never to optimise the spend down; it is to confirm the coverage exists everywhere it matters and to record any genuine exceptions (a disposable dev store) as deliberate, owned decisions.

The downside it protects against is the kind of event that does not show up on the cloud bill until it happens: engineering hours reconstructing records by hand, customer remediation, regulatory penalties for losing data you were obligated to retain, and audit findings that delay enterprise deals. Backup and recovery controls are table stakes in SOC 2, ISO 27001, PCI DSS and most customer security questionnaires, so a clean set across the estate protects the revenue pipeline as much as the data.

Priya is the finance partner reviewing the weekly compliance pack. Security Hub shows a dozen backup failures across RDS, DynamoDB and Kinesis in three accounts, plus a couple of EBS snapshots flagged as shared publicly. Her instinct is the opposite of her usual cost reflex: this is not a line to optimise down, it is coverage to confirm exists. Enabling recovery is nearly free on almost every service, so the spend question is narrow, only Kinesis extended retention carries a real per-shard-hour charge, and that is single-digit to low-hundreds of dollars a month and easy to forecast.

She asks the team to map each finding to the data behind it. A production orders database has backups disabled outright, a billing database sits below the seven-day floor, an analytics table has PITR off, and the dev-scratch instances can be documented as exceptions. The public snapshots are a separate, urgent class: a backup shared with all accounts is a public copy of the data, not a recoverability gap. Priya reframes the pack as a coverage position rather than a cost saving: 'Recovery is effectively free to switch on, and the dollars saved by leaving it off are trivial against an open-ended data-loss bill, engineering hours reconstructing records, customer remediation, regulatory penalties, stalled enterprise deals. The right response is 100% coverage on production data stores, zero public snapshots, and a recorded owner for any genuine dev exception.'

The cost model here is asymmetric in a way that is rare for security work. Enabling recovery is nearly free for almost every service (RDS includes backup storage up to the database size, DynamoDB PITR is a small per-gigabyte charge, making a snapshot private costs nothing), and the one charge with a real price tag, Kinesis extended retention, is predictable per shard-hour and easy to scope to the streams that matter. The dollars saved by leaving backups off are tiny; the downside they expose is open-ended.

The documented cost of a data-loss event includes engineering hours reconstructing records by hand, customer remediation and goodwill, regulatory penalties for losing data you were obligated to retain, and audit findings that delay certifications and stall enterprise deals. Against that, remediation is near-zero cost. The finance role is to take backup storage off the cost-cutting table, track recoverability as a coverage percentage rather than a dollar figure (the target is 100% of production data stores), and require a recorded, owned reason for any genuine exception rather than a silently suppressed finding.

Every data store in the estate can be configured to back itself up and keep a rolling window of history, so an accidental delete, a bad migration or a ransomware event becomes a quick restore instead of a permanent loss. The report shows this as a scatter of separate findings across databases, tables, streams and file systems, but the underlying question is one: if data is lost or corrupted tomorrow, can we get it back?

This is overwhelmingly a resilience and compliance issue, not a cost one. The cost of keeping recovery on is trivial for almost every service, and the cost of not having it is a data-loss or downtime event the business may not survive intact, plus a control failure auditors and customers will ask about. The healthy end state is simple to state: every production data store is recoverable to a defined window, no backup is shared publicly, and any exception is signed off in writing.

The leadership question is binary and one-minute: can we restore every production data store? A standing yes is cheap insurance. The first no is the most important thing on the page that day.

After a migration script dropped the wrong table on a production database that, it turned out, had been carrying a backup retention period of zero inherited from a tutorial template, the only restore point was a manual snapshot someone had taken by luck six weeks earlier. The reconstruction effort ran for days. At the next review the CEO asked the binary question the incident had made unavoidable: can we restore every production data store, and is any backup shared publicly?

The honest answer at the time was no on both counts, because recoverability had been inherited from copied templates rather than set as a standard. The team's response was to declare a recoverability floor as policy: every production data store recoverable to a defined window, no backup shared publicly, and any exception signed off in writing by a named owner. They set the floor and PITR-on in the infrastructure-as-code modules so new resources arrive protected, turned on account-level EBS snapshot block-public-access as a backstop, and backed it with Config rules so the posture cannot drift. The next time the question came up, the answer was a standing yes on recoverability and a standing no on public snapshots, cheap insurance against the kind of event that does not show up on the bill until it happens. The shift from relying on whoever copied the template to a stated, owned standard is the one-line confidence signal this control delivers.

A production data store that cannot be restored is a single point of catastrophic failure, and these controls surface every one of them. The reason it is tracked at the leadership level is not its cost, which is trivial, but its consequence: on a bad day an unrecoverable data store is the difference between a brief incident and a business-threatening data-loss event, plus a control failure that customers and auditors will hold against you.

It also reads as a discipline signal. A failing backup control almost always traces back to a copied template, an unowned resource, or a gap between the team that flags risks and the team that owns the fix, the same root causes behind larger resilience gaps that do not surface as cleanly. A clean set of backup controls, including no publicly shared snapshots, is cheap evidence that the basics of recoverability are taken seriously across the estate.