GCP Old Disk Snapshot
1
1
low
What does ZopNight detect here?
GCE disk snapshots older than 90 days are flagged for retention review. A source-disk-deleted flag also qualifies, though no producer stamps that flag today. Savings equal the snapshot's storage cost, GB times the per-GB rate; unreadable creation timestamps or missing pricing cause the rule to abstain.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-143 |
| Category | orphan |
| Severity | low |
| Metric | none — pure configuration read |
| Source | disk_snapshot_old.go |
Where it applies
Creation timestamp, with a deleted-source hook
- resource.Metadata: creation_timestamp (canonical sink, written by buildSnapshotMetadata), with a fallback read of the same key from resource.Tags (legacy mirror, mapGCPSnapshot). RFC3339 and date-only (2006-01-02) formats are both accepted. Abstains when neither sink yields a timestamp or a firing signal.
- resource.Metadata: source_disk_deleted==“true” (via MetadataStateMatches, Metadata-only, fail-safe): a forward-compatible orphan hook. No producer stamps this per-snapshot flag today: the GCP discoverer (gcp/snapshot.go) only ever emits a standalone gcp-snapshot when the source disk still exists; a snapshot whose source disk was deleted is instead rolled into the separate gcp-snapshot-orphan aggregate type. The branch stays wired for when/if a per-snapshot flag is added, but never fabricates a signal.
- Fires when source_disk_deleted==“true” or age > 90 days; abstains on existence alone, on an unreadable timestamp, or when GB×rate pricing is missing/zero.
Snapshot storage priced per GB
fixed estimate: snapshot storage cost (GB × per-GB rate) looked up by resource UID; abstains (no recommendation) when pricing is unavailable or zero.
Deleting past retention, then automating it
- Open Compute Engine Console → Snapshots
- Review the creation date and source disk of each snapshot
- Verify the source disk still exists and the snapshot is within your retention policy
- Delete snapshots that are beyond retention or whose source disk has been deleted
- Consider using snapshot schedules to automate retention management
No metrics, just age past 90 days
None (gate: source-disk-deleted flag OR creation age > 90d, read Metadata-first with Tags fallback for age; STORAGE snapshot GB × rate, concrete-or-abstain)