Skip to main content
orphan · azure

Orphaned Azure Snapshot

resource types
1
rule IDs covered
1
severity
low

What does ZopNight detect here?

Snapshots whose source managed disk has been deleted are rolled up per subscription and region; the rule fires when the rollup is active with more than 0 orphan snapshots and a positive priced cost. Savings equal the rollup's price: provisioned GB times the per-GB rate times 730. That is an upper-bound estimate.

Signal and threshold

How ZopNight evaluates Orphaned Azure Snapshot.
Field Value
Rule IDsRC-242
Categoryorphan
Severitylow
Metricnone — pure configuration read
Sourcesnapshot_orphan.go

Orphan snapshots arrive as a regional rollup

  • Re-keyed onto the discoverer’s per-subscription+region ROLLUP resource of type azure-snapshot-orphan (snapshots whose source disk has been deleted are aggregated into this rollup rather than surfacing as a standalone parentless azure-snapshot). Gates: resource.Status EqualFold “active” and resource.UnitCount > 0 (number of orphan snapshots aggregated into the rollup). resource.SizeGB, when present, is included in the recommendation text.

Provisioned size as an upper bound estimate

The rule is concrete or it abstains. CurrentCostUSD = SavingsUSD = r.pricing[UID], OptimizedCostUSD = 0; abstains (returns nil) when pricing is missing or ≤ 0; it never emits a zero-cost recommendation. The pricing layer prices the rollup on SizeGB × snapshot-standard per-GB rate × 730 (service.go buildResourceCostMap), where SizeGB is the sum of each orphan snapshot’s provisioned diskSizeGB. Azure bills managed-disk snapshots on used/delta data size, not provisioned capacity, so for sparse/large disks this is a directionally-correct upper-bound estimate of the true bill, not an exact figure. Byte-accurate billed size is not available from the discoverer’s current Resource Graph query (properties.diskSizeGB is always provisioned capacity) and would require a separate Azure Cost Management / Consumption Usage Details producer keyed by snapshot resourceId, which is out of scope for this rule.

Deleting snapshots after checking dependents

  1. Confirm the source disks have been deleted and the data is no longer needed
  2. If data may be required, create a new managed disk from the snapshot first
  3. Go to Azure Portal → Snapshots → filter by region → Select → Delete
  4. Verify no restore points or images depend on these snapshots

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·