Instance Types and Families Explained

Every cloud VM starts with one decision that’s easy to get wrong: the size. Pick one that’s too small and the application stalls under load. Pick one that’s too big and you pay for idle silicon every hour of every day. Pick the wrong family and you might buy twice the memory you need just to get the CPU you want.

The catalogues look intimidating because there are hundreds of options. They’re less intimidating once you see that every instance type is a combination of a handful of choices, and that the name spells those choices out. This article explains those choices, how to decode the names on AWS, Google Cloud and Azure, and a practical way to pick a starting size and then correct it.

If you haven’t met the three VM services yet, start with Deep Dive into AWS EC2 Instances, Exploring GCP Compute Engine Instances and Understanding Azure Virtual Machines. The side-by-side mapping of families between clouds is in Comparing VM Offerings Across AWS, GCP, and Azure; this article goes one level deeper into what the families actually differ on.

What an instance type fixes

An instance type is a fixed bundle of hardware. When you choose one, you’re choosing all of these at once:

• vCPU count. How many virtual processors the guest sees.
• Memory. Usually expressed as a ratio to vCPUs, such as 4 GiB per vCPU.
• Processor. Intel, AMD or the provider’s own Arm chip, and which generation.
• CPU model. Dedicated vCPUs at full speed, or burstable vCPUs that run at a baseline and spend credits to go faster.
• Local storage. Whether the host gives you fast, ephemeral NVMe disks, and how many.
• Network and disk bandwidth. Larger sizes get more of both; some variants get much more.
• Accelerators. GPUs or other chips for machine learning, graphics or video.

You can’t mix these freely on AWS or Azure. If you want 4 vCPUs with 32 GiB of memory, you look for the family whose ratio is 8 GiB per vCPU and take its 4-vCPU size. Google Cloud is the exception with custom machine types, covered below.

flowchart LR
    T["Instance type"] --> C["vCPUs"]
    T --> M["Memory ratio"]
    T --> P["Processor and generation"]
    T --> B["Dedicated or burstable"]
    T --> L["Local NVMe disks"]
    T --> N["Network and disk bandwidth"]
    T --> G["GPUs or accelerators"]

The families are mostly about memory per vCPU

Strip away the marketing and the biggest difference between the general purpose, compute optimized and memory optimized families is how much memory you get for each vCPU. The same pattern repeats on all three clouds.

Within a generation and processor, the price per vCPU is roughly constant and you pay extra for the memory. That gives you a simple rule: look at your application’s memory-to-CPU need first, then pick the family whose ratio matches. A Java service that sits at 20 percent CPU while using 28 GiB of heap belongs on a memory optimized size, not on a general purpose size twice as large.

The specialist families sit outside this ratio scale:

• Storage optimized (AWS I and D, Google Z3, Azure L-series) attach large local NVMe or HDD capacity for databases and search engines that do their own replication.
• Accelerated (AWS P, G and others, Google A and G series, Azure N-series) attach GPUs or other accelerators. You choose these for the accelerator first and the CPU second.
• HPC (AWS Hpc, Google H-series, Azure H-series) are tuned for tightly coupled simulation work, often with high-speed interconnects.

Decoding AWS names

An EC2 instance type such as c7gn.2xlarge has four parts: the family letter, the generation number, optional capability letters, and the size after the dot.

flowchart LR
    N["c7gn.2xlarge"] --> F["c: compute optimized family"]
    N --> G["7: seventh generation"]
    N --> A["g n: Graviton, network optimized"]
    N --> S["2xlarge: 8 vCPUs"]

The capability letters are where most of the information hides. The common ones are:

Sizes follow a doubling ladder. For most families large is 2 vCPUs, xlarge is 4, 2xlarge is 8, and so on up to the largest size, with metal giving you the whole physical server with no hypervisor. Burstable T instances also go below large with nano, micro, small and medium.

You don’t have to memorise any of this. The CLI will tell you what a type contains:

aws ec2 describe-instance-types --instance-types m7g.large r7i.xlarge \
  --query "InstanceTypes[].{Type:InstanceType,vCPU:VCpuInfo.DefaultVCpus,MemMiB:MemoryInfo.SizeInMiB,Arch:ProcessorInfo.SupportedArchitectures[0],Net:NetworkInfo.NetworkPerformance}" \
  --output table

Decoding Google Cloud names

