AWS Official Blog

Amazon EC2 Spot Instances – And Now How Much Would You Pay?

by Jeff Barr | on | in Amazon EC2 | | Comments

We have a whole new way for you to request access to Amazon EC2 processing power!

Using our new Spot Instances, you can bid for one or more EC2 instances at the price you are willing to pay. Your Spot Instance request consists of a number of parameters including the maximum bid that you are willing to pay per hour, the EC2 Region where you need the instances, the number and type of instances you want to run, and the AMI that you want to launch if your bid is successful.

As requests come in and unused capacity becomes available, we’ll evaluate the open bids for each Region and compute a new Spot Price for each instance type. After that we’ll terminate any Spot Instances with bids below the Spot Price, and launch instances for requests with bids higher than or at the new Spot Price. The instances will be billed at the then-current Spot Price regardless of the actual bid, which can mean a substantial potential cost savings versus the bid amount.

You’ll be able to track changes to the Spot Price over time using the EC2 API or the AWS Management Console. This means that you can now create intelligent, value-based scheduling tools to get the most value from EC2. I’m really looking forward to seeing what kinds of tools and systems emerge in this space.

From an architectural point of view, because EC2 will terminate instances whose bid price becomes lower than the Spot Price, you’ll want to regularly checkpoint work in progress, perhaps using Amazon SimpleDB or an Elastic Block Store (EBS) volume. You could also architect your application so that it pulls work from an Amazon SQS Queue, counting on the SQS visibility timeout to return any unfinished work back to the queue if it is running on a Spot Instance that is terminated. Many types of work are suitable for this incremental, background processing model including web crawling, data analysis, and data transformation (e.g. media transcoding). It wouldn’t make much sense to run a highly available application such as a web server or a database on a Spot Instance, though.

You can use the Spot instances to make all sorts of time-vs-money-vs-value trade-offs. If you have some time sensitive work that is of high value, you can place a bid that’s somewhat higher than the historical Spot Price and know that there’s a higher likelihood that it will be fulfilled. If you have some time insensitive work, you can bid very low and have your work done when EC2 isn’t overly busy, perhaps during nighttime hours for that Region. The trick will be to use the price history to understand what pricing environment to expect during the time frame that you plan to make a request for instances.

Your requests can include a number of optional parameters for even more control:

  • You can specify that the request is one-time or persistent. A persistent request will be re-evaluated from time to time and is great for long-term background processing.
  • You can specify a date and time range when your request is valid.
  • You can request that all instances in your request be started at once, as a cluster that we call a Launch Group.
  • You can request that all of the instances come from a single Availability Zone. This may, of course, make it somewhat harder for us to fulfill your request.

Spot instances are supported by the EC2 API, the EC2 Command Line Tools, and the AWS Management Console. Here’s a picture of the AWS Management Console in action:

Here’s a good example of how the Spot Instances can be put to use.

The Protein Engineering group at Pfizer has been using AWS to model Antibody-Antigen interactions using a protein docking system. Their protocol utilizes a full stack of services including EC2, S3, SQS, SimpleDB and EC2 Spot instances (more info can be found in a recent article by BioTeam‘s Adam Kraut, a primary contributor to the implementation). BioTeam described this system as follows:

The most computationally intensive aspect of the protocol is an all-atom refinement of the docked complex resulting in more accurate models. This exploration of the solution space can require thousands of EC2 instances for several hours.

Here’s what they do:

We have modified our pipeline to submit “must do” refinement jobs on standard EC2 instances and “nice to do” workloads to the Spot Instances. With large numbers of standard instances we want to optimize the time to complete the job. With the addition of Spot Instances to our infrastructure we can optimize for the price to complete jobs and cluster the results that we get back from spot. Not unlike volunteer computing efforts such as Rosetta@Home, we load the queue with tasks and then make decisions after we get back enough work units from the spot instances. If we’re too low on the Spot bids we just explore less solution space. The more Spot Instances we acquire the more of the energy landscape we can explore.

Here is their architecture:

You can learn even more about Spot Instances by reading Werner Vogels’, Expanding the Cloud – Amazon EC2 Spot Instances, Thorsten von Eiken’s Bid for Your Instances and the Introduction to Spot Instances.

So, what do you think? Is this cool, or what?

— Jeff;