Compute Engine machine types: E2, N, C and custom shapes

Compute Engine organises machines into families by what they optimise for, then gives each family a generation number and a set of predefined shapes. Once you know the four groups, the catalogue is small enough to hold in your head.

The four groups

General purpose. E2 is the cost optimised option, using a mix of underlying platforms without guaranteeing a specific processor. The N series offers a balance with a more predictable platform, and the newer general purpose generations improve on both. This is where most workloads belong.

Compute optimised. The C series, with higher clock speeds and a lower memory to vCPU ratio. Suited to CPU bound work: media processing, simulation, busy application servers and game servers.

Memory optimised. The M series, with very high memory per vCPU. In memory databases and large analytical workloads. Expensive, and you will know if you need one.

Accelerator optimised. The A and G series, built around GPUs for training and inference. These carry their own quotas, which usually start at zero and are restricted further while a billing account is still in trial status.

Google also offers scale out families using Arm processors, which target throughput per dollar on workloads that parallelise well: web serving, containerised microservices, CI fleets.

Reading the shape

A predefined type such as e2-standard-4 reads as family, shape and vCPU count. The shape word tells you the memory ratio:

• standard is the balanced ratio, roughly 4 GB per vCPU.
• highmem roughly doubles that.
• highcpu roughly halves it.
• micro and small are shared core types for very light workloads.

So n2-highmem-8 is a general purpose, second generation machine with 8 vCPUs and a high memory ratio.

Custom machine types

This is the feature that genuinely differs from the other major clouds. On several families you can specify vCPU count and memory independently, within limits, rather than picking the nearest predefined shape.

The saving is real whenever a workload sits between rungs. A process that needs 6 vCPUs and 44 GB of memory would otherwise force you up to a shape with 8 vCPUs and 64 GB, and you would pay for both increments. Custom shapes let you buy the actual requirement.

Extended memory is available beyond the family ratio at a higher rate per gigabyte, which is still usually cheaper than jumping to a memory optimised family for a modest overshoot.

Disks are part of the machine decision

Persistent disk performance scales with provisioned size and with the machine type’s own limits. A small balanced disk attached to a large instance will bottleneck it, and a very fast disk attached to a small instance will not deliver its rated throughput.

The options in rough order: standard persistent disk for cold bulk data, balanced for general use, SSD persistent disk for databases, extreme or hyperdisk where you need to set IOPS explicitly, and local SSD for ephemeral scratch space that disappears with the instance.

Quotas, before anything else

Compute Engine quotas are per project and per region, and they cover total CPUs, CPUs per family, in use IP addresses, persistent disk capacity and each GPU type separately. A new project starts from the defaults regardless of what you raised elsewhere. The account level view is in Google Cloud account options.

Choosing quickly

1. Small service, low traffic: a shared core or small E2 shape.
2. General application: E2 or N standard, sized from measurement rather than intuition.
3. CPU bound: C series, and confirm the job is actually parallel.
4. Database or cache: highmem shape, or a custom shape if the working set sits between rungs.
5. Model inference or training: accelerator families, and check the quota and trial restrictions first.

The equivalent naming schemes elsewhere are covered in EC2 instance families and Azure VM series decoded. For what these machines cost and how the automatic discounts work, see Google Cloud pricing explained.