GCP Machine Types Explained: How to Choose the Right Compute Engine VM

What is a machine type?

When you create a Compute Engine VM, you are renting compute resources on Google’s infrastructure. A machine type tells GCP exactly what hardware to give you: how many virtual CPUs (vCPUs) and how much RAM. Everything else (the operating system, disk, and network configuration) is a separate choice.

Most beginners over-provision. They pick a large machine type “just in case” and end up paying for CPU and RAM that sits idle. The better approach is to start conservatively, monitor real usage, and resize when you have evidence.

The three core workload types that guide your initial choice:

• CPU-heavy: video encoding, scientific computing, game servers. Needs high clock speed or many vCPUs.
• Memory-heavy: in-memory databases, caching layers, SAP HANA. Needs a high RAM-to-vCPU ratio.
• Balanced: web servers, APIs, microservices. Standard 4 GB per vCPU ratios work well for most cases.

How machine type names work

Machine type names follow a consistent format that tells you everything upfront:

FAMILY-RATIO-vCPUs

Machine type families

General purpose: E2, N2, N2D, N4

Start here for most workloads. General-purpose families offer balanced vCPU-to-memory ratios and cover the majority of web, API, and application backend use cases.

• E2 is cost-optimised and shares physical CPU cores across tenants. CPU performance can vary under load. Best for dev/test, microservices, and workloads that do not need consistent CPU response times.

• N2 runs on Intel Cascade Lake with dedicated vCPUs and predictable performance. The default choice for medium-sized production workloads. Supports custom machine types.

• N2D runs on AMD EPYC with a similar workload fit to N2 but often lower price per vCPU. Worth comparing for cost-sensitive production work where platform preference is not a constraint.

• N4 uses Intel Emerald Rapids, the latest-generation general-purpose option. Higher per-vCPU performance than N2.

Compute optimised: C2, C2D, C3

High clock-speed CPUs for tasks where raw compute throughput is the bottleneck. Do not use these for general web serving: they cost more and the extra CPU speed provides no benefit to workloads that are mostly idle or waiting on I/O.

• C2 uses Intel Cascade Lake with the highest sustained clock frequency in GCP’s standard range. Good for scientific computing and game servers.
• C2D is AMD EPYC-based with a large L3 cache that suits workloads with high data reuse such as simulations and analytics.
• C3 uses Intel Sapphire Rapids and is the current-generation compute-optimised option. Generally preferred over C2 for new deployments.

Memory optimised: M1, M2, M3

Very high memory-to-vCPU ratios for in-memory databases, SAP HANA instances, and data warehousing workloads that cannot fit within standard memory limits. These are large, expensive VMs. Only reach for them when you genuinely need more RAM than general-purpose highmem types can provide.

• M1: up to 4 TB of memory per VM.
• M2: up to 12 TB of memory per VM.
• M3: latest generation memory-optimised, higher performance than M1 and M2.

Accelerator optimised: A2, A3, G2

GPU-attached VMs for ML training, inference, and high-performance computing. Only use these when your workload explicitly benefits from GPU acceleration.

• A2: NVIDIA A100 GPUs, an established ML training option.
• A3: NVIDIA H100 GPUs, current generation for large-scale training.
• G2: NVIDIA L4 GPUs, suited for inference and media transcoding at lower cost than A100.

E2 vs N2 vs N2D vs C2 vs C3

The general-purpose and compute-optimised families are where most beginners get stuck. Here is a direct comparison:

Which machine type to use by workload

Use these as starting points. Monitor actual usage after deployment and adjust based on real data, not what you think might happen under load.

• Local dev or build server: e2-standard-2 or e2-standard-4. Cost over consistency: it does not matter if the CPU is occasionally shared.

• Low-traffic web app or staging environment: e2-standard-2. You do not need dedicated CPU for a site getting a few hundred requests per day.

• Production API backend with latency requirements: n2-standard-4 as a starting point. Dedicated vCPUs prevent unexpected tail latency at p99.

• PostgreSQL or MySQL database: n2-highmem-4 or n2-highmem-8. Databases benefit from more RAM for buffer caches. The highmem ratio gets you enough memory without over-buying vCPUs.

• CPU-heavy batch job (transcoding, rendering, simulation): c3-standard-8 or higher. The clock speed improvement over N2 actually matters for these workloads.

• In-memory database or SAP HANA: M-series. If you genuinely need hundreds of GB to multiple TB of RAM, this is the only family that supports it.

• ML training at scale: A2 or A3 with the appropriate GPU count. Do not attempt large model training on CPU-only VMs.

• ML inference at low-to-medium scale: G2 with NVIDIA L4. The L4 is optimised for inference throughput at lower cost than A100.

Custom machine types

