PW
Back to home

Amazon EC2 Instance Storage

Jul 15, 2026

AWS

Amazon EC2 Instance Storage, BS, Instance Store, AMI, and EFS

When we launch an EC2 instance, we are not only choosing CPU, memory, and network. We also need to think about storage, because every application needs some place to keep its files, logs, operating system, database data, cache, or temporary work. In AWS EC2, the main storage options you will see are EBS, EC2 Instance Store, and EFS. They look similar at first because all of them are related to storing data, but they solve different problems.

Before reading this, you should know the basic meaning of EC2 instance, Availability Zone, and Region. You do not need to be expert in storage, but you should understand that some data must stay safe after a server is stopped, and some data is only temporary. This difference is the main idea behind EC2 instance storage.

The Quick Answer: Which Storage Should You Use?

If you want persistent block storage for one EC2 instance, use Amazon EBS. Persistent means the data can continue to exist even when the EC2 instance is stopped or terminated, depending on the volume settings. EBS is like a network drive attached to your EC2 instance, and it is the most common storage option for boot volumes, application files, and databases.

If you want very fast temporary storage that is physically attached to the host machine, use EC2 Instance Store. It gives very high I/O performance, but the data is temporary. Meaning if the instance is stopped, terminated, or the underlying hardware fails, you should expect that data can be gone. So this is good for cache, buffers, scratch files, and temporary content, not for important permanent data.

If you want a shared file system mounted by many EC2 instances, use Amazon EFS. EFS is useful when multiple Linux instances need access to the same files, like WordPress uploads, shared web content, or common application files. It is more expensive than EBS in many cases, but it is managed, scalable, and works across multiple Availability Zones.

What Is an EBS Volume?

EBS means Elastic Block Store. It is a block-level storage service that we can attach to EC2 instances. The simple way to understand it is this: EC2 is the server, and EBS is the disk attached to that server. But EBS is not usually a physical disk inside the same machine. It is a network-attached disk, so the EC2 instance communicates with it over the AWS network.

This is why EBS is flexible. You can attach a volume to an EC2 instance, detach it, and attach it to another instance in the same Availability Zone. You can also increase the size or change some performance settings over time. But because it is network storage, there can be a little latency compared to a local disk.

One very important point is that EBS volumes are locked to one Availability Zone. If your EBS volume is created in us-east-1a, you cannot directly attach it to an instance running in us-east-1b. To move EBS data to another Availability Zone or Region, you usually create a snapshot and restore a new volume from that snapshot in the target location.

EBS and Delete on Termination

When you launch an EC2 instance, it normally has a root EBS volume. This root volume contains the operating system and boot files. By default, when the EC2 instance is terminated, the root EBS volume is also deleted. This behavior is controlled by the DeleteOnTermination attribute.

Other EBS volumes attached to the instance are usually not deleted by default when the instance is terminated. This is useful because your application data may be on a separate data volume, and you may want to keep it even after deleting the EC2 instance.

This is one place where beginners make mistakes. They think stopping and terminating are the same thing. They are not. Stopping an instance keeps the EBS-backed root volume. Terminating an instance can delete the root volume if DeleteOnTermination is enabled. If you have important data on the root volume, you should either disable delete on termination or create snapshots.

EBS Snapshots

An EBS snapshot is a point-in-time backup of an EBS volume. It is used when you want to protect your data, copy it to another Availability Zone, or copy it to another Region. You do not always need to detach the volume before taking a snapshot, but for data consistency, it is often safer to pause writes or stop the instance depending on the workload.

Snapshots are also useful for migration. Because an EBS volume is tied to one Availability Zone, the common process is: create a snapshot, then restore a new EBS volume from that snapshot in another Availability Zone. This is how you move the data, not by directly attaching the same volume across zones.

AWS also has snapshot features like Snapshot Archive, Recycle Bin, and Fast Snapshot Restore. Snapshot Archive helps reduce cost for snapshots that you do not need to restore quickly. Recycle Bin helps recover snapshots after accidental deletion. Fast Snapshot Restore helps remove first-use latency when creating volumes from snapshots, but it costs more.

AMI and EBS Snapshots

AMI means Amazon Machine Image. An AMI is like a saved image of an EC2 instance configuration. It can include the operating system, installed software, application setup, monitoring tools, and other custom configuration. Instead of launching a plain server and setting everything again manually, you can create an AMI and launch new instances from it.

The important storage connection is this: when you create an AMI from an EC2 instance, AWS also creates EBS snapshots for the volumes used by that instance. So AMI is not only about the instance settings. It is also connected to the storage state of the instance at that time.

The common AMI process is simple. Start an EC2 instance, configure it, stop it for better data consistency, create an AMI, and then launch new instances from that AMI. This is useful when you want faster boot time and consistent configuration across many servers.

What Is EC2 Instance Store?

EC2 Instance Store is temporary block storage that is physically attached to the host computer where your EC2 instance runs. Because the storage is local to the host, it can provide very high I/O performance. This is why it is used for workloads that need fast local disk access.

But the main rule is: Instance Store is ephemeral. Ephemeral means temporary. The data is not designed to live forever. If the instance is stopped or terminated, the data can be lost. If the underlying hardware fails, the data can also be lost. So you should not use Instance Store as the only place for important data.

