Google Compute Engine – Consider Using Current Generation Machine Types

The Google Compute Engine current generation machine types policy flags N1 VMs and recommends moving them to second-generation E2, N2, or N2D machine types. N1 VMs typically cost more, or deliver less performance per dollar, than their second-generation replacements. Apply this policy to general-purpose workloads that do not depend on GPUs attached to N1.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Google Compute Engine N1 is the first-generation general-purpose machine series. N1 VMs run on older Intel platforms, from Sandy Bridge through Skylake, and top out at 6.5 GB of memory per vCPU.

Google's second-generation general-purpose series replace N1 for most workloads. Each one targets a different tradeoff:

• E2 is the lowest-cost general-purpose series. Google launched E2 with a stated 31% lower total cost of ownership compared to N1.

• N2 runs on Intel Cascade Lake and Ice Lake processors. Google states N2 delivers more than 20% better price-performance than N1 for many workloads, with up to 8 GB of memory per vCPU.

• N2D runs on AMD EPYC processors and supports the highest vCPU counts of the three, up to 224 vCPUs.

The Google Compute Engine current generation machine types policy matters because N1 is rarely the cheapest or fastest option left. A VM that stays on N1 usually does so because nobody revisited the machine_type value after the first deploy.

This policy covers price-performance as well as list price. N2 costs about the same per VM as N1, so its savings come from running fewer or smaller VMs.

Potential Savings

The clearest direct saving comes from moving an N1 VM to the matching E2 machine type.

Figures are Google Compute Engine Linux on-demand list prices for us-central1. Prices vary by region, operating system, and purchase option.

Moving one n1-standard-4 VM to e2-standard-4 saves about $41 per month at list price, with 1 GB more memory. Across a fleet of 50 VMs, that is roughly $24,000 per year at list price.

That list-price gap shrinks for N1 VMs that run all month. N1 qualifies for automatic sustained use discounts of up to 30%. E2 does not, so an always-on n1-standard-4 can cost close to an e2-standard-4.

The full list-price saving applies to N1 VMs that run only part of the month. For always-on N1 VMs, check the billing export before quoting a savings figure.

The N2 row shows why the N2 path is a performance decision. N2 per-VM pricing is close to N1, so the saving depends on consolidating onto fewer or smaller N2 VMs.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show a Google Compute Engine VM on an N1 machine type, and the corrected configuration on E2.

Non-compliant configuration: N1 machine type

resource "google_compute_instance" "api" {
  name             = "api-01"
  zone             = "us-central1-a"
  machine_type     = "n1-standard-4"
  min_cpu_platform = "Intel Skylake"

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

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance" "api" {
  name             = "api-01"
  zone             = "us-central1-a"
  machine_type     = "n1-standard-4"
  min_cpu_platform = "Intel Skylake"

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

  network_interface {
    network = "default"
  }
}

resource "google_compute_instance" "api" {
  name             = "api-01"
  zone             = "us-central1-a"
  machine_type     = "n1-standard-4"
  min_cpu_platform = "Intel Skylake"

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

  network_interface {
    network = "default"
  }
}

This configuration pays first-generation pricing for 4 vCPUs and 15 GB of memory. It is a common source of wasted spend in GCP projects created before E2 and N2 existed.

Compliant configuration: E2 machine type

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

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

  network_interface {
    network = "default"
  }
}

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

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

  network_interface {
    network = "default"
  }
}

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

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

  network_interface {
    network = "default"
  }
}

The machine_type value changes from n1-standard-4 to e2-standard-4. The resource name stays the same, so Terraform updates the existing VM instead of replacing it.

The allow_stopping_for_update argument is required here. The Google provider must stop a google_compute_instance to change machine_type, and the update fails without it.

The min_cpu_platform argument is removed. E2 VMs do not support selecting a minimum CPU platform, so leaving it in place causes an error.

For CPU-heavy workloads, use n2-standard-4 or n2d-standard-4 instead of e2-standard-4. N2 and N2D both accept min_cpu_platform, so that argument can stay when moving to N2.

Step-by-Step Fix Instructions

1. Search Terraform code for machine_type values that start with n1-, in google_compute_instance resources.

2. Check shared modules, .tfvars files, and variable defaults. N1 values often sit in a variable "machine_type"default.

3. Skip any VM with a guest_accelerator block. GPUs such as the NVIDIA T4 attach to N1, not to E2, N2, or N2D.

4. Pick the target series. Use E2 for general workloads that do not need sustained full-core performance. Use N2 or N2D for CPU-intensive or memory-heavy workloads.

