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
Compute Engine machine types
1. Six families, and the series in each
| Family | Series |
|---|---|
| general-purpose | N4, N4A, N4D, N2, N2D, N1, E2, T2D, T2A |
| compute-optimised | C4, C4A, C4D, C4N, C3, C3D |
| storage-optimised | Z3, Z4D, Z4M |
| network-optimised | C4N, M4N |
| memory-optimised | X5, X4, M4, M4N, M3, M2, M1 |
| accelerator-optimised | A4X 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:
| Suffix | Means | Series the page names |
|---|---|---|
-lssd | Local SSD attached | C4, C4A, C4D, C4N, C3, C3D, H4D |
-standardlssd, -highlssd | Local SSD variants | Z3, Z4D |
-metal | bare 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:
- 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.
- 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.