Explanation
Why the waste happens and who it affects.
Many long-lived VMs, instance templates and GKE node pools still use n1-* machine types because they were created years ago or copied from old templates. Google describes E2 as the cost-optimized series with the lowest on-demand pricing across general-purpose machine types, and its GKE cost guidance states that E2 machine types offer 31% savings compared to N1.
The comparison needs care. The 31% is a list-price comparison: N1 receives sustained use discounts of up to 30% for VMs that run most of the month, while E2 receives none, so a 24/7 on-demand N1 VM can cost about the same as its E2 equivalent. The gap is real where sustained use discounts do not apply: VMs covered by committed use discounts (CUDs and SUDs cannot combine), VMs that run only part of the month, and fleets being re-committed. In those cases staying on N1 pays more for older hardware.
Billing model
The pricing dimensions that drive this cost.
Prices are per vCPU-hour and GiB-hour and vary by region.
- N1 on-demand
- Billed per second at N1 rates, with automatic sustained use discounts of up to 30% for resources used more than 25% of a month
- E2 on-demand
- Lower list price than N1 for comparable shapes, with no sustained use discounts
- Committed use discounts
- Resource-based and flexible CUDs apply to both series; SUDs do not apply to usage already covered by CUDs, so under commitments the lower E2 base price carries through
- Series-specific commitments
- Resource-based commitments are tied to a machine series, so N1 commitments do not cover E2 usage
How to detect
4 checks to find it in your estate.
- Inventory VMs, instance templates, MIGs and GKE node pools that use n1-* machine types
- For each, check how it is billed: covered by a CUD, running part of the month, or running on-demand all month with the full sustained use discount; the first two are where E2 saves the most
- Compare the net monthly price of the N1 shape (after SUD or CUD) with the equivalent E2 shape in the same region
- Exclude VMs that need what E2 does not support: GPUs, Local SSDs, sole-tenant nodes, nested virtualization or more than 32 vCPUs; consider N2, N4 or other current series for those
How to fix
4 ways to remove the waste.
- Change suitable VMs to an E2 machine type: stop the VM, set the new machine type (gcloud compute instances set-machine-type), then start it; test performance, since E2 picks the processor (Intel or AMD) for you at creation
- Update instance templates, MIGs and GKE node pool definitions so new capacity does not launch on N1
- Align commitment renewals with the migration: let N1 resource-based commitments expire or plan the move with flexible CUDs, which are not tied to a machine series
- For performance-sensitive or larger workloads, evaluate current-generation series instead of E2 and compare price for the throughput actually delivered
Documentation
Vendor references for pricing and configuration.