5. Map the shape. For example, n1-standard-8 maps to e2-standard-8 or n2-standard-8, and n1-highmem-4 maps to e2-highmem-4 or n2-highmem-4.

6. Remove min_cpu_platform if the target is E2. Set allow_stopping_for_update = true on the resource.

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

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

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

Best Practices

• Default shared Terraform modules to a second-generation machine type. Require a documented reason for any new N1 VM.

• Migrate development and staging VMs first. Compare CPU and latency metrics before moving production.

• Use E2 when cost matters most. Use N2 or N2D when the workload is CPU-bound and could run on fewer VMs.

• Roll managed instance groups through a new instance template rather than editing VMs one at a time.

• This policy does not apply to GPU workloads that depend on N1. Those VMs need an accelerator-optimized series instead, which is a separate migration.

Tools and Scripts

How does Infracost detect N1 machine types automatically?

The Google Compute Engine current generation 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 file and line to change.

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

Infracost also scans connected repositories for N1 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 the policy to new resources only, so an unrelated change does not force a VM restart.

To find N1 machine types in a Terraform codebase:

grep -rnE '"n1-(standard|highmem|highcpu|ultramem|megamem)-[0-9]+' --include="*.tf" --include="*.tfvars"

grep -rnE '"n1-(standard|highmem|highcpu|ultramem|megamem)-[0-9]+' --include="*.tf" --include="*.tfvars"

grep -rnE '"n1-(standard|highmem|highcpu|ultramem|megamem)-[0-9]+' --include="*.tf" --include="*.tfvars"

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

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

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

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

If Terraform manages a VM, change machine_type in code rather than in the Cloud Console. Otherwise the next terraform apply sets the N1 machine type again.

Examples of Impact

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

Illustrative example: an internal API tier. A platform team runs 30 n1-standard-4 VMs through a shared module. Changing the module default to e2-standard-4 lowers the on-demand list price by about 29% per VM in one pull request. The realized saving is smaller if those VMs already receive full sustained use discounts.

Illustrative example: a CPU-bound batch tier. A data team runs 12 n1-standard-8 VMs that stay near full CPU. Moving to N2 and confirming throughput lets the team retire part of the tier, which is where N2 price-performance turns into savings.

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

Considerations and Caveats

The Google Compute Engine current generation machine types policy is low risk for general workloads. It needs judgment in a few cases.

• GPUs. Several NVIDIA GPU models attach to N1 VMs. E2, N2, and N2D do not support attached GPUs, so GPU workloads need a different path.

• Sustained use discounts. N1 VMs that run all month receive automatic sustained use discounts. E2 does not, so the real saving on an always-on N1 VM can be much smaller than list-price math suggests.

• Committed use discounts. Existing N1 commitments keep billing after a migration. Check commitment coverage before moving committed VMs.

• E2 limits. E2 tops out at 32 vCPUs for predefined machine types and does not support min_cpu_platform. Larger or platform-specific workloads belong on N2 or N2D.

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

Related Policies and Concepts

• Google Compute Engine - consider using predefined machine types: a Compute-group policy that removes the custom machine type premium on Google Compute Engine VMs.

• Google Compute Engine - consider using a preferred instance type: a Compute-group policy for restricting Google Compute Engine VMs to an approved machine type list, which can exclude N1.

• Google Compute Engine - consider removing unattached disks: another Compute-group policy that cuts Google Compute Engine spend with no loss of capacity.

• Azure Virtual Machines - consider upgrading DS series machines to Dv5: the Azure equivalent of moving VMs off an older machine generation.

• Amazon EC2 - consider using latest generation instances for m family instances: the AWS equivalent for moving older EC2 instances to a current generation.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Google Compute Engine current generation machine types policy is supported in Infracost and available in the free trial. Infracost reports N1 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 current generation 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 N1 machine type in the pull request. Choosing between E2, N2, and N2D, and scheduling the restart, is a decision the team makes.

Is this policy cloud-agnostic?

No. The Google Compute Engine current generation machine types policy targets Google Cloud through the google Terraform provider. AWS and Azure have their own instance generations and separate Infracost policies for them.

Which machine series should replace Google Compute Engine N1 VMs?

E2 is the lowest-cost replacement for Google Compute Engine N1 VMs running general workloads. N2 and N2D suit CPU-intensive or memory-heavy workloads where better price-performance allows fewer or smaller VMs.

Do Google Compute Engine N1 VMs with GPUs need to move?

Not under this policy. Several NVIDIA GPU models attach only to Google Compute Engine N1 VMs among general-purpose series, so GPU workloads should stay on N1 or move to an accelerator-optimized series.

How often should I review Google Compute Engine machine generations?

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 N1 usage is a reasonable cadence for most teams.