Protect DynamoDB tables with AWS Backup

DynamoDB tables often hold the most business-critical data an application owns — orders, sessions, balances, customer records. Engineers will tell you the table has "continuous backups" turned on, and that's true: Point-in-Time Recovery lets them rewind the table to any moment in the last 35 days. The catch is that this recovery data is part of the table. If the table itself is deleted — by accident, by a compromised credential, or by an attacker — the recovery option is deleted with it. There is no second copy stored somewhere safe.

This finding flags tables that have no copy held in a separate, protected location — no AWS Backup plan. The exposure isn't a monthly dollar amount on the invoice; it's the cost of the day the data is gone and there is no path back. For regulated data, it's also a standing audit problem: most compliance regimes require demonstrable backups that are isolated from the production system and retained for years, and the 35-day in-table window satisfies neither requirement.

The right framing is risk versus the cost of protection. Bringing a table under AWS Backup is inexpensive — a few cents per GB-month of backup storage in a separate vault. The exposure it removes is the worst-case loss of the data the business runs on, plus the audit finding that lands the moment a regulator asks "where is your isolated, long-term backup of this table?" This is a coverage-gap signal, not a spend-waste signal: the question to ask is which critical tables are not yet protected, and why.

Sam is the finance partner embedded with the payments platform team. At the operational review, the engineering lead presents resilience metrics and Sam asks the question that's now standing on the agenda: "What percentage of our business-critical and regulated DynamoDB tables are covered by an isolated backup, not just the in-table recovery window?" The dashboard shows 18 tables flagged with no AWS Backup coverage — and one of them is the transaction ledger.

The conversation isn't technical. Sam doesn't ask about retention windows or vault mechanics. She asks three things: which of the flagged tables hold regulated or business-critical data, what the cost of protecting them is, and whether anyone has ever actually restored from a backup to prove it works. The answers are quick — the ledger and four others are clearly critical, the protection cost is a few dollars a month each, and no, the restore has never been tested. That's enough to act. Engineering commits to covering the critical tables this sprint and running a test restore; Sam adds coverage percentage as a recurring line on the resilience pack.

A month later the dashboard shows 100% coverage on the critical and regulated tier, with a dated, successful test restore on record. Sam knows that's the right state — not every ephemeral or cache table needs an isolated backup, but every table the business actually depends on does. The dollar cost was never the point; the coverage gap was a business-continuity exposure, and now it's closed and auditable.

The line-item cost of protecting a DynamoDB table is trivial — a few dollars a month per table for backup storage in a separate vault, with cold-storage tiers bringing long-term retention down to pennies per GB. This is not a spend-waste category; protecting these tables will barely register on the invoice. The number that matters here is exposure, not cost.

The exposure is asymmetric and catastrophic. For most categories of cloud risk, the downside is a percentage of spend. For an unprotected critical table, the downside is the complete, unrecoverable loss of data the business runs on — orders, balances, customer records — in a single deletion event, with no path back because the in-table recovery window died with the table. You can't budget your way out of that after the fact; the only mitigation is the cheap protection bought in advance.

There's a standing compliance cost too. Auditors for SOC 2, PCI, HIPAA, and GDPR expect isolated, long-term backups of regulated data. A table with only PITR fails that test on two counts — the backup isn't isolated from production and it isn't retained long enough. An audit finding here triggers remediation work, possible penalties, and in regulated industries can stall a deal or a certification. The cost of preventing the finding is a few dollars a month; the cost of explaining it to an auditor is measured in weeks of effort and reputational risk.

Finally, coverage percentage is a leading indicator of operational discipline. If critical tables are slipping through without backup coverage, it usually means provisioning happens without a protection checklist, and that same gap tends to show up across other resilience controls. Watch the coverage number on the resilience pack: 100% on the critical and regulated tier is the target, and any sustained gap is a prompt to ask why protection isn't a default at creation time.

Some of the most important data the business owns lives in DynamoDB tables. The team will say it's backed up — and in a narrow sense it is, for the last 35 days. But that protection lives inside the table and disappears the instant the table is deleted, whether by mistake or by an attacker. A second, isolated copy in a separate vault is what actually survives that event, and this finding is about which critical tables don't have one.

This is a business-continuity question, not a cost question. The exposure is the inability to recover core data after a deletion event, and the regulatory finding that follows. The protection is cheap; the gap is expensive only once, and catastrophically. What "good" looks like is simple: 100% of business-critical and regulated tables covered by an isolated, long-term backup, verified by a real restore.

At one payments company, the quarterly resilience review used to include a line that said "DynamoDB: continuous backups enabled." Everyone read that as "covered" and moved on. Then a near-miss — a destroy command aimed at the wrong environment — made it clear that the in-table window would have vanished with the table. The exec sponsor changed the question from "are backups on?" to "for our critical tables, do we have a copy that survives the table being deleted, and have we proven we can restore it?"

Within a quarter the metric on the slide changed. It was no longer "backups enabled" but "100% of business-critical and regulated tables covered by an isolated, long-term backup, with a tested restore on record this quarter." The cost was trivial; the change was in what the org chose to verify. The exec hadn't asked the team to spend more — she'd asked them to prove the recovery path existed before they needed it.

That's the right outcome state. The goal isn't "back up every table" — ephemeral and cache tables don't warrant it. The goal is full coverage of the data the business runs on, plus a restore that's actually been run. The resilience report stops being a checkbox and becomes a confidence signal.

The cost of fixing this is negligible, so it isn't a spend item — it's a continuity item. It's on the report because an unprotected critical table is a single point of failure for data the business depends on: one deletion event, accidental or malicious, and the data is gone with no recovery path that survived the event. The size of the coverage gap tells you how exposed the business is to that scenario right now.

There's a second-order signal in the trend. Full coverage of critical tables, with a restore that's actually been tested, means the org provisions data stores with protection built in and verifies its recovery paths — the hallmark of a mature operation. A persistent gap means new critical data is going live without that discipline, which is the same pattern that produces audit findings and security exposure. Most CFOs care about the regulatory side, most CIOs about the recoverability; both should care that the coverage number is 100% and proven.