Protect RDS instances with AWS Backup

When engineers say a database "has backups," they usually mean the automatic daily copy that AWS takes for free. That copy is genuinely useful — it lets the team rewind a database to any moment in the last few weeks. But it has a property nobody mentions until an incident: it lives inside the same account as the database, can't be kept longer than 35 days, and gets deleted the instant the database is deleted. If an attacker, a disgruntled insider, or an automation error removes the database, the built-in backup goes with it. The protection and the thing it protects share a single point of failure.

This finding flags databases that rely only on those built-in backups and aren't enrolled in a centralized backup plan. The fix is cheap insurance: a policy-driven copy that lands in a separate, locked vault — ideally in another account and another Region — and survives even if the original database is wiped. The cost of that protection is modest, typically a few dollars to low tens of dollars per database per month in storage. The exposure it covers is not modest: the cost of a multi-day customer-data outage, a failed audit, or a ransomware event that finds your only backups sitting in the same blast radius as production.

From a risk and budgeting standpoint, the right framing is exposure, not line-item. The relevant question at the operational review isn't "how much does the backup cost?" — it's "what is our exposure if this database and its backups disappear together, and is every regulated database covered by a copy that an attacker or an accident can't reach?" Good looks like 100% coverage of production and regulated databases under a centralized plan, with copies isolated in a separate account. A coverage number below that is a quantified, named risk, not a cost-optimization opportunity.

Sam is the finance partner embedded with the platform team. At the quarterly operational review, the engineering lead reports that "all databases have backups enabled." Sam asks the question that's now standard on the agenda: "How many of our production and regulated databases have a backup copy that survives the database being deleted, and that an attacker in the production account can't reach?" The honest answer is 4 of the 11 are uncovered by the centralized plan — they only have the built-in backups that live in the same account and vanish with the instance.

The conversation that follows isn't technical. Sam doesn't ask about retention windows, snapshot dedup, or KMS keys. She asks three things: which databases hold customer or regulated data, whether each one has an isolated copy in a separate account, and what the recovery story is if the production account itself is compromised. The framing is exposure, not cost — the centralized copies add maybe $40 a month across the whole estate, while the exposure of losing the orders database and its only backups together is a company-ending event and a near-certain audit failure.

Engineering commits to bringing 100% of production and PII databases under the centralized plan with cross-account copy within the sprint. Sam adds "% of regulated databases with isolated, deletion-proof backups" as a standing line on the operational review — not a dollar figure, a coverage percentage. She knows the target is 100% for that tier and that anything less is a named, quantified risk she can put in front of the audit committee, not a cost-optimization opportunity to be traded away.

The spend involved is small and easy to approve — a few dollars to low tens of dollars per database per month for the isolated, long-retained copy. The mistake is treating that number as the thing to optimize. The relevant number isn't the cost of the backup; it's the magnitude of the exposure it covers. For a system of record, the exposure side of the ledger is a multi-day outage, a regulatory penalty, and in the genuine worst case a company-ending data-loss event. No reasonable view of that asymmetry justifies trimming the protection to save tens of dollars.

The exposure is also concentrated and non-diversifiable, which is what makes it a board-level risk rather than a routine cost. A few specific databases — the orders DB, the billing DB, the identity store — carry almost all of the consequence. You cannot average this risk across the estate the way you can with idle compute; one uncovered production database is one uncovered production database, and its loss is not offset by the other ten being fine. That concentration is exactly why the right metric is coverage of the critical tier, expressed as a percentage, with a target of 100%.

There's a compliance and audit-credibility dimension that finance feels directly. When an auditor or regulator asks to see the backup-and-recovery control for regulated data, "we have automatic backups" is no longer a sufficient answer if those backups share an account and a fate with production. An isolated, immutable, tested copy is the evidence that satisfies SOC 2, PCI-DSS, and HIPAA contingency requirements. A documented coverage gap on a regulated database is a finding waiting to happen and a far harder conversation than the spend ever was.

Finally, the coverage percentage is a leading indicator of DR maturity. If production and regulated databases drift below 100% centralized, deletion-proof coverage, it almost always means tagging discipline or the backup-plan-by-default convention is slipping — the same slippage that predicts gaps in EBS protection, cross-Region failover, and recovery testing. Watch the regulated-tier coverage number as a signal of whether continuity engineering is actually keeping pace with the estate, not as a cost to be minimized.

Databases are where the business keeps the record that matters — customers, orders, transactions, regulated data. The default "automatic backup" AWS provides lives in the same account as the database and is deleted the moment the database is deleted. If a single compromised credential or operator error removes the production database, the safety net goes with it. That is a continuity risk hiding behind a feature everyone assumes is sufficient.

Closing this gap is inexpensive and largely a policy decision: keep an isolated, immutable copy of every important database in a separate account and Region, retained long enough to satisfy auditors and ransomware-recovery scenarios. The headline isn't the cost of the backups — it's whether the company could still recover its system of record after a worst-case event. A coverage gap here is one of the cleanest signals that disaster-recovery posture is aspirational rather than real.

At one company, the disaster-recovery section of the board pack used to say "automated database backups: enabled." Technically true, and quietly misleading — those backups lived in the same account as production and would be gone in any scenario where production itself was lost. The exec sponsor stopped accepting "backups: enabled" and started asking a sharper question: "If someone deleted our production account tomorrow, could we still recover the customer database?"

Within a quarter the answer changed from "probably not" to "yes, within hours, from an isolated copy in a separate account in another Region." The board pack line became "100% of regulated databases have an immutable, off-account backup copy, tested quarterly." The cost of getting there was trivial against the spend; the value was that the continuity claim was now true rather than aspirational.

That's the right outcome state. The goal isn't "backups are on" — it's "every system of record has a recovery copy that survives the loss of the environment that holds it." Coverage of the regulated tier becomes a confidence signal at the leadership review, not a recurring action item.

The cost in this category is trivial; it's tracked because of what a gap exposes. Databases hold the system of record, and the default backup that everyone assumes is sufficient shares an account and a fate with the thing it's supposed to protect. A coverage gap on a production or regulated database is a concentrated, non-diversifiable continuity risk — the kind where a single event (a compromised credential, an operator error, a ransomware payload) can take both production and its only safety net at once. That is precisely the scenario that ends companies, so it belongs on the risk register, not buried in a cost report.

There's a regulatory and reputational dimension too. Demonstrable, isolated, tested database backups are an explicit expectation under SOC 2, PCI-DSS, and HIPAA, and increasingly the specific control auditors probe as ransomware-recovery scrutiny intensifies. A known, documented gap on a regulated database is worse in an audit than the spend was ever going to be. So this sits at the intersection of business continuity, security posture, and compliance — and the leadership question is whether the company could still recover its system of record after losing the environment that holds it.