Google Compute Engine – Consider Predefined Machine Types

The Google Compute Engine predefined machine types policy flags VMs that use a custom machine type where a predefined machine type fits the same shape. Google charges a 5% on-demand premium for custom machine types, so a duplicated shape adds cost without adding capacity. Use a custom machine type only when no predefined machine type fits the workload's vCPU, memory, or licensing needs.

Why This Policy Matters

How It Helps Reduce Cloud Costs

A Google Compute Engine custom machine type lets a team pick an exact number of vCPUs and an exact amount of memory. Custom machine types are available on the N4, N4D, N4A, N2, N2D, E2, and N1 general-purpose series, plus the accelerator-optimized G2 series.

Google prices that flexibility. Per Google's general-purpose VM pricing page, on-demand prices for custom machine types include a 5% premium over the on-demand prices for standard machine types.

The premium only makes sense when the custom shape buys something a predefined machine type cannot provide. Many custom machine types in Terraform code reproduce a predefined shape exactly, such as 4 vCPUs with 16 GB of memory. In that case the team pays 5% more for an identical VM.

This is a common source of wasted spend in long-lived GCP projects. A custom machine type often enters a shared module during early sizing experiments and is never revisited.

Potential Savings

Moving a Google Compute Engine VM from a custom to a matching predefined machine type removes the 5% custom premium.

Figures use Google's default N4 on-demand list rates for custom vCPU, custom memory, and n4-standard-4. Prices vary by region, machine series, and purchase option.

One instance saves about $6.60 per month, or roughly $80 per year. The saving is small per VM. It scales linearly with fleet size, so 50 matching instances save roughly $4,000 per year for a one-line change each.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show a Google Compute Engine VM on a custom machine type that duplicates a predefined shape, and the corrected configuration.

Non-compliant configuration: custom machine type with a predefined shape

resource "google_compute_instance" "api" {
  name                      = "api-01"
  zone                      = "us-central1-a"
  machine_type              = "n4-custom-4-16384"
  allow_stopping_for_update = true

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

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance" "api" {
  name                      = "api-01"
  zone                      = "us-central1-a"
  machine_type              = "n4-custom-4-16384"
  allow_stopping_for_update = true

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

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance" "api" {
  name                      = "api-01"
  zone                      = "us-central1-a"
  machine_type              = "n4-custom-4-16384"
  allow_stopping_for_update = true

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

  network_interface {
    network = "default"
  }
}

This configuration pays the 5% custom machine type premium for 4 vCPUs and 16 GB of memory, which n4-standard-4 already provides.

Compliant configuration: predefined machine type

resource "google_compute_instance" "api" {
  name                      = "api-01"
  zone                      = "us-central1-a"
  machine_type              = "n4-standard-4"
  allow_stopping_for_update = true

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

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance" "api" {
  name                      = "api-01"
  zone                      = "us-central1-a"
  machine_type              = "n4-standard-4"
  allow_stopping_for_update = true

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

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance" "api" {
  name                      = "api-01"
  zone                      = "us-central1-a"
  machine_type              = "n4-standard-4"
  allow_stopping_for_update = true

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

  network_interface {
    network = "default"
  }
}

The only change is the machine_type value. The resource keeps its name, so Terraform updates the existing VM instead of creating a new one.

The allow_stopping_for_update argument matters here. The Google provider must stop a google_compute_instanceto change machine_type, and the update fails if this argument is not set to true.

N4 VMs boot only from Hyperdisk, so the examples set hyperdisk-balanced explicitly. On N2, E2, or N1, a Persistent Disk type such as pd-balanced works instead.

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

resource "google_compute_instance_template" "workers" {
  name_prefix  = "workers-"
  machine_type = "n4-standard-8" # previously "n4-custom-8-32768"

  disk {
    source_image = "debian-cloud/debian-12"
    disk_type    = "hyperdisk-balanced"
  }

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance_template" "workers" {
  name_prefix  = "workers-"
  machine_type = "n4-standard-8" # previously "n4-custom-8-32768"

  disk {
    source_image = "debian-cloud/debian-12"
    disk_type    = "hyperdisk-balanced"
  }

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance_template" "workers" {
  name_prefix  = "workers-"
  machine_type = "n4-standard-8" # previously "n4-custom-8-32768"

  disk {
    source_image = "debian-cloud/debian-12"
    disk_type    = "hyperdisk-balanced"
  }

  network_interface {
    network = "default"
  }
}

Step-by-Step Fix Instructions

1. Search Terraform code for machine_type values containing custom, in google_compute_instance and google_compute_instance_template resources.

2. Check shared modules, .tfvars files, and variable defaults. Custom machine types often sit in a variable "machine_type" default rather than the resource block.

3. Decode each custom value. The format is custom-VCPUS-MEMORY_MB for N1, or a series prefix such as n2-custom-VCPUS-MEMORY_MB.

4. Find the predefined machine type in the same series with the same or slightly larger vCPU and memory. For example, n2-custom-8-32768 maps to n2-standard-8.

5. If no predefined machine type matches without a large jump in size, keep the custom machine type and record why.

6. Change the machine_type value and confirm allow_stopping_for_update = true on google_compute_instance resources.

7. Run terraform plan. Confirm the plan shows an in-place update to machine_type, not a replacement.

8. Apply during a maintenance window, because the VM stops and starts.

