---
cuppy_hub: gcp
cuppy_path: reference/compute/compute-engine.md
cuppy_section: docs
cuppy_doc: X3Y5-RN6J
cuppy_doc_uuid: 4ea362f3-7fbe-4466-90d7-6bc7e5871e5e
cuppy_permalink: https://cuppy.io/gcp/d/X3Y5-RN6J
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/compute/compute-engine
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: e4656bcc3848fe19850daa243d70e4b30559137df2a9a95bfca62df85e46b995
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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:

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.
2. 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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->