Category: Amazon EC2*

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

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;

Amazon EC2 Running Microsoft Windows Server 2008

You can now run Microsoft Windows Server 2008, SQL Server 2008 Express, and SQL Server Standard 2008 on Amazon EC2. There has been a lot of demand for this particular feature and I’m happy to be able to make this announcement!

You can launch these instances in all three AWS Regions (US East, US West, and EU) right now, and you can also take advantage of additional EC2 features such as Elastic IP Addresses, the Amazon Elastic Block Store, Amazon CloudWatch, Elastic Load Balancing, and Auto Scaling.

You can use the entire Microsoft Web Platform, including ASP.NET, ASP.NET Ajax, Silverlight, and Internet Information Server (IIS) and you can also use the AWS SDK for .NET to access other parts of AWS such as Amazon S3, the Amazon Simple Queue Service, or Amazon SimpleDB.

Pricing starts at $0.12 per hour for Windows Server 2008 and $1.08 per hour for SQL Server Standard Edition. There’s more information on the Amazon EC2 Running Windows page.

I think that this new release highlights a key aspect of AWS — flexibility. As your needs dictate, you can launch EC2 instances running an incredibly diverse array of operating systems including Windows Server 2003 and 2008, seven distinct Linux distributions (Fedora, CentOS, Debian, Gentoo, Red Hat, SUSE, and Ubuntu), and even OpenSolaris. You can launch a few (or a bunch of) instances in three separate geographic Regions, and you can keep them running for as long as you need them.

This additional flexibility means that you can use EC2 to create heterogeneous application architectures, using the operating system that is best suited to each part of the system. You can do your web crawling on some Linux instances, transcode the data on a Windows instance or two, and then serve up the final results using a web server running on another Linux instance.

Windows Server 2008 makes use of our new Boot from EBS feature, so your root partition can occupy  up to 1 TB. You can stop, and then later start the instances with ease, all from the AWS Management Console.

How do you plan to use Windows Server 2008? Leave me a comment!

— Jeff;   

The Economics of AWS

For the past several years, many people have claimed that cloud computing can reduce a company’s costs, improve cash flow, reduce risks, and maximize revenue opportunities. Until now, prospective customers have had to do a lot of leg work to compare the costs of a flexible solution based on cloud computing to a more traditional static model. Doing a genuine “apples to apples” comparison turns out to be complex it is easy to neglect internal costs which are hidden away as “overhead”.

We want to make sure that anyone evaluating the economics of AWS has the tools and information needed to do an accurate and thorough job. To that end, today we released a pair of white papers and an Amazon EC2 Cost Comparison Calculator spreadsheet as part of our brand new AWS Economics Center. This center will contain the resources that developers and financial decision makers need in order to make an informed choice. We have had many in-depth conversations with CIO’s, IT Directors, and other IT staff, and most of them have told us that their infrastructure costs are structured in a unique way and difficult to understand. Performing a truly accurate analysis will still require deep, thoughtful analysis of an enterprise’s costs, but we hope that the resources and tools below will provide a good springboard for that investigation.

Here’s what we are releasing:

Whitepaper The Economics of the AWS Cloud vs. Owned IT Infrastructure. This paper identifies the direct and indirect costs of running a data center. Direct costs include the level of asset utilization, hardware costs, power efficiency, redundancy overhead, security, supply chain management, and personnel. Indirect factors include the opportunity cost of building and running high-availability infrastructure instead of focusing on core businesses, achieving high reliability, and access to capital needed to build, extend, and replace IT infrastructure.


Ec2costcalc The Amazon EC2 Cost Comparison Calculator is a rich Excel spreadsheet that serves as a starting point for your own analysis. Designed to allow for detailed, fact-based comparison of the relative costs of hosting on Amazon EC2, hosting on dedicated in-house hardware, or hosting at a co-location facility, this detailed spreadsheet will help you to identify the major costs associated with each option. We’ve supplied the spreadsheet because we suspect many of our customers will want to customize the tool for their own use and the unique aspects of their own business.


UserguideThe second white paper is a User Guide for the Amazon EC2 Cost Comparison Calculator. This document is intended for use by financial decision makers as a companion to the calculator. The document and the associated calculator identifies and focuses on the direct costs of IT infrastructure and skips the indirect costs, which are far more difficult to quantify.

All these resources and tools are available in our AWS Economics Center. As always, feedback is always appreciated.

— Jeff;

Gear6 Web Cache Server for the Cloud

Many Web 2.0 applications include a substantial amount of dynamic content. The pages of these applications generally cannot be generated once and then saved for reuse, and must be built from scratch in response to each request.

