Protect EC2 instances with AWS Backup

An EC2 instance is the compute unit behind most AWS workloads: the server your application runs on. When AWS Backup covers an instance, it regularly captures the full machine state: a restorable snapshot of the OS, software, config, and data. Without coverage, losing an instance to a hardware failure, accidental deletion, or data corruption means rebuilding from scratch: an engineering effort measured in hours to days, plus whatever customer-facing downtime accompanies it.

The cost of backup coverage is almost entirely storage: EBS snapshots are charged at roughly $0.05 per GB-month and are deduplicated, so you only pay for changed blocks after the first backup. A 100 GB instance with daily backups and 30-day retention typically runs $5-15/month. That figure is easy to model and easy to budget. The cost of no coverage is the opposite: unquantifiable until the incident happens, then very large.

For finance, this is a straightforward tiering question with clear unit economics. Long-lived, stateful instances (app servers, jump hosts, anything bespoke) are cheap to protect and expensive to lose. Stateless auto-scaling nodes are cattle: back up their data layer (RDS, S3, EFS) instead and don't spend backup budget on instances that are already disposable. COV-001 tells you which tier each instance falls into and whether the decision has been made.

Dana is the finance partner reviewing the monthly cloud governance report. COV-001 shows 14 EC2 instances with no backup coverage, three of them in production. Before approving or rejecting any budget, she asks the tiering question: which of these are long-lived stateful servers that carry real recovery cost if lost, and which are stateless auto-scaling nodes where backup spend would be pure waste?

The engineering team segments the list in a few minutes using environment and launch-type tags. The three production instances are bespoke app servers with on-disk state; at roughly $8/month each in snapshot storage, the annual protection cost for all three is under $300. The other eleven are ASG nodes: by definition disposable, replaceable in minutes from a launch template. Dana flags those eleven as correctly excluded and documents the reason.

Her contribution to the budget discussion is one number and one policy question: the $300/year to protect the three pets is clearly approved; the question for the team is whether the data those servers write is also being captured somewhere (RDS, S3), not just the instance itself. If the answer is yes, the coverage picture is complete. If not, there's a second, larger conversation about data-layer backup that COV-001 is surfacing indirectly.

Backup storage cost for EC2 instances is unusually easy to forecast. EBS snapshots are deduplicated and charged at roughly $0.05/GB-month, with each subsequent snapshot storing only changed blocks. A 100 GB instance with daily backups and 30-day retention typically costs $5-15/month. That means for any given instance you can calculate the annual protection premium in under a minute, then compare it directly against the cost of rebuilding that instance from scratch if it's lost.

The rebuild cost is the harder number, but it's the one that makes the insurance case. For a bespoke application server that took days to configure, 'rebuild from scratch' includes engineering time, configuration reconstruction, data reconciliation from logs or replicas, and however many hours of customer-facing downtime the incident produces. For most production pets, the annual backup premium is a small fraction of a single incident's cost. That math makes the decision straightforward when you do it explicitly.

From a chargeback and unit-economics perspective, backup cost should be allocated to the team or workload that owns the instance, not pooled invisibly in a shared infrastructure budget. When teams see the $8/month line for their server's backup, they make better decisions about which instances are pets worth protecting and which are cattle that shouldn't be in the backup plan at all. Hidden shared costs lead to over-protection of throwaway resources and under-protection of critical ones.

On the audit side, COV-001 creates a paper trail. If a regulator asks about backup coverage for systems holding regulated data, a list of unprotected instances with no documented exception is a liability. The right posture is every flagged instance either remediated or carrying a recorded, finance-visible justification for why it's intentionally excluded, so that the coverage picture is always defensible.

An unprotected EC2 instance is one where, if the underlying server fails, someone has to rebuild it from whatever they remember: reinstalling software, reconstructing configuration, recovering data from logs. The COV-001 check identifies every running instance where AWS Backup has no recent recovery point. HIGH severity means the org has accepted a recovery risk it may not have consciously evaluated.

Backup protection is not a binary all-or-nothing question; it's a deliberate tiering decision. Bespoke, long-lived servers that run critical workloads should be protected. Stateless auto-scaling servers that are disposable by design should not be included in instance backups (their data layer is backed up separately). The leadership question is whether that tiering is a recorded policy or an accident of whoever last launched each instance.

When the CISO at one company first reviewed COV-001 results, the finding count looked alarming: dozens of unprotected EC2 instances. But the framing was wrong: the number that mattered wasn't total unprotected instances, it was unprotected instances that the business actually depended on.

After the team applied a pet-versus-cattle lens, the picture changed: a handful of long-lived application servers were genuinely unprotected and got backup plans immediately. The rest were stateless nodes in auto-scaling groups; protecting them at the instance level was unnecessary spend. The CISO's ask wasn't 'cover everything'; it was 'show me which servers we can't rebuild without a recovery point, and confirm those are protected.'

That framing turned COV-001 from a noisy metric into a clean governance signal: the finding count tells you how many servers are in scope; the tier breakdown tells you whether any of those servers actually represent unacceptable recovery risk. A mature posture is not zero findings: it's all production pets protected, all cattle intentionally excluded, and the boundary between the two written down.

An unprotected critical server is a recovery risk the business has accepted without evaluating. The failure mode isn't abstract: it's the engineering team at 3am trying to rebuild an application server from memory, or announcing to customers that data from the last several days is gone. COV-001 makes that risk visible by naming which servers have no recovery point.

The impact is also regulatory. SOC 2, ISO 27001, and HIPAA all require demonstrable backup coverage for systems holding relevant data. An instance that your own monitoring flags as unprotected, with no documented exception, becomes evidence of a known gap at audit time. The risk isn't just the recovery event itself; it's the compliance exposure from documented awareness of insufficient controls.

The executive frame for this finding isn't 'protect everything'; it's 'nothing critical should be unprotected by accident.' Stateless servers in auto-scaling groups are designed to be disposable and shouldn't be in backup plans. Long-lived servers running critical workloads should be protected by default. The governance question is whether that boundary has been set as policy, or whether it's whoever-clicked-whatever in the AWS console last year.