Amazon EBS FAQs

 General

 Performance

 Snapshots

 Encryption

 Billing and Metering

Get Started with AWS for Free

Create a Free Account

AWS Free Tier includes 30GB of Storage, 2 million I/Os, and 1GB of snapshot storage with Amazon Elastic Block

Store (EBS).

View AWS Free Tier Details »

General
Q: Are Amazon EBS volume and snapshot ID lengths changing in 2016?

Yes, please visit the EC2 FAQ page for more details.

Q: What happens to my data when an Amazon EC2 instance terminates?

Unlike the data stored on a local instance store (which persists only as long as that instance is
alive), data stored on an Amazon EBS volume can persist independently of the life of the
instance. Therefore, we recommend that you use the local instance store only for temporary
data. For data requiring a higher level of durability, we recommend using Amazon EBS volumes
or backing up the data to Amazon S3. If you are using an Amazon EBS volume as a root
partition, set the Delete on termination flag to "No" if you want your Amazon EBS volume to
persist outside the life of the instance.

Q: What kind of performance can I expect from Amazon EBS volumes?

Amazon EBS provides four current generation volume types: Provisioned IOPS SSD (io1),
General Purpose SSD (gp2), Throughput Optimized HDD (st1) and Cold HDD (sc1). These
volume types differ in performance characteristics and price, allowing you to tailor your storage
performance and cost to the needs of your applications. For more performance information see
the EBS product details page.

For more information about Amazon EBS performance guidelines, see Increasing EBS
Performance.
Q: Which volume should I choose?
Amazon EBS includes two major categories of storage: SSD-backed storage for transactional
workloads (performance depends primarily on IOPS) and HDD-backed storage for throughput
workloads (performance depends primarily on throughput, measured in MB/s). SSD-backed
volumes are designed for transactional, IOPS-intensive database workloads, boot volumes, and
workloads that require high IOPS. SSD-backed volumes include Provisioned IOPS SSD (io1)
and General Purpose SSD (gp2). HDD-backed volumes are designed for throughput-intensive
and big-data workloads, large I/O sizes, and sequential I/O patterns. HDD-backed volumes
include Throughput Optimized HDD (st1) and Cold HDD (sc1).

Q: How do I modify the capacity, performance, or type of an existing EBS volume?

Changing a volume configuration is easy. The Elastic Volumes feature allows you to increase
capacity, tune performance, or change your volume type with a single CLI call, API call or a few
console clicks. For more information about Elastic Volumes, see the Elastic Volumes
documentation.

Q: Are EBS Standard Volumes still available?

EBS Standard Volumes have been renamed to EBS Magnetic volumes. Any existing volumes
will not have been changed as a result of this and there are no functional differences in the EBS
Magnetic offering compared to EBS Standard. The name of this offering was changed to avoid
confusion with our General Purpose SSD (gp2) volume type which is our recommended default
volume type.

Q: Are Provisioned IOPS SSD (io1) volumes available for all Amazon EC2 instance types?

Yes, Provisioned IOPS SSD (io1) volumes are available for all Amazon EC2 Instance Types. To
enable your EC2 instances to use the IOPS provisioned on an EBS volume consistently and
predictably, you can launch selected EC2 instance types as EBS-optimized instances. EBS-
optimized instances deliver dedicated throughput between Amazon EC2 and Amazon EBS, with
options between 62.5 MB/s and 1,750 MB/s depending on the instance type used.

Performance
Q: What level of performance consistency can I expect to see from my Provisioned IOPS SSD
(io1) volumes?

When attached to EBS-optimized instances, Provisioned IOPS SSD (io1) volumes are designed
to deliver within 10% of the provisioned IOPS performance 99.9% of the time in a given year.
Your exact performance depends on your application’s I/O requirements.

Q: What level of performance latency can I expect to see from my Provisioned IOPS SSD (io1)
volumes?

When attached to EBS-optimized instances, Provisioned IOPS volumes can achieve single digit
millisecond latencies. Your exact performance depends on your application’s I/O requirements.

Q: Does the I/O size of my application reads and writes affect the rate of IOPS I get from my
Provisioned IOPS SSD (io1) volumes?

