We see a clear opportunity in our data: Roughly 85% of the Google Cloud instances we manage are still running on N1, N2, or N2D. If you’re still kicking the can down the road on upgrading, you may not want to delay much further.
You’ve likely heard the buzz about N4 and N4D: better performance, lower cost per unit of work, and new discount options. The natural question is: “Is it actually worth the migration effort?” Let’s explore a few considerations to take into account.
Why Move Off N1 and N2 Now?
N1 and N2 have been the reliable workhorses of many GCP estates for years. They are familiar, widely available, and your workloads “just work.” However, customers are starting to consider an upgrade to the newly released N4 and N4D machines for a few reasons:
First, greater price-performance. Newer generations consistently deliver more output per vCPU and per GB of RAM. This means the same amount of resources generates significantly more throughput, or the same workload may be able to run on a down-sized instance for greater efficiency.
Second, consider lifecycle risk mitigation. Older machine families eventually lose support. You don’t want to wait too long and be forced to replatform a massive N1 fleet at an inopportune time. Proactive modernization puts your organization ahead of the curve and saves you a potential fire drill later down the road.
Third, you’ll open up better discount levers. Modernizing your fleet creates an opportunity to establish new baseline commitment coverage with resource-based CUDs which come with higher discounts. Therefore, by shifting to a newer machine series, you can boost efficiency at two levels — greater price-performance and better discounts on that usage.
Better yet, you could implement an automated commitment portfolio strategy that optimizes commitment coverage across your estate while minimizing lock-in risk.
The Commitment “Unlock” with N4 / N4D
If you’re already buying CUDs for your fleet, your commitment portfolio may include a mix of Flexible (spend-based) CUDs, possibly some older resource-based CUDs, and more on-demand usage than you probably want to admit to your finance team 😬.
Spend-based CUDs offer excellent technical flexibility. They provide a discount for a committed dollar spend across most machine types and regions you run in. They’re an excellent choice when your infrastructure environment is constantly changing and a lower discount is worth the optionality.
However, when you modernize to a 4th generation machine series like N4 or N4D, your usage profile is less likely to change in the near term. That predictability gives you the chance to increase your savings with resource-based CUDs. On a 3-year term, many customers can see roughly an additional ~9% discount by moving stable usage from spend-based Flex CUDs to resource-based CUDs. This is on top of the performance gains you already get from the newer family. This often makes migration a double win.
- More output per dollar from newer machines (N4/N4D) 🏅
- Better discounted rates from resource-based CUDs 🏆
Our typical recommendation is simple. Use resource-based CUDs for your stable, predictable, always-on workloads running on N4/N4D. Keep Flex CUDs as a “base layer” for variable or experimental workloads. For best results, let automation continuously optimize the mix to ensure you are fully covered without being overcommitted or at risk of being locked in.
Top Considerations Before You Upgrade
Based on conversations we’re having with our customers, here are some key areas we recommend evaluating prior to modernization.
1. Performance and Sizing
Don’t assume a 1:1 mapping from N1/N2 to N4/N4D. Benchmark representative workloads first, looking at throughput, latency, and CPU utilization. Check if the increased efficiency-per-core allows you to rightsize to a smaller instance on the new machine series. This could reduce your overall spend. Custom machine types — a key advantage of the N-series — still apply, letting you fine-tune vCPU and memory to match your workload precisely. Just note that custom machines typically carry a 5% premium.
2. Licensing and Per-Core Costs
If you use software licensed per vCPU core (e.g., databases, commercial applications), verify how the vendor treats newer machine types. Confirm you won’t unintentionally increase your license count when you resize. The better performance of N4/N4D may actually allow you to consolidate onto fewer instances, ultimately reducing your licensing exposure.
3. Availability and Regional Coverage
Check and confirm regional availability. Are N4/N4D instances available in all the regions and zones you currently utilize? Is there available capacity? If you run multi-region or highly available services, map your High Availability (HA) and Disaster Recovery (DR) strategy to the new machine family before starting bulk migrations. Consider using future reservations to ensure you have capacity on your designated migration date.
4. Storage Efficiency
If you often find yourself over-sizing disks to meet growing throughput demands on N1 or N2, moving to the latest generation machine family unlocks significant storage efficiencies. N4 machines support Hyperdisk storage pools which enable thin provisioning and greater utilization by sizing at the pool level rather than individual disks. Independent scaling of IOPS, throughput, and capacity lets you rightsize the aggregate pool for peaks across multiple VMs without over-provisioning volumes at the disk level.
5. Machine Series Properties
Cross-reference and compare your current machine series to the new generation and see if the same VM properties are supported. For example, will the same disk interfaces, network interfaces, and local SSDs be supported? If not all are supported, consider if there would be any implications for the workloads on your fleet. You can use this Machine Series comparison guide as a quick reference.
Intel to AMD: What to Watch for with N4D
If you are moving from Intel-based N1/N2 to AMD-based N4D, a few extra technical checks are prudent.
Compatibility Checks
While most modern workloads are CPU vendor-agnostic, you should still look for any hard-coded CPU assumptions within your applications. Validate that container images and base OS images are supported on the new family. Confirm that performance-sensitive native modules (e.g., ML libraries, compression tools) perform as expected on AMD. A small pilot is essential for flushing out surprises before you move large production chunks.
Performance Characteristics
AMD and Intel can exhibit subtle differences in performance for specific workloads like vectorized code, cryptography, and compression. We recommend running synthetic benchmarks (sysbench, fio, etc.) for a quick read and real workload tests in a staging or dev environment to validate end-to-end impact. The ultimate goal is simple: Does this machine type make this workload cheaper and faster overall?
Ecosystem Dependencies
If you rely on vendor-supported database images, Marketplace appliances, or third-party agents, make sure those vendors explicitly support the N4D family or AMD-based instances. Verification now is far better than discovery during an incident.
Derisk your Migration
Start with non-critical workloads. Batch jobs, dev & test environments, stateless services, and internal-facing business applications are some examples of low-risk workloads that can be ideal testbeds. Migrate a subset, monitor behavior, tune, validate, and then look to expand. As you move toward medium to high risk workloads, consider running dual fleets during the migration. Keep some traffic on existing N1/N2 and gradually shift percentage weights to N4/N4D behind a load balancer. This gives you the option to quickly roll back in case unforeseen issues arise with the new fleet.
Once the upgrade is complete, start applying your commitment strategy. Avoid a sudden batch purchase of resource-based CUDs all at once. Instead, gradually build up resource-based CUDs as the N4/N4D footprint stabilizes. Allow any Flex CUDs to naturally expire, apply to new resources, or scale down to avoid over-commitment. Better yet, consider an automated solution that applies advanced commitment purchasing techniques like Adaptive Laddering that optimizes your CUD coverage while reducing commitment lock-in risk.
This is where having a software partner that actively manages your portfolio with homegrown expertise is invaluable. ProsperOps continuously tracks your usage, models different portfolio compositions, and optimizes for savings, flexibility, and lock-in risk.
Leverage Custom Machines
A possible benefit of staying within the N-series is the ability to use custom machine types. Unlike some specialized families that lock you into fixed shapes, N4/N4D allows you to dial in vCPU and memory to fit your workload requirements more precisely. For example, you can avoid paying for over-provisioned RAM if you are only looking to scale CPU capacity.
It is worth noting, however, that custom machine types often come at a 5% premium compared to fixed shapes. So if your custom machine minimally deviates from a predefined machine like an n4-highcpu or n4-highmem, you may want to run detailed cost analysis to see if the flexibility is worth the premium for your specific workloads’ needs.
Putting It All Together
If your current environment is heavily reliant on N1, N2, or N2D, you are sitting on a meaningful optimization opportunity.
A strategic N4/N4D migration plan delivers: Better per-core performance efficiency, which can reduce your infrastructure footprint. Roughly 9% extra discount on steady workloads via optimized 3-year resource-based CUDs. Lower long-term lifecycle risk and more precise sizing through custom machine types. You don’t need to execute this all at once. You can move gradually, workload by workload, while we monitor the numbers and keep your commitments synchronized with reality.
To help plan your migration, we built a Google VM Price Comparison tool that lets you quickly compare price-performance across regions, machine families, generations, and custom machine configurations.
If you’re interested in learning more about price-performance benchmarking in Google Cloud, check out this article.
