In this hands-on guide, we will share how to properly maintain your Amazon Elastic Block Store (EBS) snapshots by identifying and deleting or archiving old snapshots. By performing basic snapshot maintenance, you can greatly reduce your AWS storage costs.
Amazon Elastic Block Store (EBS) snapshots are point-in-time copies of an EBS volume. They are stored in Amazon S3 and can be used to create new EBS volumes, or to restore data to an existing volume.
EBS snapshots are incremental, which means that only the blocks that have changed since the last snapshot are saved, resulting in lower storage costs. Snapshots can be used to create new EBS volumes, or to restore data to an existing volume. They can also be used as a backup solution and enable users to create multiple versions of a volume, or to move data between regions or accounts.
Snapshots can be created manually or scheduled to run automatically at specified intervals. They can also be protected from accidental deletion and users can set up retention policies for them.
The monthly bill for Amazon Elastic Block Store (EBS) snapshots varies depending on the amount of data stored in the snapshots and the region where the snapshots are stored.
The storage cost for an EBS snapshot is based on the amount of data stored per month, measured in gigabytes (GB). The cost varies by region, but in general, it is very low, typically a few cents per GB per month.
As of today, a standard EBS snapshot storage pricing is $0.05/GB-month,
While archive EBS snapshot storage is $0.0125/GB-month.
While this unit cost may not sound like much, here’s a simple calculation to demonstrate what your team may be paying for unused EBS snapshots:
Let’s say you have 200 EBS snapshots with 250 GB of data each, that are not in use. You might be paying 200 x 250 x $0.05 = $2,500/month per team.
When you pay for snapshot storage you don't need, you may be adding to your organization's increasing cloud costs.
Important notes:
Snapshots are incremental backups, meaning that only the blocks on the device that have changed is saved on the "newer" snapshot been taken. The snapshots also contain information references to a previous snapshot regarding the data that has not been changed.
Here’s Amazon’s guidance on how snapshots work.
An EBS snapshot would be considered as "old" if you have not used it in X time/days/months - depends what you consider as "old" per policy. Some can say it's 3 months while others 1 year. It really depends on the user and use-case.
An old snapshot may still be in use or referenced from newer snapshots (again, depending on policy), but it becomes redundant when there’s a new snapshot that covers the same data (disk sections). Old snapshots that are no longer referenced are called orphaned snapshots (aka orphans or unused EBS snapshots). When an instance in AWS is deleted (terminated), the volumes of this instance are also deleted (usually), but its snapshots remain in the cloud.
You can delete EBS snapshots using AWS console or AWS CLI.
When you delete a snapshot, only the data that is referenced exclusively by that snapshot is removed. Unique data is only deleted if all the snapshots that reference it are deleted.
To find and delete a snapshot using the console:
AWS CLI allows you to search for specific types of snapshots.
aws ec2 describe-snapshots
--query "Snapshots[?(StartTime<=`2022-06-01`)].[SnapshotId]" --output text
aws ec2 describe-snapshots --filter Name=tag:Team,Values=Infra
--query "Snapshots[?(StartTime<=`2020-03-31`)].[SnapshotId]" --output text
aws ec2 delete-snapshot --snapshot-id <value>
As previously mentioned, snapshots are incremental, meaning that if you delete a snapshot that has data referenced by another snapshot, that data will be transferred to the next snapshot. This means that the reduction in storage may not be as significant as you expect, as the data is still stored in other snapshots. However, if there are block data changes that were captured by snapshots that are no longer needed, deleting those will save storage space, thus lowering costs.
Archiving snapshots is another way to potentially lower costs for long-term storage of rarely accessed snapshots that do not need frequent or fast retrieval.
While archived snapshots are stored at a much lower cost (up to 75% lower) than standard snapshots, archived snapshots are always full snapshots, meaning, they will likely be larger than the incremental snapshot from which they were created from.
Some typical use cases for archiving snapshots include:
To evaluate if snapshot archiving is a potential solution you can take to lower your storage costs, I would recommend reviewing archiving snapshots considerations and limitations and AWS guidelines and best practices for archiving snapshots.
Amazon Data Lifecycle Manager (DLM) is a service provided by Amazon Web Services (AWS) that allows you to automate the management of the lifecycle of your Amazon Elastic Block Store (EBS) and Amazon Relational Database Service (RDS) snapshots.
DLM can be used to automatically create snapshots, schedule the creation of snapshots, and set retention policies for snapshots. It also provides options for controlling the number of snapshots kept, and the time period for which snapshots are retained. You can also use DLM to automatically delete or archive snapshots that are no longer needed, helping you to reduce your storage costs.
DLM is a simple and cost-effective way to manage your snapshots, it allows you to back up your data, and recover data from snapshots without any manual effort. You can also use it to schedule automated backups, and to set up retention policies for backups.
Amazon Data Lifecycle Manager (DLM) can help you reduce your cloud costs by automating the management of the lifecycle of your Amazon Elastic Block Store (EBS) and Amazon Relational Database Service (RDS) snapshots.
Here are a few ways that DLM can help you reduce your cloud costs:
It's important to note that DLM can only be used for EBS and RDS snapshots, and it does not support other types of data, such as files stored in Amazon S3.
Using Stream.Security Architectural Standards, you can easily find potential old EBS snapshots to be deleted. You can use Stream’s out-of-the-box EBS snapshots cost rules or you can create your own custom rules for tags and various EBS snapshot attributes.
By using these capabilities, you can review the total predicted cost of each rule, and the breakdown of cost per violated resource within each rule.
Example architectural standard: Ensure there are no EBS snapshots older than a month
This rule checks for EBS snapshots older than 1 month within your AWS account, so you can remove them in order to lower the cost of your monthly bill. The threshold for the retention period is 1 month, which means that all incremental snapshots older than 1 month should be deleted. Since EBS snapshots are incremental, deleting previous (older) snapshots does not affect the ability to restore the volume data from later snapshots which allows you to keep just the necessary backup data and lower your AWS monthly costs.
This rule can also help you work with the AWS Well-Architected Framework.
This architectural standard’s conditions:
Review rule violations: When there are violations for this rule (or any rule in our architectural standards), this view shows each violated resource including the related predicted cost.
You can also create your own custom rules using the rule creation wizard on Stream.Security.
Here’s a custom rule example:
The below custom rule checks for EBS snapshots older than 3 months owned by Team Infra. EBS snapshots offer teams the ability to back up their EBS volumes and easily create a new volume with point-in-time data. Using the “Team” tag is helpful in identifying who owns the snapshots, in order to identify and delete snapshots that are no longer needed.
- Read Tal's second blog post in this series: Hands-on Guide: How to Find and Remove Unattached Elastic IPs
- Reach out to Tal on LinkedIn if you'd like to suggest other topics, tips & tricks to reduce AWS cost.
Stream.Security delivers the only cloud detection and response solution that SecOps teams can trust. Born in the cloud, Stream’s Cloud Twin solution enables real-time cloud threat and exposure modeling to accelerate response in today’s highly dynamic cloud enterprise environments. By using the Stream Security platform, SecOps teams gain unparalleled visibility and can pinpoint exposures and threats by understanding the past, present, and future of their cloud infrastructure. The AI-assisted platform helps to determine attack paths and blast radius across all elements of the cloud infrastructure to eliminate gaps accelerate MTTR by streamlining investigations, reducing knowledge gaps while maximizing team productivity and limiting burnout.