Google Compute Engine Resource Policy

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

google_compute_resource_policy (Terraform)

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

Example Usage from GitHub
resource "google_compute_resource_policy" "daily-backup" {
  project = var.project_id
  name   = "daily-backup"
  region = var.region
  snapshot_schedule_policy {
    schedule {
resource "google_compute_resource_policy" "vm" {
  name   = local.standardized_snapshot_schedule
  region = var.region

  snapshot_schedule_policy {
    schedule {
resource "google_compute_resource_policy" "server_snapshot" {
  name = "disk-policy"
  region = "europe-central2"
  snapshot_schedule_policy {
    schedule {
      hourly_schedule {
resource "google_compute_resource_policy" "snapshot" {
  name   = "snapshot"
  region = "asia-northeast1"
  snapshot_schedule_policy {
    schedule {
      weekly_schedule {
resource "google_compute_resource_policy" "hourly" {
  name        = "policy"
  region      = "europe-west3"
  description = "Start and stop instances"
  instance_schedule_policy {
    vm_start_schedule {

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).


  • id optional computed - string
  • name required - string

The name of the resource, provided by the client when initially creating the resource. The resource 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.

Region where resource policy resides.

  • self_link optional computed - string
  • group_placement_policy list block

    The number of availability domains instances will be spread across. If two instances are in different availability domain, they will not be put in the same low latency network

    Collocation specifies whether to place VMs inside the same availability domain on the same low-latency network. Specify 'COLLOCATED' to enable collocation. Can only be specified with 'vm_count'. If compute instances are created with a COLLOCATED policy, then exactly 'vm_count' instances must be created at the same time with the resource policy attached. Possible values: ["COLLOCATED"]

    Number of vms in this placement group.

  • snapshot_schedule_policy list block
    • retention_policy list block

      Maximum age of the snapshot that is allowed to be kept.

      Specifies the behavior to apply to scheduled snapshots when the source disk is deleted. Default value: "KEEP_AUTO_SNAPSHOTS" Possible values: ["KEEP_AUTO_SNAPSHOTS", "APPLY_RETENTION_POLICY"]

    • schedule list block
      • daily_schedule list block

        The number of days between snapshots.

        This must be in UTC format that resolves to one of 00:00, 04:00, 08:00, 12:00, 16:00, or 20:00. For example, both 13:00-5 and 08:00 are valid.

      • hourly_schedule list block

        The number of hours between snapshots.

        Time within the window to start the operations. It must be in an hourly format "HH:MM", where HH : [00-23] and MM : [00] GMT. eg: 21:00

      • weekly_schedule list block
        • day_of_weeks set block
          • day required - string

          The day of the week to create the snapshot. e.g. MONDAY Possible values: ["MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY", "SATURDAY", "SUNDAY"]

          Time within the window to start the operations. It must be in format "HH:MM", where HH : [00-23] and MM : [00-00] GMT.

    • snapshot_properties list block

      Whether to perform a 'guest aware' snapshot.

      • labels optional - map from string to string

      A set of key-value pairs.

      Cloud Storage bucket location to store the auto snapshot (regional or multi-regional)

  • timeouts single block

Explanation in Terraform Registry

A policy that can be attached to a resource to specify or schedule actions on that resource.

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 Resource Policy?

Google Compute Engine Resource Policy 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 Resource Policy?

For Terraform, the rwang249/terraform, jonathanrboniface/terraform-standards and InverMN/miencraft-server-infrastructure 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.