Protect EBS volumes with AWS Backup

EBS volumes hold the persistent data behind your EC2 fleet: databases, application state, audit logs, anything that costs money to recreate or is simply irreplaceable. AWS replicates each volume within one Availability Zone, but that protection covers only hardware failure inside that zone. It does nothing for accidental deletion, a misconfigured script, ransomware, or a bad deployment that corrupts data. Those scenarios require a snapshot, and a snapshot only exists if something is scheduled to create one.

Continuity check COV-002 flags volumes with HIGH severity when there is no scheduled backup policy (AWS Backup plan or DLM) actively covering them and no recent recovery point on record. From a finance perspective, the cost of coverage is predictable and small: EBS snapshot storage runs roughly $0.05 per GB-month, and incremental snapshots after the first baseline are typically a fraction of the volume's size. A 500 GB volume on a 35-day daily schedule typically costs $10-30 per month in snapshot storage.

The cost exposure on the other side of that equation is unbounded. Unrecoverable data can mean re-running a week of transactions manually, breaching an SLA, paying for an incident response engagement, or failing an audit that requires demonstrable backup procedures under HIPAA, SOC 2, or PCI. COV-002 at HIGH severity is the signal that the cheap insurance is missing on volumes that may carry significant data liability.

Dana is the FinOps lead reviewing the monthly continuity report. COV-002 has surfaced 16 unprotected EBS volumes in production, at HIGH severity across the board. Rather than treat this as an engineering task to clear, Dana frames it as a data-liability pricing exercise: which of those 16 volumes hold data that would be expensive or impossible to reconstruct, and what is the snapshot-storage cost to protect each one?

She cross-references the volume list against workload tags. Eleven of the 16 are attached to production services: two hold database storage, five hold application-layer state, four hold audit-log archives. The remaining five are development sandboxes. For the eleven production volumes, the total snapshot-storage cost at 35-day daily retention comes to roughly $40/month. Dana flags that against the cost of a single data-loss incident: even a conservative estimate of engineering hours to rebuild plus SLA penalties easily reaches five figures.

Dana's recommendation to the finance pack is one line: "Cover the eleven production volumes at $40/month; classify the five dev volumes as intentionally unprotected with a recorded reason." The spend is predictable, the liability it removes is clear, and the documentation satisfies the auditor's question of whether backup procedures are active and deliberate.

The cost model for EBS backup is unusually simple to underwrite. Snapshot storage runs roughly $0.05/GB-month, and incremental snapshots after the first baseline are typically 5-20% of the volume's full size depending on write churn. That means a 500 GB production database volume on a 35-day daily retention policy costs $10-30/month to protect, a number that is easy to forecast and easy to include in a workload's total cost of ownership.

The exposure on the unprotected side is the inverse: whatever the data is worth on the day it disappears. For a database holding a week of transactions, 'the data is worth' means the labour cost to reconstruct it from upstream sources (if possible at all), SLA penalties, potential regulatory fines under HIPAA or PCI for a healthcare or payment dataset, and the engineering and incident-response hours. A conservative single incident estimate typically runs 100x to 1000x the annual backup storage premium.

For compliance, COV-002 HIGH findings are a direct audit risk. HIPAA, SOC 2, and PCI DSS all require active, demonstrable backup procedures, not an old ad-hoc snapshot, but an ongoing policy with evidence of recent recovery points. AWS Backup Audit Manager produces exactly that evidence, but only if coverage exists. From a finance-partner view, every unprotected production volume on the COV-002 list is a line item on the risk register with a quantifiable cost to close.

The tiering logic is the same as any insurance decision. Paying snapshot-storage premiums on every volume equally is not the goal: dev and test volumes should be explicitly excluded to keep costs rational. The goal is that every production-critical volume is covered by design, every exception is documented, and the total snapshot-storage spend is a predictable, budgeted line rather than a surprise discovered after an incident.

EBS volumes are the persistent disks behind your cloud compute fleet. AWS protects them against hardware failure, but not against the real data-loss scenarios: accidental deletion, ransomware, a bad deployment, or a misconfigured script. Protection against those requires regular snapshots, and a snapshot only exists if a backup policy is actively scheduling them.

COV-002 flags volumes where that policy is absent. HIGH severity means there is no recovery path: if data on one of those volumes is lost or corrupted today, the options are rebuild from scratch or accept the loss. For a production database or a compliance-relevant dataset, neither is acceptable.

The fix is a tag-based backup policy that absorbs new volumes automatically, not a per-volume manual process. The right governance posture is opting out of backups requiring a deliberate, recorded decision, not the other way around. Until that default is in place, COV-002 is a standing inventory of uninsured data.

At one company, the VP of Engineering, Sofia, used to get a vague "we have backups" answer whenever data resilience came up in board prep. After COV-002 surfaced 30 unprotected volumes in a single audit cycle, the answer changed shape: a one-page tier showing every production EBS volume covered by a tag-based plan, every dev volume intentionally excluded with a documented reason, and a Backup Audit Manager report confirming the plan produced recovery points in the last 24 hours.

The point Sofia cared about wasn't the snapshot count; it was that the coverage decision had been made deliberately and was on record. Production data was protected by design, not by whoever remembered to click a button in the console two years ago. The small monthly snapshot-storage cost was an explicit, approved line, not a surprise discovered after an incident.

That's the right end state for this control: not 'every volume has a backup,' but 'every volume's backup status is a recorded choice that matches its data criticality.' COV-002 stops being a recurring to-do and becomes evidence that the policy is being enforced.

COV-002 at HIGH severity is a direct answer to the question: if data on this volume were lost or corrupted today, could you recover it? An unprotected volume means no, and 'no' in production is the difference between an incident that resolves in hours and one that results in permanent data loss, customer notification obligations, or a failed audit.

The second dimension is compliance exposure. Regulated industries (healthcare, finance, payments) require demonstrable backup procedures with documented RPO and RTO. A COV-002 finding on a volume holding relevant data is not just a technical gap; it's an audit finding that says the control claimed in a compliance report does not match reality. That gap, if surfaced by an external auditor rather than an internal check, is far more costly to address.

The governance posture that resolves this is a default of 'everything is backed up unless there's a recorded reason not to be.' Tag-based selection in AWS Backup enforces that at scale: new volumes inherit coverage automatically when tagged. The leadership question is whether that default is the policy, or whether individual teams are opting in at their own discretion. COV-002 tells you the answer.