Steve, "...we won't respond to your testing as if your instances were under attack." So how do I test my application to see how it will really behave if it was under attack? AWS's DDoS and attack mitigation are a part of my application delivery path and I want to test the real thing as well, not just my application "naked" to the internet with AWS's stuff turned off - though I will test that, too. If I specify in my penetration testing request that I want AWS to leave in place its attack responses, will you honor that request? Thanks.

Jeff, this is a really cool addition to the RRS service. Can you comment on how soon after an object is really lost the SNS notification will be sent? I'm interested to know if that latency is small enough to practically ignore the possibility that someone else will request the object before I've been notified of its loss.

Thanks for linking to my article!

There's no reason to assume that the spot price is always set below some bid. It could be a pure function of the supply of spot instances. Just because the price was set to a certain level doesn't mean anyone bought at that price. In effect, when there are no spot instances left the spot price can be said to be infinite - so no bids would ever win.

"There will always be a premium placed on guaranteed capacity." And when there are no more on-demand instances... the spot price will be higher than the on-demand price. If you really want to ensure you have access to the on-demand prices longer-term, you should buy reserved instances now. In less than six months (at current rates) the 1-year term breaks even.

Looking at the historical graphs of spot instance prices you can see that the spot price occasionally spikes to above the on-demand price. http://cloudexchange.org/charts/us-east-1.linux.m1.large.html Presumably this occurs when a large batch of on-demand instances is provisioned. For example, the spike to 0.400 in the us-east region on 17 Dec is nicely correlated with this user's provisioning of 300 m1.large instances: http://twitter.com/Lounibos/status/6777451245 The fact that the price drops back down to its prior level after a few hours is likely an indication that Amazon's pricing algorithm is still being perfected. But the bottom line is: the spot price can exceed the on-demand price.

One more Whoa Moment data point: As reported in this thread, http://developer.amazonwebservices.com/connect/thread.jspa?threadID=39924&tstart=0 the spot price for one instance type did already exceed the on-demand price. It was for a short time, but it happened.

Hi Geva, The idea of a spot instance contest came from David Kavanagh (and includes the caveat of "for the least $"). Here's my tweet, which is a retweet of David's: http://twitter.com/ShlomoSwidler/status/6722022106 Regarding the availability of EC2 instances, don't assume they're always available. Here are a bunch of threads in the EC2 support forum where people complain of the InsufficientCapacity error. This error means there's no more on-demand instances available at the moment. These threads are from all over the calendar, so it's not a recent development. http://www.google.com/search?q=site%3Adeveloper.amazonwebservices.com+InsufficientCapacity Currently there are 270 results for this query. Whoa moment. IMO, Spot Instances should be a wake-up call for developers: Be careful wedding your code to EC2, lest you find yourself paying above the on-demand price when there are no more on-demand instances.

Very nice to see the application handling its own operational events. A minor nitpick: Example 3 probably should say if (averageRequests > maxRequestsPerInstance) otherwise you're scaling up when you don't need to.