Dave Naffziger's Blog

Amazon announced today Spot prices for EC2 instances - market-driven pricing for unused Amazon EC2 capacity.

You bid an amount per hour of usage, and if the spot price is equal to or lower than the amount, you then get the instance for that hour. This would be a great way to do things such as process time-insensitive data (maybe log files, updates of denormalized data, etc.)

A quick look at the historic graph, shows spot pricing for a Linux m1.small running between $0.025 and $0.35 per hour, averaging $0.030 per hour. Normal instances cost $0.085 per hour. Reserved instances cost $0.030 per hour.

The question that I’m most intrigued with currently is whether we should just move all of our normal instances to Spot instances. We would then set bids equal to the regular pricing. In theory, our pricing should never be worse than what we pay currently and would most likely be much better.

The long-term outcome is likely to be that all of EC2 pricing (except for the Reserved instances) moves to Spot Pricing.

The only risk I can think of is other companies doing the same thing but bidding more than the regular instance price. Then we’d get screwed as all of our instances are turned off. But of course, any company that switches from a regular instance to Spot instances, should free up an equal amount of capacity as they are currently using.

What am I missing? Are there other risks to this strategy?

Amazon announced their first EC2 price reduction since EC2 was launched in August 2006.

Amazon’s price reductions take the form of EC2 ‘Reserved’ Instances. Users can opt to ‘reserve’ an instance for an up front cost. Reserved Instances then have a lower rate for each instance-hour use afterwards. For example, a Small instance normally costs $.10 /hour. A 1-yr Reserved Small Instance costs $325 up front and then $.03/hour. That works out to a 33% discount if you use it for a full year. A 3-yr Reserved Instance ($500 up front), results in a 50% discount over the 3 years.

The discounts are the same across the spectrum of EC2 Instance types. If you use your servers full-time, the 3-yr Reserved Instance is the better deal compared to the 1-yr instance if you use the instance for longer than 12 months:

What’s wrong with discounts?

Don’t get me wrong, the Reserved Instances will save BrandVerity a lot of money. I completely understand why these long-termish commitments make sense for Amazon, but some of the magic of EC2 just disappeared:

• Moore’s Law Violations: EC2 is nearing 3yrs old and Amazon hasn’t lowered prices (or increased capabilities) of its basic compute unit. They’ve introduced a ton of different configurations, but core prices haven’t budged. Committing to 3-yr usage and prices gives me the feeling that we aren’t on a pricing slope that parallels Moore’s Law.
• Oh, The Democracy!: Capital suddenly matters. Nothing costs more for the boot-strapped startup, but the company with capital can build a significantly lower cost-basis.
• Scale Flexibility: Committing to specific instance types increases the cost of moving between different EC2 types. UnReserved Surge capacity is now much more expensive vis-a-vis Reserved every-day servers.

Of course, Amazon isn’t bound by many of the assumptions I made above. Their next pricing update could address some of those issues - even for customers that have already purchased a reserved instance.

Both are nearly always useless, but are often used heavily in the marketing or sale of products and services. However, SLAs are frequently demanded by businesses. What gives?

But my tire has an 80,000 mile warranty
Read the fine print on your tire warranty. Here are a few snippets from Goodyear’s warranty:

Tires not eligible for replacement [greater than 2/32” of treadwear or 12 months] … will be replaced with a comparable Goodyear tire on a prorated basis. Replacement price will be calculated by dividing the tire’s retail price at the time of adjustment by the percentage of usable tread that has been worn off…You pay for mounting and balancing and any applicable taxes.

So, if your tire dies (due to normal wear and tear) at 70K miles in the middle of nowhere, you get a 8.75% discount on a new tire… if you can prove that you did all of the proper rotating, have your original invoice, etc. There is no compensation for you hassle or even the additional cost of having to put no tires on.

But my hosting SLA says I get 99.999% uptime
The crux of the reason why most SLAs are useless is that they have no teeth. Let’s look at Rackspace’s SLA (which guarantees 100% network uptime):

Upon experiencing downtime, Rackspace will credit the customer 5% of the monthly fee for each 30 minutes of downtime (up to 100% of customer’s monthly fee for the affected server).

If the Rackspace datacenter goes down again, and you lose a day (or more) of business, all you get back is 1 month of hosting fees. I expect that Rackspace’s outage (or 365 Main’s) cost ill-prepared customers way more than a single month of hosting fees.

And therein lies the problem with SLAs. No reasonable service provider is going to contractually put their business on the line for each customer (for large customers, the actual cost of a network outage can be huge). Their primary (and fully aligned) motivation is that if their service sucks, customers will go elsewhere.

EC2 and AppEngine don’t have SLAs
This meme echoes around the blogosphere from time-to-time. Companies are uncomfortable running on EC2 because EC2 has no SLA or or comment on AppEngine’s lack of SLA for that matter.

SLAs rarely make a service. Instead evaluate the service and their historic performance. Understand how they are prepared for outages. What happens to them if their service goes down? I’d contend that Amazon would face such a crisis of confidence that it would cripple their new offerings.

And do your own disaster planning.