Benefits of EBS vs instance-store

Question

Can someone tell me about the benefits I may get from EBS vs.Instance-store for my instances on Amazon EC2.

Answer 1

This question can be approached by different perspectives. Here is my take on it:

• EBS instances don’t get terminated accidently. The reason is these backed instances are set
• EBS backed instances can help you save money as they can be turned off and when not being used
• Even if an EBS instance crashes you do not lose your stored data, because recovery becomes easier. Plus, you can resize your instances dynamically
• EBS lets you transfer storage to a new instance that means switching between hardware becomes easier
• EBS instances are easy to launch because we do not have any data fetching from S3
• EBS Instances support automated scheduling

Apart from EBS being little costlier than its counterpart it should not be a bad choice

People also face issues with EBS, there are times when you can avoid its usage, some of the highlights are:

• There were downtime issues wrecked by EBS
• It can be flaky when you must consider I/O performance. If your need is high I/O it wont be very wise to choose EBS
• S3 Offers more stability when you require persistence
• EBS instances can dies at any point but they are more durable

Hope this helps!

Join AWS DevOps training today to learn more.

Thanks!

Answer 2

The EC2 "Hardware"

When an EC2 instance is launched, a virtual machine is reserved for the instance to run. That virtual machine has particular specifications depending on the instance type: 32-bit or 64-bit CPU, number of virtual cores, size of hard drive, etc. Details about the instance specs is available at http://aws.amazon.com/ec2/#instance.

When your EC2 instance is in a "running" state, that means that it’s running on the virtual machine, and this is what you get charged for.

The virtual machine’s hard drive is considered "ephemeral". The term "ephemeral" comes from the greek word "ephemeros" which means "lasting only one day". Anything on such a hard drive should be considered temporary. Unless the data is copied off the hard drive, if the virtual machine is stopped, then the data is lost. This includes data, software, and even an operating system that resides on those hard drives.

Amazon Web Services provides EC2 instances with two types of root devices.: "EBS-backed" and "instance store".

"Instance Store" Instances

An "instance store" instance is an EC2 instance whose root device resides on the virtual machine’s hard drive. When the instance is created, the base AMI is copied to the virtual machine’s hard drive and launched. The instance can run for as long as you want, but it cannot be stopped. Since the instance’s root device is the actual hard drive, it is "stuck" on the hardware, and the only thing you can do is terminate the instance. If you do this, the instance is deleted, never to be recovered. You also run the risk that if the virtual machine’s hardware fails, then you will also lose anything on the hard drive.

If you launch an "instance store" instance, be prepared to leave it running until you’re completely done with it. Note that you will be charged from the moment the instance is started, until the time it is terminated.

"EBS-Backed" Instances

An "EBS-backed" instance is an EC2 instance which uses an EBS volume as it’s root device. EBS volumes are redundant, "virtual" drives, which are not tied to any particular hardware, however they are restricted to a particular EC2 availability zone. This means that an EBS volume can move from one piece of hardware to another within the same availability zone. You can think of EBS volumes as a kind of Network Attached Storage.

If the virtual machine’s hardware fails, the EBS volume can simply be moved to another virtual machine and re-launched. In theory, you won’t lose any data.

Another benefit, is that EBS volumes can easily be backed up and duplicated. So you can take easy backup snapshots of your volumes, create new volumes and launch new EC2 instances based on those duplicate volumes.

Probably the biggest advantage "EBS-backed" instances have over "instance store" instances is that they can be stopped. When you do this, the virtual machine is shutdown and the EBS volume is stored for later retrieval. The hardware is then available for someone else to use. In addition, during this time, you are not charged the EC2 instance running charge. But you are charged for the EBS storage. When you want the instance to run again, you just start it up again. A new virtual machine is reserved, your EBS volume is attached, and your instance is booted.

But what about the virtual machine’s hard drives?

Yes, it is possible to use those hard drives, even when your EC2 instance is "EBS-backed". By default, they are not available. If you use the command line programs to launch your instance, you can use the "-b" option on the ec2-run-instances command to attach the "instance store" drives to your EC2 instance.

Having these drives available can be beneficial if you want to store temporary data. Read and write access should be faster than reading from and writing to an EBS volume because you’re not sending data over the network. In addition, you won’t be charged for data transfer or data storage. But this only works if the data can be lost at any time.

Answer 3

EBS is like the virtual disk of a VM:

• Durable, instances backed by EBS can be freely started and stopped (saving money)
• Can be snapshotted at any point in time, to get point-in-time backups
• AMIs can be created from EBS snapshots, so the EBS volume becomes a template for new systems

Instance storage is:

• Local, so generally faster
• Non-networked, in normal cases EBS I/O comes at the cost of network bandwidth (except for EBS-optimized instances, which have separate EBS bandwidth)
• Has limited I/O per second IOPS. Even provisioned I/O maxes out at a few thousand IOPS
• Fragile. As soon as the instance is stopped, you lose everything in instance storage.

Answer 4

• Use EBS for the backing OS partition and permanent storage (DB data, critical logs, application config)
• Use instance storage for in-process data, noncritical logs, and transient application state. Example: external sort storage, tempfiles, etc.
• Instance storage can also be used for performance-critical data, when there's replication between instances (NoSQL DBs, distributed queue/message systems, and DBs with replication)
• Use S3 for data shared between systems: input dataset and processed results, or for static data used by each system when lauched.
• Use AMIs for prebaked, launchable servers

Answer 5

As of now all AMI's in quickstart section are EBS backed

Also there's a good explanation at official doc for difference between EBS and Instance store

& this image pretty much sums it up

Answer 6

A number of thorough answers here as to the pros and cons, (among them, durability is a real concern if the instance is stopped and careful consideration of how to recover/failover from that is important). However, on the flipside, from a performance perspective, the local instance store is unquestionably superior. It's local to the server and no limitations on bandwidth or iops. We did a set of benchmarks.

specifically the takeaways were on 4 different scenarios (ebs 3k, ebs 50k, instance store single disk, instance store raid1 2 disk),

1. the local disk options are vastly better at random access than EBS, due to low latency and iops being a limiting factor. Although most applications try to avoid random reading, it’s hard to avoid completely and so good performance in this area is a big plus. Sequential reads are also vastly better than EBS, mainly due to rate limiting of EBS, specifically the throughput. Generally you are going to get full, unrestricted access to a local disk with much lower latency than network storage (EBS).
2. Raid1 is (not surprisingly) up to 2x better for reads than the single disk. Writes are the same due to needing to write to both disks. However on larger system, you can have 4+ disks and do raid10 (mirrored striping) which would give improvements to writes as well.
3. Unfortunately as mentioned at the start, local disk options are ephemeral and will lose your data on a terminate/stop of the instance. Even so, it might be worth considering a high availability architecture to allow using it.
4. EBS 50K is certainly more performant than 3K, although you generally need to get past 4+ threads to see a real difference (e.g. a database). Single threaded processes are not going to be much faster (e.g. a file copy, zip, etc..). EBS 50k was limited by the instance max iops (30k), so generally be aware the instance size also can be a limiting factor on EBS performance.
5. It’s possible to raid EBS as well, but keep in mind it’s networked storage and so that will likely be a real bottleneck on any performance gains. Worth a separate test to compare.