Enable DynamoDB point-in-time recovery

DynamoDB is the database behind many of the application features customers touch every day. When engineers say the data is "highly durable," that's true — it's copied across three data centers automatically. But durable is not the same as recoverable. If a software bug or a mistaken command corrupts or deletes the data, the platform dutifully preserves the corrupted version. Without a recovery feature turned on, there is simply no way to go back to how the data looked before the mistake.

Point-in-Time Recovery is that feature. Turned on, it keeps a rolling 35-day rewind capability so the team can restore the table to any second before an incident. The cost is modest and predictable — it scales with how much data the table holds, not with how busy it is, at roughly twenty cents per gigabyte per month. For most tables that is single-digit to low-double-digit dollars a month. The thing it protects against — losing or corrupting the live data behind a customer-facing service — is open-ended: lost revenue, breached SLAs, regulatory exposure, and engineering time spent reconstructing data by hand.

This finding is therefore best read as a risk-and-coverage signal, not a cost line. The dollar amount of enabling PITR is trivial; the dollar amount of not having it during an incident is not. A table without PITR is an uninsured asset. The right framing at a review is not "what does this cost" but "what is our recovery coverage across the production tables, and which ones are exposed."

Dana is the finance partner embedded with the platform team. At the monthly operational review the reliability lead is walking through continuity findings, and Dana asks the question that's now standard on her agenda: "What's our PITR coverage on production DynamoDB tables, and which ones are exposed?" The answer is 16 of 18 production tables covered — two gaps, both customer-facing.

The conversation isn't technical. Dana doesn't ask about restore mechanics or backup internals. She asks three things: what would it cost to close the two gaps, what's the exposure if one of those tables is corrupted, and why they weren't covered already. The cost answer is about $25 a month for both; the exposure answer is "the live orders data behind the checkout flow, unrecoverable." That asymmetry makes the decision instantly — close the gap this week, and add PITR-on-create to the table-provisioning standard so new tables arrive covered.

The number Dana tracks from then on isn't a dollar figure — it's coverage as a percentage of production tables. She wants to see 100%, and she wants to know the moment a new table lands without it, because that's the leading indicator that the provisioning standard is slipping. The cost of PITR never comes up again; it was never the point.

The cost of PITR is small, predictable, and proportional to data size rather than activity — roughly $0.20 per GB-month. For a typical production table that's single to low-double-digit dollars a month, and across a whole estate it's a minor, stable line you can forecast precisely. It will never be the reason a cloud budget misses. So the interesting question this finding raises is not about cost at all.

The interesting question is exposure. An unprotected table behind a customer-facing service is an uninsured asset: the moment its data is corrupted or deleted, the loss is open-ended — lost revenue while the service is down, SLA penalties, breach-disclosure and legal costs if it's regulated data, and the engineering hours spent reconstructing records by hand. Set the certain, trivial cost of protection next to the uncertain, potentially severe cost of an incident and the decision makes itself. This is insurance, and the premium is negligible.

There's a compliance dimension too. SOC 2, PCI DSS, and most enterprise customer contracts require demonstrable backup and recovery for systems of record. A production database with no recovery path is a finding waiting to be raised — by an auditor, or worse, by a customer's security review during a deal. The cost of that finding, in remediation scramble and deal friction, far exceeds the cost of simply having had the feature on.

The metric to carry into the operational review is coverage, expressed as a percentage of production tables with PITR enabled. The target is 100%. Watch the trend: a coverage number that slips after being at 100% means new tables are arriving without the protection standard applied, which is exactly the kind of drift that's cheap to fix now and expensive to discover during an incident.

DynamoDB is a core database behind many products. It keeps the data extremely safe from hardware failure — but "safe" is not the same as "recoverable." If a bad deploy or a human error corrupts or deletes the live data, the only thing that brings it back is a recovery feature that has to be switched on in advance. It is off by default, and switching it on costs almost nothing.

This is a business-continuity control, not a cost item. Every table without it is a production system with no undo button — one mistake away from data loss the business cannot reverse. Full coverage on production tables is cheap insurance; a gap in coverage is the kind of single point of failure that turns a routine engineering mistake into a customer-facing incident.

At one company the quarterly continuity review used to surface a recurring item: "N production databases with no point-in-time recovery." The number bounced around — sometimes two, sometimes five — because new tables kept arriving without it. The exec sponsor stopped asking how many and started asking why any: "Why would we ever stand up a customer-facing database with no way to undo a mistake?"

Within a quarter the answer changed. PITR became a non-negotiable default in the provisioning standard, the gap closed to zero on production, and a quarterly restore test proved the recovery actually worked. The continuity slide stopped being a list of exposures and became a single green line: "100% PITR coverage on production, recovery verified." The exec hadn't asked anyone to chase a cost — she'd asked them to close a single point of failure, and the cost turned out to be immaterial.

This isn't a cost item; it's a single-point-of-failure item. Every production database without point-in-time recovery is a system where one mistake — a bad deploy, a human error — can destroy live customer data with no way to undo it. The cost to remove that failure mode is immaterial. The cost of hitting it is an outage, lost or corrupted customer data, and the reputational and contractual fallout that follows.

So the size of this finding isn't measured in dollars; it's measured in exposure. A clean report means every customer-facing database can be rewound to before a mistake. A gap means at least one cannot. This sits squarely at the intersection of reliability, customer trust, and audit posture — and the fix is one of the cheapest insurance policies in the entire cloud estate.