VMs (bin-packed reservations)
A virtual machine is a slice of one of your physical servers -- its own CPU, memory and disk -- rented to a customer as if it were a whole machine. One server runs many VMs at once, side by side, and none of the tenants ever see the hardware underneath. They just see "their" computer.
VMs are the bread-and-butter product: easy to understand, easy to grow into. A customer starts with one box and asks you for more as they get busier. That steady "can I have another?" is the heartbeat of the early game -- every yes compounds into more revenue, and a happy growing tenant is the best advertising you have.
Because many tenants share one server, a single greedy VM can spoil the day for everyone else on that box -- the noisy-neighbor problem. Pack the servers sensibly, leave headroom, and watch which machines are running hot.
Detailed explanation
A VM is a reservation of (vCPU millicores, RAM, block GB/IOPS) bin-packed onto a host with free capacity. The allocator first-fits across reachable, powered, in-region hosts; one host carries many tenants' VMs simultaneously. Capacity is a vector, not a scalar -- the binding constraint is whichever of vCPU, RAM, SSD GB, or SSD IOPS exhausts first on a given host.
Common ratios: 3-4x CPU oversubscription, ~1x RAM (an OOM kill is brutal and customer-visible), 5:1+ on shared SSD IOPS. Steady-state utilization above ~80% pushes p99 into the hockey-stick region. Pick host categories to match the tenant mix -- ComputeDense for CPU-bound APIs, MemoryOpt for game/DB boxes -- rather than packing everything onto one balanced SKU.