orphaned-cloud-resource-cleanup

Orphaned Cloud Resource Cleanup

Purpose

Every cloud account accumulates a background hum of resources that outlived the thing they were attached to: an EBS volume/managed disk left behind after its instance was terminated, an Elastic IP/Public IP reserved for a test that was never released, a load balancer or target group pointing at a service that was decommissioned months ago, a manual snapshot taken "just in case" before a change that was never cleaned up afterward. None of these show up as a dramatic cost spike — each is individually cheap — but collectively, across dozens of accounts and years of accumulation, they become a steady, invisible tax. This skill covers finding these specific classes of orphaned resource and removing them safely, with the non-negotiable discipline that "looks unattached" and "is confirmed unused" are not the same thing — a resource detached from its original parent can still be an intentional backup, a disaster-recovery artifact, or something a team meant to reattach next sprint.

When to use

• A recurring or one-off request to reduce cloud waste by cleaning up unattached storage, unused reserved IPs, or orphaned network resources.
• A cost review or cloud-cost-anomaly-investigation identifies a resource that appears unused and hands it off for confirmed, safe removal.
• Preparing an account/subscription for decommissioning and needing a complete sweep of everything left behind by long-terminated workloads.
• A cloud provider's own trusted-advisor/cost-recommendation tooling (AWS Trusted Advisor, Azure Advisor) flags idle resources and someone needs to action the list rather than let it sit.
• Setting up a recurring scheduled check for orphaned resources instead of a one-time manual sweep.

Prerequisites & environment

• Read access to list resources and their attachment state: AWS CLI (ec2, elb/elbv2) or Trusted Advisor, Azure CLI (az disk, az network public-ip, az network lb) or Azure Advisor, gcloud compute for the GCP equivalents (persistent disks, static external IP addresses, forwarding rules/load balancers).
• Delete/release permissions scoped narrowly to the resource types being cleaned up — not a broad admin role — per cloud-iam-hardening; a cleanup script should not be able to touch resources outside its stated scope.
• A tagging/labeling convention (owner, environment, decommission-date) to check before deleting anything — per cloud-cost-finops-optimization — since tag absence is itself a reason for extra caution, not a green light to delete faster.
• Awareness of, and a check against, any active disaster-recovery-and-backup-strategy plan for the account/subscription — DR-pattern resources (a pilot-light database replica, a cross-region backup vault, a manually retained pre-migration snapshot) can look identical to genuine orphans from a pure "is it attached right now" query.
• A grace-period/quarantine mechanism (a tag, a holding folder/resource group, or a "stop, don't delete" first pass) rather than immediate hard deletion for the first pass of any new cleanup process.