Orphan Resource Cleanup with Evidence-Gated Deletes

What counts as an orphan

An orphan finding means the thing a resource existed for is gone, but the resource still bills. ZopNight’s orphan rules cover block storage, addresses, snapshots, keys, secrets and network plumbing. Examples from the rule catalog:

• Orphaned EBS Volume and Unattached GCP Persistent Disk and Unattached Azure Managed Disk
• Unassociated Elastic IP and Azure Public IP Not Associated
• Orphaned EBS Snapshot, GCP Old Disk Snapshot, Orphaned Azure Snapshot
• Unused KMS Key, Unused Secrets Manager Secret, Azure Key Vault Unused
• WAF Web ACL Without Associated Resources, Azure NSG Not Associated with Any Resource, Azure VNet Peering Disconnected
• Kubernetes leftovers: Unbound PVC, Released PersistentVolume, Service With No Endpoints

Not every orphan-category finding asks for a delete. S3 Incomplete Multipart Uploads Accumulating asks for a lifecycle rule on a bucket that is still in use, and the recommendation title says so instead of printing a generic “delete unattached” line. Each rule declares whether its resource is unattached, unused, or orphaned from a parent that no longer exists, and the title follows that declaration.

The evidence bar for a delete

A delete cannot be undone, so ZopNight treats it differently from every other lever:

• Detached long enough. A disk qualifies for an automatic delete only when the control plane shows it detached for at least seven days, which keeps a volume that is mid-migration off the list.
• Source provably gone. A snapshot qualifies when its source disk no longer exists.
• No association. An IP qualifies when the provider reports no instance, interface or gateway using it.
• Kubernetes-managed volumes are skipped. An EBS volume created for a PVC is left alone, because deleting it would strand the pod.

Where the evidence is missing, the finding is still shown, as advisory. AWS exposes no detach timestamp for EBS, so orphaned EBS volumes stay advisory. Orphaned EBS snapshots are guided, with type-to-confirm, because a snapshot can still back an AMI.

Most cleanup deletes run as guided workflows with a type-to-confirm review, and a non-admin who starts one needs an admin to approve it. One-click is kept for deletes backed by hard evidence: an unassociated public IP, a GCP or Azure disk the control plane shows detached for at least seven days, or an empty Azure backup vault.

Where to go next

The resource fact sheets explain each type’s billing: EBS volumes, Elastic IPs, GCP persistent disks and Azure public IPs. The full family is on orphan recommendations, and the workflow mechanics are on auto-remediation.