AWS News Blog

New SSD-Backed Elastic Block Storage

Amazon Elastic Block Store (EBS for short) lets you create block storage volumes and attach them to EC2 instances. AWS users enjoy the ability to create EBS volumes that range in size from 1 GB up to 1 TB, create snapshot backups, and to create volumes from snapshots with a couple of clicks, with optional encryption at no extra charge.

We launched EBS in the Summer of 2008 and added the Provisioned IOPS (PIOPS) volume type in 2012. As a quick refresher, IOPS are short for Input/Output Operations per Second. A single EBS volume can be provisioned for up to 4,000 IOPS; multiple PIOPS volumes can be connected together via RAID to support up to 48,000 IOPS (see our documentation on EBS RAID Configuration for more information).

Today we are enhancing EBS with the addition of the new General Purpose (SSD) volume type as our default block storage offering. This new volume type was designed to offer balanced price/performance for a wide variety of workloads (small and medium databases, dev and test, and boot volumes, to name a few), and should be your first choice when creating new volumes. These volumes take advantage of the technology stack that we built to support Provisioned IOPS, and are designed to offer 99.999% availability, as are the existing EBS volume types.

General Purpose (SSD) volumes take advantage of the increasing cost-effectiveness of SSD storage to offer customers 10x more IOPS, 1/10th the latency, and more bandwidth and consistent performance than offerings based on magnetic storage. With a simple pricing structure where you only pay for the storage provisioned (no need to provision IOPS or to factor in the cost of I/O operations), the new volumes are priced as low as $0.10/GB-month.

General Purpose (SSD) volumes are designed to provide more than enough performance for a broad set of workloads all at a low cost. They predictably burst up to 3,000 IOPS, and reliably deliver 3 sustained IOPS for every GB of configured storage. In other words, a 10 GB volume will reliably deliver 30 IOPS and a 100 GB volume will reliably deliver 300 IOPS. There are more details on the mechanics of the burst model below, but most applications won’t exceed their burst and actual performance will usually be higher than the baseline. The volumes are designed to deliver the configured level of IOPS performance with 99% consistency.

You can use this new volume type with all of the EBS-Optimized instance types for greater throughput and consistency.

Boot Boost
The new General Purpose (SSD) volumes can enhance the performance and responsiveness of your application in many ways. For example, it has a very measurable impact when booting an operating system on an EC2 instance.

Each newly created SSD-backed volume receives an initial burst allocation that provides up to 3,000 IOPS for 30 minutes. This initial allocation provides for a speedy boot experience for both Linux and Windows, and is more than sufficient for multiple boot cycles, regardless of the operating system that you use on EC2.

Our testing indicates that a typical Linux boot requires about 7,000 I/O operations and a typical Windows boot requires about 70,000. Switching from a Magnetic volume to a General Purpose (SSD) volume of the same size reduces the typical boot time for Windows 2008 R2 by approximately 50%.

If you have been using AWS for a while, you probably know that each EC2 AMI specifies a default EBS volume type, often Magnetic (formerly known as Standard). A different volume type can be specified at instance launch time. The EC2 console makes choosing General Purpose (SSD) volumes in place of the default simple, and you can optionally make this the behavior for all instance launches made from the console.

When you use the console to launch an instance, you have the option to change the default volume type for the boot volume. You can do this for a single launch or for all future launches from the console, as follows (you can also choose to stick with magnetic storage):

If you launch your EC2 instances from the command line, or the EC2 API, you need to specify a different block device mapping in order to use the new volume type. Here’s an example of how to do this from the command line via the AWS CLI:


$ aws ec2 run-instances \
  --key-name mykey \
  --security-groups default \
  --instance-type m3.xlarge \
  --image-id ami-60f69f50 \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeType":"gp2"}}]' \
  --region us-west-2

To make it easier to get started with General Purpose (SSD) boot volumes when using the command line or EC2 API, versions of the latest Amazon Linux AMI and the Windows Server 2012 R2 Base AMI in English which specify General Purpose (SSD) volumes as the default are now available. To obtain the ID of the latest published General Purpose (SSD) Windows AMI in your region you can use the Get-EC2ImageByName cmdlet as follows:


C:\> Get-EC2ImageByName -Names Windows_Server-2012-R2_RTM-English-64Bit-GP2*

Here are the names and identifiers for the Amazon Linux AMIs:

