How do you decide which EC2 instance family and size to run a service on, and why is a fleet of many small instances not automatically cheaper or safer than fewer large ones?

## Step one: find the binding constraint Right-sizing starts by identifying which resource runs out first under real traffic. Everything else follows from that answer. - CPU-bound (encoding, compilation, crypto, tight request handlers) → the `c` family, roughly 2 GiB per vCPU. - Balanced or unmeasured → `m`, roughly 4 GiB per vCPU. The honest default. - Memory-bound (caches, large heaps, in-memory joins) → `r` at roughly 8 GiB per vCPU, and the `x`/`u` families beyond that. - Local storage throughput-bound → `i` families with local NVMe. - Spiky and mostly idle → burstable `t`, accepting its baseline entitlement. The measurement itself has a trap on AWS worth naming out loud: **CloudWatch does not report guest memory utilisation by default**. CPU, network and disk come from the hypervisor, but memory requires the CloudWatch agent inside the instance. Teams that never installed it are, by construction, right-sizing on CPU alone — and then wonder why their `c` instances swap. AWS Compute Optimizer will make recommendations from the metrics you do have, and it is a reasonable starting point, but its memory advice is only as good as the agent data behind it. ## Step two: the size, and why small is not automatically cheaper **Per-instance overhead is paid every time.** Each instance carries the OS, the monitoring agent, a security agent, a log shipper, service-mesh or sidecar processes, and whatever floor your runtime needs — a JVM's non-heap footprint, a connection pool per process, a per-instance warm cache. Split 64 GiB across sixteen small machines instead of four large ones and you pay that overhead sixteen times. For memory-hungry runtimes this alone can erase the supposed saving. **Bandwidth does not scale linearly downward.** AWS quotes smaller sizes as "up to" some figure — a **burst** ceiling sustained by a network I/O credit mechanism, over a lower guaranteed baseline. The largest size in a family gets its full allocation without bursting. A fleet of small instances doing steady bulk transfer or heavy remote-storage I/O can therefore hit a sustained ceiling that its "up to" spec sheet never suggested, while a couple of large instances would not. This is one of the most common surprises in a small-instance fleet, and it is invisible in CPU graphs. **Per-vCPU price is roughly flat within a family.** Within a generation, on-demand cost scales close to linearly with size, so "scale up" is not usually a price premium — it is a different packaging of the same capacity. (How you *buy* that capacity is a separate matter.) **Some things do not shard.** A single large in-memory dataset, a licence keyed per host, a workload with a large shared cache, or anything needing more RAM than a small type offers, forces the large end regardless of preference. ## Step three: what small instances genuinely buy They are not the wrong answer — they are the right answer for different reasons than people give: - **Blast radius.** Losing one instance out of twenty removes 5% of capacity; out of four, 25%. Hardware failures, host retirements and rolling replacements all hurt less on a larger fleet of smaller machines. - **Scaling granularity.** Adding capacity in small increments tracks demand more tightly, and less capacity is wasted at each step. With four large instances, adding one is a 25% jump. - **Placement flexibility.** Smaller types are easier to place across Availability Zones and easier to find capacity for, which matters when you want a broad list of acceptable types rather than one. - **Even distribution.** Load balancing across many similar targets smooths hot spots better than across a handful. ## The synthesis The defensible position is a **middle size, several of them, across multiple Availability Zones** — enough instances that losing one is not an incident, each big enough that fixed overhead and burstable bandwidth are not dominating. Then state the exceptions explicitly: go larger when per-instance overhead is heavy, when a dataset must be resident, or when sustained network and storage throughput matter; go smaller when the workload shards cleanly and you want fine scaling steps and a small blast radius. Two further points separate a principal-level answer: **Right-sizing is a loop, not a decision.** Traffic shape changes, runtimes change, and new generations appear with better price-performance. Re-examine periodically, with an owner and a cadence, rather than treating a launch-day choice as permanent. **Headroom is a policy, not a number pulled from the air.** How much spare capacity you keep is set by how fast you can add more and how much a saturation event costs. A service that scales in two minutes can run hotter than one whose instances take ten minutes to become useful. Say which of those you are designing for, and the size follows.