EC2 Storage: Instance Store vs EBS

EC2 instances can use two types of local storage: Instance Store and Amazon EBS (Elastic Block Store). Instance Store is physically attached to the host server, offering very high IOPS and throughput but with a critical caveat—data is lost when the instance stops or terminates. EBS provides persistent network-attached block storage that survives instance stop/start/termination. Understanding when to use each is a recurring topic on the SAA-C03 exam.

Instance Store (also called ephemeral storage) consists of NVMe SSDs physically attached to the host hardware that runs your EC2 instance. Data in the instance store is lost whenever the instance is stopped, hibernated, or terminated, or if the underlying hardware fails. However, data persists through a reboot. Instance Store is ideal for: buffer/cache/scratch data, temporary files, data that is replicated across a fleet (e.g., Cassandra nodes). Not all instance types include Instance Store; look for the d suffix (e.g., i3.xlarge, m5d.large).

Amazon EBS volumes are network-attached storage that persist independently of the EC2 instance lifecycle. An EBS volume exists in a specific Availability Zone and can be attached to one EC2 instance at a time (except for io1/io2 multi-attach). When you stop and restart an instance, the EBS volume retains all data. You can detach it from one instance and attach it to another in the same AZ, or create a snapshot to copy it to another AZ or Region.

AWS offers four EBS volume types. gp3 (General Purpose SSD): baseline 3,000 IOPS and 125 MB/s, independently configurable up to 16,000 IOPS and 1,000 MB/s—the default and most cost-effective choice for most workloads. gp2: older General Purpose SSD where IOPS scale with size (3 IOPS/GB, max 16,000)—being phased out in favour of gp3. io2 Block Express: Provisioned IOPS SSD up to 256,000 IOPS and 4,000 MB/s—for I/O-intensive databases like SAP HANA or Oracle. io1: legacy Provisioned IOPS SSD.

The two HDD-based EBS types are optimised for throughput, not IOPS. st1 (Throughput Optimised HDD): baseline 40 MB/s/TB, burst to 250 MB/s/TB—ideal for big data, log processing, and data warehouses with large sequential reads. sc1 (Cold HDD): baseline 12 MB/s/TB, burst to 80 MB/s/TB—lowest-cost EBS option for infrequently accessed sequential data. HDD volumes cannot be used as boot volumes (root device). Choose st1 or sc1 only when throughput matters more than IOPS and the data access pattern is large sequential reads/writes.

EBS snapshots are point-in-time backups of a volume stored durably in Amazon S3 (though you access them through the EC2 API, not S3 directly). Snapshots are incremental: the first snapshot captures the full volume, and subsequent snapshots record only the blocks that changed since the last snapshot, reducing storage cost. You can create a new EBS volume from any snapshot in any AZ within the same Region, or copy the snapshot to another Region for cross-region disaster recovery.

EBS volumes and snapshots can be encrypted using AWS KMS keys. Encryption is transparent to the instance—data is encrypted in transit between the instance and the volume and at rest on the storage. You can enable account-level default encryption so every new EBS volume created in the account is automatically encrypted without per-volume configuration. Encrypting an unencrypted volume requires creating a snapshot, creating an encrypted copy of the snapshot, then creating a new volume from the encrypted snapshot.

EBS Multi-Attach allows an io1 or io2 volume to be attached to up to 16 EC2 instances in the same Availability Zone simultaneously. All attached instances have full read/write access. This is used for clustered Linux applications (like Oracle RAC or Teradata) that manage concurrency at the application layer using a cluster-aware file system. Multi-Attach is not a replacement for EFS for shared file systems—it is specifically for clustered block-level access with application-managed coordination.

Key decision criteria: Persistence needed? → Use EBS. Data can be recreated or is replicated? → Instance Store is acceptable and gives higher performance. Database with critical data? → Always EBS (with snapshots and encryption). Temporary scratch space for ML training or sort operations? → Instance Store for maximum throughput at zero extra cost. The exam commonly presents scenarios where you must identify whether ephemeral or persistent storage is appropriate for a given workload.

EBS-optimised instances provide dedicated network bandwidth between the EC2 instance and EBS, separate from the general instance network bandwidth. This prevents network contention between application traffic and storage I/O. Most current-generation instance types are EBS-optimised by default at no extra charge. Older instance types may require enabling EBS optimisation manually (for an additional hourly fee). For high-I/O database workloads, always confirm your instance type is EBS-optimised to achieve the full provisioned IOPS of your volume.

Amazon Data Lifecycle Manager (DLM) automates the creation, retention, and deletion of EBS snapshots and AMIs. You define lifecycle policies that specify which volumes to back up (by tag), how frequently to create snapshots (every 1, 2, 3, 4, 6, 8, or 12 hours, or daily), and how many snapshots to retain. DLM eliminates the need for custom backup scripts and integrates with CloudWatch for monitoring policy health. For cross-region snapshots, configure a copy policy in the same DLM definition.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Instance Store offers the highest local I/O performance but is ephemeral—data is lost on stop or termination, EBS provides persistent network-attached block storage with four volume types optimised for IOPS (gp3, io2) or throughput (st1, sc1), and EBS snapshots enable point-in-time backups stored in S3 that can be used for cross-AZ or cross-region recovery. Next up we explore S3 Object Storage Fundamentals.