AWS EFS vs EBS vs S3 differences when to use

Question

These are the basic definitions

• S3 is a storage facility accessible any where

• EBS is a device you can mount onto EC2

• EFS is a file system you can mount onto EC2

But I am not sure what to use where?

Answer 1

EFS is:

• May not yet be available in every region

• It may have more latency

• More features but at a higher cost

• The regions it is available, there you can call it as highly available service

• It is possible to attach EFS storage to an EC2 Instance

• Multiple instances can access it simultaneously (EC2)

• Now it is possible to attach your EFS storage directly to on-premise servers via Direct Connect

EBS is:

• Think of it as a block storage. This means you are able to choose which type of file system you want.

• As it's a block storage, you can use Raid 1 (or 0 or 10) with multiple block storages

• It is really fast

• It is relatively cheap

• With the new announcements from Amazon, you can store up to 16TB data per storage on SSD-s.

• You can snapshot an EBS for backup reasons

• But it only exists in a particular region. Although you can migrate it to another region, you cannot just access it across regions (only if you share it via the EC2; but that means you have a file server)

• You need an EC2 instance to attach it to

• You can now increase volume size, adjust performance, or change the volume type while the volume is in use. You can continue to use your application while the change takes effect.

S3 is:

• An object store (not a file system).

• You can store files and "folders" but can't have locks, permissions etc like you would with a traditional file system

• This means, by default you can't just mount S3 and use it as your webserver

• But it's perfect for storing your images and videos for your website

• Great for short term archiving (e.g. a few weeks). It's good for long term archiving too, but Glacier is more cost efficient.

• Great for storing logs

• You can access the data from every region (extra costs may apply)

• Highly Available, Redundant. Basically data loss is not possible (99.999999999% durability, 99.9 uptime SLA)

• Much cheaper than EBS.

• You can serve the content directly to the internet, you can even have a full (static) website working direct from S3, without an EC2 instance

Glacier is:

• Long term archive storage

• Extremely cheap to store

• Potentially very expensive to retrieve

• Takes up to 4 hours to "read back" your data (so only store items you know you won't need to retrieve for a long time)

Note following points for pricing:

Glacier, S3, EFS allocates the storage based on your usage, With EBS you need to pre-define the allocated storage. Which means, you need to over estimate. However it's easy to add more storage to your EBS volumes, it requires some engineering, which means you always "overpay" your EBS storage, which makes it even more expensive. Learn more about EFS and S3 here.

Answer 2

As per the title of this question, what are the practical differences between AWS EFS, EBS and S3?

My understanding of each:

• S3 is a storage facility accessible any where
• EBS is a device you can mount onto EC2
• EFS is a file system you can mount onto EC2

So why would I use EBS over EFS? 

Ans: Seem like they have the same use cases but minor semantic differences? Although EFS is replicated across AZs where as EBS is just a mounted device. I guess my understanding of EBS is lacking hence I'm unable to distinguish.

Why choose S3 over EFS? 

Ans: They both store files, scale and are replicated. I guess with S3 you have to use the SDK where as with EFS being a file system you can you standard I/O methods from your programming language of choice to create files. But is that the only real difference?

Answer 3

EFS can be mounted on more than one EC2 instance at the same time, enabling access to files on EFS at the same time.

Answer 4

Fixing the comparison:

• S3 is a storage facility accessible any where
• EBS is a device you can mount onto EC2
• EFS is a file system you can mount onto several EC2 instances at the same time

At this point it's a little premature to compare EFS and EBS- the performance of EFS isn't known, nor is its reliability known.

Why would you use S3?

• You don't have a need for the files to be 'local' to one or more EC2 instances.
• (effectively) infinite capacity
• built-in web serving, authentication

Comments

So basically, when I'm having multiple EC2 instances, I can use one S3 as my database for all my instances right?

Answer 5

EBS

Taken from EBS docs:

| EBS volume | Throughput |           Throughput          |
|    type    |   MiB/s    |         dependent on..        |
|------------|------------|-------------------------------|
| gp2 (SSD)  | 128-160    | volume size                   |
| io1 (SSD)  | 0.25-500   | IOPS (256Kib/s per IOPS)      |
| st1 (HDD)  | 20-500     | volume size (40Mib/s per TiB) |
| sc1 (HDD)  | 6-250      | volume size (12Mib/s per TiB) |

Note, that for io1, st1 and sc1 you can burst throughput traffic to at least 125Mib/s, but to 500Mib/s, depending on volume size.

You can further increase throughput by e.g. deploying EBS volumes as RAID0

EFS

Taken from EFS docs

| Filesystem |    Base    |   Burst    |
|    Size    | Throughput | Throughput |
|    GiB     |   MiB/s    |   MiB/s    |
|------------|------------|------------|
|         10 |        0.5 |        100 |
|        256 |       12.5 |        100 |
|        512 |       25.0 |        100 |
|       1024 |       50.0 |        100 |
|       1536 |       75.0 |        150 |
|       2048 |      100.0 |        200 |
|       3072 |      150.0 |        300 |
|       4096 |      200.0 |        400 |

The base throughput is guaranteed, burst throughput uses up credits you gathered while being below the base throughput (so you'll only have this for a limited time, see here for more details.

S3

S3 is a total different thing, so it cannot really be compared to EBS and EFS. Plus: There are no published throughput metrics for S3. You can improve throughput by downloading in parallel (I somewhere read AWS states you would have basically unlimited throughput this way), or adding CloudFront to the mix