Hardware Basics #9: Reading Cloud Instance Specs — Choosing to Match the Workload
In #8 we said that using the cloud as IaaS means picking an instance type yourself. This final post is about that choice. A name like c5.xlarge looks like a cipher at first, but if you’ve followed this series, every part of it maps to the four resources from #1. We’ll close the series by reading a spec sheet and picking a type that fits the workload.
Where this post sits in the Hardware Basics series:
- #1 Four resources that run a computer — CPU / Memory / Storage / Network
- #2 CPU — Cores / Threads / Clock / Cache, and what a vCPU really is
- #3 Memory — RAM, the hierarchy, and what happens when swapping starts
- #4 Storage ① Devices — HDD / SSD / NVMe and IOPS / Throughput / Latency
- #5 Storage ② Layout and connection — RAID and DAS / NAS / SAN
- #6 Network — Bandwidth and latency, from the NIC to the data center
- #7 Virtualization and containers — How one physical server becomes many
- #8 Cloud — From owning to renting, from on-prem to IaaS / PaaS / SaaS
- #9 Reading cloud instance specs — Choosing to match the workload ← this post
Dissecting an instance name #
AWS instance names follow a rule. Take c5.xlarge — it splits into three pieces.
c 5 xlarge
family generation size
(purpose) (which gen) (how big)- Family — which resource the type leans toward (
cis compute-optimized) - Generation — which generation (higher is newer, generally faster and more efficient)
- Size — how many resources (
large→xlarge→2xlargegrows)
Just reading the name reveals the character: “latest-generation, compute-leaning, mid-size.” Other clouds use different notation, but the structure of splitting by family and size is similar.
Family — which resource it leans toward #
The family shows which of the four resources from #1 it leans toward. At the same vCPU count, the memory ratio and storage profile change.
| Family | Character | Leaning resource | Suited workload |
|---|---|---|---|
t | burstable / general | low by default, brief bursts as needed | small scale, low traffic |
m | general | balanced vCPU and memory | general web / app servers |
c | compute-optimized | high CPU ratio | compute-heavy, batch |
r | memory-optimized | high memory ratio | databases / caches |
i | storage-optimized | fast local NVMe | bulk / high IOPS |
The c family has more vCPU relative to memory; the r family the opposite. Which resource becomes the bottleneck — the CPU from #2 or the memory from #3 — is what decides the family.
Size — multiples within the same family #
The size sets the amount of resources within a family. Each step up roughly doubles vCPU and memory, and the price with it.
| Size | vCPU | Memory | Price |
|---|---|---|---|
large | 2 | baseline | baseline |
xlarge | 4 | 2x | about 2x |
2xlarge | 8 | 4x | about 4x |
Recall from #2 that a vCPU usually corresponds to one hyper-thread, so xlarge’s 4 vCPUs is roughly 2 physical cores.
Reading the spec sheet by the four resources #
At the end of the day, an instance’s spec sheet is nothing more than this series’ four resources. Map each item to the post that covered it and the spec sheet falls into place.
| Spec-sheet item | What it is | Covered in |
|---|---|---|
| vCPU | compute capacity measured in hyper-threads | #2 |
| Memory (GiB) | the amount of working space | #3 |
| Storage | EBS-only or local NVMe | #4 , #5 |
| Network bandwidth | maximum Gbps | #6 |
Notations like “EBS-optimized” or “up to 10 Gbps” now make sense too. The former means extra bandwidth is reserved for network-attached block storage in #5; the latter is the NIC ceiling of #6.
Choosing by workload #
Each workload has a different resource that becomes the bottleneck. Picking the family that leans toward that resource is the starting point.
| Workload | Main bottleneck | Recommended family |
|---|---|---|
| General web / app server | balanced | m (general) |
| Compute-heavy batch / encoding | CPU | c (compute) |
| Database / in-memory cache | memory | r (memory) |
| Bulk / high-IOPS storage | storage | i (storage) |
| Small scale, low traffic | low by default | t (burstable) |
The order for choosing #
The order follows the bottleneck principle from #1.
- Decide the bottleneck resource. See which of CPU / memory / storage / network this workload is most sensitive to.
- Pick the family. Choose the family that leans toward that resource.
- Pick the size. Set it to the vCPU and memory you need. Start small.
- Measure and adjust. Under real load, see which resource hits its limit first and change the size or family.
The key is not to size up based on a guess. Starting small and growing through measurement beats sizing big upfront and bleeding cost.
Common pitfalls #
“Just take a big one to be safe” #
The most common waste. Most instances have resources to spare most of the time. Starting small and growing by measurement saves cost.
“I chose by vCPU count alone” #
At equal vCPU, the memory ratio differs by family. Put a database on the c family and memory runs short first, spilling into the swap of #3.
“I ran a steady load on burstable (t)”
#
As #2 noted, the t family is throttled once credits run out. It doesn’t fit workloads that use CPU steadily.
“Pick once and you’re done” #
Workloads change. Reviewing the type periodically against measured numbers prevents over- and under-provisioning.
Wrap-up — closing the series #
What we covered:
- An instance name dissects into family (purpose), generation, size.
- The family shows which of the four resources it leans toward (
m,c,r,i,t); the size sets the amount. - The spec sheet’s vCPU, memory, storage, and network are exactly the resources from #2, #3, #4, and #6.
- The order for choosing is bottleneck resource → family → size → measure and adjust. Start small and grow by measurement.
Over nine posts we went from four resources to a cloud instance spec sheet. Now “slow” and “expensive” are things to diagnose rather than guess at.
Next — on to AWS #
If this series was about reading a spec sheet, actually launching and operating an instance is the job of the AWS series. Set up your account and region in AWS Basics, launch this post’s instance directly in EC2 and VPC in AWS Intermediate, and connect it to storage (S3). That’s how hardware knowledge turns into real-world operations.