[Turbot On] Unattached Storage Volume Cleanup

How to save big, by cleaning up older, unattached and unneeded block storage.

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 week we will look at how Turbot 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

With Turbot, you can use active guardrails to identify if a resource is in active use. Once something has been identified as inactive, Turbot 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 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 getting this configured in your environment please reach out to Turbot Support, and keep an eye on your inbox for another Turbot tip next week!

Cheers,

Bob