In order to make a Web 2.0 application run with an acceptable degree of efficiency, it is often necessary to do some application-level caching. The open source Memcached server is often used for this purpose. It is relatively easy to install Memcached on one or more servers, creating a single, cache which can expand to consume the available RAM on all of the servers if necessary. The cache can be checked before performing an expensive calculation or database lookup, often obviating the need for the calculation or the lookup. The results can be stored in the cache for the next time around. Properly implemented, a cache can provide a tremendous speed benefit while also reducing traffic to database and compute servers.

Gear6 has created a version of Memcached suitable for mission-critical work. This product is now available as an Amazon EC2 AMI.

Think of it as “Memcached as a service.”

The Gear6 implementation of Memcached leverages the instance’s local (ephemeral) storage, providing a 100x cache capacity increase per instance (when compared to a purely RAM-based cache), while remaining 100% compatible with the existing memcached API. There’s a web UI (shown at right) for monitoring, with access to 24 hours of historical usage and performance data.

The 32-bit (Small) instances are free (regular EC2 usage charges apply) and the 64-bit instances are available on an hourly basis, with prices ranging from $0.50 (Large) to $0.86 (Quad Extra Large) per hour, plus EC2 usage charges, including 24×7 support from Gear6. Get started now.

Memcached client libraries are available for every common programming language, including C / C++, PHP, Java, Python, Ruby, Perl, .Net, MySQL, PostgresQL, Erlang, Lua, LISP, and ColdFusion.

I’m really happy to see this offering from Gear6. As I note in this blog from time to time, powerful, high-level services like this allow application developers to spend more time focusing on the novel and value-added aspects of their application and less time on the underlying infrastructure.

— Jeff;

Expanding the AWS Footprint

A new AWS Region is online and available for use!

Our new Northern California (US-West) Region supports Amazon EC2, Amazon S3, SimpleDB, SQS, Elastic MapReduce, Amazon CloudWatch, Auto Scaling, and Elastic Load Balancing. The AWS documentation contains the new endpoints for each service.

The existing Amazon S3 US Standard Region provides good, cost-effective performance for requests originating from anywhere in the country. The new S3 region optimizes performance for requests originating from California and the Southwestern United States. In either case, Amazon CloudFront can be used to provide low-latency global access to content stored in S3. The Northern California and EU Regions provide read-after-write consistency for PUTs of new objects in your Amazon S3 bucket and eventual consistency for overwrite PUTs and for DELETEs. The existing US Standard Region continues to provide eventual consistency.

Service pricing in the Northern California Region will be at a small premium to the pricing in our existing US-based Region, reflecting a difference in our operating costs.


As you can see from the screen shot at right, the newest release of Bucket Explorer provides support for the new region. Other tools will add support in the near future. If you are a tool vendor, please post a comment as soon as you’ve added support for the new region.


Update: The CloudBerry S3 Explorer now supports the Northern California Region. It also includes a preview version of the code needed to support AWS Import/Export.


You can get started with this Region now. Existing code and tools should require only a change of service endpoint to work. The AWS Management Console and ElasticFox already support the new Region.

As you may already know, we have already announced that we plan to bring AWS to Asia in 2010, starting out with multiple Availability Zones in Singapore in the first half of 2010, followed by other Asian locations later in the year.

Update: The AWS Simple Monthly Calculator has also been updated and now shows the new region in the drop down box. You can use to the calculator to estimate your costs.

— Jeff;

New Amazon EC2 Feature: Boot from Elastic Block Store

You can now launch Amazon EC2 instances from an AMI backed by Amazon EBS (Elastic Block Store). This new functionality enables you to launch an instance with an Amazon EBS volume that serves as the root device.

This new feature brings a number of important performance and operational benefits and also enables some really powerful new features:

  • Headroom – The root device (and hence the Amazon Machine Image or AMI) can now occupy up to 1 TB. You can now create more richly featured AMIs, installing additional tools, libraries, applications, and even reference data ahead of time.
  • Flexibility – Each AMI can now reference one or more EBS snapshots. An EBS volume will be created from each snapshot and then attached to the new instance before it begins to boot. For instance, you could attach reference data such as a Public Data Set to each new instance.
  • Performance – Instances will launch more quickly when they are booted from an EBS snapshot.
  • Control – Instances can be stopped and then restarted at a later time. The contents of the volume are, of course, preserved while the instance is stopped, so you get the benefits of a persistent root device without being tied down to a particular piece of compute hardware.

Let’s compare and contrast the original S3-based boot process and the new EBS-based process. Here’s what happens when you boot from an AMI that references an image residing in S3:

  1. EC2 locates and allocates a suitable piece of compute hardware (the instance).
  2. The S3 image is copied to the root device of the instance.
  3. The instance is booted.

