Unattached storage volume cleanup
How to save big, by cleaning up older, unattached and unneeded block storage.
Remote Access Using SSH Cryptographic Keys
The ability to easily create, attach and unattach disk volumes is one of the key benefits of working with IaaS, but it can also become a source of unchecked cost if not watched closely. Even if an Amazon EBS Volume, Azure Compute Disk, or GCP Compute Engine Disk is unattached, you are still billed for their provisioned storage. Surprisingly this adds up fast; we have seen customers with 1000s of unattached volumes siphoning their cloud budget dry.
This post focuses on how Turbot Guardrails can help enforce the clean up of unused volumes and disks
Traditional Workflow
It is very common during development, and when working with ephemeral workloads, to create and destroy large numbers of VMs. The default console setting will detach, but not delete, storage volumes when instances are destroyed and to larger application & operations teams it can seem risky to delete random volumes you didn’t create with the excuse, "what if someone needs it for something"; meanwhile dozens or hundreds of unused disks pile-up from inaction and improper handling.
Get it done with Turbot Guardrails
With Turbot Guardrails, you can use active guardrails to identify if a resource is in active use. Once something has been identified as inactive, Turbot Guardrails has the ability to cleanup the unused resources with corrective controls, or alert you with detective controls. “Active” type policies have defined sub-policies to calculate the “active” status based on conditions such as age
, last modified
, etc. One such criteria is the “attached” state sub-policy for Amazon EBS Volumes shown in the example below:
Create a new policy to force the volume to “inactive” state if it is unattached:
Create a new policy to take corrective action for resources that are in an “inactive” state:
After setting the policies, Turbot Guardrails automation will identify all currently unattached volumes, and then handle remediation (backup and delete) with a configurable warning period. To evaluate the impact of this in your environment we suggest setting the value to Check: Active
at the Turbot level, and then selectively applying the enforcement setting to development and/or sandbox environments to see how the corrective controls will work in practice.
Make it happen!
See for yourself how easy it is to automate storage volume cleanup with just a few clicks. Open source Terraform templates with policy examples for how to do this on AWS EBS Volumes, Azure Compute Disks and GCP Compute Engine Disks are available in the Turbot Development Kit (TDK). If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!