Good use cases for Instance Store are cache, buffer, temporary files, scratch data, and data that can be recreated or replicated somewhere else. For example, if your application processes large files temporarily and then stores the final output in S3 or EBS, Instance Store can be useful. But if you are storing a database and you care about durability, EBS is usually the safer choice.

EBS Volume Types

EBS has different volume types because not every workload needs the same storage performance. Some applications need low cost. Some need high IOPS. Some need high throughput. AWS gives multiple EBS volume types so we can choose based on the workload.

General Purpose SSD volumes are gp2 and gp3. These are common for boot volumes, development environments, virtual desktops, and many normal workloads. gp3 is usually preferred in modern AWS usage because you can configure IOPS and throughput separately from storage size.

Provisioned IOPS SSD volumes are io1 and io2. These are for critical workloads that need strong and consistent performance, like important databases. They are more expensive, but they are designed for workloads where storage performance matters a lot.

Throughput Optimized HDD is st1. It is used for large, frequently accessed, sequential workloads like big data, data warehouses, and log processing. Cold HDD is sc1. It is lower cost and used for data that is accessed less often. One key exam point is that HDD-based st1 and sc1 volumes cannot be boot volumes.

EBS Multi-Attach

Normally, one EBS volume is attached to one EC2 instance at a time. EBS Multi-Attach is the exception. It allows the same io1 or io2 volume to be attached to multiple EC2 instances in the same Availability Zone.

This sounds simple, but there is an important warning. If multiple instances can read and write to the same volume, the application must manage concurrent writes correctly. You also need a cluster-aware file system. Normal file systems like EXT4 or XFS are not designed for this kind of shared writing. So Multi-Attach is for specific clustered applications, not for normal shared file storage.

If your actual goal is just to share files between many EC2 instances, EFS is usually the better answer.

What Is Amazon EFS?

EFS means Elastic File System. It is a managed NFS file system that can be mounted by many EC2 instances. It works well for Linux-based workloads and can be used across multiple Availability Zones. This makes it different from EBS, because EBS is usually attached to one instance in one Availability Zone, while EFS is built for shared file access.

EFS is useful for content management systems, web serving, shared application files, and WordPress uploads. It uses security groups for access control, supports encryption at rest with KMS, and scales automatically. You do not need to provision a fixed size like EBS, because EFS grows and shrinks as files are added or removed.

The tradeoff is cost and performance behavior. EFS is often more expensive than EBS, and because it is a shared network file system, you should choose it when you actually need shared file access. Do not choose EFS only because it sounds more flexible. If one EC2 instance needs one disk, EBS is usually simpler and cheaper.

EFS Performance and Storage Classes

EFS has different performance and throughput options. General Purpose performance mode is the default and is good for latency-sensitive applications like web servers and content management systems. Max I/O is for highly parallel workloads, but it can have higher latency.

For throughput, EFS can use bursting, provisioned, or elastic throughput. Bursting depends on the amount of data stored. Provisioned lets you set throughput manually. Elastic throughput automatically scales based on workload behavior, which is useful when traffic is unpredictable.

EFS also has storage classes. Standard is for frequently accessed files. Infrequent Access is for data accessed less often. Archive is for rarely accessed data. Lifecycle policies can move files between these classes automatically, which helps reduce cost.

EBS vs EFS vs Instance Store

EBS is block storage for EC2. Use it when one instance needs persistent disk storage. It is good for root volumes, databases, and application data. It is tied to an Availability Zone, and snapshots are used for backup or migration.

EFS is file storage for many instances. Use it when multiple Linux instances need to share the same files. It works across multiple Availability Zones and scales automatically, but it can cost more than EBS.

Instance Store is temporary local storage. Use it when you need very fast storage for data you can lose or recreate. It is good for cache and scratch data, but backups and replication are your responsibility.

Common Mistakes to Avoid

One common mistake is thinking Instance Store is the same as EBS. It is not. EBS is persistent network block storage. Instance Store is temporary local block storage. If the data is important, do not keep it only on Instance Store.

Another mistake is forgetting that EBS volumes are tied to an Availability Zone. You cannot directly attach a volume from one AZ to an instance in another AZ. You need to take a snapshot and restore it in the target AZ.

Another mistake is using EFS when EBS is enough. EFS is powerful, but if you only have one instance and one application disk, EBS is usually the right option. EFS becomes useful when many instances need shared file storage.

The final mistake is ignoring delete on termination. If your root EBS volume contains important data and delete on termination is enabled, terminating the instance can delete that volume. For production, keep important data on separate volumes, create snapshots, and understand the termination behavior before deleting instances.

Final Summary

Amazon EC2 Instance Storage is mainly about choosing the correct storage based on how your application uses data. If data must persist, think about EBS. If data must be shared between many Linux instances, think about EFS. If data is temporary and needs very fast local disk performance, think about Instance Store.

For the AWS Certified Developer exam, remember the simple difference. EBS is persistent block storage. Instance Store is temporary local storage. EFS is shared file storage. If you understand this difference clearly, most EC2 storage questions become much easier.

Useful References