2.2 Virtual machines and instance types

What this is and why it exists

A virtual machine is the most familiar thing the cloud rents: a computer, with an operating system you log into, that happens to appear in ninety seconds and disappear when you say so. The skill this topic buys you is not starting one — that is a form — but choosing its size for a reason you could defend, instead of picking something large because small feels risky.

The vocabulary

• Instance — one running virtual machine; Amazon calls the service EC2, Azure calls it Virtual Machines, Google calls it Compute Engine.
• Instance family — a group of sizes tuned for one shape of work: general purpose, compute-heavy, memory-heavy, storage-heavy, or GPU.
• vCPU — the unit of processor you are sold, usually one hardware thread rather than a whole core.
• Image — the frozen contents of a disk that a new machine starts from.
• Golden image — an image you built deliberately, with your packages and settings already in it.
• Snapshot — a point-in-time copy of a volume, used to restore or to build an image from.
• Right-sizing — choosing the size from measurements of the real workload.

The mental model

You are renting a slice, not a machine, and the slice has a shape. Families exist because workloads are lopsided: a web server that is idle between requests wants moderate processor and modest memory; a video encoder wants processor above everything; an in-memory cache wants memory above everything; a database wants fast local disk; a model training run wants GPUs. Within a family the sizes step up by doubling, and the important consequence is that processor and memory usually rise together — so the way to get more memory is often to pay for processor you will not use. When that ratio is wrong for your workload, the fix is a different family, not a bigger machine in the same one.

Images are the second idea, and they are what makes machines disposable. If everything a server needs is baked into the image, a machine is a thing you can destroy and recreate rather than repair — which is the whole basis of autoscaling, of recovering from a failed host, and of not having a server that nobody dares reboot. The alternative, configuring machines by hand after they boot, produces servers that are individuals, and individuals cannot be replaced automatically. Building a golden image on a schedule, with the operating-system patches already applied, also moves patching from an anxious live operation to a routine rebuild.

Then right-sizing, which is mostly a psychological problem. Almost everybody's first instance is too big, because the cost of being too small is a visible outage and the cost of being too large is an invisible line on a bill. The correction is measurement: run the workload, look at processor use, memory use and disk throughput over a normal week including its peak, and choose the size that fits the peak with headroom rather than the size that fits your anxiety. Two habits make this safe — measure before you resize, and resize in one step at a time so you can attribute the effect. A machine sitting at four percent processor for a month is not a safety margin; it is a subscription to unused hardware.

What you should now be able to explain or do

Name the five instance families and give a workload that belongs to each. Explain why moving up a size usually adds processor and memory together, and what to do when only one of them is the constraint. Say what a golden image is and why it makes servers replaceable rather than repairable. Describe, in three steps, how you would right-size a machine you inherited — including which numbers you would look at and over what period.

Check yourself