Yes. For a given allocation of resources, the IOPS rate you get depends on the I/O size of your
application reads and writes. Provisioned IOPS volumes process your application reads and
writes in I/O sizes of 256KB or less. Every increase in I/O size above 256KB increases linearly
the resources you need to achieve the same IOPS rate. For example, if you have provisioned a
volume with 500 IOPS, that means that it can handle up to 500 256KB writes per second, 250
512KB writes per second, or 125 1024KB writes per second, and so on. You can use Amazon
CloudWatch to monitor your throughput and I/O sizes.

Q: What factors can affect the performance consistency I see with Provisioned IOPS SSD (io1)
volumes?
Provisioned IOPS SSD (io1) volumes attached to EBS-optimized instances are designed to offer
consistent performance, delivering within 10% of the provisioned IOPS performance 99.9% of the
time over a given year. For maximum performance consistency with new volumes created from a
snapshot, we recommend reading or writing to all of the blocks on your volume before placing it
into service.

Another factor that can impact your performance is if your application isn’t sending enough I/O
requests. This can be monitored by looking at your volume’s queue depth. The queue depth is
the number of pending I/O requests from your application to your volume. For maximum
consistency, a Provisioned IOPS volume must maintain an average queue depth (rounded to the
nearest whole number) of one for every 500 provisioned IOPS in a minute. For example, for a
volume provisioned with 1500 IOPS, the queue depth average must be 3. For more information
about ensuring consistent performance of your volumes, see Increasing EBS Performance.
Q: What level of performance consistency can I expect to see from my HDD-backed volumes?

When attached to EBS-optimized instances, Throughput Optimized HDD (st1) and Cold HDD
(sc1) volumes are designed to deliver within 10% of the expected throughput performance 99%
of the time in a given year. Your exact performance depends on your application’s I/O
requirements and the performance of your EC2 instance.

Q: Does the I/O size of my application reads and writes affect the rate of throughput I get from
my HDD-backed volumes?

Yes. The throughput rate you get depends on the I/O size of your application reads and writes.
HDD-backed volumes process reads and writes in I/O sizes of 1MB. Sequential I/Os are merged
and processed as 1 MB units while each non-sequential I/O is processed as 1MB even if the
actual I/O size is smaller. Thus, while a transactional workload with small, random IOs, such as a
database, won't perform well on HDD-backed volumes, sequential I/Os and large I/O sizes will
achieve the advertised performance of st1 and sc1 for a longer period of time.

Q: What factors can affect the performance consistency of my HDD-backed volumes?

Throughput Optimized HDD (st1) and Cold HDD (sc1) volumes attached to EBS-optimized
instances are designed to offer consistent performance, delivering within 10% of the expected
throughput performance 99% of the time in a given year. There are several factors that could
affect the level of consistency you see. For example, the relative balance between random and
sequential I/O operations on the volume can impact your performance. Too many random small
I/O operations will quickly deplete your I/O credits and lower your performance down to the
baseline rate. Your throughput rate may also be lower depending on the instance selected.
Although st1 can drive throughput up to 500 MB/s, performance will be limited by the separate
instance-level limit for EBS traffic. Another factor is taking a snapshot which will decrease
expected write performance down to the baseline rate, until the snapshot completes. This is
specific to st1 and sc1.

Your performance can also be impacted if your application isn’t sending enough I/O requests.
This can be monitored by looking at your volume’s queue depth and I/O size. The queue depth is
the number of pending I/O requests from your application to your volume. For maximum
consistency, HDD-backed volumes must maintain an average queue depth (rounded to the
nearest whole number) of four or more for every 1 MB sequential I/O. For more information about
ensuring consistent performance of your volumes, see Increasing EBS Performance.

Q: Can I stripe multiple volumes together to get better performance?

Yes. You can stripe multiple volumes together to achieve up to 75,000 IOPS or 1,750 MiB/s
when attached to larger EC2 instances. However, performance for st1 and sc1 scales linearly
with volume size so there may not be as much of a benefit to stripe these volumes together.

Snapshots
Q: Will I be able to access my snapshots using the regular Amazon S3 API?

No, snapshots are only available through the Amazon EC2 API.

Q: Do volumes need to be un-mounted to take a snapshot?

