EBS, EFS, and EC2 instance store can all appear next to an EC2 workload, but they represent different persistence and sharing models. Choosing among them by price per gigabyte or a single performance number misses the design boundary. The important questions are whether data must survive instance replacement, whether multiple hosts need concurrent access, which Availability Zones participate, and whether the workload can reconstruct local data after failure.
Those trade-offs are central to SAA-C03, where storage choices have consequences for performance, resilience, and cost. In production, a wrong assumption can be severe: a team may put durable state on instance store, design a multi-zone service around a zonal EBS volume, or use a shared file system where the application really needs low-latency block storage.
The most reliable decision sequence is persistence first, access model second, failure domain third, and performance tuning fourth. Once those constraints are explicit, the storage choice is usually clearer than a feature-by-feature comparison.
EBS is persistent block storage attached to compute
Amazon EBS provides block volumes for EC2. A volume persists independently of the life of the instance unless deletion behavior is configured otherwise. That makes EBS a natural fit for boot volumes, databases that manage their own filesystem and storage layout, and applications that need block-device semantics with controllable IOPS and throughput.
The architectural boundary is Availability Zone placement. An EBS volume exists in one Availability Zone and attaches to compatible instances in that zone. Snapshots provide a durable way to back up volumes and create new volumes elsewhere, but a snapshot is not the same as having the active block device simultaneously available across zones. Multi-zone application resilience therefore needs replication or recovery logic above the individual volume.
EFS is a shared file system, not a bigger EBS volume
Amazon EFS provides managed file storage that clients mount over NFS. Multiple compute instances can access the same directory tree, making it useful for shared content, user files, web assets, build artifacts, and applications that already expect POSIX-style shared filesystem behavior.
For Regional EFS storage, data and metadata are stored across Availability Zones and clients normally use mount targets in the zones where compute runs. That creates a different failure model from a zonal block volume. The difference between block and file storage matters because an application designed around block-level database I/O is not automatically improved by moving to a network filesystem.
Instance store is fast local working space with an explicit loss boundary
Instance store is physically attached to the host supporting certain EC2 instance types. It can provide very high local I/O performance, but the data is temporary. Terminating the instance destroys instance-store data, and stop or hibernate behavior also makes it unsuitable as the sole location for information that must survive the instance lifecycle.
That does not make instance store “bad” storage. It is excellent for caches, buffers, scratch space, replicated data, shuffle files, and other information the system can regenerate. The correct question is whether loss of the host is an expected recovery event. If the application already treats local data as disposable, instance store can remove unnecessary network-storage dependency.
Sharing requirements often decide the choice before performance does
A single EC2 instance needing a durable boot or data disk naturally points toward EBS. Many instances needing the same filesystem namespace point toward EFS. A host needing temporary high-speed workspace may benefit from instance store. These access semantics are more fundamental than benchmark numbers because they determine how the application coordinates data.
The distinction among EBS, S3, and EFS is useful only when the service boundary is kept visible. EBS is block storage, EFS is shared file storage, and S3 is object storage. Substituting one for another often requires application changes, not merely a different mount command.
EBS Multi-Attach is a specialized capability, not a general shared filesystem
Some EBS volume types support Multi-Attach to multiple compatible instances in the same Availability Zone. That can help clustered applications designed to coordinate access to shared block storage, but the volume does not become a normal multi-writer filesystem automatically. The application or clustering layer must handle concurrency and consistency correctly.
EBS Multi-Attach should therefore be selected because the workload understands shared block semantics. If the requirement is simply “many Linux hosts need the same files,” EFS is usually the more natural abstraction. Specialized capability should not be used to recreate a service AWS already manages directly.
Failure domains should be tested before storage performance is tuned
A volume can meet every latency target and still be the wrong architecture if losing its Availability Zone breaks the entire service. Conversely, a Regional file system can survive zone issues but still become an application bottleneck if the workload depends on low-latency local writes. Resilience and performance have to be evaluated together.
Test the failure that matters. For EBS-backed state, determine how another instance obtains current data after a host or zone loss. For EFS, verify that compute in each active zone uses an appropriate mount target and that security groups permit the NFS path. For instance store, demonstrate that replacement nodes can rebuild their working data fast enough to meet the recovery target.
Backup strategy follows the persistence model
EBS snapshots can protect block volumes and support restoration or migration. EFS integrates with backup mechanisms and can also use lifecycle management for cost optimization. Instance store should normally be excluded from the durable backup model because valuable state should already exist elsewhere; backing it up continuously would undermine the reason it was chosen as disposable local storage.
The broader storage technology model helps separate availability from backup. Keeping a workload running through a failure and restoring data after corruption are different goals. A storage service that is highly available still needs recovery planning for deletion, application corruption, ransomware, or bad changes.
Choose by data behavior, then validate with workload evidence
Start with the data: must it persist after instance loss, must it be shared concurrently, can it be recreated, and which zones need access? Then measure latency, throughput, IOPS, concurrency, file counts, and growth using a representative workload. Avoid selecting a service because its headline maximum is larger than another service’s; applications rarely exercise storage in the same pattern as a marketing benchmark.
The storage judgment behind AWS Certified Solutions Architect – Associate can be summarized cleanly. EBS provides persistent block storage tied to a zone, EFS provides managed shared file storage with Regional and One Zone options, and instance store provides temporary host-local block storage. The right choice follows from persistence, sharing, failure domain, and access behavior before it follows from cost or peak performance.
EBS performance also varies by volume type and configuration. General-purpose SSD volumes are appropriate for many workloads, while provisioned-IOPS options exist for latency-sensitive and I/O-intensive databases. Performance limits can depend on volume settings, instance capabilities, and queue behavior. A storage benchmark should therefore run on the intended EC2 class and filesystem, not on an isolated volume whose host cannot deliver the same throughput.
EFS has its own performance and throughput choices. Shared-file workloads can be limited by metadata operations, small-file patterns, or aggregate throughput long before raw capacity becomes the issue. The default General Purpose performance mode is appropriate for most file systems, and throughput behavior should be tested with the actual concurrency and file sizes the application uses. “Automatically scalable storage” does not mean every workload pattern has identical latency.
Instance store can also be combined across local devices for specialized workloads, but striping temporary disks only increases the amount of data lost with the host. That can be acceptable for scratch processing when the source data exists elsewhere and the job can restart. It is dangerous when engineers see high local throughput and gradually allow irreplaceable state to leak onto the node.
Security follows the access model. EBS encryption protects volumes and snapshots, EFS supports encryption and network access controls around mount targets, and instance-store data still needs operating-system and application controls while the host is running. Encryption does not replace access policy, and shared filesystems need deliberate client authorization because many instances may reach the same namespace.
Cost comparisons should include data transfer, snapshots or backups, provisioned performance, idle capacity, and operational effort. EBS may be economical for a stable single-host volume, EFS may remove the complexity of maintaining a shared file server, and instance store may eliminate network-storage cost for disposable data. The architecture should price the behavior it needs rather than compare only the per-gigabyte line item.
Migration cost can dominate the storage decision when large data sets already exist. Moving from EBS to EFS changes filesystem and network behavior; moving shared files back to block storage may require application redesign; replacing instance-store scratch space with durable storage can add both latency and cost. The best architecture may therefore be the one that reduces future coupling even if the first migration requires more work.
Data locality matters for performance and cost as well. A compute fleet that repeatedly crosses Availability Zones to reach storage or mount targets can create avoidable latency and transfer charges. Zonal block storage should stay aligned with its compute, Regional EFS should use local mount targets where practical, and disposable local data should be recreated near the worker using it. Placement is part of the storage design, not a deployment detail.
Filesystem semantics can be the hidden constraint in legacy applications. File locking, rename behavior, permission models, hard links, and expected mount options may matter more than throughput. Before migrating a shared workload, test the operations the application actually performs under concurrency. A storage service can be fast and durable yet still be wrong if its access semantics do not match the software.
