The Compounding Cost of Forgotten Cloud Assets
A common scenario in cloud operations: a developer terminates an EC2 instance and its EBS volume after a project is decommissioned. The task is closed, but a critical oversight remains. The automated daily snapshots associated with that volume continue to exist, silently accumulating storage costs month after month. This is the core of the orphaned snapshots cloud cost problem. These assets don’t consume active resources like CPU or memory, so they fly under the radar of performance monitoring tools. They represent a slow, compounding bleed in your cloud budget that native tools like AWS Cost Explorer, which focus on aggregate spend, often fail to isolate. The FinOps Foundation’s State of FinOps 2024 report highlights that significant cloud spend is waste, and unmanaged, forgotten assets like snapshots are a primary contributor.
Technical Guide: How to Identify Orphaned Snapshots
Identifying these hidden costs requires querying resource states directly, not just billing dashboards. Orphaned snapshots typically fall into two main categories: those from detached or deleted EBS volumes, and those associated with deregistered Amazon Machine Images (AMIs). Manually cross-referencing thousands of assets is impossible. The command line offers a direct method for discovery, but it must be used with caution.
Finding Snapshots of Non-Existent Volumes (AWS)
This approach lists all your snapshot IDs and compares them against the list of all active volume IDs. The snapshots that don’t have a corresponding active volume are potential orphans. Be aware: on accounts with tens of thousands of snapshots, these API calls can be slow and may require pagination.
# Get all snapshot IDs you own
ALL_SNAPSHOTS=$(aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[*].SnapshotId' --output text)
# Get all snapshot IDs that are associated with an existing volume
ATTACHED_SNAPSHOTS=$(aws ec2 describe-volumes --query 'Volumes[*].SnapshotId' --output text)
# The following requires a tool like 'comm' to compare the lists.
# This command shows snapshots present in the first list but not the second.
echo "$ALL_SNAPSHOTS" | tr ' ' '\n' | sort > all_snapshots.txt
echo "$ATTACHED_SNAPSHOTS" | tr ' ' '\n' | sort > attached_snapshots.txt
comm -23 all_snapshots.txt attached_snapshots.txtFinding Unattached Snapshots in Azure
In Azure, the principle is the same: find snapshots that are not associated with an active managed disk. The Azure CLI can filter for this directly using a query. This command is a robust starting point for an Azure cleanup script, targeting snapshots where the `managedBy` property is null.
# List all snapshots in a resource group not managed by a disk
az snapshot list --resource-group YOUR_RESOURCE_GROUP \
--query "[?managedBy==null].{ID:id, Name:name, Size:diskSizeGb, Location:location}" \
--output tableWhile effective for a single subscription, managing this across a large enterprise becomes a significant operational burden, pushing teams to seek more robust cloud cost optimization software that can automate discovery across their entire cloud estate.
A Framework for Safe Deletion
Executing a bulk deletion based on the scripts above is extremely risky. A snapshot might be the foundation of a critical ‘golden AMI’ for deploying new instances, or it could be intentionally retained for long-term compliance. A safe deletion strategy requires contextual analysis that simple scripts cannot provide.
1. Implement Proactive Tagging and Lifecycle Policies
Prevention is the most effective strategy. Use AWS Data Lifecycle Manager (DLM) or Azure Policy to automate snapshot creation, retention, and deletion schedules. Enforce a mandatory tagging policy (e.g., `owner`, `project`, `retention-policy`, `creation-date`) to provide the necessary context for future cleanup decisions.
2. Differentiate Between AMI and Volume Snapshots
Before deleting any snapshot, you must verify if it’s part of a registered AMI’s block device mapping. Deleting a snapshot used by an AMI will break any future deployments from that image. The correct workflow is to first identify and deregister unused AMIs, and only then clean up their associated snapshots.
# Find the snapshot ID(s) associated with a specific AMI
aws ec2 describe-images --image-ids ami-0123456789abcdef0 \
--query 'Images[].BlockDeviceMappings[].Ebs.SnapshotId' \
--output text3. Adopt a Tiered, Risk-Averse Deletion Workflow
For established environments, the fear of causing an outage often leads to inaction. A tiered approach mitigates this risk:
- Tier 1 (Automated Deletion): Snapshots older than 180 days, from a volume that was deleted over 90 days ago, not associated with any AMI, and lacking a `legal-hold` or `compliance` tag.
- Tier 2 (Manual Review): Snapshots associated with deregistered AMIs, snapshots from detached (but not deleted) volumes, or those with ambiguous tags.
- Tier 3 (Do Not Delete): Any snapshot with an explicit `legal-hold`, `compliance`, or `do-not-delete` tag.
This is a common challenge for organizations realizing that native cloud tools are no longer enough to manage complexity at scale.
Automating Cleanup Beyond Native Tooling
While CLI scripts are useful for targeted cleanups, they don’t solve the systemic problem of managing resource lifecycles at scale. The risk of human error is high, and the engineering hours required for manual review are substantial. This is where automated FinOps platforms provide critical value. A platform like Thalaxo continuously scans for orphaned snapshots, unattached volumes, and idle IPs across AWS, Azure, and GCP. It automates the contextual analysis by checking for AMI dependencies, resource lineage, and tag-based policies, presenting a clear, risk-assessed list of savings opportunities. This transforms a high-risk manual task into a safe, automated process, allowing engineers to focus on building products instead of cleaning up infrastructure debt. You can see our supported integrations and transparent pricing to evaluate if it fits your needs.
