Google Compute Engine – Snapshot Retention Policy

The Google Compute Engine snapshot retention policy flags snapshot schedules that keep every snapshot they create, with no limit on age. Without a retention policy, Compute Engine keeps scheduled snapshots indefinitely, so snapshot storage costs grow every day the schedule runs. Set a retention policy on every snapshot schedule that runs on a recurring basis.

Why This Policy Matters

How It Helps Reduce Cloud Costs

A Google Compute Engine snapshot schedule creates standard snapshots of a Persistent Disk or Hyperdisk volume on an hourly, daily, or weekly cycle. Each snapshot is billed for the data it stores, every month it exists.

Google's documentation is explicit about the default. If a snapshot schedule has no retention policy, Compute Engine retains the snapshots indefinitely.

That turns a backup schedule into an ever-growing storage bill. A daily schedule adds roughly 30 snapshots a month to every attached disk, and none of them ever expire.

A retention policy fixes this at the source. The max_retention_days setting tells Compute Engine to delete scheduled snapshots once they pass a maximum age, so storage plateaus instead of climbing.

This is a common source of wasted spend in GCP projects. Teams set up a snapshot schedule once for disaster recovery and rarely look at it again.

Potential Savings

Google Compute Engine standard snapshots cost about $0.05 per GiB per month for regional storage in us-central1. Multi-regional standard snapshot storage costs about $0.083 per GiB per month. Rates vary by region.

Snapshots are incremental, so each new snapshot stores only the data that changed since the previous one. The cost of an unlimited schedule therefore depends on the disk's change rate and on how long the schedule has run.

These figures are an illustrative upper bound at the us-central1 regional rate. Compute Engine compresses snapshot data, so real stored bytes are usually lower.

The gap widens every month. A schedule with no retention policy never reaches a steady state, while a schedule with a retention policy does.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

In Terraform, a Google Compute Engine snapshot schedule is a google_compute_resource_policy resource with a snapshot_schedule_policy block. The schedule is attached to a disk with google_compute_disk_resource_policy_attachment.

Non-compliant configuration: snapshot schedule with no retention policy

resource "google_compute_disk" "data" {
  name = "app-data"
  type = "pd-balanced"
  zone = "us-central1-a"
  size = 500
}

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

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

    snapshot_properties {
      storage_locations = ["us-central1"]
    }
  }
}

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

resource "google_compute_disk" "data" {
  name = "app-data"
  type = "pd-balanced"
  zone = "us-central1-a"
  size = 500
}

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

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

    snapshot_properties {
      storage_locations = ["us-central1"]
    }
  }
}

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

resource "google_compute_disk" "data" {
  name = "app-data"
  type = "pd-balanced"
  zone = "us-central1-a"
  size = 500
}

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

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

    snapshot_properties {
      storage_locations = ["us-central1"]
    }
  }
}

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

This schedule creates a snapshot of app-data every day and never deletes one. Snapshot storage for this disk grows for as long as the schedule exists.

Compliant configuration: snapshot schedule with a retention policy

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

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

    retention_policy {
      max_retention_days    = 14
      on_source_disk_delete = "APPLY_RETENTION_POLICY"
    }

    snapshot_properties {
      storage_locations = ["us-central1"]
    }
  }
}

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

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

    retention_policy {
      max_retention_days    = 14
      on_source_disk_delete = "APPLY_RETENTION_POLICY"
    }

    snapshot_properties {
      storage_locations = ["us-central1"]
    }
  }
}

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

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

    retention_policy {
      max_retention_days    = 14
      on_source_disk_delete = "APPLY_RETENTION_POLICY"
    }

    snapshot_properties {
      storage_locations = ["us-central1"]
    }
  }
}

The retention_policy block is the only change. The google_compute_disk and google_compute_disk_resource_policy_attachment resources stay the same. The max_retention_days argument is required inside that block and sets the maximum age of a scheduled snapshot.

The on_source_disk_delete argument controls what happens after the source disk is deleted. The default, KEEP_AUTO_SNAPSHOTS, keeps scheduled snapshots indefinitely once the disk is gone. APPLY_RETENTION_POLICY keeps applying max_retention_days, so those snapshots still expire.

For a daily schedule, the Google provider requires days_in_cycle = 1 and a start_time of 00:00, 04:00, 08:00, 12:00, 16:00, or 20:00 UTC.

Step-by-Step Fix Instructions

1. Search Terraform code for google_compute_resource_policy resources that contain a snapshot_schedule_policy block.

2. Check each snapshot_schedule_policy block for a retention_policy block. Schedules without one keep snapshots indefinitely.

3. Agree on a recovery window with the disk's owner. Base max_retention_days on how far back the team actually restores, not on a guess.

4. Add a retention_policy block with max_retention_days set to that window.

5. Decide on on_source_disk_delete. Use APPLY_RETENTION_POLICY unless a disk's snapshots must outlive the disk.

6. Run terraform plan. Check whether the plan updates the resource policy in place or replaces it, and review any change to the attachment before applying.

7. Apply the change, then list existing scheduled snapshots with the gcloud commands below. Delete any old snapshots that fall outside the new recovery window and are no longer needed.

8. Add Infracost to CI/CD so new snapshot schedules without a retention policy are flagged in pull requests before they merge.

Best Practices

• Set retention_policy in shared Terraform modules for google_compute_resource_policy, with max_retention_days as a module variable that has a sensible default.

• Match retention to environment. Production disks usually need a longer recovery window than development or staging disks.

• Use shorter retention for hourly schedules. Hourly snapshots multiply quickly, and few teams restore from a 40-day-old hourly snapshot.

• Choose regional storage_locations when the recovery plan allows it. Regional standard snapshot storage costs less than multi-regional storage.

