Unattached EBS volume workflow

Detached does not mean disposable

An available EBS volume may be an abandoned development artifact, but it may also contain a database, a deliberately detached recovery copy, or state retained during a migration. Attachment state alone is not enough evidence for deletion.

Proposed evidence

The workflow would inspect attachment history, age, tags, encryption, snapshots, CloudTrail context where available, and references from launch templates or infrastructure code. It would require an accountable owner and a configurable grace period.

For Terraform-managed volumes, OpsTiller could propose removal from code only after a unique ownership match. For unmanaged volumes, an eventual direct action would require a dedicated allowlisted adapter, a fresh snapshot, explicit approval, and post-action verification. AWS explains the states and deletion behavior in the EBS volume documentation.

Safety gates

1. Exclude protected accounts, environments, and tags.
2. Require the volume to remain detached throughout the observation window.
3. Resolve the owner and show the last known attachment.
4. Create and verify a snapshot before any approved deletion.
5. Revalidate immediately before action and retain an audit trail.

Limitations and risks

Tags and CloudTrail retention may be incomplete. Snapshots reduce recovery risk but add cost and do not guarantee application-consistent data. The estimated opportunity should account for the retained snapshot and any incremental storage.

See how FinOps approvals can preserve accountability or review the idle RDS workflow.