Compute Engine — machine families, series, the machine-type naming grammar, and where custom types are allowed

How to name the VM you want. The six machine families and the series in each, the series-type-vCPU naming grammar with its suffix conventions, the shared-core types, and the fact that custom machine types exist only for two general-purpose series and cost more than an equivalent predefined type.

markdownreferencev1X3Y5-RN6Jstage: designtrust: officialfamily: computeservice: compute-engineinterface: anycompute enginemachine familymachine seriesmachine typen2-standard-4custom machine typeshared-coree2-micro-lssd-metalgeneral-purposememory-optimizedaccelerator-optimized

Created 21 Oct 2026 · Modified 23 Oct 2026 · 1 version

Compute Engine machine types

1. Six families, and the series in each

FamilySeries
general-purposeN4, N4A, N4D, N2, N2D, N1, E2, T2D, T2A
compute-optimisedC4, C4A, C4D, C4N, C3, C3D
storage-optimisedZ3, Z4D, Z4M
network-optimisedC4N, M4N
memory-optimisedX5, X4, M4, M4N, M3, M2, M1
accelerator-optimisedA4X Max, A4X, A4, A3, A2, G4, G2

Note that C4N and M4N each appear in two families. The families are a way of talking about the series, not a partition of them.

2. The naming grammar

<series>-<type>-<vCPUs>          e.g. n2-standard-4

The <type> word is the memory-per-vCPU shape: highcpu, standard, highmem, megamem, ultramem, hypermem. Suffix conventions worth recognising on sight:

SuffixMeansSeries the page names
-lssdLocal SSD attachedC4, C4A, C4D, C4N, C3, C3D, H4D
-standardlssd, -highlssdLocal SSD variantsZ3, Z4D
-metalbare metal—

Shared-core types are their own small set and do not follow the grammar: e2-micro, e2-small, e2-medium on E2, and f1-micro, g1-small on N1.

3. Custom machine types — allowed in two places and not free

"Custom machine types cost slightly more to use compared to an equivalent predefined machine type."

And they are available only for the N and E series in the general-purpose family. Two consequences for a migration estimate:

  1. A right-sizing exercise that assumes arbitrary vCPU/memory combinations is assuming N or E series. On any

compute-, memory-, storage- or accelerator-optimised series you must fit a predefined shape, which usually means rounding up.

  1. Custom types trade a price premium for avoiding that rounding. Which is cheaper is arithmetic on live

prices, not a rule — read both from the pricing API (reference/overview/quotas-and-limits-model.md for why no number is typed here).

4. The choice that is hard to undo is the zone, not the type

An instance is a zonal resource and a zonal disk must be in the same zone as the instance it attaches to. A machine type can be changed on a stopped instance; a zone cannot, and the disk is why (reference/storage/persistent-disk-and-hyperdisk.md §3). Choose the zone against the data, not against the compute.

5. What this document does not carry

No vCPU, memory, price or regional-availability values, and no per-series performance numbers. Series availability is per zone and changes; read it with gcloud compute machine-types list --zones=... rather than from any document, including this one.

Next: reference/compute/gke-cluster-modes.md, reference/compute/cloud-run.md, reference/compute/errors.md, and the cross-cloud sizing comparison in guides/parity/compute.md.

Read this document as markdown — the same bytes an agent receives.