Orphan snapshots: the hidden backup bill and how to clean it up with approval

Snapshots are the easiest cloud resource to forget. They do not show up in any active resources dashboard, they produce no usage metrics and their cost grows so slowly that nobody notices. Until someone reviews the bill and finds years of copies of disks that no longer exist. In this article we show how AAA Sentinel detects those orphan snapshots on AWS and how to clean them up with the AI Agent without losing control: every deletion is proposed, approved, waits out a grace period and is then measured.

How they pile up

Almost always through one of these four routes:

• Automatic backups with no retention: someone scheduled a daily snapshot and never set how many to keep.
• "Just in case" copies: a snapshot is taken before a migration or an upgrade, everything goes fine and nobody deletes it.
• Old AMIs: on AWS, every AMI creates one snapshot per volume. Old versions of an image drag their snapshots along.
• Deleted volumes: the disk is removed, but its snapshots are not. These are orphan snapshots, and nobody links them to anything anymore.

What they cost

On AWS, a standard EBS snapshot costs about 0.05 US$ per GB per month in us-east-1, and Azure and Google Cloud are in the same range. It sounds small, but it adds up: 3 TB of forgotten snapshots is about 150 US$ a month, every month, with nobody benefiting from them.

What you get out of it

With detection and the agent working together:

• You see every orphan snapshot across your AWS accounts in Active Findings, with its estimated cost.
• You delete them without going into the console, and without anyone deleting things on their own: a person approves every deletion.
• You get a window to change your mind before it runs, and a record of who approved what.
• You find out afterwards whether the account's spend really went down, not just what was estimated.

What AAA Sentinel detects

The STORAGE_ORPHAN_SNAPSHOT rule, included in every plan and in the 30-day trial, checks the EBS snapshots you own in each AWS region and flags the ones created from a volume that no longer exists in the account. Each one produces a high-severity "Orphan snapshot" finding, with an estimated saving equal to the source volume size times 0.05 US$ per GB per month.

• There is no age-based rule. A three-year-old snapshot whose volume still exists produces no finding; yesterday's snapshot of a deleted volume does.
• It is an AWS rule. Azure and Google Cloud snapshots, RDS snapshots and AMIs are not analyzed.
• A snapshot backing a registered AMI also shows up as orphan if its volume no longer exists. AWS will not let you delete it while the AMI exists, so check it first.

Worked example: ACME's snapshots

ACME, a fictional company on the Business plan, connects its production AWS account. The first scan finds this:

Step 1: find the orphan snapshots

In Active Findings, pick the account in the selector and the High tab. Orphan snapshots appear as "Orphan snapshot", followed by the snapshot name or ID. When you open one, the "Finding detail" shows the "Recommendation": delete it if you do not need it for disaster recovery, but first check that it is not the only copy of critical data. If you decide to keep one, mark it as "Dismissed" so it stops counting in the KPIs.

Step 2: prepare the agent

The AI Agent is part of the Business plan and needs write permissions. When you connect the account, the "Enable autonomous agent (optional)" step creates a second role, separate from the read-only one. That role can delete snapshots and detached volumes; unlike actions on EC2 instances, deleting a snapshot does not require the FinOpsSentinelManaged=true tag, so approval is your main control.

Step 3: turn on the playbook

In AI Agent → Playbooks, as long as you have no playbooks you will see the "Predefined templates". The one we want is old-snapshots-cleanup, shown as "Limpieza de snapshots antiguos". When you use it you pick the account, and the playbook is created with this configuration:

• It is evaluated when every scan of that account finishes, against its findings of medium severity or higher.
• It selects findings on EBS snapshots more than 90 days old, counted from creation. Since the only snapshot finding is the orphan snapshot one, in practice these are orphan snapshots older than 90 days.
• It proposes the delete snapshot action, always pending approval and with a 48-hour grace period.
• It proposes at most 10 actions per scan. The "Run" button evaluates it right away against the latest scan and picks the 10 with the highest savings.

Step 4: approve or reject

