Stop 04 · Compute ServicesTopics · 2/10

Instance Types & Sizing

In short

AWS alone has hundreds of instance types. Pick too small and your app crawls. Pick too big and you're burning money every hour. The names look scary but follow a simple pattern.

Cloud providers offer many VM sizes and families optimized for different workloads — general purpose, compute-optimized, memory-optimized — choosing correctly avoids both under-provisioning and wasted spend.

The blob character thinks while standing beside an auto-rickshaw, a minibus and a small truck.

Think of it like this

Auto, minibus or tempo

Two friends to the station? Take an auto. A cricket team to a match? Book a minibus. Shifting a fridge? Call a tempo. Nobody books a truck for two people. Instance types are vehicles for different loads.

Watch it happen

Decoding an instance name

large

1/6AWS names look random but read left to right: family, generation, extras, size.

The big ideas

What you need to know

General purpose first

Web apps and APIs usually start on general purpose (m or t). Switch only when metrics show a clear bottleneck.

Compute vs memory

Video encoding or batch maths? Compute-optimised. Big caches or in-memory databases? Memory-optimised.

Burstable t types

t instances earn CPU credits while idle and spend them in bursts. Great for low, spiky use; poor for constant heavy load.

Size from data

Watch CPU and memory for a week. If CPU never passes 20%, go a size down. That's right-sizing.

See it in code

A tiny example

bash

1aws ec2 describe-instance-types \2  --instance-types t3.micro m7i.large c7i.large r7i.large \3  --query "InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,MemoryInfo.SizeInMiB]" \4  --output table

Compare vCPUs and memory side by side. Notice r7i.large has the same vCPUs as c7i.large but four times the memory.

Save yourself the pain

Common mistakes

Oops

Picking the biggest instance 'to be safe'.

Do this instead

Start modest, watch real metrics, then resize. Changing instance type takes a stop and start, not a rebuild.

Oops

Running a busy production database on a tiny burstable instance.

Do this instead

Once CPU credits run out, a t instance slows right down. Use t for light or spiky work only.

Your mission

Match the workload

~20 min

Quick check

Your app's CPU sits at 15% but memory is always above 90%. What change makes sense?

Go deeper

1Compare 3 instance types from different families and note their CPU/memory ratios.
2Learn to match a workload type (web server, database, batch job) to an appropriate instance family.
3Practice right-sizing a hypothetical workload rather than defaulting to 'the biggest one to be safe'.