Start with block versus file, then persistence and scope
A volume in one Availability Zone, presented like a disk to supported EC2 instances.
High-performance storage physically attached to the EC2 host; data is replaceable.
Managed NFS storage for concurrent access from multiple clients.
“Disk for one instance” suggests EBS. “Scratch, cache or buffer that can disappear” suggests instance store. “Shared Linux files across instances or zones” suggests EFS.
Amazon EBS: persistent, network-attached block storage
An EBS volume belongs to one Availability Zone and must attach to a supported EC2 instance in that zone. Data can persist when an instance stops, and a separately managed data volume can outlive instance termination. The root volume’s delete-on-termination behavior depends on its configuration.
Uses the volume as a block device.
Persists independently when configured to remain.
Creates recoverable point-in-time data managed by EBS.
To move data to another Availability Zone, create a snapshot and restore a new volume in the destination zone. Design snapshots, encryption, monitoring and application-consistent recovery separately from basic volume persistence.
gp3 vs io2: general purpose versus mission-critical Provisioned IOPS
gp3 includes baseline performance independent of volume size and allows additional IOPS and throughput to be provisioned. io2, including io2 Block Express capabilities on supported platforms, is designed for demanding latency-sensitive and durability-sensitive workloads.
Many databases perform well on gp3. Choose io2 only when measured or stated IOPS, latency, consistency and durability requirements justify Provisioned IOPS.
Instance store: fast temporary storage tied to the host
Instance-store volumes are backed by disks physically attached to the host computer. They are valuable for caches, buffers, scratch space, replicated data and temporary processing. The application must be able to recreate or retrieve the data elsewhere.
Snapshots cannot preserve an instance-store volume through the EBS snapshot mechanism. Copy valuable results to durable storage such as EBS, S3 or EFS before the instance lifecycle removes them.
Amazon EFS: elastic shared NFS for multiple clients
EFS provides a managed file system that Linux-based clients can mount through NFS. Regional file systems store data across multiple Availability Zones and use mount targets for VPC access. Capacity grows and shrinks as files are added and removed.
EFS suits shared web content, home directories, content management, analytics and container workloads needing concurrent file access. It is not a block device; confirm that a shared POSIX-style file interface is the actual requirement.
Regional Amazon EFS file system
Worked scenario: scalable image-processing fleet
Situation: An Auto Scaling group runs Linux workers across two Availability Zones. Every worker must read the same source images. Each worker also creates temporary intermediate files that are discarded after the final output is written to S3.
Shared source files
Use regional EFS when all Linux workers need the same mounted file namespace across zones.
Temporary high-speed scratch
Use instance store on supported instance types when intermediate data is replaceable and lifecycle loss is acceptable.
Durable result
Write completed objects to S3; do not leave the only copy on instance store.
EBS is AZ-scoped block storage. It is not a regional shared NFS file system for an elastic fleet across multiple Availability Zones.
EBS latency increased: verify the complete I/O path
- Workload demand: inspect volume IOPS, throughput, queue length and latency rather than CPU alone.
- Volume configuration: compare provisioned gp3 or io2 performance with observed demand.
- Instance limits: confirm the EC2 type’s EBS bandwidth and IOPS limits are not lower than the volume configuration.
- Initialization: consider whether blocks restored from a snapshot require initialization before full performance.
- Application pattern: inspect I/O size, concurrency, fsync behavior, file system and database configuration.
Provisioning more volume IOPS does not help when the instance’s EBS channel or application pattern is the bottleneck. Measure both ends of the path.
Practice checks with explanations
A database needs persistent SSD block storage with ordinary performance needs and independent IOPS tuning. What fits?
Best answer: gp3. It is the general-purpose SSD choice and separates performance provisioning from capacity.
A distributed cache can rebuild every entry and needs host-local temporary performance. What fits?
Best answer: instance store on a suitable instance type, with the application designed for loss and replacement.
Linux web servers in three Availability Zones need concurrent access to the same uploaded files. What fits?
Best answer: a regional EFS file system with appropriate mount targets and network controls.
Common SAA-C03 storage mistakes
- Using instance store for the only copy of valuable data.
- Assuming EBS volumes attach across Availability Zones.
- Choosing io2 for every database without performance evidence.
- Treating EBS Multi-Attach as a general shared-file-system replacement.
- Choosing EFS when the application requires a block device.
- Ignoring EC2 EBS bandwidth limits while increasing volume performance.
- Confusing EBS snapshots with files visible in an S3 bucket.
Frequently asked questions
What is the difference between EBS gp3 and io2?
gp3 is the general-purpose SSD choice for a broad range of workloads and lets capacity, IOPS and throughput be provisioned independently. io2 is Provisioned IOPS SSD for latency-sensitive, I/O-intensive workloads needing higher performance consistency and durability.
What is the difference between EBS and instance store?
EBS is network-attached persistent block storage whose volume lifecycle can be independent of an EC2 instance. Instance store is physically attached to the host and its data is temporary, so applications must tolerate loss on stop, hibernation, termination or host failure.
When should I choose EFS instead of EBS?
Choose EFS when multiple Linux clients need a managed shared NFS file system that can grow and shrink automatically. Choose EBS when an EC2 workload needs low-latency block storage in the same Availability Zone.
Can an EBS volume be attached across Availability Zones?
No. An EBS volume is created in one Availability Zone and attaches to supported instances in that same zone. Use a snapshot to create a new volume in another zone or choose a regional service such as EFS when the access pattern requires it.
Does rebooting an EC2 instance erase instance-store data?
A reboot normally preserves instance-store data, but a stop, hibernation, termination or underlying host failure does not. Never use instance store as the only copy of irreplaceable data.
Official AWS references
Review AWS documentation for EBS volume types, EBS volumes, EC2 instance store, how Amazon EFS works, and the official SAA-C03 certification page.