Establish AWS Backup Plans

An AWS Backup Plan is a configuration document that answers three questions at once: when do recovery points get taken (the schedule), how long do they get kept (the retention rule), and which resources do they apply to (the selection). Once wired up, backup cost becomes a predictable, budgeted line: storage billed per GB at rates ranging from ~$0.05/GB-month for EBS to higher per-GB rates for RDS and DynamoDB, multiplied by the fleet size and the retention window. Without a plan, that cost doesn't disappear — it becomes invisible and uncontrolled, spread across manual snapshots nobody tracks.

The finance risk in having no plan isn't just data loss — it's the unmodelled recovery cost that materialises when something goes wrong. A database rebuild from a month-old manual snapshot can take hours of engineering time plus potential data re-entry labour, customer credits, and SLA breach penalties. None of that shows up in a budget until it happens. A Backup Plan caps the worst-case recovery scenario at a known retention tier and makes the tradeoff explicit: pay a predictable monthly storage cost, or carry the open-ended liability of ad hoc recovery.

Continuity check BKP-003 fires at CRITICAL severity when a region has zero AWS::Backup::BackupPlan resources. From a finance and audit standpoint, CRITICAL means this is not a best-practice gap — it is a documented uninsured position. SOC 2, HIPAA, and ISO 27001 all expect a formal, automated backup policy with evidence; 'we have some snapshots somewhere' is not evidence. Establishing even a minimal plan with tiered retention resolves the finding and produces the audit artefact at the same time.

Priya is the finance partner for a healthcare SaaS running 300 EBS volumes, 40 RDS instances, and a dozen DynamoDB tables. The continuity dashboard shows BKP-003 at CRITICAL across all four active regions — no Backup Plans anywhere. Rather than ask engineering to 'just fix it,' Priya starts by scoping the spend impact of doing it right.

She asks the tiering question first: which resources actually need formal backup coverage, and at what retention level? Engineering tags production databases and EFS file systems as BackupRequired=true. Ephemeral autoscaling nodes, scratch EBS volumes, and dev instances stay untagged and intentionally out. The tag-based model means Priya can see exactly what's in scope and cost-model it before any plan is created.

With the in-scope fleet identified, she runs the storage math: daily recovery points at 7-day retention, weekly at 1 month, monthly at 1 year with cold-storage transition after 30 days. The monthly storage cost comes out to roughly $600 — a planned, predictable line item. Priya puts it in the budget with the note 'backup coverage for 40 RDS + 12 DynamoDB + stateful EBS, tiered retention, compliant with HIPAA §164.308(a)(7)(ii)(A).' The CRITICAL finding clears, the audit artefact exists, and the cost was decided in advance rather than discovered on the next bill.

The primary exposure is unmodelled recovery cost. When a production database is lost without a formal backup, the cost of recovery isn't zero — it's engineering hours to rebuild, data re-entry labour for anything not captured in the last manual snapshot, customer credits, potential SLA breach payments, and regulatory notification if the data was personal or healthcare-related. None of that is budgeted before the incident. A Backup Plan caps the worst-case recovery scope at the retention window and makes the remaining exposure an explicit, finite number.

The second exposure is audit and compliance cost. SOC 2 CC7.5, HIPAA §164.308(a)(7)(ii)(A), and ISO 27001 A.12.3 all require a documented, tested backup policy. Without a formal Backup Plan, the evidence collection before an audit is manual and unreliable — engineers pull together screenshots and spreadsheets of 'what we think we have.' With a plan and AWS Backup Audit Manager enabled, the evidence is a single automated report. The time saved per audit cycle is typically measured in days.

The third exposure is hidden snapshot cost without the lifecycle control. Manual snapshots taken outside a Backup Plan don't expire unless someone explicitly deletes them. AWS field data shows a median of 1,200 untagged manual EBS snapshots per mid-size account, costing around $9k/year with no value. A Backup Plan with explicit retention rules replaces this graveyard with a self-managing lifecycle.

The one cost a Backup Plan does create is storage: recovery points billed at per-GB-month rates (~$0.05/GB for EBS, higher for RDS and DynamoDB). For a 10 TB stateful fleet with tiered retention, budget $500–$800/month as the baseline; add cross-region copies or extend monthly retention to a year and that can climb past $2k. This cost is predictable and should be modelled before enabling the plan, not discovered on the next bill. The finance contribution is to run that model in advance and treat backup storage as a planned infrastructure line, not an afterthought.

An AWS Backup Plan is the mechanism that turns 'we think our data is backed up' into 'we have a policy that says what gets backed up, how often, and for how long.' Without one, backup happens — if it happens at all — by individual engineers remembering to do it manually. That is not a policy; it is a hope.

Continuity check BKP-003 fires at CRITICAL severity when there are zero Backup Plans in a region. CRITICAL here means a single accidental deletion, a ransomware event, or a compromised credential walking the account could result in permanent, unrecoverable data loss. The control is blunt by design: if no plan exists, no policy exists.

The leadership question is not whether the team is trying hard — it is whether recovery is governed by policy or by accident. A Backup Plan is the answer to that question. It is also the cheapest possible defence against the kind of incident that generates customer notification letters, regulatory inquiries, and board-level post-mortems.

At one company the CISO used to get 'we have some snapshots' as the answer to 'can we recover from a data loss event?' After the team established a formal Backup Plan with tag-based selection and vault deletion protection, the answer changed shape: a one-page coverage report showing exactly which resources are backed up, at what frequency, for how long, and that the recovery points cannot be deleted even by a compromised admin account.

The point leadership cared about wasn't the technical mechanism — it was that recovery was now a policy, not a memory. The question 'if an engineer accidentally drops the wrong database at 2am, can we recover to within the last hour?' had a documented, auditable yes as the answer. The backup cost was a small, planned line on the cloud bill rather than a variable that materialised after an incident.

That's the right end state for this control: not 'we take some snapshots,' but 'we have a policy that defines what is covered, how long it's kept, and who can delete it — and none of those answers are accidental.'

The headline risk is simple: without a Backup Plan, a single bad event — a wrong deletion, a ransomware payload, a compromised credential walking the account — can result in permanent, unrecoverable data loss. The question 'can we recover?' has no confident answer. That is the class of incident that generates customer notification letters, regulatory inquiries, and post-mortems at the board level.

The second risk is that ad hoc backup is invisible to governance. When engineers take manual snapshots without a policy, there is no single place to verify coverage, no audit trail that satisfies a control owner, and no mechanism that prevents the snapshots from being quietly deleted. A Backup Plan makes coverage a policy artefact — something that can be shown to an auditor, a regulator, or a customer security questionnaire as evidence of a deliberate, maintained commitment.

The right frame for leadership is not 'how much does backup cost?' It is 'are we governing recovery by policy or by memory?' A Backup Plan is the answer. The cost — a predictable monthly storage line proportional to the fleet — is the price of being able to answer that question with a yes.