Google Compute Engine – Consider a Preferred Instance Type

The Google Compute Engine preferred instance type policy restricts Google Compute Engine VMs to an approved list of machine types that meets your organization's cost, performance, and support requirements. Without that list, engineers set machine_type ad hoc, which leads to oversized VMs, usage outside committed use discounts, and unpredictable Google Cloud spend. Use this policy when several teams provision Compute Engine through Terraform and you want machine type choices to follow one standard.

Why This Policy Matters

How does a preferred machine type list reduce Google Cloud costs?

Google Compute Engine offers general-purpose series such as E2, N2, and N2D, plus compute-optimized, memory-optimized, and accelerator-optimized families. Every predefined size in every series is a valid value for machine_type in Terraform.

That freedom is the problem. Engineers copy a machine type from an old module, a tutorial, or a production stack, and nobody checks whether the workload needs it.

A Google Compute Engine preferred instance type policy narrows the choice to a short list your platform team has already vetted for price, performance, and support. This policy turns machine type selection from a per-engineer guess into an organization-wide standard.

A preferred list also protects commitment discounts. Resource-based committed use discounts in Google Cloud are purchased for a specific machine series in a specific region. VMs that drift to a different series fall outside that coverage and bill at on-demand rates.

This policy is most useful in multi-team Google Cloud organizations. A single team running a handful of VMs gets less value from a formal list.

Potential Savings

The Google Compute Engine preferred instance type policy saves money mainly by preventing oversizing and by keeping usage inside existing commitments.

The size gap inside a single machine series is large. On-demand Linux pricing in us-central1 (Iowa) shows how quickly cost scales with size.

Monthly figures assume 730 hours at on-demand list prices, before sustained use discounts. N2 VMs that run most of the month receive automatic sustained use discounts, so actual bills can be lower. E2 VMs do not receive sustained use discounts. Prices vary by region.

A development VM launched as n2-standard-16 when n2-standard-2 would do wastes about $496 per month. Ten of those across a few teams add up to nearly $60,000 per year.

Actual savings depend on how far current usage has drifted from a sensible standard. Organizations with no machine type guardrails usually see the largest gains.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show a Google Compute Engine VM using a machine type outside the approved list, and the corrected configuration that enforces the list in Terraform.

Non-compliant configuration: unrestricted machine type

variable "machine_type" {
  type    = string
  default = "n2-standard-16"
}

resource "google_compute_instance" "api" {
  name         = "api-dev-01"
  machine_type = var.machine_type
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  labels = {
    environment = "dev"
  }
}

variable "machine_type" {
  type    = string
  default = "n2-standard-16"
}

resource "google_compute_instance" "api" {
  name         = "api-dev-01"
  machine_type = var.machine_type
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  labels = {
    environment = "dev"
  }
}

variable "machine_type" {
  type    = string
  default = "n2-standard-16"
}

resource "google_compute_instance" "api" {
  name         = "api-dev-01"
  machine_type = var.machine_type
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  labels = {
    environment = "dev"
  }
}

Any value passes here, including a 16 vCPU VM for a development API. This is a common source of wasted spend, because the default gets copied into every new environment.

Compliant configuration: approved machine types enforced with a validation block

variable "machine_type" {
  type        = string
  default     = "e2-standard-4"
  description = "Must be an approved Google Compute Engine machine type."

  validation {
    condition     = contains(["e2-standard-2", "e2-standard-4", "n2-standard-2", "n2-standard-4"], var.machine_type)
    error_message = "machine_type must be one of: e2-standard-2, e2-standard-4, n2-standard-2, n2-standard-4."
  }
}

resource "google_compute_instance" "api" {
  name                      = "api-dev-01"
  machine_type              = var.machine_type
  zone                      = "us-central1-a"
  allow_stopping_for_update = true

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  labels = {
    environment = "dev"
  }
}

variable "machine_type" {
  type        = string
  default     = "e2-standard-4"
  description = "Must be an approved Google Compute Engine machine type."

  validation {
    condition     = contains(["e2-standard-2", "e2-standard-4", "n2-standard-2", "n2-standard-4"], var.machine_type)
    error_message = "machine_type must be one of: e2-standard-2, e2-standard-4, n2-standard-2, n2-standard-4."
  }
}

resource "google_compute_instance" "api" {
  name                      = "api-dev-01"
  machine_type              = var.machine_type
  zone                      = "us-central1-a"
  allow_stopping_for_update = true

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  labels = {
    environment = "dev"
  }
}

