Then I started thinking about the fleet model for such images. The best way would be for me to tell EC2 the max number of these smallest instances I want, and it would constantly try to have that many running, constantly starting new ones as space becomes available. The current EC2 API starts your fleet up all at once, and if you later want more, you have to explicitly ask for more.
Then I started thinking about how Amazon should charge for these things. The simplest way would be to pick some flat per-hour rate, just like their other instances sizes.
But then I realized that the better way would be to do it as a continuous dutch auction. I would specify the most per instance-hour I was willing to pay, and EC2 works out the lowest price across the entire universe of currently outstanding bids that will completely fill the capacity available for these things. As more people come into the system and bid for capacity, my instance-hour price I am paying can rise or fall based on everyone else's bids, and I could have my instances shut down if the current market clearing price rises higher than my set max bid.
There is competition to EC2 coming online soon. Eventually, someone is going to try this charging model.
If I was to build an EC2-like system, it's the charging model I would use. It would most perfectly capture and monetize my value to my users, giving me the largest possible income for the value I am providing, which I can use to build more capacity. It would also give me a much better and smoother signal to how much my users like my system, other than "there is more capacity than is being used, I overbuilt" or "I'm oversubscribed, and at 100% utilization, I need to build out more".
Plus it would make money during off-peak time.