[tptacek]

A reserved instance is just an instance you don't pay hourly for. Lots of people use AWS specifically so they can pay hourly, turning up servers dynamically in response to load, and then turning them off when spikes subside, without penalty.

[paulmd]

However, most people's load doesn't regularly go to zero - and in fact it still might be advantageous to use reserved instances even if it did, because they're so much cheaper.

The situation is analogous to "base-load vs peak-load" on the power grid. Base-load power (reserved instances) are very cheap but cannot respond to transient spikes in the load. Peaking plants (on-demand instances) can respond to transient spikes quickly, but are expensive to run.

A naieve model is that you find your minimum usage and buy enough baseload to cover that, with peaking beyond that. However, since peaking is so much more expensive than baseload this is not necessarily optimal - instead, you may want to buy some extra baseload that isn't fully utilized during your off-hours, because that offsets expensive peaking capacity during your high-demand hours.

You almost certainly would not want to have zero reserved instances.

[cothomps]

.... kind of. A reservation is all about planning capacity. If you know (e.g.) that you need two web servers "hot" all the time to serve a base level of traffic, you can pay for that up front either partially or in total (a reservation) at some pretty significant savings. You can add hourly (or spot) capacity as needed - but paying for what you'll be using up front can make AWS very economical.

If you're paying for X1 servers for an extended period of time on an hourly basis, you should be entitled to a thank you note from Jeff Bezos.