variable "machine_type" {
  type        = string
  default     = "e2-standard-4"
  description = "Must be an approved Google Compute Engine machine type."

  validation {
    condition     = contains(["e2-standard-2", "e2-standard-4", "n2-standard-2", "n2-standard-4"], var.machine_type)
    error_message = "machine_type must be one of: e2-standard-2, e2-standard-4, n2-standard-2, n2-standard-4."
  }
}

resource "google_compute_instance" "api" {
  name                      = "api-dev-01"
  machine_type              = var.machine_type
  zone                      = "us-central1-a"
  allow_stopping_for_update = true

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  labels = {
    environment = "dev"
  }
}

The validation block makes terraform plan fail when a caller passes a machine type outside the list. The allow_stopping_for_update argument lets Terraform stop the VM to apply a new machine type; without it, the update fails.

A validation block only protects modules that use it. Machine types hardcoded elsewhere still slip through.

The same rule applies to instance templates used by managed instance groups:

resource "google_compute_instance_template" "workers" {
  name_prefix  = "workers-"
  machine_type = "e2-standard-4" # previously "n2-standard-16"

  disk {
    source_image = "debian-cloud/debian-12"
    boot         = true
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_instance_template" "workers" {
  name_prefix  = "workers-"
  machine_type = "e2-standard-4" # previously "n2-standard-16"

  disk {
    source_image = "debian-cloud/debian-12"
    boot         = true
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_instance_template" "workers" {
  name_prefix  = "workers-"
  machine_type = "e2-standard-4" # previously "n2-standard-16"

  disk {
    source_image = "debian-cloud/debian-12"
    boot         = true
  }

  network_interface {
    subnetwork = google_compute_subnetwork.private.id
  }

  lifecycle {
    create_before_destroy = true
  }
}

Instance templates are immutable, so changing machine_type creates a new template. The managed instance group then needs a rolling update to move existing VMs onto it.

Step-by-Step Fix Instructions

1. Agree on an approved Google Compute Engine machine type list with platform, FinOps, and application owners. Separate lists for production and non-production are common.

2. Search Terraform code for every machine_type value on google_compute_instance and google_compute_instance_template, including variable defaults and .tfvars files. Google Kubernetes Engine node pools also set machine_type inside the node_config block of google_container_node_pool.

3. Compare each value against the approved list and flag every mismatch.

4. For each mismatch, check CPU and memory utilization in Cloud Monitoring before choosing the replacement machine type.

5. Change the machine_type value, set allow_stopping_for_update = true on standalone VMs, and run terraform plan.

6. Apply the change during a maintenance window, then validate the workload. For managed instance groups, roll out the new instance template.

7. Add validation blocks to shared modules, and add Infracost to CI/CD so new non-approved machine types are flagged in pull requests.

Best Practices

• Keep the approved list short. A list with 40 machine types gives engineers little guidance.

• Allow whole series for non-production, such as all E2 sizes, and exact sizes for production.

• Align the list with existing committed use discounts, so new VMs land inside committed capacity.

• Include current-generation series only. A preferred list that still contains older series locks in worse price performance.

• Decide whether custom machine types are allowed. Custom shapes are valid in Google Compute Engine, but they make a preferred list harder to enforce.

• Document an exception path. GPU, memory-optimized, and high-performance workloads need types outside a general list, and a blocked engineer with no exception path will route around the policy.

• This policy sets the boundary of acceptable choices. It does not replace rightsizing inside that boundary.

Tools and Scripts

How does Infracost detect non-approved Google Compute Engine machine types automatically?

The Google Compute Engine preferred instance type policy is available in Infracost, including in the free trial. Teams enable the policy named "General - consider using preferred instance types" in Infracost Cloud under Governance > FinOps policies, then enter approved region and instance type pairs, one per line, with each region and instance type separated by a colon.

Infracost supports * wildcards in that list to match any region or any instance type. More specific patterns override broader ones, so a team can allow a series everywhere and still restrict one region.

When Infracost runs in CI/CD, it checks Google Compute Engine resources in each pull request. Any machine type outside the approved list appears in the PR comment, so the engineer fixes it before merge rather than after deployment.

Teams choose whether a policy failure warns the engineer or blocks the pull request. They can also limit checks to new resources, so an unrelated pull request does not force a disruptive machine type change on a running VM.

Infracost also scans connected repositories for non-approved machine types already in code. FinOps and platform teams can burn down that backlog over time and measure progress, tracking issues prevented before merge separately from existing issues fixed.

To list machine types already set in Terraform code:

grep -rnE 'machine_type\s*=' --include="*.tf" --include="*.tfvars"

grep -rnE 'machine_type\s*=' --include="*.tf" --include="*.tfvars"

grep -rnE 'machine_type\s*=' --include="*.tf" --include="*.tfvars"

To count running Google Compute Engine VMs by machine type with the gcloud CLI:

gcloud compute instances list \
  --filter="status=RUNNING" \
  --format="value(machineType.basename())" | sort | uniq -c | sort -rn

gcloud compute instances list \
  --filter="status=RUNNING" \
  --format="value(machineType.basename())" | sort | uniq -c | sort -rn

gcloud compute instances list \
  --filter="status=RUNNING" \
  --format="value(machineType.basename())" | sort | uniq -c | sort -rn

Examples of Impact

The Google Compute Engine preferred instance type policy has the most impact where many engineers provision infrastructure independently.

Illustrative example: oversized development stacks. A shared Terraform module defaults to n2-standard-16, and six teams use it for development environments. Switching the module default to e2-standard-4 cuts each development VM from about $567 to about $98 per month at on-demand list prices.

Illustrative example: commitment drift. A platform team buys N2 committed use discounts in us-central1. New services then launch on a mix of N2D and C2 VMs. Adding N2 types to the preferred list steers new services that fit N2 onto the committed capacity, so they stop billing at on-demand rates.

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

Considerations and Caveats

The Google Compute Engine preferred instance type policy is only as good as the list behind it, and a stale list causes more harm than no list.

• Specialized workloads. GPU, memory-optimized, and compute-optimized workloads often need machine types outside a general list. Plan an exception process.

• List maintenance. Google Cloud releases new machine series regularly. Review the approved list at least quarterly.

• Restart required. Changing machine_type on an existing google_compute_instance stops and starts the VM, and fails unless allow_stopping_for_update is set.

• Coverage gaps. A Terraform validation block only guards modules that include it. Infracost checks pull requests in every connected repository, including code that bypasses shared modules.

• Provider-specific. This page covers Google Compute Engine through the google Terraform provider. Amazon EC2 and Azure Virtual Machines use different resource and attribute names.

Related Policies and Concepts

• Amazon EC2 - Consider using a preferred instance type: the same approved-list approach applied to instance_type on Amazon EC2 instances and launch templates.

• Azure Virtual Machines - Consider using a preferred instance type: the Azure equivalent for restricting VM sizes to an approved list.

• Google Compute Engine - Consider using predefined machine types: a related Compute-group policy that standardizes machine shapes instead of allowing custom sizes.

• Google Compute Engine - consider using current generation machine types: a related policy that keeps VMs on newer series, useful when deciding which series belong on a preferred list.

• Google Compute Engine - consider using a retention policy for snapshots: another Google Compute Engine cost policy that targets waste left behind by VM fleets.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Google Compute Engine preferred instance type policy is supported in Infracost and available in the free trial. Infracost flags Google Compute Engine machine types outside the approved list in pull requests, before the change merges.

Can this policy be customized?

Yes. Customization is the core of the Google Compute Engine preferred instance type policy. Teams define the approved list in Infracost as region and instance type pairs, one per line, with wildcards for broader rules. Teams also choose whether a violation warns the engineer or blocks the pull request.

Does Infracost automatically fix violations?

Infracost reports each Google Compute Engine machine type outside the preferred list in the pull request, so the engineer knows exactly which resource to change. Choosing the right approved machine type still depends on the workload's CPU and memory needs, so engineers review and apply the change.

Is this policy cloud-agnostic?

No. This page covers the Google Compute Engine preferred instance type policy for the google Terraform provider. Infracost applies the same preferred instance type approach to Amazon EC2 and Azure Virtual Machines, each with its own instance type names.

Do I need to restart a VM to change its Google Compute Engine machine type?

Yes. Changing machine_type on a running Google Compute Engine VM requires stopping the instance. In Terraform, set allow_stopping_for_update to true on google_compute_instance, or the update fails. Plan the change for a maintenance window.

How often should I review the Google Compute Engine preferred instance type list?

Review the Google Compute Engine preferred instance type list at least quarterly, and whenever Google Cloud releases a new machine series. An outdated preferred list can push teams toward older, more expensive machine types.