Orphaned EBS Volume
1
1
low
What does ZopNight detect here?
Unattached EBS volumes recover their full priced monthly cost on deletion once they have sat in the available state for at least 7 days, the orphanSince dwell gate that suppresses mid-provisioning volumes. ZopNight abstains on Kubernetes CSI-tagged volumes, cedes ownership when an abandoned EKS cluster rec already counts the volume, and skips unpriced rows.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-002 |
| Category | orphan |
| Severity | low |
| Metric | none — pure configuration read |
| Source | orphan_ebs.go |
Where it applies
When an unattached volume counts as orphaned
- resource.Status: available
- not Kubernetes-managed (kubernetes.io/* CSI tags => abstain, since deleting would strand the pod that provisioned the PVC)
- RC-043 cede (2026-07, cross-resource): given EvaluationContext, RC-002 skips an available volume that RC-043 already folds into an abandoned EKS cluster’s node-group rec: it backs a Released/Available eks-pv (csiVolumeHandle == vol-id) whose cluster has an abandoned node group, and it is priced (ebsVolumeCededToRC043). This makes RC-043 the single owner of that recoverable cost (no double-count with RC-043, Principle 6) and closes the static-PV gap the kubernetes.io/* tag heuristic above misses. Without context RC-043 abstains, so RC-002 stays the sole owner.
- 7-day dwell gate (2026-07 audit, RC-212 pattern): when the discoverer stamps Metadata[“orphanSince”] (aws ebs.go sets it to the volume’s CreateTime for every unattached volume), the volume must have carried it ≥7d (orphanEBSMinDwell) before firing, which suppresses just-created / mid-provisioning volumes. Absent/unparseable timestamp => the status check alone stands (the gate only ever reduces firing). The emitted rec carries OrphanSince. Residual producer gap: AWS exposes no detach timestamp, so for a previously-attached volume orphanSince == CreateTime and an old volume detached seconds ago still passes; closing that needs a discoverer first-observed-unattached stamp under the same key.
Why deleting recovers the full volume cost
an available volume is still billed at the same per-GB-month storage rate as an attached one, so its full priced cost is recoverable on delete: SavingsUSD = pricing[uid] × 1.00, OptimizedCostUSD = 0; abstains when pricing is absent/≤0 (no $0 recs).
Snapshot first, then delete
- Check if any snapshots exist for this volume
- Create a snapshot if data may be needed later
- Delete the unattached volume via EC2 Console → Volumes