Basics of IaaS Spot Pricing

This is part 4 of my pricing in the cloud series.

Exactly one year ago - on Monday, December 14, 2009 - Amazon Web Services launched spot pricing as a new feature of Amazon EC2.

In a nutshell, spot pricing is a dynamic pricing scheme for EC2 instances. At each moment in time, provider sets a price for each type of instance. Users specify the maximum amount they are willing to pay for a spot instance (bid). If the amount specified by a user equals or exceeds current spot price, user gets to run the instance and pays the spot price for the instance (important - user always pays the spot price, not their bid price!); otherwise, user’s instance is terminated or user doesn’t get the instance at all until the spot price is reduced below or to a level of user’s bid. Fundamentally, from cloud provider’s perspective, spot instances are a mechanism that allows cloud provider to sell its unused capacity at a discount, while retaining the right to reclaim it quickly if necessary. Let’s continue exploring spot pricing from a cloud provider’s point of view. It’s trickier than may look at first sight.

Suppose at some point in time there are N instance slots available for spot instances of some type (for example, Linux/UNIX m1.large). At the same time, there are M single-instance bids - [ B1, B2, …, Bm ], assume this array is sorted - BiBi+1.

Let’s say NM. In this case, information above is not sufficient for provider to set the spot price - it can vary quite a bit depending on optimization. If provider wants to maximize the number of running spot instances, it will set spot price at or below B1. On the other hand, if provider wants to maximize its revenue, it will set the spot price quite differently - depending on specific values of Bi. Note that which optimization is used can change at any moment.

For example, with N=10, if bids are [ 1, 2, 5, 50 ], revenue-maximizing spot price is 50; if bids are [ 1, 2, 5, 45, 50 ], it’s 45.

(https://gist.github.com/739949)

This thought exercise also shows that bids placed on the lower end of the spectrum have a very little chance of actully getting an instance. In the above example, for a bid of 2 to run, spot price must not exceed 2. But because all customers pay the spot price and not their bid, a provider stands to lose quite a bit of revenue if it were to do it - at spot 45, revenues are 90. At spot 2, revenues will be only 8 (even though more customers will get their instances).

Now let’s say N < M. In this case, no matter how you slice it, bid B1 can’t be allowed to run - hence spot price is going to be greater than B1. And this highlights another weakness of spot pricing from provider’s point of view. What if B1 = B2 = B3 = … = Bk? None of them can be allowed to run and spot price must be set at a higher level.

For example, with N=3, if bids are [ 10, 20, 30, 40 ], revenue-maximizing spot price is 20 or 30, both yield revenue of 60. But if bids are [ 10, 10, 10, 40 ], [ 20, 20, 20, 40], [ 30, 30, 30, 40 ] or even [ 39, 39, 39, 40 ], revenue-maximizing spot price is 40 with only 40 of revenue.

Therefore, a conclusion - provider benefits from diversity of bids, especially at the low end, and hence should potentially encourage it.

Consider the following extreme case as an example. Let’s say bids are [ 40, 40, 40 ] and N = 2. Spot price can’t be set at or below 40 in this case, so as a result there will be no spot instances running at all, despite available slots.

How could a provider influence bids submitted by customers, to achieve desired diversity? One way of doing it is through the use of price anchoring. One obvious anchor is a regular price for a specific product (for example, $0.085 per hour for m1.small Linux/UNIX in us-east-1). Another anchor is current spot price. I don’t know whether this technique is used and if yes, how effective it is in delivering diverse bids but I am sure a provider can measure degree of correlation between bids and current spot price (I wish I had access to this dataset…).

Spot pricing is all about random variables. Provider starts with knowing only N and setting some initial spot price. Spot price itself is a random variable to customers - no one knows if spot price is going to go up or down next, exactly when it will happen and by how much. In response to spot price, customers submit their bids - which cumulatively are a random variable to provider because it can’t know what they will be (this is most likely a lie - with a year worth of usage, I am confident Amazon has already built fairly accurate models for incoming bids). Once the bids are in, spot price is recalculated and the cycle continues.

A single spot price is set for entire region and each region has two or more availability zones. If a submitted bid exceeds a spot price and requests a specific zone which has no spot capacity, provider faces a dilemma. It could raise the spot price for entire region to the level above this bid. Or it could set individual spot prices for each zone instead of each region. Or it could make an exception and let the bid in without getting an instance until capacity becomes available.

Amazon seems to have chosen the latter approach, even though the second approach would have been cleaner but would allow users to match zones between AWS accounts.

This pretty much covers the basics. Because everyone pays the same price, spot pricing could be one of the easiest-to-implement dynamic pricing schemes. Which obviously doesn’t mean that it’s easy to implement - to the best of my knowledge, even after a full year, Amazon remains the only public IaaS cloud to offer non-static pricing. Their continued hiring efforts lead me to believe that they are not done - I am looking forward to more pricing goodness from Amazon.

Read other posts on my blog tagged amazon-ec2-spot or cloud-pricing .

Categories: cloud-computing | economics |