Region AMI ID Full Name
us-east-1 ami-aaf408c2 amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2
us-west-2 ami-8f6815bf amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2
us-west-1 ami-e48b8ca1 amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2
eu-west-1 ami-dd925baa amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2
ap-southeast-1 ami-82d78bd0 amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2
ap-southeast-2 ami-91d9bcab amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2
ap-northeast-1 ami-df470ede amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2
sa-east-1 ami-09cf6014 amazon/amzn-ami-hvm-2014.03.2.x86_64-gp2

We are also working to make it simpler to configure storage for your instance so that you can easily choose storage options for existing EBS-backed AMIs (stay tuned for an update).

Choosing an EBS Volume Type
With today’s launch, you can now choose from three distinct types of EBS volumes and might be wondering which one is best for each use case. Here are a few thoughts and guidelines:

  • General Purpose (SSD) – The new volume type is a great fit for small and medium databases (either NoSQL or relational), development and test environments, and (as described above) boot volumes. In general, you should now plan to start with this volume type and move to one of the others only if necessary. You can achieve up to 48,000 IOPS by connecting multiple volumes together using RAID.
  • Provisioned IOPS (SSD) – Volumes of this type are ideal for the most demanding I/O intensive, transactional workloads and large relational or NoSQL databases. This volume type provides the most consistent performance and allows you to provision the exact level of performance you need with the most predictable and consistent performance. With this type of volume you provision exactly what you need, and pay for what you provision. Once again, you can achieve up to 48,000 IOPS by connecting multiple volumes together using RAID.
  • Magnetic – Magnetic volumes (formerly known as Standard volumes) provide the lowest cost per Gigabyte of all Amazon EBS volume types and are ideal for workloads where data is accessed less frequently and cost management is a primary objective.

You can always switch from one volume type to another by creating a snapshot of an existing volume and then creating a new volume of the desired type from the snapshot. You can also use migration commands and tools such as tar, dd or Robocopy.

Under the Hood – Performance Burst Details
Each volume can also provide up to 3,000 IOPS in bursts that can span up to 30 minutes, regardless of the volume size. The burst of IOPS turns out to be a great fit for the use cases that I mentioned above. For example, the IOPS load generated by a typical relational database turns out to be very spiky. Database load and table scan operations require a burst of throughput; other operations are best served by a consistent expectation of low latency. The General Purpose (SSD) volumes are able to satisfy all of the requirements in a cost-effective manner. We have analyzed a wide variety of application workloads and carefully engineered General Purpose (SSD) to take advantage of this spiky behavior with the expectation that they will rarely exhaust their accumulated burst of IOPS.

Within the General Purpose (SSD) implementation is a Token Bucket model that works as follows:

  • Each token represents an “I/O credit” that pays for one read or one write.
  • A bucket is associated with each General Purpose (SSD) volume, and can hold up to 5.4 million tokens.
  • Tokens accumulate at a rate of 3 per configured GB per second, up to the capacity of the bucket.
  • Tokens can be spent at up to 3000 per second per volume.
  • The baseline performance of the volume is equal to the rate at which tokens are accumulated — 3 IOPS per GB per second.

All of this work behind the scenes means that you, the AWS customer, can simply create EBS volumes of the desired size, launch your application, and your I/O to the volumes will proceed as rapidly and efficiently as possible.

OpsWorks and CloudFormation Support
You can create volumes of this type as part of an AWS OpsWorks Layer:

You can also create them from within a CloudFormation template as follows:


...
{
   "Type":"AWS::EC2::Volume",
   "Properties" : {
      "AvailabilityZone" : "us-east-1a",
      "Size" : 100,
      "VolumeType" : "gp2"
   }
}
...

Pricing
The new General Purpose (SSD) volumes are priced at $0.10 / GB / month in the US East (Northern Virginia) Region, with no additional charge for I/O operations. For pricing in other AWS Regions, please take a look at the EBS Pricing page.

We are also announcing that we are reducing the price of IOPS for Provisioned IOPS volumes by 35%. For example, if you create a Provisioned IOPS volume and specify 1,000 IOPS your monthly cost will decline from $100 to $65 per month in the US East (Northern Virginia) Region, with similar reductions in the other Regions. The cost for Provisioned Storage remains unchanged at $0.125 / GB / month.

Jeff;

TAGS:
Jeff Barr

Jeff Barr

Jeff Barr is Chief Evangelist for AWS. He started this blog in 2004 and has been writing posts just about non-stop ever since.