Standard machine types use fixed vCPU-to-memory ratios. Custom machine types let you specify exact values, useful when no preset fits your workload without wasting one of the two resources.

For example, if your application needs 6 vCPUs and 12 GB RAM, there is no exact preset match. Your options without a custom type:

• n2-standard-4: 4 vCPUs, 16 GB (not enough CPU, extra RAM you do not need)
• n2-standard-8: 8 vCPUs, 32 GB (more of everything than required)
• n2-custom-6-12288: exactly 6 vCPUs and 12 GB RAM

Custom types are priced proportionally. You pay for exactly the vCPU and memory you request, which makes them cost-efficient when you know your requirements precisely. E2, N2, and N2D support custom machine types. C2 and memory-optimised families do not.

Custom types are most useful when:

• Your application profile clearly does not match a standard ratio
• You have measured actual usage and know the exact requirement
• Wasted resources are significant at scale, across many long-running VMs

They add naming complexity and can be harder to reason about inside instance templates and infrastructure-as-code. For most early-stage workloads, a standard preset is simpler and close enough.

How to choose the right machine type

Follow this process rather than guessing upfront:

1. Identify your workload type. Is it CPU-bound, memory-bound, or balanced? This narrows down the right family immediately.

2. Choose the family. General purpose (E2, N2, N2D) for most workloads. Compute-optimised (C2, C3) if CPU throughput is the bottleneck. Memory-optimised (M-series) only if you genuinely need hundreds of GB of RAM.

3. Choose the ratio. Standard for balanced workloads. Highmem for databases and caches. Highcpu for batch processing. Custom if no preset fits without meaningful waste.

4. Start conservatively. It is easier and faster to resize up than to over-provision from day one. Start smaller and monitor.

5. Monitor and resize. Use Cloud Monitoring to observe CPU and memory usage over time. Resize based on that data rather than intuition.

Common gcloud commands

List available machine types in your target zone before committing to a family. Not all types are available in every zone:

gcloud compute machine-types list --filter="zone:europe-west2-a"

Create a VM with a specific machine type. This is the most common starting point for production deployments:

gcloud compute instances create my-app-prod \
  --zone=europe-west2-a \
  --machine-type=n2-standard-4

Create a VM with a custom machine type when no preset fits your vCPU and RAM requirements without waste (N2, 6 vCPUs, 12 GB RAM):

gcloud compute instances create my-custom-vm \
  --zone=europe-west2-a \
  --machine-type=n2-custom-6-12288

Resize an existing VM. The VM must be stopped first. After setting the new type, start it again:

gcloud compute instances stop my-app-prod --zone=europe-west2-a

gcloud compute instances set-machine-type my-app-prod \
  --zone=europe-west2-a \
  --machine-type=n2-standard-8

gcloud compute instances start my-app-prod --zone=europe-west2-a

Right-sizing with Cloud Monitoring and Recommender

The machine type you pick on day one is a hypothesis. Right-sizing is the process of testing that hypothesis with real usage data and adjusting based on evidence.

Signs your VM is over-provisioned:

• Average CPU utilisation is consistently below 20%
• RAM usage stays well below total capacity with no memory pressure
• GCP Recommender surfaces a suggestion to downsize

Signs your VM is under-provisioned:

• CPU spikes frequently above 80 to 90% at peak load
• The OS reports memory pressure, swapping, or OOM kills
• Response times are higher than expected with no obvious network or disk cause

# View CPU utilisation for a VM over the last 24 hours
gcloud monitoring read \
  "compute.googleapis.com/instance/cpu/utilization" \
  --filter='metric.labels.instance_name="my-app-prod"' \
  --interval="24h"

# List GCP-generated right-sizing recommendations
gcloud recommender recommendations list \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --location=europe-west2-a \
  --project=my-project-id

GCP Recommender observes 30 days of usage and surfaces specific suggestions automatically, including estimated monthly savings. Check these before committing to a long-term machine type or signing a committed use discount.

For workloads that can tolerate interruption, switching to Spot VMs cuts costs by 60 to 91% regardless of machine type. That is often a larger saving than right-sizing the machine type alone.

Scale up vs scale out

A bigger machine type is not always the right answer. When a VM is under load, you have two choices:

• Scale up: resize to a larger machine type, adding more vCPU and RAM on one VM
• Scale out: run more VMs of the same size behind a load balancer

Four n2-standard-4 VMs give you the same total compute as one n2-standard-16, and if one VM fails, the others absorb traffic without interruption.

Managed instance groups with autoscaling let you do this automatically. GCP adds and removes VMs based on CPU usage or custom metrics. If your application is stateless, this approach is almost always preferable to running one very large VM.

If your application holds state locally and cannot be spread across multiple VMs, scaling up makes sense. But that constraint is worth revisiting before committing to it permanently.