EFS and EBS Storage Management

Amazon Web Services (AWS) offers two main types of storage for virtual machines (EC2 instances): EBS and EFS. Let us break down exactly what these are, why they exist, and how you use them.

Amazon Elastic Block Store (EBS) is a high-performance, persistent block storage volume you attach to a single EC2 instance. Think of it as a virtual hard drive. You create an EBS volume, attach it to a virtual server, format it with a file system (like ext4 or XFS), and then you can store files on it. The key characteristic is that it is attached to one instance at a time. You can detach it and reattach it to another instance, but while it is attached, only that instance can read or write to it. EBS volumes come in different types: General Purpose SSD (gp2/gp3) for most workloads, Provisioned IOPS SSD (io1/io2) for high-performance databases, Throughput Optimised HDD (st1) for big data and log processing, and Cold HDD (sc1) for rarely accessed data. Each type is optimised for different price and performance needs. You can take snapshots (point-in-time backups) of EBS volumes and store them in Amazon S3. Snapshots are incremental: the first snapshot copies the entire volume, but subsequent snapshots only copy changed blocks. This saves storage costs.

Amazon Elastic File System (EFS) is a fully managed, scalable file storage system that you can mount on many EC2 instances simultaneously using the NFS protocol. It is like a network drive that multiple servers access at the same time. EFS is designed for shared workloads like content management systems, web serving, or big data analytics where multiple instances need to read and write the same files. EFS automatically grows and shrinks as you add and remove files—you do not need to provision capacity in advance. You are billed only for the storage you actually use. EFS has two storage classes: Standard (for frequently accessed data) and Infrequent Access (IA) (for data accessed less than once a quarter). You can also enable Lifecycle Management to automatically move files from Standard to IA after a set number of days without access.

Why do both exist? The answer is about access patterns. EBS gives you fast, dedicated access to a single block device—perfect for databases, boot volumes, or applications that need low-latency, consistent performance. EFS gives you shared access across many instances—perfect for web server farms, shared configuration files, or collaborative editing. You cannot use EBS for shared access; if you try to attach the same EBS volume to two instances, it will corrupt the data. You cannot use EFS for a high-performance database that requires very low latency; NFS overhead adds slight delay.

What did they replace? Before cloud, you bought physical hard drives. You had to guess how much storage you would need for years. You had to physically install drives in servers. You had to manage backup tapes. EBS and EFS replace all that with elastic, programmable, pay-as-you-go storage.

To manage EBS efficiently, you must understand:

To manage EFS efficiently, you must understand:

The exam loves to test the differences between EBS and EFS. They will give you a scenario—'You have a web application running on 10 EC2 instances that all need to read the same configuration file. Which storage option?' The answer is EFS. They will ask about snapshot behaviour—'Which is true about EBS snapshots?' Answer: Snapshots are incremental after the first full copy. They will test which EBS volume type to use for a high-transaction database: Provisioned IOPS SSD (io1/io2). They will test when to use EBS versus instance store (ephemeral storage): instance store loses data on stop/terminate; EBS persists.

Remember: EBS = block storage, single-instance, persistent, backup via snapshots. EFS = file storage, multi-instance, managed, scalable. Both are essential building blocks for any AWS solution.

Imagine you are the new cloud engineer at a medium-sized online retailer. The company migrated its applications to AWS six months ago, but storage management is a mess. You walk into your first incident review.

The company runs a customer-facing e-commerce site. The database team manages a MySQL database on an EC2 instance with a 500 GB General Purpose SSD (gp2) EBS volume. The web team runs 25 EC2 instances behind a load balancer, all serving the same PHP application. The application's images and CSS files are stored on each instance's local disk. When a new set of promotional images is uploaded to one instance, the other 24 do not see them. The site serves inconsistent content. The marketing team is furious.

The root cause: the web servers are not sharing storage. They should use EFS. Here is what you do step by step.

First, you create an Amazon EFS file system. You open the AWS Management Console, navigate to EFS, and click 'Create file system'. You give it a name like 'shared-web-assets'. You select your VPC (Virtual Private Cloud) and choose the Availability Zones where your web instances run. For each AZ, you create a mount target—this is the network endpoint that instances connect to. You configure the security group for the mount targets to allow inbound NFS traffic (port 2049) from the security group of your web servers.

Next, you update your web server configuration. On each of the 25 instances, you install the NFS client (amazon-efs-utils on Amazon Linux). You create a mount point directory (e.g., /var/www/html/images). Then you mount the EFS file system using the command 'sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-12345678.efs.us-east-1.amazonaws.com:/ /var/www/html/images'. You add the entry to /etc/fstab so the mount persists across reboots. Now, when marketing uploads new promotional images to one instance, those images are written to the EFS file system. All 25 instances read from the same file system immediately. The inconsistency is gone.

Meanwhile, the database administrator is worried about the MySQL volume. It is a 500 GB gp2 volume that is 90% full. The database is running out of space. You need to resize it without any downtime. Here is how you do it:

You take a snapshot of the volume first, just in case. Navigate to EC2 > Elastic Block Store > Volumes, select the volume, and choose 'Actions > Create snapshot'. You give it a description like 'pre-resize-snapshot-mysql-20250101'. While the snapshot is being created (it happens in the background), you modify the volume. You select the volume, click 'Actions > Modify Volume', and change the size from 500 to 750 GB. You confirm the change. Within a few minutes, the volume expands. On the EC2 instance, you extend the file system. For a Linux ext4 file system, you run 'sudo growpart /dev/xvda 1' and 'sudo resize2fs /dev/xvda1'. The database sees more space without any restart. The database admin is relieved.

You also implement a snapshot lifecycle policy: automatic weekly snapshots retained for 4 weeks, with daily snapshots retained for 7 days. This ensures the company can restore the database to any point in the last week.

Later, you migrate the database to a Provisioned IOPS volume (io2) to guarantee consistent 10,000 IOPS during peak shopping periods. You create a new io2 volume, attach it to a new EC2 instance, restore the latest snapshot onto it, and then switch the database server. Cost increases slightly, but the database performance becomes predictable.

Finally, you clean up: you identify 20 orphaned EBS volumes (volumes not attached to any instance) that were left over from terminated instances. Each is charging the company $10/month for no reason. You delete them. The monthly bill drops by $200.

In this real-world scenario, you used EBS for the database (dedicated, high-performance, resizable) and EFS for shared web assets (multi-instance access, auto-scaling). You used snapshots for backup and volume modification for resizing. You used volume types correctly: gp2 for general use, io2 for performance-critical workloads. You also learned the importance of cleaning up unused resources to save cost.