1. Assessment

  • List EBS volumes and metadata
  • Identify unattached volumes and assess safety
  • List snapshots for candidate volumes
  • User: review and approve snapshot/delete actions

2. Configuration

  • Create snapshots for approved volumes
  • Delete approved unattached volumes

3. Validation

  • Verify snapshots created and volumes deleted
1 Credits

Clean Up Unattached EBS Volumes

Overview

Identify EBS volumes that are not attached to running resources, capture safe backups when required, and remove truly unused volumes to reclaim capacity and reduce cost. This plan will enumerate all EBS volumes and their associations, evaluate unattached candidates against safety rules (tags, snapshots, age, ownership, groupings), present recommended actions and options for snapshots/deletion for your review, collect explicit approvals and execution preferences, perform snapshot creation and/or volume deletions per your instructions, and finally verify and produce auditable reports for each step.

Execution Details

Assessment

  • Inventory all EBS volumes and metadata across the target account/region: IDs, types, size, encryption/KMS, multi‑attach attributes, creation time, tags, attachment arrays, and provider-specific fields. Record API request IDs, timestamps and any enumeration anomalies for audit.
  • Resolve attachment targets (Instance/ENI/NAT Gateway/other) and mark volumes attached-to-terminated resources. Compute derived fields (ageDays) and produce a machine-readable volume inventory (JSON) and summary aggregates (counts by state/type, total GiB, protective-tag counts).
  • Identify unattached candidates using a documented rule (e.g., State == "available" or empty attachments or attachments resolve to terminated). Apply safety checks per candidate: snapshot existence, created-from-snapshot/AMI, protective tags (do-not-delete/retain), owner/contact tags, age thresholds, and group/share indicators. Perform a live re-check immediately before finalizing candidates to avoid race conditions.
  • For candidate volumes, enumerate existing snapshots (including metadata, encryption/KMS, retention tags, and whether snapshots appear to be from automated backup policies). Produce machine-readable artifacts: candidate list and VolumeId→snapshot mapping, plus per-volume recommendations labeled (safe-to-delete, snapshot-required-before-delete, requires-owner-confirmation, do-not-delete) with rationale and evidence.

User review & approval

  • Deliver the candidate inventory and snapshot mapping for user review. Guide you through options and collect explicit, machine-readable decisions per volume: keep, create-snapshot-then-delete, or delete-without-snapshot.
  • Collect snapshot parameters (description, tags, encryption/KMS choices), retention and naming conventions, owner approval evidence (identity or ticket), change window/schedule, and execution preferences (stop-on-first-error vs continue, parallelism, wait-for-snapshot-completion vs immediate-delete).
  • Validate user-provided KMS choices and require explicit irreversibility acknowledgements for deletions without snapshots. Perform a final live pre-approval check and persist an approval artifact containing approver identity, timestamps, per-volume actions, and conditional approvals.

Configuration / Execution

  • Create snapshots for approved volumes per the approval artifact: perform final pre-checks, validate snapshot parameters (including KMS), initiate snapshots, record SnapshotIds and API metadata, and optionally wait for completion or proceed immediately per user preference. Support requested cross-region or cross-account copies and record copy-task metadata.
  • Delete approved unattached volumes after final live pre-delete checks, respecting change windows, pre-delete tagging/annotation requests, owner notifications, and the chosen error policy. Capture full API responses, produce per-volume deletion logs, and persist a deletion-result artifact that lists deleted/skipped/failed items with remediation suggestions.

Validation

  • Verify snapshot and deletion outcomes by checking expected SnapshotIds and expected deletions. Confirm snapshot states, encryption/KMS settings, sizes and tags; confirm deleted volumes no longer appear in inventory.
  • Produce a consolidated verification report (machine-readable) with per-item expected vs actual state, API request IDs/timestamps, pass/fail status, diffs and remediation steps for failures or inconsistencies.
  • Link verification results to the approval, snapshot-result, and deletion-result artifacts for a complete audit trail and return a final status: completed or requires manual remediation.

Artifacts & Audit Trail

  • Machine-readable artifacts are produced and persisted at each major step: full EBS inventory, candidate list, VolumeId→snapshot mapping, approval artifact, snapshot-result artifact, deletion-result artifact, and final verification report.
  • Every API interaction and live check records request IDs, timestamps, and exact error messages when present. Recommendations and remediation steps are captured for failures, and approver identities and timestamps are embedded in the audit trail.

This plan emphasizes conservative safety checks (protective tags, owner confirmations, snapshot preservation), explicit user approvals and scheduling, comprehensive logging of API metadata for traceability, and clear remediation paths for any inconsistencies.