Unused Volumes Policy#
The Unused Volumes policy automatically detects and removes unattached (orphaned) storage volumes across Azure, AWS, and GCP. These volumes accumulate over time when compute resources are deleted without cleaning up their attached disks, and continue to generate cost with no associated workload.
Navigate: left navigation → Automation → Policies → “+ New Policy”.
How it works#
When the policy fires, it scans all storage volumes within the configured scope and identifies volumes that have no active attachment to a running compute instance. Each orphaned volume is then deleted. Volumes that are attached are always skipped — only genuinely unattached volumes are removed.
Supported resource types#
Provider |
Resource type |
|---|---|
Azure |
Managed Disks ( |
AWS |
EBS Volumes with |
GCP |
Persistent Disks with no users (not attached to any Compute Engine instance) |
Creating an Unused Volumes policy#
Navigate to Automation → Policies → “+ New Policy”
Set Policy type = Unused Volumes
Set Scope — select a Group, Environment, or Project from the Allocation hierarchy; the policy applies to all matching volumes within that scope
Set the Schedule using the cron picker (see Create Automation Policies for schedule examples)
Click Save
Warning
This policy deletes cloud storage volumes permanently. Ensure the scope is correct before saving. Deleted volumes cannot be recovered unless a snapshot or backup exists.
Recommended workflow#
Tip
Run Unused Volumes on a weekly schedule rather than daily. This gives engineers time to notice and reclaim accidental orphans before the policy removes them. A monthly snapshot strategy provides a recovery safety net.
Audit first — trigger the policy manually on first run and review the execution history before enabling a schedule. This surfaces any volumes that may still be needed.
Scope tightly — scope to non-production environments first (e.g. Dev or Staging groups in your Allocation hierarchy) and expand to production only after validating results.
Pair with snapshots — configure a cloud-native snapshot policy (Azure Backup, AWS Data Lifecycle Manager, GCP Scheduled Snapshots) on volumes before enabling automated deletion in production.
Execution results#
After each run, each volume shows one of:
Result |
Meaning |
|---|---|
Processed |
Volume was identified as unattached and deleted successfully |
Skipped |
Volume is currently attached to a compute instance — no action taken |
Failed |
Deletion failed — usually a permissions issue or a provider-level lock on the volume |
Warning
Failed results typically mean the cloud connection’s service principal or IAM role lacks the required delete permissions:
Azure:
Microsoft.Compute/disks/deleteaction on the subscription or resource groupAWS:
ec2:DeleteVolumepermission in the IAM policyGCP:
compute.disks.deletepermission on the project
Review the connection permissions in Tenant → Connections.
Policy credits#
Each volume deleted by an Unused Volumes policy consumes one policy credit. Each tenant has a monthly credit allowance (see your quota in Tenant → Quota). Credits reset on the first day of each month.
If the tenant reaches its monthly credit limit mid-run, remaining volumes in that execution are skipped with a CreditLimitReached status.