Compute Instance Types Decoded: AWS vs Azure vs GCP

Same workload — 4 vCPU, 16 GB RAM, general purpose, no GPU, no local NVMe requirement — on three clouds. The specs match almost exactly; the names don’t look like it.

The instances

These are published list rates for a US region, on-demand, Linux — not a quote, and they move (a few cents, roughly quarterly). The number that survives any price change is the one worth remembering: the three non-burstable options land within a cent of each other. General-purpose compute is the most commoditized layer of any cloud, so on-demand price is a weak differentiator — reserved/committed-use discounts, egress, and managed-service fit are where the real cost differences show up.

Decoding the names

AWS: m5.xlarge

   m        5       xlarge
   |        |       |
family   generation  size

• m = general purpose family (t = burstable, c = compute-optimized, r = memory-optimized)
• 5 = 5th generation of that family’s underlying hardware
• xlarge = size tier. Sizes double each step: medium (1 vCPU) -> large (2) -> xlarge (4) -> 2xlarge (8) -> 4xlarge (16) — RAM doubles in lockstep for a given family, which is why xlarge reliably means 4 vCPU / 16 GB across the whole m5 line.

Azure: Standard_D4s_v5

Standard_  D    4      s        _v5
           |    |      |          |
        family vCPU  premium-  generation
                      storage

• D = general purpose family (E = memory-optimized, F = compute-optimized)
• 4 = vCPU count, stated directly in the name — no lookup table needed
• s = supports Premium SSD/Ultra Disk (its absence, Standard_D4_v5, caps you at Standard SSD/HDD — the same vCPU and RAM either way)
• v5 = generation

GCP: n2-standard-4

n2  -  standard  -  4
|         |         |
series   tier      vCPU

• n2 = machine series (2nd-generation general purpose; n1 is the older series, c2 is compute-optimized, m2 is memory-optimized)
• standard = memory tier for this series (highmem doubles RAM per vCPU, highcpu quarters it)
• 4 = vCPU count, also stated directly — GCP and Azure both put the number in the name; AWS is the one where you memorize (or look up) what xlarge means.

Checking the specs against the cloud’s own source of truth

Rather than trust a table (including this one, months from now), ask each CLI directly.

aws ec2 describe-instance-types --instance-types m5.xlarge \
  --query "InstanceTypes[0].{vCPU:VCpuInfo.DefaultVCpus,MemoryMiB:MemoryInfo.SizeInMiB}"

$ aws ec2 describe-instance-types --instance-types m5.xlarge --query "InstanceTypes[0].{vCPU:VCpuInfo.DefaultVCpus,MemoryMiB:MemoryInfo.SizeInMiB}"
{
    "vCPU": 4,
    "MemoryMiB": 16384
}

az vm list-skus --size Standard_D4s_v5 --resource-type virtualMachines \
  --query "[0].capabilities[?name=='vCPUs' || name=='MemoryGB']"

$ az vm list-skus --size Standard_D4s_v5 --resource-type virtualMachines --query "[0].capabilities[?name=='vCPUs' || name=='MemoryGB']"
[
  { "name": "vCPUs", "value": "4" },
  { "name": "MemoryGB", "value": "16" }
]

gcloud compute machine-types describe n2-standard-4 --zone=us-central1-a \
  --format="value(guestCpus,memoryMb)"

$ gcloud compute machine-types describe n2-standard-4 --zone=us-central1-a --format="value(guestCpus,memoryMb)"
4    16384

All three agree: 4 vCPU, 16384 MiB. The naming schemes disagree; the hardware you’re renting doesn’t.

Practice

gcloud compute machine-types describe n2-highmem-4 --zone=us-central1-a --format="value(guestCpus,memoryMb)"

4    32768

aws pricing get-products --service-code AmazonEC2 \
  --filters "Type=TERM_MATCH,Field=instanceType,Value=m5.xlarge" "Type=TERM_MATCH,Field=location,Value=US East (N. Virginia)"

Next: the same upload-list-sign task against S3, Blob Storage, and GCS, one script per cloud, with the actual output from each API.