Compute Engine groups machine types into machine families (general purpose, compute optimized, memory optimized, storage optimized, accelerator optimized), each containing machine series such as E2, N2, N4, C4, C4A or M3. A machine type name is the series, a profile, and the vCPU count, separated by hyphens.

The exact memory per vCPU for each profile differs a little between series, so treat standard, highcpu and highmem as relative labels and check the series page for the precise numbers. Some series also offer -metal bare metal shapes.

The feature no other provider matches is the custom machine type. On series that support it, such as N2, N2D and E2, you choose the vCPU count and the memory within that series’ limits:

# 6 vCPUs and 20 GB of memory on N2, a shape no predefined type offers
gcloud compute instances create app-1 \
  --zone=us-central1-a \
  --custom-vm-type=n2 --custom-cpu=6 --custom-memory=20GB \
  --image-family=debian-12 --image-project=debian-cloud

# Inspect any machine type
gcloud compute machine-types describe n2-highmem-8 --zone=us-central1-a

The resulting machine type is named after its shape, for example n2-custom-6-20480 (6 vCPUs, 20,480 MB). Custom types cost slightly more per vCPU and per GB than predefined ones, so they pay off when they save you from buying a size up, not when a predefined type is already close.

Decoding Azure names

Azure size names pack the most information into the fewest characters. Microsoft documents the order as family, optional sub-family, vCPU count, optional constrained vCPU count, additive feature letters, optional accelerator, and version.

flowchart LR
    N["Standard_E8-4ads_v5"] --> F["E: memory optimized family"]
    N --> C["8: vCPUs of the full size"]
    N --> K["-4: constrained to 4 active vCPUs"]
    N --> A["a d s: AMD, local temp disk, premium storage"]
    N --> V["v5: fifth version"]

The lowercase letters after the number are the part to learn:

So Standard_D4ps_v6 is a general purpose D-series size with 4 vCPUs on an Arm processor (Cobalt 100 in v6), premium storage capable, version 6. Standard_D4lds_v5 is a D-series with 4 vCPUs, low memory (2 GiB per vCPU instead of 4), a local temp disk and premium storage support.

The constrained sizes deserve a note. A size like Standard_E8-4ads_v5 keeps the memory, storage and bandwidth of the 8-vCPU size but enables only 4 vCPUs. It exists mostly for software licensed per core, such as some database engines, where you want big-machine memory without paying licence fees on extra cores.

Check what a size offers in a region before you design around it:

az vm list-skus --location canadacentral --size Standard_D4ps_v6 \
  --query "[0].capabilities[?name=='vCPUs' || name=='MemoryGB' || name=='CpuArchitectureType']" \
  --output table

Processor choice: x86 or Arm

All three clouds now sell their own Arm processors: AWS Graviton, Google Axion and Azure Cobalt. They’re usually cheaper per vCPU than comparable x86 sizes, and an Arm vCPU is a full physical core rather than one hyperthread. For many workloads that means better price-performance.

The cost is compatibility. An Arm VM needs an arm64 operating system image and arm64 builds of everything you run on it. Interpreted languages and most popular open source software are fine. The usual problems are:

• Container images published only for amd64.
• Native extensions and binary dependencies without an arm64 build.
• Commercial software licensed or supported only on x86.
• Build pipelines that produce only x86 artifacts.

A sensible approach is to move one stateless service first, build multi-architecture images for it, and benchmark it against the x86 size you use today. If it holds up, the rest of the fleet can follow at its own pace. Between Intel and AMD the switch is much lighter, since the instruction set is the same; benchmark, compare price, and choose.

Burstable instances and CPU credits

Burstable families (AWS T, Google E2 shared-core, Azure B-series) are built for workloads that are idle most of the time: small web servers, development boxes, build agents that wait more than they work. They’re cheap because you don’t get full use of every vCPU all the time.

On AWS and Azure the model uses CPU credits. Each size has a baseline, a percentage of CPU it can use indefinitely. While the VM runs below the baseline it earns credits; when it runs above, it spends them. On AWS one credit is one vCPU at 100 percent for one minute.

flowchart TB
    R["VM running"] --> Q{"CPU above baseline?"}
    Q -->|"No"| E["Earn credits up to a cap"]
    Q -->|"Yes"| H{"Credits left?"}
    H -->|"Yes"| S["Burst, spending credits"]
    H -->|"No"| X{"Mode"}
    X -->|"AWS standard or Azure B-series"| T["Throttled to baseline"]
    X -->|"AWS unlimited"| U["Keeps bursting, surplus credits billed"]

