I don't buy the argument that this somehow puts a big provisioning planning burden back on users. Most small users of EC2 know that they are going to need one

I don't buy the argument that this somehow puts a big provisioning planning burden back on users. Most small users of EC2 know that they are going to need one or two instances on all the time. Amazon just lowered their base costs, making it easier for them to choose EC2 over another VPS offering. Most larger users also know they have a "base load" that they have to meet. It's not hard to imagine that a lot of sites will have 2 machines as redundant load balancers, two as redundant web/app servers, and two for a DB failover cluster. Paying in advance for these instances is a no-brainer once you've decided EC2 is for you. If figuring out the rest is too much work or involves too much uncertainty, the on-demand pricing is still compelling. "In principle, it costs the same to run one instance for 1000 hours than to run 1000 instances for one hour." This wouldn't be true if you were operating your own datacenter, and it's not true in Amazon's datacenter either. In order to offer on-demand instances, Amazon has to keep idle capacity in reserve. There is a difference in degree, since Amazon is averaging over a lot more customers, but they still have to build and maintain capacity that will sit idle for significant periods of time. By creating a new pricing tier for reserved instances, they can both reduce their uncertainty about unused capacity, and give customers a better price for making that commitment. What's really missing here is another low-priced tier for low-priority instances. These would either be suspended and paged completely to disk during times of high load, or they'd be started and killed automatically to make use of idle capacity. They could be used for long-running batch jobs.