Amazon EFS vs. EBS

When thinking about your cloud application, you’ll quickly get to the question of which storage service should you use.

In today’s article we’ll cover EFS (Elastic File System) and EBS (Elastic Block Store) and the different use-cases where you should use each one of them.

EFS (Elastic File System)

EFS is a file storage service that is mostly used with compute services
(such as EC2).
It provide a simple interface that allows you to create and configure file systems quickly and easily.
When using EFS, the storage capacity is elastic — growing and shrinking automatically as you add and remove files, so your applications have the storage they need, when they need it, and you don’t need to pre-provision storage like on EBS
EFS is great for file servers and sharing files between EC2 instances.

A simple example for using EFS would be storing a website in one place and have couple of EC2 instances accessing it.

EFS can scale up to Petabytes and support thousands of concurrent connections.

EFS also has storage classes (similar to S3) where in the standard class, the data is stored in multiple Availability Zones, but also have “One Zone” class where the data is stored only in one Availability Zone.

EFS standard file system interface and file system semantics make it easy to migrate enterprise applications to the AWS cloud or to build new ones.
That’s why many companies that are migrating their on-premise servers to AWS choose EFS as their File Storage Service

EBS (Elastic Block Store)

EBS is a block-level storage (as opposed to EFS which is File storage)
It has high-performance and designed to be used with EC2 instance.
One of the important features of EBS is that the data stored on it can persist independently of the life of the instance (unlike local instance store) depending on the configuration you set when launching it.

Each EBS volume is auto replicated within its Availability Zone to protect from failures and achieve high availability and durability.

EBS have 2 major categories:
· SSD (Solid State Drive) which is mostly used for transactional workloads
· HDD (Hard-Disk Drive) which is mostly used for throughput intensive workloads.
For each of the above there are sub-types where you can choose from depending on your workload and needed IOPS.

The EBS Volume can be “attached” to only one EC2 instance, and it will be on the same Availability Zone as the instance.

EBS Volumes are pre-provisioned, but you can change their size “on the fly” (while the instance is running) but be aware that it might affect performance and you’ll have to run a re-partition command in order for the instance OS be aware of the new volume size.

So… Which One Should You Choose?

The answer to that actually depends on the usage and performance you want to achieve from your storage service.

• If you want to quickly migrate your enterprise applications to the cloud without changing the architecture — EFS is your choice.
• If you need to run a NoSQL Database (such as MongoDB and Cassandra) on your instance, you should probably choose EBS volume as its
  low-latency and consistent character.
• EBS is also better for Relational Databases (such as MySQL and PostgreSQL) as it scales to meet your changing storage needs.
• For Analytics and Big-Data application you should choose EFS because of its high throughput and low latency file access characteristics.
• As stated above, if you have a website or a blog, and you want it to be stored in one place but server many EC2 instances — you should go with EFS.
• For the ability to quickly back-up and recover in order to achieve Business Continuity you should choose EBS as you can easily create Snapshots and Machine Images.

Summary

When trying to choose a storage service for your cloud application, first think of the use cases it should serve and the performance you need to get from it.
Once you have these requirements — choosing the right storage would be an easy task.