Now, here’s what happens when you boot from an AMI that references an image residing in EBS:

  1. EC2 locates and allocates a suitable piece of compute hardware (the instance).
  2. An EBS volume is created for each EBS snapshot referenced by the AMI. The first snapshot is mandatory and denotes the root device; the others are optional and denote additional volumes to be created from other snapshots.
  3. The instance is booted. Unlike the S3-based instances, the ephemeral (local) disks are not mounted automatically. If you need to use these disks for temporary storage, you can request that they be mounted using an option to the RunInstances function. The usual charges for I/O requests apply to an EBS root device; you should consider using ephemeral storage volumes for applications that depend on the local file system for short-term storage. 

Up until this point the two processes are quite similar. However, the new model allows the instance to be stopped (shut down cleanly and the EBS volumes preserved) at any point and then rebooted later. Here’s the process:

  1. The shut down process is initiated and the operating system takes itself out of service.
  2. The EBS volumes are detached from the compute hardware.
  3. The compute hardware associated with the instance is freed and returned to the resource pool.
  4. The state of the instance is set to “stopped.”

At this point the instance neither consumes nor possesses any compute hardware and is not accruing any compute hours. While the instance is stopped, the new ModifyInstanceAttribute function can be used to change instance attributes such as the instance type (small, medium, large, and so forth), the kernel, the user data, and so forth. The instance’s Id remains valid while the instance is stopped, and can be used as the target of a start request. Here’s what happens then:

  1. EC2 locates and allocates a suitable piece of compute hardware (the instance).
  2. The EBS volumes are attached to the instance.
  3. The instance is booted.

When the instance is finally terminated, the EBS volumes will be deleted unless the deleteOnTermination flag associated with the volume was cleared prior to the termination request.

We made a number of other additions and improvements along the way including a disableApiTermination flag on each instance to protect your instances from accidental shutdowns, a new Description field for each AMI, and a simplified AMI creation process (one that works for both Linux and Windows) based on the new CreateImage function.

Detailed information about all of the new features can be found in the EC2 documentation. You should also take a look at the new Boot from EBS Feature Guide. This handy document includes tutorials on Running an instance backed by Amazon EBS, stopping and starting an instance, and bundling an instance backed by Amazon EBS. It also covers some advanced options and addresses some frequently asked questions about this powerful new feature.


I recently spent some time using this new feature and I had an enjoyable (and very productive) time doing so.

I built a scalable, distributed ray tracing system around the venerable POV-Ray program. I was able to test and fine-tune the startup behavior of my EC2 instance without the need to create a new AMI for each go-round. Once I had it working as desired, I created the AMI and then enjoyed quicker boot times as I brought additional EC2 instances online and into my “farm” of ray-tracing instances.

I’ll be publishing an article with full details on what I built in the near future, so stay tuned!

— Jeff;

IBM Tivoli Now Available on Amazon EC2

Adoption of the AWS Cloud by mainstream ISVs is underway as you read this. There are numerous posts about IBMs work to bring their product line into the AWS environment, and todays is no exception. IBM Tivoli monitoring is now available as an Amazon Machine Image (AMI) that runs as a virtual computer in the AWS environment. Its one more example of enterprise-class applications from household-name ISVs that run in the Amazon Cloud.

And it’s simple to Use – IBM provides self-install scripts for data collection agents, self-help guides and maintains infrastructure for delivery of Tivoli software Because there is no hardware or software to purchase and because the hourly price for Tivoli on EC2 includes an IBM license its super easy to get data collection up and running. At the end of the day, its the same enterprise-class software that organizations used to buy traditional licenses for but without the big PO approval required. In fact, its as simple as logging in to the AWS Console, and then searching for AMIs with Tivoli in the name.

There’s a comprehensive FAQ about Tivoli on AWS on IBM developerWorks.

If you are interested in a close look at IBM Tivoli, there will be a webcast on Dec 15, 2009 at 8 AM PST, or 11 AM EST that features IBM product managers. You can register here.

— Mike

The New AWS Simple Monthly Calculator

Our customers needed better ways to model their applications and estimate their costs. The flexible nature of on-demand scalable computing allows you pick and choose the services you like and only pay for those. Hence to give our customers an opportunity to estimate their costs, we have redesigned our current AWS Simple Monthly Calculator

The link to the new calculator is 

AWS Simple Monthly Calculator

This new calculator incorporates a wide array of pricing calculations across all our services in all our regions. It also shows breakdown of features for each service in each region. Most of our customers use multiple AWS services in multiple regions. Hence the calculator has a mechanism to select a service in a particular region and add it to the bill.