What happens when credits run out differs:

The trap is a burstable instance that isn’t really bursty. If a T3 runs at high CPU all day in unlimited mode, you pay surplus charges and the total can approach or exceed a general purpose size of the same shape. If an Azure B-series does the same, it gets throttled and the application slows down for no obvious reason. Watch the credit balance metric (CPUCreditBalance in CloudWatch, the CPU credits metrics in Azure Monitor). A balance that keeps falling toward zero means the workload belongs on a non-burstable size.

AWS Flex instances such as m7i-flex and c7i-flex are a related idea for general purpose work: a lower price in exchange for not being designed to run every vCPU flat out all the time. They suit workloads that are busy sometimes and moderate most of the time.

Generations: newer is usually cheaper per unit of work

The generation number (m5 to m7, _v4 to _v6, N1 to N4) matters more than people expect. Each new generation typically brings a newer processor, more network and disk bandwidth per size, and often a similar or lower hourly price. Old generations stay available for years, so nothing forces you to move.

Two practical consequences:

• Default to the latest generation that’s available in your region and supported by your image, unless you have a reason not to.
• Revisit long-running VMs once a year. A fleet still on a generation from several years ago is often paying more for less. Moving is usually a stop, a size change and a start, but check that the new generation supports your disk type and drivers. Newer Google series, for example, use Hyperdisk rather than older Persistent Disk types, and older AWS and Azure images may lack the NVMe or network drivers that newer hardware needs.

Commitments interact with this. A three-year commitment tied to a specific family can make an upgrade awkward. The next article in this series covers on-demand, reserved, savings plan and Spot pricing, including which commitments stay flexible across families.

Choosing a starting size

There’s no way to pick the perfect size from a spec sheet. The practical method is to start with a reasonable guess, measure, and correct.

Then measure for at least a week of normal traffic, looking at peak and average CPU, memory used (which needs an agent on all three clouds, since the hypervisor can’t see inside the guest’s memory), disk IOPS and network throughput. Each provider will do some of this analysis for you:

• AWS Compute Optimizer recommends instance types for EC2 instances and Auto Scaling groups based on utilisation history.
• Google Cloud machine type recommendations (from the Recommender service) suggest resizing over- or under-used VMs in the console.
• Azure Advisor flags underused VMs and suggests a smaller size or shutdown.

Treat recommendations as a starting point, not an instruction. They can’t see a monthly batch job that didn’t run during the sample window, and they don’t know your latency targets.

For groups of VMs, avoid hard-coding a single type at all. AWS attribute-based instance type selection lets an Auto Scaling group or EC2 Fleet ask for requirements instead of a type name, which makes Spot capacity much easier to find. You can preview what a set of requirements matches:

aws ec2 get-instance-types-from-instance-requirements \
  --architecture-types x86_64 \
  --virtualization-types hvm \
  --instance-requirements 'VCpuCount={Min=4,Max=8},MemoryMiB={Min=16384},InstanceGenerations=current' \
  --output table

Scaling those groups up and down is the subject of the last article in this series.

Further reading

• Amazon EC2 instance type naming conventions
• Burstable performance instances on EC2
• Compute Engine machine families resource and comparison guide
• Create a VM with a custom machine type
• Azure virtual machine sizes naming conventions
• Azure B-family burstable sizes

Key takeaways

• An instance type fixes vCPUs, memory, processor, CPU model, local storage, bandwidth and accelerators as one bundle.
• The main difference between general purpose, compute and memory optimized families is memory per vCPU: roughly 2, 4 and 8 GiB, with Google’s N2 highcpu going as low as 1 GB. Match the ratio to your workload before picking a size.
• AWS names read as family, generation, capability letters and size (c7gn.2xlarge). Google names read as series, profile and vCPUs (n2-highmem-8). Azure names read as family, vCPUs, feature letters and version (Standard_E8-4ads_v5).
• Only Google Cloud offers custom machine types with exactly the vCPUs and memory you choose.
• Arm sizes (Graviton, Axion, Cobalt) usually give better price-performance, but every image, container and binary must support arm64.
• Burstable sizes suit mostly idle workloads. A credit balance that keeps draining means the VM belongs on a dedicated-vCPU size.
• Prefer the latest generation, start with a reasonable guess, measure for a week with a memory agent installed, and rightsize with the provider’s recommendations as a guide.