Proposals appear in AI Agent → Panel, under "Pending approval", with the resource, the reason and the estimated saving. People with the owner, admin or approver role also receive an email with a link to review them in the platform.

• "Approve" moves it to the execution queue. "Reject" discards it and records the reason. "Cancel proposal" withdraws it.
• A proposal nobody approves within 7 days expires on its own.
• Some actions require a second approval from a different person. Today those are security fixes, such as closing admin ports or blocking public access to a bucket. Deleting a snapshot needs just one.
• At ACME, the approver rejects the two snapshots backing an AMI in use and approves the other seven.

Step 5: the grace period

Approval does not run anything yet. The action moves to "Approved — awaiting execution", with the date under "Will execute:", and waits out the grace period: 48 hours to delete a snapshot. When 4 hours or less remain, approvers get an email reminder. Until then, "Cancel proposal" stops it with no consequences.

Step 6: execution, and what cannot be undone

Once the grace period is over, the agent checks that the snapshot still exists and deletes it. If something fails, approvers receive an email with the error. Every action is recorded in AI Agent → History, and its detail includes a "Rollback" section with what can be done to revert it.

• Deleting a snapshot cannot be undone. The history says so itself: the snapshot has been permanently deleted. Unless you have the AWS Recycle Bin set up, there is no way back.
• The "Undo" button only appears on actions that stored the previous value, such as applying tags.
• Deleting a detached volume is different: before deleting it, the agent takes a backup snapshot and the history gives you the command to recreate the volume from it.

Step 7: verify the savings

The Panel keeps two figures apart: "Estimated savings (executed)", which adds up what the rules estimated, and "Verified savings", measured against real cost. Since there is no per-resource billing, verification compares the daily spend rate of the whole account before and after the action, based on scans.

• It is not attempted until at least 7 days after execution.
• If the account's spend does not go down, the action is left as not confirmed, never as a negative saving.
• If other actions ran on the same account during those days, confidence in the figure drops, because the effect of each one cannot be isolated.

Prevention: retention policies

Cleaning up what is there is half the job; the other half is making sure it does not pile up again. All three providers handle it with their own tools:

• AWS: Data Lifecycle Manager or AWS Backup create snapshots and delete them by count or by age. For what you must keep for a long time, the snapshot archive tier costs about 0.0125 US$ per GB per month, with a 90-day minimum and a restore fee.
• Azure: Azure Backup policies define how long each copy is kept.
• Google Cloud: snapshot schedules include the retention days.
• A starting point: in production, daily copies for 7 days, weekly for 4 weeks and monthly for 3 months; in staging, 3 days; in development, usually none; and manual snapshots with an expiry date tag.

What it does not do yet

So you know where the limits are:

• There is no age-based rule, and none for snapshots whose volume still exists.
• AWS EBS snapshots only: no Azure, Google Cloud, RDS or AMIs.
• Each scan reads up to 500 snapshots per region.
• The estimated saving uses the source volume size and does not account for snapshots being incremental.
• A playbook does not propose an action that is already pending or approved again, and it does not act on dismissed or resolved findings. If you reject a proposal, the next scan may make it again: to stop it, dismiss the finding.
• The unused-volumes-cleanup template ("Limpieza de volúmenes sin usar") proposes deleting volumes that have been unattached for more than 30 days. The clock starts at the first scan that saw the volume unattached, not when it was created, and resets if it is attached again. On all three clouds a backup snapshot is taken before deleting; if it cannot be created, nothing is deleted.

Checklist to get started

With this in place, snapshots stop being a bill nobody reviews:

• Your AWS accounts connected and a scan reviewed in Active Findings.
• Snapshots backing AMIs in use, and copies you want to keep, identified.
• Business plan, the agent role created and, if you want a safety net, an AWS Recycle Bin rule.
• The old-snapshots-cleanup playbook turned on, or one created from the finding with "Turn into playbook".
• Someone with the approver role keeping an eye on the Panel and the emails.
• A retention policy on each cloud so they do not pile up again.