Old Disk Snapshots in GCP: Why Stale Compute Engine Snapshots Are a Cost and Security Risk

Snapshots are easy to create and even easier to forget. A quick backup before a risky migration, a one-off copy of a production database, an automated job that never had a cleanup step. Months later you are left with a pile of disk snapshots nobody remembers creating, each one holding a frozen copy of whatever data lived on that disk at the time.

The Old Disk Snapshot check looks at your GCP Compute Engine snapshots and flags any that are more than 180 days old. It is a housekeeping signal with both a cost and a security angle.

---

What this check detects

Lensix inspects every Compute Engine disk snapshot in the projects it has access to and compares the snapshot creation timestamp against the current date. If a snapshot was created more than 180 days ago, it gets flagged.

The check does not assume the snapshot is useless. Plenty of teams keep long-term snapshots on purpose for compliance or disaster recovery. What it does is surface every old snapshot so a human can decide whether it still earns its place.

---

Why it matters

Cost creep

Snapshot storage is billed per GB-month. Individually the numbers look tiny, but they accumulate. A 500 GB disk snapshotted nightly with no retention policy turns into hundreds of GB of stored deltas within a few months. Multiply that across dozens of disks and several projects, and snapshot storage becomes a line item nobody can explain on the bill.

Data exposure surface

A snapshot is a full copy of your data at a moment in time. If that disk held a database, customer records, secrets, or credentials, the snapshot holds them too. An old snapshot from a now-deleted production VM can still contain sensitive data long after the original workload is gone.

Compliance drift

Retention rules cut both ways. Some regulations require you to delete personal data after a defined period. A snapshot taken 200 days ago that still contains user data may put you out of compliance with data minimization requirements like GDPR, even though the original disk is long gone.

---

How to fix it

1. List your old snapshots

Start by seeing what you actually have. This command lists snapshots with their creation timestamps so you can spot the old ones.

gcloud compute snapshots list \
  --format="table(name, diskSizeGb, creationTimestamp, sourceDisk)" \
  --sort-by=creationTimestamp

To filter programmatically for snapshots older than 180 days, use a date comparison:

CUTOFF=$(date -u -d '180 days ago' +%Y-%m-%dT%H:%M:%SZ)

gcloud compute snapshots list \
  --filter="creationTimestamp < '${CUTOFF}'" \
  --format="table(name, diskSizeGb, creationTimestamp)"

2. Verify before you delete

Check what each snapshot was made from and whether anything still depends on it. Look at labels, descriptions, and the source disk to understand the context.

gcloud compute snapshots describe SNAPSHOT_NAME \
  --format="yaml(name, sourceDisk, creationTimestamp, labels, description, storageBytes)"

3. Delete the ones you do not need

Delete a single snapshot:

gcloud compute snapshots delete SNAPSHOT_NAME --quiet

Delete a batch of old snapshots in one pass:

CUTOFF=$(date -u -d '180 days ago' +%Y-%m-%dT%H:%M:%SZ)

gcloud compute snapshots list \
  --filter="creationTimestamp < '${CUTOFF}'" \
  --format="value(name)" | \
  xargs -r -I {} gcloud compute snapshots delete {} --quiet

Console steps

1. Open the Google Cloud Console and go to Compute Engine, then Snapshots.
2. Click the Creation time column header to sort oldest first.
3. Select the snapshots you want to remove using the checkboxes.
4. Click Delete and confirm.

---

How to prevent it from happening again

Manual cleanup does not scale. The real fix is to make snapshots expire on their own and to stop creating orphans in the first place.

Use snapshot schedules with retention

GCP resource policies let you define a snapshot schedule with automatic retention. New snapshots created by the schedule are deleted once they pass the retention window, so they never become stale.

gcloud compute resource-policies create snapshot-schedule daily-30day \
  --region=us-central1 \
  --max-retention-days=30 \
  --start-time=02:00 \
  --daily-schedule \
  --on-source-disk-delete=apply-retention-policy

Attach the policy to a disk so it starts producing managed, self-expiring snapshots:

gcloud compute disks add-resource-policies my-disk \
  --zone=us-central1-a \
  --resource-policies=daily-30day

Bake it into Terraform

Define the schedule as code so every disk gets consistent retention without anyone remembering to click through the console.

resource "google_compute_resource_policy" "daily_backup" {
  name   = "daily-30day"
  region = "us-central1"

  snapshot_schedule_policy {
    schedule {
      daily_schedule {
        days_in_cycle = 1
        start_time    = "02:00"
      }
    }

    retention_policy {
      max_retention_days    = 30
      on_source_disk_delete = "APPLY_RETENTION_POLICY"
    }
  }
}

resource "google_compute_disk_resource_policy_attachment" "attach" {
  name = google_compute_resource_policy.daily_backup.name
  disk = google_compute_disk.app_data.name
  zone = "us-central1-a"
}

Catch manual snapshots

Ad hoc snapshots created by hand will never be covered by a schedule. Run a scheduled Cloud Function or a small cron job that flags any snapshot older than your threshold and posts to Slack, or rely on Lensix to surface them continuously so they never pile up silently.

---

Best practices

• Label every snapshot with intent. Add labels like owner, purpose, and expires so future-you can tell a deliberate compliance archive from a forgotten one-off.
• Match retention to the data. Short-lived dev disks rarely need more than a week of snapshots. Production data may need 30 to 90 days. Long-term archives belong in a deliberate, documented policy, not in scattered manual snapshots.
• Encrypt with customer-managed keys. Snapshots inherit encryption from their source disk. Using CMEK gives you the ability to revoke access to old data by rotating or disabling the key.
• Restrict snapshot permissions. The compute.disks.createSnapshot and compute.snapshots.useReadOnly permissions effectively grant read access to disk data. Keep them off broad roles and out of default service accounts.
• Review snapshot spend monthly. Add a billing budget alert or a regular cost report so snapshot storage growth gets noticed early rather than at audit time.
• Treat snapshots as data, not infrastructure. They fall under the same access reviews, retention rules, and data classification as the disks they came from.

The 180 day mark is not a hard rule, it is a prompt. Some of your old snapshots are doing exactly the job you want them to. The point of this check is to make sure every one of them is old on purpose, not by accident.