Compute
Intermediate 13 min read Compute

Compute Families and Sizing

Matching hardware profiles to workloads

Instance types are grouped into families tuned for CPU, memory, storage or GPU. Choosing the right family and size directly controls cost, latency and throughput of every workload.

instance familyvCPUmemory optimizedcompute optimizedGPUsizing
Prerequisites: Virtual Machines and Instances
Before we start

What you will learn

  • Read an instance type naming convention on any provider
  • Match workload shape (CPU, memory, GPU, burst) to a family
  • Size instances from actual utilization data, not intuition
In 60 seconds

Families trade vCPU/RAM/network/GPU ratios. A cache (Redis) wants memory-optimized; an ML model wants GPU; a bursty dev server wants burstable. Sizing from metrics beats guessing.

Introduction

What is this?

AWS families: t (burstable), m (balanced), c (compute), r (memory), i/d (storage), p/g (GPU), and graviton (arm64) variants. Azure: B (burstable), D (general), F (compute), E (memory), NC/ND (GPU). GCP: e2/n2/c3 (general), c2 (compute), m1/m2/m3 (memory), a2/g2 (accelerator). Naming encodes size: m5.2xlarge = 8 vCPU/32 GiB; D8s_v5 = 8 vCPU/32 GiB. Burstable types have baselines and CPU credits that survive on/off spikes.

Motivation

Why do you need it?

  • Right family = right price: you're paying for the whole box, use all of it.
  • Burstable instances cut idle dev costs 40-60%.
  • GPU families are 10-30x the price of CPU; buying them for the wrong job wastes money.
  • Mis-sized fleets are the #1 line item in every cost review.
Think about it

Mental model

Imagine

Buying a vehicle for the cargo, not the showroom

Think of

Choosing an instance family

A sports car (compute-optimized) hauls nothing but goes fast; a truck (memory-optimized) carries the heavy load. Also buy the right-size truck — a trailer you never fill costs you fuel every mile.

Mechanics

How it works

  • Each family fixes a vCPU:memory ratio (balanced ~1:4, compute ~1:2, memory ~1:8).
  • Within a family, size doubles: m5.large → m5.xlarge → m5.2xlarge scaling 2x resources.
  • Cores amplify network bandwidth and local SSD counts, so I/O-heavy jobs need core count, not just RAM.
  • Burstable types accumulate CPU credits; credits deplete under sustained load and force throttling.
  • GPUs attach in fixed slice counts (A100, T4, L4) and are metered per GPU-hour.

Mapping workload shape to family.

Profile the workload
Pick family
Pick size
Validate on metrics
Optimize
Hands-on

Examples

Decode a type name

Decode a type name
# AWS m5.xlarge: family m (balanced), gen 5, size xlarge (4 vCPU / 16 GiB)
# Azure Standard_D8s_v5: D general family, 8 vCPU, v5 gen
# GCP c2-standard-4: c2 compute family, 4 vCPU
 
# list instance types by memory in AWS
aws ec2 describe-instance-types --filters Name=vcpu-info.default-vcpus,Values=8 \
  --query 'InstanceTypes[?MemoryInfo.SizeInMiB>=32768].{type:InstanceType}' \
  --output table

Naming conventions are consistent and queryable; scripting lets you shortlist families that match your needs.

Real world

In production

  • A Redis cache runs on r-family (memory-optimized) with 1:8 ratio.
  • A video-encoding pipeline uses c-family spot instances for 50+% savings.
  • An online store mixes t3 (ALB/web), m5 (app), and r6g (database reader replicas) per tier.
Guidelines

Best practices

  • Start small and autoscale up rather than over-provision once.
  • Use metrics (CPU, memory, network) to rightsize quarterly.
  • Reserve or commit on stable base capacity; spot for elastic batch work.
  • Standardize on 2-3 families per account so capacity pools stay warm.
Watch out

Common mistakes

  • Copying an instance type from a tutorial blog forever.
  • Picking family by name ('compute' sounds better) instead of workload ratio.
  • Ignoring network bandwidth: adding vCPUs can bottleneck old NIC bandwidth.
  • Burstable instances under sustained load → CPU throttling surprises.
Root cause analysis

Common issues

Error
Burstable instance throttled at 'CPU balloon'
Root cause

Credit balance exhausted under sustained load

Fix

Switch to a non-burstable family or larger standard type, or split load.

Error
Instance slow but utilization low
Root cause

Wrong family shape for the workload

Fix

Check memory pressure, disk IOPS and network; move to the family matching the bottleneck.

When things break

Debugging tips

  • Install cloud collector agents (or OS metrics) then compare util% vs type capacity.
  • Check CPU credit balance on burstable types (aws ec2 describe-instance-types / GetMetrics).
  • When latency rises, look at vCPU-to-network ratio, not just RAM.
  • Use provider calculators to compare across types before changing.
Interviews

Interview checkpoint

Practice

Hands-on lab

Match Instances to Workloads by Family
20 min · intermediate
In progress
Objectives
  • Decode instance names across AWS, Azure and GCP
  • Select a family plus size for four workload sketches
  • Query provider type catalogs programmatically

Match Instances to Workloads by Family

20 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

A Redis cache that is RAM-bound is best served by which family?

Go deeper

Official documentation

AWS — Instance types
docs
Azure — VM sizes
docs
GCP — Machine families
docs