Enable S3 versioning on critical buckets

Amazon S3 stores objects — files, configuration, application state, Terraform plans, audit logs. By default a bucket has no version history: any overwrite or delete is immediate and permanent. There is no undo and no support escalation that can recover lost data. The continuity check S3-DR-001 flags these buckets at HIGH severity because the business cost of permanent data loss is nearly always far higher than the cost of the control.

S3 versioning keeps every prior copy of each object, indexed by a version-id, for as long as you choose. The storage bill does grow — every overwrite keeps the old copy — but that cost is entirely controllable. A lifecycle rule that expires non-current versions after 30 to 90 days puts a hard ceiling on retained storage, so you get a rolling recovery window without unbounded accumulation. The incremental cost on a well-governed bucket is typically 10-40% of the bucket's baseline storage spend.

The finance framing is a tiering decision with a predictable cost model: identify which buckets hold irreplaceable data, estimate the versioning storage increment (current bucket size × churn rate × retention window), and approve the spend tier-by-tier. The alternative — no versioning — is an unquantifiable tail risk that materialises the moment someone runs the wrong command. Most organisations find the premium trivially small against the data they're protecting.

Priya is the finance partner for the platform team. The continuity report lands with 47 HIGH-severity findings — 47 buckets with no version history. Rather than treat it as a bulk engineering task, she asks the tiering question: which of these 47 hold data that the business could not reconstruct if it were destroyed, and what would that reconstruction actually cost?

The team groups them in thirty minutes using bucket tags and naming conventions. Seven hold genuinely irreplaceable data: production Terraform state, application config, customer-uploaded documents, and audit logs. For those seven, Priya models the versioning increment — average bucket size times estimated churn rate times a 90-day retention window — and finds the total additional monthly storage cost is well under $200. Against the exposure of losing production infrastructure state or customer documents, the spend is trivially justified.

The remaining 40 buckets are data-pipeline staging: re-derived from upstream sources on every run, nothing irreplaceable. The team documents them as intentionally unversioned and suppresses the findings with a recorded reason. Priya's output for the finance review is a one-liner: seven critical buckets now version-protected at $180/month incremental cost; 40 pipeline buckets intentionally unversioned with sign-off. The spend is predictable, the risk is tiered, and both decisions are on the record.

The absence of versioning is a tail risk with a bimodal cost distribution: almost nothing, almost always — then a catastrophic one-time event when the bad command finally runs. The challenge for finance is that a bucket that has never had an incident looks identical on the bill to one that has versioning. The risk is invisible until it materialises.

The cost of a data-loss event on an unversioned bucket is almost always dominated by labour and business impact, not infrastructure. A lost Terraform state file for production infrastructure means days of engineering time to reconstruct it from provider APIs, plus the downstream delays to any infrastructure changes during the recovery window. A bucket holding customer-generated content that is accidentally wiped may have no recovery path at all — the cost is the customer relationship and any regulatory exposure.

The incremental cost of S3 versioning is predictable and modelable. For any bucket, the monthly storage increment is roughly: (average object size × daily write volume × retention days × $S3-per-GB). Pair that with a 90-day lifecycle expiration and the number is bounded. For most production buckets holding configuration or state, the monthly premium runs in the tens to low hundreds of dollars — a fraction of what a single recovery incident would cost in engineering hours alone.

Finance's role here is to push for the tiering decision and the lifecycle rule, not just approval of the versioning toggle. An organisation that enables versioning without a noncurrent-version lifecycle will see storage costs drift upward silently. The right package is both controls deployed together, with the lifecycle window set deliberately based on how long a recovery window the business actually needs.

S3 is where cloud workloads store their state — Terraform configurations, application data, audit logs, customer uploads. Without versioning, any overwrite or delete is permanent. A misconfigured script, a compromised credential, or a single mistaken command can erase data with no recovery path. This control — flagged HIGH severity — asks whether that scenario is possible on your critical buckets.

Versioning flips the default: deletes become reversible and overwrites keep their history. The cost increment is modest and controllable with a retention window. The leadership question is whether data loss from human or automated error is an acceptable business risk, or whether a small recurring storage cost is the right trade. For any bucket holding regulated data, customer records, or infrastructure state the answer is almost always clear.

At one company the VP of Engineering used to answer questions about data recovery with "we rely on S3 durability." That answer protected against disk failure, not against a developer running the wrong delete command — which is the scenario that actually happens. After adopting S3-DR-001 as a tracked control, the answer changed: a short, tiered list showing which buckets had versioning and a rollback window, and which were intentionally unversioned pipeline buckets with a documented reason.

What changed wasn't just the technical configuration. It was that the question "can we recover if someone deletes the wrong thing?" had a specific, defensible answer rather than a vague one. The critical buckets had a 90-day recovery window by policy. The non-critical ones were intentionally unprotected with a recorded justification. The residual risk was visible and owned.

That's the right end state: not versioning on every bucket regardless of cost, but a deliberate tier where the buckets that matter are protected, the ones that don't are documented, and the posture is maintained by a Config rule that fires the moment someone creates an unversioned bucket in a production account.

S3 buckets are where organisations store the things that are hard or impossible to recreate: infrastructure state, customer uploads, compliance records, application configuration. Without versioning, any delete or overwrite is permanent. The question this control asks is whether the organisation is one bad command away from a data-loss incident with no recovery path — and for unversioned critical buckets, the answer is yes.

The HIGH severity rating reflects the asymmetry of the risk. The cost of enabling versioning is small and predictable. The cost of not having it is unbounded and back-loaded — nothing happens for years, and then the one incident where it would have mattered makes the entire saving irrelevant. This is the pattern that belongs on a risk register, not just a security findings dashboard.

The right posture is a deliberate tier: versioning on every bucket that holds data the business cannot reconstruct, a lifecycle window that bounds the storage cost, and a documented decision for every bucket left unversioned. An auditor, a regulator, or a board asking about data recovery capability should get a specific answer — not a reference to S3's hardware durability guarantees.