• Keep long-term or compliance backups out of short-cycle schedules. Those needs belong in a separate, deliberate backup process.

Tools and Scripts

How does Infracost detect Google Compute Engine snapshot schedules without a retention policy?

The Google Compute Engine snapshot retention policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks the Terraform changes in each pull request against enabled FinOps policies. A finding appears in the PR comment with the best practice, why it matters, and the exact file and line to change.

This moves the decision to code review. An engineer sees the missing retention policy before merge, not months later as a growing line item on the GCP bill.

Infracost also scans connected repositories for snapshot schedules already in code. FinOps and platform teams can burn down that backlog over time and track new issues prevented separately from existing issues fixed.

Each policy can warn engineers or block the pull request. Infracost AutoFix can also generate pull requests that fix policy failures, which engineers review before merge.

To find snapshot schedules in a Terraform codebase:

grep -rn "snapshot_schedule_policy" --include="*.tf" .
grep -rn "retention_policy" --include="*.tf"

grep -rn "snapshot_schedule_policy" --include="*.tf" .
grep -rn "retention_policy" --include="*.tf"

grep -rn "snapshot_schedule_policy" --include="*.tf" .
grep -rn "retention_policy" --include="*.tf"

To list scheduled snapshots that already exist in a project with the gcloud CLI:

gcloud compute snapshots list \
  --filter="autoCreated=true" \
  --sort-by=creationTimestamp \
  --format="table(name,sourceDisk.basename(),storageBytes,creationTimestamp)"

gcloud compute snapshots list \
  --filter="autoCreated=true" \
  --sort-by=creationTimestamp \
  --format="table(name,sourceDisk.basename(),storageBytes,creationTimestamp)"

gcloud compute snapshots list \
  --filter="autoCreated=true" \
  --sort-by=creationTimestamp \
  --format="table(name,sourceDisk.basename(),storageBytes,creationTimestamp)"

To inspect a snapshot schedule and confirm its retention settings:

gcloud compute resource-policies describe daily-backup --region

gcloud compute resource-policies describe daily-backup --region

gcloud compute resource-policies describe daily-backup --region

Examples of Impact

The Google Compute Engine snapshot retention policy pays off most on high-churn disks and long-running schedules.

Illustrative example: a database disk on a daily schedule. A platform team snapshots a 500 GiB database disk every day with no retention policy. After a year, the disk has about 365 snapshots. Adding max_retention_days = 14 and deleting the older snapshots cuts stored snapshot data to roughly two weeks of history.

Illustrative example: an hourly schedule in a dev project. A developer copies a production module with an hourly snapshot schedule into a development project. The schedule creates about 720 snapshots a month and keeps all of them. A short retention window on the development schedule removes nearly all of that growth.

(These are illustrative scenarios, not specific customer accounts.)

Considerations and Caveats

The Google Compute Engine snapshot retention policy is low risk when the recovery window is agreed in advance. It removes recovery points, so it needs an owner's sign-off.

• Deleted snapshots are gone. Once a snapshot passes max_retention_days, Compute Engine deletes it. Confirm the recovery window before applying.

• Source disk deletion default. The default on_source_disk_delete value, KEEP_AUTO_SNAPSHOTS, keeps snapshots indefinitely after the disk is deleted. That can be intentional for decommissioned systems, but it is also a common source of orphaned snapshot costs.

• Existing snapshots need review. Adding a retention policy does not guarantee that every older snapshot in the project is cleaned up. Review existing scheduled snapshots after the change.

• Compliance retention. Some regulations require backups for months or years. Those needs may justify longer retention or a separate archive process.

• Provider-specific. This policy targets Google Compute Engine through the google Terraform provider. AWS and Azure use different resources for scheduled disk snapshots.

Related Policies and Concepts

• Google Compute Engine - remove unattached disks: a Compute-group policy that removes Google Compute Engine storage spend on Persistent Disks no VM uses.

• Amazon CloudWatch - consider using a retention policy to reduce storage costs: the same retention discipline applied to log data in AWS.

• Amazon ECR - consider using a lifecycle policy: a policy that expires old container images automatically, the registry equivalent of snapshot retention.

• Amazon S3 - consider deleting or moving old objects to a cheaper storage class: a policy that limits how long data accumulates in object storage.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Google Compute Engine snapshot retention policy is supported in Infracost and available in the free trial. Infracost reports findings in pull requests, with the file and line to change.

Can this policy be customized?

Yes. Teams can configure how Infracost enforces the Google Compute Engine snapshot retention policy. A finding can warn engineers or block the pull request, and the policy can apply to newly added resources only.

Does Infracost automatically fix violations?

No. Infracost reports Google Compute Engine snapshot retention policy findings, and engineers add the retention policy themselves. Infracost AutoFix can also generate pull requests that fix policy failures, which engineers review before merge.

Is this policy cloud-agnostic?

No. The Google Compute Engine snapshot retention policy targets Google Cloud through the google Terraform provider. AWS and Azure use different resources and settings for scheduled disk snapshots.

What happens to Google Compute Engine snapshots without a retention policy?

Google Compute Engine keeps scheduled snapshots indefinitely when a snapshot schedule has no retention policy. Snapshot storage costs then grow for as long as the schedule runs.

How long should Google Compute Engine snapshots be retained?

Google Compute Engine snapshot retention should match the recovery window the team actually uses. Many teams keep daily snapshots for one to four weeks and handle long-term retention through a separate backup process.

How often should I review Google Compute Engine snapshot retention?

Teams running Infracost in CI/CD get a Google Compute Engine snapshot retention check on every pull request that touches a snapshot schedule. For existing schedules, a quarterly review of retention settings is a reasonable cadence for most teams.