No, snapshots can be done in real time while the volume is attached and in use. However,
snapshots only capture data that has been written to your Amazon EBS volume, which might
exclude any data that has been locally cached by your application or OS. To ensure consistent
snapshots on volumes attached to an instance, we recommend detaching the volume cleanly,
issuing the snapshot command, and then reattaching the volume. For Amazon EBS volumes that
serve as root devices, we recommend shutting down the machine to take a clean snapshot.

Q: Does it take longer to snapshot an entire 16 TB volume as compared to an entire 1 TB

volume?

By design, an EBS Snapshot of an entire 16 TB volume should take no longer than the time it
takes to snapshot an entire 1 TB volume. However, the actual time taken to create a snapshot
depends on several factors including the amount of data that has changed since the last
snapshot of the EBS volume.

Q: Are snapshots versioned? Can I read an older snapshot to do a point-in-time recovery?

Each snapshot is given a unique identifier, and customers can create volumes based on any of
their existing snapshots.

Q: How can I discover Amazon EBS snapshots that are shared with me?

You can find snapshots that are shared with you by selecting Private Snapshots from the list in
the Snapshots section of the AWS Management Console. This section lists both snapshots that
you own and snapshots that are shared with you.

Q: How can I find which Amazon EBS snapshots are shared globally?

You can find snapshots that are shared globally by selecting Public Snapshots from the list in the
Snapshots section of the AWS Management Console.

Q: How can I find a list of Amazon public datasets stored in Amazon EBS Snapshots?

You can use the AWS Management Console to find public datasets stored as Amazon
Snapshots. Log into the console, select the Amazon EC2 Service, select Snapshots and then
filter on Public Snapshots. All information on public datasets is available in our AWS Public
Datasets resource center.

Encryption
Q: What is Amazon EBS encryption?

Amazon EBS encryption offers seamless encryption of EBS data volumes, boot volumes and
snapshots, eliminating the need to build and maintain a secure key management infrastructure.
EBS encryption enables data at rest security by encrypting your data using Amazon-managed
keys, or keys you create and manage using the AWS Key Management Service (KMS). The
encryption occurs on the servers that host EC2 instances, providing encryption of data as it
moves between EC2 instances and EBS storage. For more details, see Amazon EBS encryption
in the Amazon EC2 User Guide.

Q: What is the AWS Key Management Service (KMS)?

AWS KMS is a managed service that makes it easy for you to create and control the encryption
keys used to encrypt your data. AWS Key Management Service is integrated with other AWS
services including Amazon EBS, Amazon S3, and Amazon Redshift, to make it simple to encrypt
your data with encryption keys that you manage. AWS Key Management Service is also
integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your
regulatory and compliance needs. To learn more about KMS, visit the AWS Key Management
Service product page.

Q: Why should I use EBS encryption?

You can use Amazon EBS encryption to meet security and encryption compliance requirements
for data at rest encryption in the cloud. Pairing encryption with existing IAM access control
policies improves your company’s defense-in-depth strategy.

Q: How are my Amazon EBS encryption keys managed?

Amazon EBS encryption handles key management for you. Each newly created volume gets a
unique 256-bit AES key; Volumes created from the encrypted snapshots share the key. These
keys are protected by our own key management infrastructure, which implements strong logical
and physical security controls to prevent unauthorized access. Your data and associated keys
are encrypted using the industry-standard AES-256 algorithm.

Q: Does EBS encryption support boot volumes?

Yes.

Billing and Metering

Q: Will I be billed for the IOPS provisioned on a Provisioned IOPS volume when it is
disconnected from an instance ?

Yes, you will be billed for the IOPS provisioned when it is disconnected from an instance. When
a volume is detached, we recommend you consider creating a snapshot and deleting the volume
to reduce costs. For more information, see the "Underutilized Amazon EBS Volumes" cost
optimization check in Trusted Advisor. This item checks your Amazon Elastic Block Store
(Amazon EBS) volume configurations and warns when volumes appear to be underused.

Q: Do your prices include taxes?

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT
and applicable sales tax. For customers with a Japanese billing address, use of AWS services is
subject to Japanese Consumption Tax. Learn more.