Users can select a region and simply input the usage values of each service in that region and then click on the “Add to Bill” button. This will add the service to the bill. Once the service is added to the bill, the user can modify/update the input fields, and the calculator will automatically recalculate. Users can remove the service from the bill by simply clicking on the red cross button Delete in the bill. Each input field represents to be a value per month. For example, Amazon S3 Data Transfer out is 40 GB in a Month and 5 Extra Large Linux Instances running for 10 hours in a month. For EC2/RDS/EMR, Users can click on green plus button Add and add similar type of instances (for eg., Web Servers, App Servers, MySQL DB Servers) in their topology.

The calculator also shows common customer samples and their usage. Users can click on “Disaster Recovery and Backup” sample or “Web Application” sample and see usages of each service. We will continue to add new real-world customer samples in future. If you would like us to add your sample usage, please let us know.

Last month, we announced new EC2 pricing, new Instance Types and a new AWS service (Amazon RDS). This calculator incorporates all of these new features and services and will continue to evolve as we add new features, new services and new regions .

The calculator is currently in beta and provides an estimate of the monthly bill. The goal is to help our customers and prospects estimate their monthly bill more efficiently. In the future, we would also like to give you recommendations on how you can save more by switching to Reserved Instances from on-demand instances or using AWS Import/Export service instead of standard S3 data transfer. Stay Tuned.

We would love to hear your feedback. Please let us know whether this new version of the calculator is helpful in estimating your AWS costs. You can send your feature requests, comments, suggestions, appreciations, confusions, frustrations to evangelists at amazon dot com. 

— Jinesh

New EC2 High-Memory Instances

In many cases, scaling out (by launching additional instances) is the best way to bring additional CPU processing power and memory to bear on a problem, while also distributing network traffic across multiple NICs (Network Interface Controllers). Certain workloads, however, are better supported by scaling up with a more capacious instance. Examples of these workloads include commercial and open source relational databases, mid-tier caches such as memcache, and media rendering.

To enable further scaling up for these workloads, we are introducing a new family of memory-heavy EC2 instances with the Double and Quadruple Extra Large High-Memory instance types. Here are the specs (note that an ECU is an EC2 compute unit, equivalent in CPU power to a 1.0-1.2 GHz 2007-era AMD Opteron or Intel Xeon processor):

  • Double Extra Large – 34.2 GB of RAM, and 13 ECU (4 virtual cores with 3.25 ECU each), 64-bit platform.
  • Quadruple Extra Large – 68.4 GB of RAM, and 26 ECU (8 virtual cores with 3.25 ECU each), 64-bit platform.

These new instance types are available now in multiple Availability Zones of both EC2 regions (US and Europe). Double Extra Large instances cost $1.20 per instance hour and the Quadruple Extra Large instances cost $2.40 per instance hour (these prices are for Linux instances in the US region).

These new instances use the most recent generation of processor and platform architectures. In order to get the best possible performance you should experiment with compiler settings and may also want to check out specialized compilers such as Intel’s Professional Edition and AMD’s Open64 Compiler Suite. As with all EC2 instances where the processor architecture underlying the virtualized compute resources may vary, you may want to think about ways to detect and adapt to the processor type at launch time if this will make a difference for your particular workload.

You can launch new Double Extra Large and Quadruple Extra Large instances today using the AWS Management Console or ElasticFox.

— Jeff;

Amazon EC2 – Now an Even Better Value

Effective November 1, 2009, the following per-hour prices will be in effect for Amazon EC2:

Linux Windows SQL Linux Windows SQL
m1.small $0.085 $0.12 $0.095 $0.13
m1.large $0.34 $0.48 $1.08 $0.38 $0.52 $1.12
m1.xlarge $0.68 $0.96 $1.56 $0.76 $1.04 $1.64
c1.medium $0.17 $0.29 $0.19 $0.31
c1.xlarge $0.68 $1.16 $2.36 $0.76 $1.24 $2.44

This represents a reduction of up to 15% from the current prices for Linux instances and is a direct result of our policy of working non-stop to drive our operating costs down for the benefit of our customers. This does not affect the price of our two new instance types.

This isn’t the first time we’ve lowered our prices in order to make AWS an even better value. In the past we’ve done this by adding tiered pricing to Amazon S3, reducing the storage and processing charges for SimpleDB, reducing the per-request pricing for SQS, and reducing bandwidth pricing for all services.

We’ve also reduced the prices for a number of IBM platform technologies. Take a look at Amazon Running IBM for a complete list of what we have to offer, along with the new prices.

Update: The first version of this post had the wrong prices for the SQL Server m1.large instances.

— Jeff;