Orphaned Cloud Resources: Detached, Unused, Parentless

Orphans are the leftovers of normal operations: the volume that stayed behind when an instance was terminated, the snapshot of a disk deleted last year, the public IP nobody released. They share one trait, a standing charge with no workload behind it, but they are not all the same fact, and ZopNight’s orphan rules say which fact they established.

Three kinds of orphan

Each orphan rule declares its case, and the recommendation title follows from it:

• Unattached: the rule proved the resource is detached from what it normally attaches to. Unattached GCP Persistent Disk and Unattached Azure Managed Disk are examples, both gated on a seven-day dwell so a disk mid-migration is not flagged.
• Unused: the resource is still live but measured non-use, such as an AWS KMS key with zero aliases and no crypto requests, or a CloudWatch dashboard last viewed 45 or more days ago.
• Orphaned: the parent or source is provably gone, as with an Orphaned EBS Snapshot whose source volume no longer exists and that no AMI references.

When a rule’s honest action is not a deletion, it says so in prose. S3 Incomplete Multipart Uploads Accumulating is filed as an orphan but asks for a lifecycle rule on a live bucket, not a delete. A rule that has not declared its case never inherits a generic “delete unattached” headline.

Residual cost counts too

Some orphan findings sit on resources that are stopped rather than detached. Stopped Standalone GCE VM and Deallocated Azure VM Residual Cost price only what keeps billing after the compute stopped: the attached disks and reserved IPs. If that residual is zero, the rule stays silent.

How deletes are gated

Orphan cleanup is where ZopNight can delete, so the safety gate is strict. A delete runs automatically only when the resource carries authoritative evidence: an IP explicitly not associated, a disk detached for at least seven days, a snapshot whose source is gone, or a recovery vault holding zero protected items. Stateful resources and anything without that evidence are demoted to advisory. Several cleanups, including unused Secrets Manager secrets and unused Key Vaults, are guided: they run through the wizard with a type-to-confirm review. Admin approval applies to destructive steps started by non-admins. More on the workflow in orphan cleanup.

By cloud

The per-cloud pages list the rules in detail: AWS orphans, GCP orphans and Azure orphans.

Every orphaned resource check ZopNight runs has its own page, with the reason it fires and the fix: see the orphaned resource checks in the ZopNight rule catalogue.