Google Compute Engine Snapshot

This page shows how to write Terraform for Compute Engine Snapshot and write them securely.

google_compute_snapshot (Terraform)

The Snapshot in Compute Engine can be configured in Terraform with the resource name google_compute_snapshot. The following sections describe 5 examples of how to use the resource and its parameters.

Example Usage from GitHub
resource "google_compute_snapshot" "snapshot_app" {
  name        = "usa-app-01-snapshot"
  source_disk = "usa-app-01"
  zone        = "us-west1-b"
  labels = {
    my_label = "app_vm_snapshot"
resource "google_compute_snapshot" "snapshot" {
  project = var.project_id
  name        =
  source_disk = var.source_disk_name
  zone        =
  storage_locations = var.location
resource "google_compute_snapshot" "secure" {
  name        = "secure"
  source_disk =
resource "google_compute_snapshot" "this" {
  description = var.description
  labels      = var.labels
  name        =
  project     = var.project
  source_disk = var.source_disk
resource "google_compute_snapshot" "no-deletion-protection" {
  name        = "no-deletion-protection"
  source_disk =

Review your Terraform file for Google best practices

Shisho Cloud, our free checker to make sure your Terraform configuration follows best practices, is available (beta).


Creation timestamp in RFC3339 text format.

An optional description of this resource.

Size of the snapshot, specified in GB.

The fingerprint used for optimistic locking of this resource. Used internally during updates.

  • labels optional - map from string to string

Labels to apply to this Snapshot.

  • licenses optional computed - list of string

A list of public visible licenses that apply to this snapshot. This can be because the original image had licenses attached (such as a Windows image). snapshotEncryptionKey nested object Encrypts the snapshot using a customer-supplied encryption key.

Name of the resource; provided by the client when the resource is created. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression 'a-z?' which means the first character must be a lowercase letter, and all following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash.

The unique identifier for the resource.

A reference to the disk used to create this snapshot.

A size of the storage used by the snapshot. As snapshots share storage, this number is expected to change with snapshot creation/deletion.

Cloud Storage bucket storage location of the snapshot (regional or multi-regional).

  • zone optional computed - string

A reference to the zone where the disk is hosted.

  • snapshot_encryption_key list block

    The name of the encryption key that is stored in Google Cloud KMS.

    The service account used for the encryption request for the given KMS key. If absent, the Compute Engine Service Agent service account is used.

    Specifies a 256-bit customer-supplied encryption key, encoded in RFC 4648 base64 to either encrypt or decrypt this resource.

    • sha256 optional computed - string

    The RFC 4648 base64 encoded SHA-256 hash of the customer-supplied encryption key that protects this resource.

  • source_disk_encryption_key list block

    The service account used for the encryption request for the given KMS key. If absent, the Compute Engine Service Agent service account is used.

    Specifies a 256-bit customer-supplied encryption key, encoded in RFC 4648 base64 to either encrypt or decrypt this resource.

  • timeouts single block

Explanation in Terraform Registry

Represents a Persistent Disk Snapshot resource. Use snapshots to back up data from your persistent disks. Snapshots are different from public images and custom images, which are used primarily to create instances or configure instance templates. Snapshots are useful for periodic backup of the data on your persistent disks. You can create snapshots from persistent disks even while they are attached to running instances. Snapshots are incremental, so you can create regular snapshots on a persistent disk faster and at a much lower cost than if you regularly created a full image of the disk. To get more information about Snapshot, see:

Tips: Best Practices for The Other Google Compute Engine Resources

In addition to the google_compute_disk, Google Compute Engine has the other resources that should be configured for security reasons. Please check some examples of those resources and precautions.



Ensure the encryption key for your GCE disk is stored securely

It is better to store the encryption key for your GCE disk securely. Secret Manager could be used instead.



Ensure your VPC firewall blocks unwanted outbound traffic

It is better to block unwanted outbound traffic not to expose resources in the VPC to unwanted attacks.



Ensure appropriate service account is assigned to your GCE instance

It is better to create a custom service account for the instance and assign it.



Ensure OS login for your GCE instances is enabled at project level

It is better to enable OS login for your GCE instances. Enabling OS login ensures that SSH keys used to connect to instances are mapped with IAM users, allowing centralized and automated SSH key management.



Ensure to use modern TLS protocols

It's better to adopt TLS v1.2+ instead of outdated TLS protocols.



Ensure VPC flow logging is enabled

It is better to enable VPC flow logging. VPC flow logging allows us to audit traffic in your network.

Review your Google Compute Engine settings

In addition to the above, there are other security points you should be aware of making sure that your .tf files are protected in Shisho Cloud.

Frequently asked questions

What is Google Compute Engine Snapshot?

Google Compute Engine Snapshot is a resource for Compute Engine of Google Cloud Platform. Settings can be wrote in Terraform.

Where can I find the example code for the Google Compute Engine Snapshot?

For Terraform, the xmano/intercontinental-vm-migration, savitapal8/pocs_repos and security-assesment/cloud-whitebox-vulndb source code examples are useful. See the Terraform Example section for further details.


Automate config file reviews on your commits

Fix issues in your infrastructure as code with auto-generated patches.