New High I/O EC2 Instance Type - hi1.4xlarge - 2 TB of SSD-Backed Storage

The Plot So Far
As the applications that you build with AWS grow in scale, scope, and complexity, you haven't been shy about asking us for more locations, more features, more storage, or more speed.

Modern web and mobile applications are often highly I/O dependent. They need to store and retrieve lots of data in order to deliver a rich, personalized experience, and they need to do it as fast as possible in order to respond to clicks and gestures in real time.

In order to meet this need, we are introducing a new family of EC2 instances that are designed to run low-latency, I/O-intensive applications, and are an exceptionally good host for NoSQL databases such as Cassandra and MongoDB.

High I/O EC2 Instances
The first member of this new family is the High I/O Quadruple Extra Large (hi1.4xlarge in the EC2 API) instance. Here are the specs:

• 8 virtual cores, clocking in at a total of 35 ECU (EC2 Compute Units).
• HVM and PV virtualization.
• 60.5 GB of RAM.
• 10 Gigabit Ethernet connectivity with support for cluster placement groups.
• 2 TB of local SSD-backed storage, visible to you as a pair of 1 TB volumes.

The SSD storage is local to the instance. Using PV virtualization, you can expect 120,000 random read IOPS (Input/Output Operations Per Second) and between 10,000 and 85,000 random write IOPS, both with 4K blocks. For HVM and Windows AMIs, you can expect 90,000 random read IOPS and 9,000 to 75,000 random write IOPS. By way of comparison, a high-performance disk drive spinning at 15,000 RPM will deliver 175 to 210 IOPS.

Why the range? Write IOPS performance to an SSD is dependent on something called the LBA (Logical Block Addressing) span. As the number of writes to diverse locations grows, more time must be spent updating the associated metadata. This is (very roughly speaking) the SSD equivalent of seek time for a rotating device, and represents per-operation overhead.

This is instance storage, and it will be lost if you stop and then later start the instance. Just like the instance storage on the other EC2 instance types, this storage is failure resilient, and will survive a reboot, but you should back it up to Amazon S3 on a regular basis.

You can launch these instances alone, or you can create a Placement Group to ensure that two or more of them are connected with non-blocking bandwidth. However, you cannot currently mix instance types (e.g. High I/O and Cluster Compute) within a single Placement Group.

If you want to run Micorosft Windows on this new instance type, be sure to use one of the Microsoft Windows AMIs that are designed for use with Cluster Instances:

You can launch High I/O Quadruple Extra Large instances in US East (Northern Virginia) and EU West (Ireland) today, at an On-Demand cost of $3.10 and $3.41, respectively. You can also purchase Reserved Instances, but you cannot acquire them via the Spot Market. We plan to make this new instance type available in several other AWS Regions before the end of the year.

Watch and Learn
I interviewed Deepak Singh, Product Manager for EC2, to learn more about this new instance type. Here's what he had to say:

And More
Here are some other resources that you might enjoy:

• Adrian Cockcroft wrote about Benchmarking High Performance I/O with SSD for Cassandra on AWS for the Netflix Tech Blog.
• Werner Vogels went into detail on the differences between magnetic disk and SSD, and talks about ways to use this new instance type for databases in his post, Expanding The Cloud – High Performance I/O Instances for Amazon EC2.
• The Hacker News discussion has a lot of interesting commentary.

-- Jeff;

Comments

[R]

Forwarded this to my coworkers with the subject line "Hallelujah!". Biggest thing that made it impossible to replicate our setup in AWS so definitely a BFD as Vice President Biden would say. (Google [biden BFD] for context, if needed.)

Also awesome that the first hi instance type is robust in other specs too -- 10GigE and plenty of CPU and RAM.

[Bo B]

Excellent! But please consider adding a wider range of instance types with SSD storage. Not every server needs 60GB ram and 1TB ssd. Ideally every current instance type should be available with the choice of SSD storage instead(or at least a selection of the most popular ones).

Oh and it would be very nice being able to spin up some Amazon RDS mysql instances backed by SSDs.

[Benjamim JR]

With each new release of the amazon, I see how much your competitors are arrears.

Congratulations, I am a client and AWS evangelist.

[Thierryschellenbach]

That's awesome :)

[Don]

Any plans to offer lower end instances with SSD-backed storage? Our use case is we have an I/O hungry application that can run fine on m1.large. Would like to eliminate poor EBS performance bottleneck.

[Markus Wanner]

Cool thing. Although I'm wondering about PVM being faster than HVM? Or is this just Windows that slows things down here?

[Thomasfloracks]

+1 for smaller SSD backed instances or a SSD EBS.

[Curious]

Those are some interesting numbers you have posted there. Can you share how you measured and arrived at those statistics ?

[Peter Horoszowski]

I second the request to see this on an m1.large instance..

[R]

What does "this storage is failure resilient" mean here? That you might sometimes keep your data if the instance shuts down because of a hardware failure? Or just that it's meant to be reliable while running? I assume we're not talking about RAID, since that would add a lot to the price.

[Stuart]

Here's some performance benchmarks: http://blog.serverbear.com/post/27553311076/hi1-4xlarge-benchmarks

[Thomas]

Yet another benchmark:

http://www.dbasquare.com/2012/07/20/amazon-ec2-now-powered-by-high-performance-storage-ssd/

[bo]

This is useless from mssql server point of view. We can't store the SQL data on a storage will disappear after reboot. I strongly suggest AWS should supply an SSD EBS, not the local one.