It’s great that you pay for just what you use in Amazon Cloud, right?
Well, that’s not quite the whole story.
Typically, what AWS charges for is what you’ve allocated. Whether you’re actively using that allocated resource, or not, is really up to you.
At CloudKeep, we are focused on the numerous ways that AWS customers can save money based on this rather simple observation, especially when it comes to storage.
Here’s an easy one:
Detached EBS volumes
These are EBS volumes that are not attached to any EC2 instances - just sitting idle, not being used for anything. For the most common type, gp2 (General Purpose SSD), the cost (minimally) is $0.10 per GB per month. That may not sound like a lot, but consider this: one of CloudKeep’s first users discovered that they had approximately 30 TB of detached EBS volumes. That’s $3,000/month, or $36,000/year!
Now, there is no good reason to have detached volumes. You can delete them, taking a snapshot before doing so if you think they may be needed in the future. We can think of this as moving the data from EBS volumes to EBS snapshot which is (minimally) $0.05 per GB per month - thus reducing the cost by 50%. (The actual savings are probably more since the snapshots are only taken of allocated blocks on EBS volumes.)
So, in this case, the customer was looking at an easy $1,500/month of savings. (In reality, they were able to save even more since some of the EBS volumes were simply not needed.)
You may be wondering how any customer could end up with 30 TB of detached volumes. In defense of this and many other customers, let me walk you through how easily this can happen.
How do you end up with detached EBS volumes?
Every time you start an EC2 instance and you need extra storage, you add an EBS volume. When you do that, you have to decide on whether to check this “Delete on Termination” box or not:
(Note - the checkbox is not checked by default.)
It’s a safe bet that the majority of users don’t click on that box. After all, the extra volumes are typically provisioned to hold application data. And it’s hard to predict that such data won’t be needed when the EC2 instance needs to be terminated.
But come one day, the EC2 instance needs to be terminated. Maybe it was to support a project that has been completed. Or, maybe a new workload has been introduced and the old one needs to be retired. And when you terminate the instance, you are greeted with this pop-up:
Here is a reminder that you (or someone else) did not click on that checkbox when this instance was launched. But at this point, there is no easy way to enable “delete on terminate.” There is no way to do this via the console; you’ll have to do this via the API or using the command-line client.
That difficulty means you’ll likely just terminate the instance and deal with the volume later. So, you click on “Yes, Terminate” and voila now you have a detached volume!
But dealing with these volumes later presents its challenges.
Why do detached EBS volumes stay around?
The simple answer is that it’s hard to deal with them. (Yes, the title of this blog article says it’s easy. We’ll get to that in a little bit.)
No, it’s not hard to delete a detached EBS volume. In fact, it’s almost too easy. It’s not hard to take a snapshot before deleting the volume either.
The hard part is having to make decisions on the importance of the data on the EBS volume. Does it warrant taking a snapshot before deletion? If so, how long do you keep the snapshot?
The fact there are typically no easy answers to these questions leads to inaction, and thus an accumulation of these detached volumes.
An easy way to clean up the detached EBS volumes - lifecycle it and save money!
Here is what we would recommend today:
- Set a
schedule- say once a month - when you will take inventory of your detached EBS volumes.
- Identify those detached volumes that have been detached longer than some
threshold- say three days. These are the EBS volumes that you would feel comfortable can be cleaned up.
- Take a snapshot of each of these idle detached EBS volumes and tag with the information of the EBS volume.
- Additionally, tag an
expiration_dateat which point the snapshot can safely be removed. This is your safety period, based on your organizational tolerance for risk.
- Remove the detached EBS volumes that have been snapshotted.
- Scan existing snapshots for
expiration_date’s that are beyond the current date and remove these.
- For those of you with a managerial bend, you might also want to calculate how much money you just saved your organization!
Note here we are assessing the importance of the data by setting a
threshold of inactivity before
removing the detached EBS volume while eliminating the risk of losing data by taking a snapshot first.
We are then using the
expiration_date to make sure we do not forget to eventually clean up the snapshots while giving ample time within which to reclaim the data if needed.
How can CloudKeep help make this process easy for you?
Right now we can help on the very first part - identifying your detached EBS volumes across all of your accounts and all of your regions. We can also identify how long these volumes have been detached which helps you make decisions on whether they should be snapshotted and removed.
Sign up here for our private beta program and get free access to our dashboard that provides this information and more.
Note, the whole lifecycle described above can naturally be automated via policies, and we are working on introducing such automation as a product in the future. If such automation is something that you think would be beneficial to you and your organization, please reach out to us at email@example.com - we’d love to hear from you.
If you found this article useful, please share it with your colleagues via email or via social media. (See bottom of the page for share links.)