9. Add Infracost to CI/CD so new custom machine types are flagged in pull requests before they merge.

Best Practices

• Default shared Terraform modules to predefined machine types. Require a documented reason for any custom machine type.

• Stay within the same machine series when switching. Moving from n2-custom to n2-standard changes only the price, not the processor.

• Round up only when the gap is small. Jumping from 6 vCPUs to 8 vCPUs to avoid a 5% premium can cost more than it saves.

• Migrate development and staging VMs first, then roll production through managed instance groups.

• This policy is about matching shapes. Rightsizing an oversized VM is a separate decision with its own testing cost.

Tools and Scripts

How does Infracost detect Google Compute Engine custom machine types automatically?

The Google Compute Engine predefined machine types policy is available in Infracost, including in the free trial. When Infracost runs in CI/CD, it checks Google Compute Engine resources in each pull request. Findings appear in the PR comment with the exact file and line to change.

This moves the decision to code review. An engineer sees the custom machine type finding before merge, not as a FinOps ticket after the VM is live.

Infracost also scans connected repositories for custom machine types already in code. FinOps and platform teams can burn down that backlog over time and track issues prevented in pull requests separately from existing issues fixed.

Each policy can warn engineers or block the pull request. Teams can also limit a policy to new resources only, so an unrelated change does not force a VM restart.

To find custom machine types in a Terraform codebase:

grep -rnE '"([a-z0-9]+-)?custom-[0-9]+-[0-9]+' --include="*.tf" --include="*.tfvars"

grep -rnE '"([a-z0-9]+-)?custom-[0-9]+-[0-9]+' --include="*.tf" --include="*.tfvars"

grep -rnE '"([a-z0-9]+-)?custom-[0-9]+-[0-9]+' --include="*.tf" --include="*.tfvars"

To list running Google Compute Engine VMs on custom machine types with the gcloud CLI:

gcloud compute instances list \
  --filter="machineType~custom" \
  --format="table(name,zone.basename(),machineType.basename(),status)"

gcloud compute instances list \
  --filter="machineType~custom" \
  --format="table(name,zone.basename(),machineType.basename(),status)"

gcloud compute instances list \
  --filter="machineType~custom" \
  --format="table(name,zone.basename(),machineType.basename(),status)"

If a VM is managed by Terraform, change machine_type in code rather than in the Cloud Console. Otherwise the next terraform apply sets the custom machine type again.

Examples of Impact

Savings from the Google Compute Engine predefined machine types policy scale with fleet size, because each fix is one attribute.

Illustrative example: an API tier. A platform team runs 20 VMs on n2-custom-4-16384 through a shared module. Changing the module default to n2-standard-4 removes the 5% custom premium from all 20 VMs in one pull request.

Illustrative example: a batch worker pool. A data team runs a managed instance group from a template set to n4-custom-8-32768. Updating the template to n4-standard-8 and rolling the group lowers the hourly rate with no change in capacity.

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

Considerations and Caveats

The Google Compute Engine predefined machine types policy is low risk when shapes match exactly. It needs judgment when they do not.

• Licensing. Google documents per-CPU software licensing as a reason to use custom machine types. Fewer vCPUs can lower license costs by more than 5%.

• Shapes with no match. Some workloads need unusual vCPU-to-memory ratios. Custom machine types support extended memory beyond 8 GB per vCPU, which predefined types may not offer.

• Restart required. Changing machine_type stops and starts the VM. Without a static IP, the external IP can change.

• Discounts. Committed use discounts and other commitment pricing have their own custom machine type rates. Check existing commitments before migrating.

• Provider-specific. This policy targets Google Compute Engine through the google Terraform provider. AWS and Azure do not offer custom instance shapes in the same way.

Related Policies and Concepts

• Google Compute Engine - consider a preferred instance type: a Compute-group policy for enforcing an approved list of Google Compute Engine machine types.

• Google Compute Engine - consider using current generation machine types: the companion policy for moving VMs off older machine series.

• Google Compute Engine - consider removing unattached disks: another Compute-group policy that removes Google Compute Engine spend that adds no capacity.

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

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Google Compute Engine predefined machine types policy is supported in Infracost and available in the free trial. Infracost reports custom machine types 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 predefined machine types policy. A finding can warn engineers or block the pull request, and the policy can apply to new resources only.

Does Infracost automatically fix violations?

No. Infracost reports each Google Compute Engine custom machine type in the pull request. Choosing the matching predefined machine type, or keeping the custom type for licensing reasons, is a decision the team makes.

Is this policy cloud-agnostic?

No. The Google Compute Engine predefined machine types policy targets Google Cloud through the google Terraform provider. AWS and Azure use fixed instance sizes and do not offer custom machine types in the same way.

How much more do Google Compute Engine custom machine types cost?

Google Compute Engine custom machine types carry a 5% premium over equivalent predefined machine types at on-demand prices. For a 4 vCPU, 16 GB N4 VM, that is about 6.60 dollars per month per instance.

When is a Google Compute Engine custom machine type worth the premium?

A Google Compute Engine custom machine type is worth the premium when no predefined machine type fits the workload. Common reasons are per-CPU software licensing and memory ratios that predefined machine types do not offer.

How often should I review Google Compute Engine machine types?

Teams running Infracost in CI/CD get a Google Compute Engine machine type check on every pull request that touches a VM. For existing VMs, a quarterly review of custom machine types is a reasonable cadence for most teams.