EBS

AWS EC2 Storage

~ Last updated on : ~ jayendrapatil ~ 6 Comments

EC2 Storage Overview

EC2 Storage Options - EBS, S3 & Instance Store

Storage Types

Elastic Block Store – EBS

  • Elastic Block Store – EBS provides highly available, reliable, durable, block-level storage volumes that can be attached to an EC2 instance.
  • persists independently from the running life of an instance.
  • behaves like a raw, unformatted, external block device that can be attached to a single EC2 instance at a time (except Multi-Attach enabled io1/io2 volumes that can attach to up to 16 Nitro-based instances).
  • is recommended for data that requires frequent and granular updates e.g. running a database or filesystem.
  • is Zonal and can be attached to any instance within the same Availability Zone and can be used like any other physical hard drive.
  • is particularly well-suited for use as the primary storage for file systems, databases, or any applications that require fine granular updates and access to raw, unformatted, block-level storage.
  • provides six volume types: Provisioned IOPS SSD (io2 Block Express and io1), General Purpose SSD (gp3 and gp2), Throughput Optimized HDD (st1) and Cold HDD (sc1).
  • General Purpose SSD (gp3) volumes support up to 64 TiB, 80,000 IOPS, and 2,000 MiB/s throughput (enhanced in September 2025 from 16 TiB, 16,000 IOPS, 1,000 MiB/s).
  • Provisioned IOPS SSD (io2 Block Express) volumes support up to 64 TiB, 256,000 IOPS, and 4,000 MB/s throughput with sub-millisecond latency and 99.999% durability.
  • supports data protection features including Snapshots, EBS Snapshot Archive, Recycle Bin (accidental deletion protection), and Snapshot Lock (WORM protection).

Instance Store Storage

  • Instance store provides temporary or Ephemeral block-level storage.
  • is located on the disks that are physically attached to the host computer.
  • consists of one or more instance store volumes exposed as block devices.
  • The size of an instance store varies by instance type.
  • Virtual devices for instance store volumes are ephemeral[0-23], starting the first one as ephemeral0 and so on.
  • While an instance store is dedicated to a particular instance, the disk subsystem is shared among instances on a host computer.
  • is ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content, or for data that is replicated across a fleet of instances, such as a load-balanced pool of web servers.
  • delivers very high random I/O performance and is a good option for storage with very low latency requirements, but you don’t need the data to persist when the instance terminates or you can take advantage of fault-tolerant architectures.
  • Data is lost when the instance is stopped, terminated, or the underlying host fails. Data persists during an instance reboot.
  • Instance store volumes are included as part of the usage cost of the instance.

Amazon EBS vs Instance Store

More detailed @ Comparison of EBS vs Instance Store

Simple Storage Service – S3

More details @ AWS S3

Elastic File System – EFS

  • Elastic File System – EFS provides a simple, fully managed, easy-to-set-up, scalable, serverless, and cost-optimized file storage.
  • can automatically scale from gigabytes to petabytes of data without needing to provision storage.
  • provides managed NFS (network file system) that can be mounted on and accessed by multiple EC2 instances in multiple AZs simultaneously.
  • offers highly durable, highly scalable, and highly available storage.
    • EFS Regional file systems (recommended) store data redundantly across multiple AZs in the same region.
    • EFS One Zone file systems provide lower-cost option storing data in a single AZ.
    • grows and shrinks automatically as files are added and removed, so there is no need to manage storage procurement or provisioning.
  • supports the Network File System version 4 (NFSv4.1 and NFSv4.0) protocol.
  • provides file system access semantics, such as strong data consistency and file locking.
  • is compatible with all Linux-based AMIs for EC2, POSIX file system (~Linux) that has a standard file API.
  • is a shared POSIX system for Linux systems and does not work for Windows (use FSx for Windows File Server instead).
  • offers the ability to encrypt data at rest using KMS and in transit.
  • can be accessed from on-premises using an AWS Direct Connect or AWS VPN connection between the on-premises datacenter and VPC.
  • can be accessed concurrently from servers in the on-premises data center as well as EC2 instances in the VPC.
  • supports up to 2.5 million read IOPS and 500,000 write IOPS per file system (10x increase announced Nov 2024).
  • supports Elastic Throughput of up to 60 GiB/s read and 5 GiB/s write throughput per file system.
  • supports up to 10,000 access points per file system for application-specific access management (increased Feb 2025).
  • supports IPv6 for both EFS APIs and mount targets (added Jun 2025).

Amazon FSx

  • Amazon FSx provides fully managed file storage built on four widely-used file systems: Lustre, NetApp ONTAP, OpenZFS, and Windows File Server.
  • FSx for Windows File Server – provides fully managed Windows-native shared file storage using SMB protocol. Supports Windows features like Active Directory, DFS, and shadow copies.
  • FSx for Lustre – provides high-performance file storage optimized for fast processing of workloads such as ML, HPC, video processing, and financial modeling. Delivers up to terabytes/second of throughput and millions of IOPS.
  • FSx for NetApp ONTAP – provides fully managed shared storage with NetApp ONTAP features including snapshots, clones, FlexClone, SnapMirror replication. Supports NFS, SMB, and iSCSI protocols.
  • FSx for OpenZFS – provides fully managed shared storage powered by OpenZFS file system. Delivers up to 21 GB/s throughput and over 1 million IOPS for cached data. Supports NFS protocol with data compression, snapshots, and cloning.
  • Use FSx for Windows File Server for Windows-based applications that need SMB protocol.
  • Use FSx for Lustre for compute-intensive workloads requiring the fastest storage performance.

Block Device Mapping

  • A block device is a storage device that moves data in sequences of bytes or bits (blocks) and supports random access and generally use buffered I/O for e.g. hard disks, CD-ROM etc
  • Block devices can be physically attached to a computer (like an instance store volume) or can be accessed remotely as if it was attached (like an EBS volume)
  • Block device mapping defines the block devices to be attached to an instance, which can either be done while creation of an AMI or when an instance is launched
  • Block device must be mounted on the instance, after being attached to the instance, to be able to be accessed
  • When a block device is detached from an instance, it is unmounted by the operating system and you can no longer access the storage device.
  • Additional Instance store volumes can be attached only when the instance is launched while EBS volumes can be attached to a running instance.
  • Viewing the block device mapping for an instance only shows the EBS volumes and not the instance store volumes. Instance metadata can be used to query the complete block device mapping.

AWS Open Data (Registry of Open Data on AWS)

  • AWS provides the Registry of Open Data on AWS that makes high-value, cloud-optimized datasets publicly available for analysis on AWS.
  • The registry has surpassed 1,000+ datasets and over 100 petabytes of data available for public use.
  • Datasets are also discoverable on AWS Data Exchange alongside 3,000+ existing data products.
  • There is no charge for accessing the public data sets. You pay only for the compute and storage you use for your own applications.
  • Previously referred to as “AWS Public Data Sets,” this is now the AWS Open Data Sponsorship Program.

EC2 Storage Comparison

Feature EBS Instance Store EFS S3
Storage Type Block Block File (NFS) Object
Persistence Persistent Ephemeral Persistent Persistent
Scope Single AZ Single Instance Regional (Multi-AZ) Regional (Multi-AZ)
Access Single instance (or Multi-Attach for io1/io2) Single instance Multiple instances concurrently Multiple instances/services
Performance Up to 256K IOPS (io2 BE) Very high random I/O Up to 2.5M read IOPS Virtually unlimited
Use Case Databases, boot volumes Buffers, caches, temp data Shared file systems, CMS Backups, data lakes, static content
OS Support Linux/Windows Linux/Windows Linux only Any (via API)

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. When you view the block device mapping for your instance, you can see only the EBS volumes, not the instance store volumes.
    1. Depends on the instance type
    2. FALSE
    3. Depends on whether you use API call
    4. TRUE
  1. Amazon provides the Registry of Open Data on AWS that makes high-value datasets publicly available. What is the monthly charge for using the public data sets?
    1. A 1 time charge of 10$ for all the datasets.
    2. 1$ per dataset per month
    3. 10$ per month for all the datasets
    4. There is no charge for using the public data sets
  1. How many types of block devices does Amazon EC2 support?
    1. 2 (EBS volumes and Instance Store volumes)
    2. 4
    3. 3
    4. 1
  1. A company needs shared file storage for Linux-based EC2 instances across multiple Availability Zones. Which AWS storage service should they use?
    1. Amazon EBS with Multi-Attach
    2. Amazon S3
    3. Amazon EFS
    4. Amazon FSx for Windows File Server
  1. Which EC2 storage option provides the highest random I/O performance but does NOT persist data when the instance is stopped or terminated?
    1. Amazon EBS gp3
    2. Amazon EBS io2 Block Express
    3. EC2 Instance Store
    4. Amazon EFS
  1. A company requires Windows-based shared file storage with SMB protocol support. Which AWS service is the most appropriate?
    1. Amazon EFS
    2. Amazon EBS
    3. Amazon FSx for Windows File Server
    4. Amazon S3
  1. Which statement about EBS Multi-Attach is correct?
    1. Multi-Attach is supported on all EBS volume types
    2. Multi-Attach allows io1/io2 volumes to be attached to up to 16 Nitro-based instances in the same AZ
    3. Multi-Attach allows volumes to be attached to instances across multiple AZs
    4. Multi-Attach is only supported on gp3 volumes
  1. What is the maximum IOPS supported by Amazon EBS General Purpose SSD (gp3) volumes? [Updated Sept 2025]
    1. 16,000 IOPS
    2. 64,000 IOPS
    3. 80,000 IOPS
    4. 256,000 IOPS

References

AWS EC2 EBS Monitoring

~ Last updated on : ~ jayendrapatil ~ 2 Comments

EBS Monitoring

AWS supports EBS monitoring by automatically providing data, such as CloudWatch metrics and volume status checks to help monitor EBS volumes.

CloudWatch Monitoring

  • CloudWatch metrics are statistical data that you can use to view, analyze, and set alarms on the operational behavior of the EBS volumes.
  • All Amazon EBS volume types automatically send 1-minute metrics to CloudWatch at no additional charge, but only when the volume is attached to an instance.
  • Some metrics have differences on Nitro-based instances vs. Xen-based instances.
  • EBS Metrics (AWS/EBS namespace)
    • VolumeReadBytes & VolumeWriteBytes
      • Provides information on the I/O operations in a specified period of time, in bytes.
    • VolumeReadOps & VolumeWriteOps
      • Total number (count) of I/O operations in a specified period of time.
    • VolumeTotalReadTime & VolumeTotalWriteTime
      • Total number of seconds spent by all operations that were completed in a specified period of time.
      • For Xen instances, data is reported only when there is read/write activity on the volume.
    • VolumeIdleTime
      • Total number of seconds, in a specific period, when the volume was idle (no read and write operations).
    • VolumeQueueLength
      • Number of read and write operations, in a specific period, waiting to be completed.
    • VolumeThroughputPercentage (Provisioned IOPS SSD volumes only)
      • Percentage of I/O operations per second (IOPS) delivered of the total IOPS provisioned.
    • VolumeConsumedReadWriteOps (Provisioned IOPS SSD volumes only)
      • Total amount of read and write operations (normalized to 256K capacity units) consumed in a specified period of time.
    • BurstBalance (gp2, st1, and sc1 volumes only)
      • Percentage of I/O credits (for gp2) or throughput credits (for st1 and sc1) remaining in the burst bucket.
      • Data is reported only when the volume is active. If the baseline performance exceeds the maximum burst performance, credits are never spent and burst balance remains at 100%.

I/O Latency Metrics (Nitro Instances Only – Added Oct 2024)

  • VolumeReadLatency
    • The per-minute average read I/O latency for the EBS volume, in milliseconds.
  • VolumeWriteLatency
    • The per-minute average write I/O latency for the EBS volume, in milliseconds.
  • Available at 1-minute granularity at no additional charge for all EBS volumes attached to EC2 Nitro instances.
  • Helps identify if latency is a result of under-provisioned EBS volumes.

Performance Exceeded Check Metrics (Nitro Instances Only – Added Oct 2024)

  • VolumeIOPSExceededCheck
    • Reports whether an application consistently attempted to drive IOPS that exceeds the volume’s provisioned IOPS performance within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • VolumeThroughputExceededCheck
    • Reports whether an application consistently attempted to drive throughput that exceeds the volume’s provisioned throughput performance within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • Supported for all volume types except magnetic (standard) attached to Nitro instances.
  • Not supported with Multi-Attach enabled volumes.

Average Performance Metrics (Nitro Instances Only – Added Oct 2025)

  • VolumeAvgIOPS
    • The average read and write IOPS driven to the volume in a minute.
    • Returns zero if no operations were driven to the volume within the last minute.
  • VolumeAvgThroughput
    • The average read and write throughput (KiB/s) driven to the volume in a minute.
    • Returns zero if no operations were driven to the volume within the last minute.
  • Useful for tracking performance trends, detecting bottlenecks, and right-sizing provisioned performance.

Instance-Level EBS Metrics (AWS/EC2 Namespace – Nitro Instances)

  • InstanceEBSIOPSExceededCheck (Added Oct 2025)
    • Reports whether driven IOPS is exceeding the maximum EBS IOPS that the instance can support within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • InstanceEBSThroughputExceededCheck (Added Oct 2025)
    • Reports whether driven throughput is exceeding the maximum EBS throughput limits for the instance within the last minute.
    • Returns 0 (not exceeded) or 1 (exceeded).
  • EBSReadOps & EBSWriteOps
    • Completed read/write operations from all EBS volumes attached to the instance.
  • EBSIOBalance% & EBSByteBalance%
    • Percentage of I/O credits and throughput credits remaining for burst-capable instances.
    • Available for instances that burst to their maximum performance for 30 minutes at least once every 24 hours.

CloudWatch Agent – EBS Detailed Performance Statistics (Added Jun 2025)

  • The CloudWatch agent can collect NVMe-based detailed performance statistics from EBS volumes attached to Nitro instances.
  • Metrics include queue depth, number of operations, bytes sent and received, and time spent on read and write I/O operations.
  • Available at sub-minute granularity as custom metrics in CloudWatch.
  • Provides deeper visibility beyond standard CloudWatch metrics for performance-sensitive workloads.

Volume Status Checks Monitoring

EC2 EBS Volume Status Check Monitoring

  • Volume status checks are automated tests that run every 5 minutes and return a pass or fail status.
  • Volume check status
    • Ok – all the status checks passed
    • Impaired – if the status checks failed
    • Insufficient-Data – checks are still in progress
    • Warning – the I/O performance of the volume is below expectations
  • When EBS determines the volume’s data is potentially inconsistent, it disables the I/O to the EBS volume from the attached EC2 instance to prevent any data corruption. This leads to the status check to fail and the volume status being impaired. Amazon waits for the I/O to be enabled, giving you an opportunity to perform consistency checks.
  • If the auto disabling of I/O is not needed, it can be overridden by enabling the Auto-Enabled IO flag, which would make the EBS volume auto-available immediately after the impaired status.
  • Events would be fired for notification whenever the I/O for an EBS volume is disabled.
  • I/O performance status checks compare actual volume performance with the expected volume performance and alert if performing below expectations. Applicable to io1, io2, and gp3 volumes.
  • While initializing Provisioned IOPS (SSD) volumes that were restored from snapshots, the performance of the volume may drop below 50 percent of its expected level, which causes the volume to display a warning state in the I/O Performance status check. This is expected and can be ignored.

EC2 EBS Volume Status

Attached EBS Status Checks (Added Aug 2024)

  • Amazon EC2 now includes a third type of status check — Attached EBS Status Check — that monitors whether the EBS volumes attached to an instance are reachable and can complete I/O operations.
  • The CloudWatch metric StatusCheckFailed_AttachedEBS reports a binary value:
    • 0 – All attached EBS volumes are reachable and can complete I/O.
    • 1 – One or more attached EBS volumes are impaired and unable to complete I/O operations.
  • Available for Nitro-based EC2 instances.
  • Enables creating CloudWatch alarms to automatically detect and respond to EBS volume reachability issues at the instance level.
  • Three types of EC2 status checks now exist:
    • System status checks – monitor the AWS systems the instance runs on.
    • Instance status checks – monitor the instance’s software and network configuration.
    • Attached EBS status checks – monitor reachability of attached EBS volumes.

Volume Initialization Status Monitoring (Added Jul 2025)

  • EBS now provides visibility into volume initialization status for volumes created from snapshots.
  • Allows you to validate when all blocks have been downloaded and written to the volume, enabling fully provisioned performance.
  • Can be used to time application launches to align with volume initialization completion.
  • EBS also supports Provisioned Rate for Volume Initialization (Added May 2025) that allows specifying a volume initialization rate between 100-300 MiB/s for faster initialization of snapshot-restored volumes.
  • EventBridge events are published for volume initialization state changes.

Volume Events Monitoring

  • EBS sends events to Amazon EventBridge for volume status changes and actions performed on volumes and snapshots.
  • Each event includes a start time that indicates the time at which the event occurred and a duration that indicates how long I/O for the volume was disabled.
  • Events description can be:
    • Awaiting Action: Enable IO – Volume data is potentially inconsistent, I/O is disabled.
    • IO Enabled – I/O operations were explicitly enabled for this volume.
    • IO Auto-Enabled – I/O operations were automatically enabled on this volume after an event.
    • Normal – For io1, io2, and gp3 volumes only. Volume performance is as expected.
    • Degraded – For io1, io2, and gp3 volumes only. Volume performance is below expectations.
    • Severely Degraded or Stalled – Volume performance significantly impacted.
  • EventBridge rules can trigger programmatic actions in response to these events (e.g., send notifications, invoke Lambda functions).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has configured CloudWatch monitoring on an EBS backed EC2 instance. If the user has not attached any additional device, which of the below mentioned metrics will always show a 0 value?
    1. DiskReadBytes
    2. NetworkIn
    3. NetworkOut
    4. CPUUtilization
  2. What does it mean if you have zero IOPS and a non-empty I/O queue for all EBS volumes attached to a running EC2 instance?
    1. The I/O queue is buffer flushing.
    2. Your EBS disk head(s) is/are seeking magnetic stripes.
    3. The EBS volume is unavailable. (EBS volumes are unavailable when all of the attached volumes perform zero read write IO, with pending IO in the queue. Refer link)
    4. You need to re-mount the EBS volume in the OS.
  3. While performing the volume status checks, if the status is insufficient-data, what does it mean?
    1. checks may still be in progress on the volume
    2. check has passed
    3. check has failed
  4. An application running on an EC2 instance with an io2 EBS volume is experiencing intermittent latency spikes. Which NEW CloudWatch metrics should be used to identify if the volume is under-provisioned? (Choose 2)
    1. VolumeReadLatency and VolumeWriteLatency
    2. VolumeQueueLength
    3. VolumeIOPSExceededCheck
    4. VolumeIdleTime
    5. VolumeTotalReadTime
  5. A company wants to monitor whether EBS volume performance bottlenecks are caused by the volume limits or the EC2 instance limits. Which combination of metrics should be used?
    1. VolumeReadOps and VolumeWriteOps
    2. BurstBalance and VolumeQueueLength
    3. VolumeIOPSExceededCheck (volume-level) and InstanceEBSIOPSExceededCheck (instance-level)
    4. EBSIOBalance% and VolumeThroughputPercentage
  6. After the August 2024 update, how many types of EC2 status checks are available?
    1. One – System status check
    2. Two – System and Instance status checks
    3. Three – System, Instance, and Attached EBS status checks
    4. Four – System, Instance, EBS Volume, and Network status checks

References

AWS EBS Performance

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS EBS Performance Tips

  • EBS Performance depends on several factors including I/O characteristics, instances and volumes configuration and can be improved using Provisioned IOPS (io2 Block Express), EBS-Optimized instances, proper volume type selection, and RAID configuration.

📢 Key Updates (2025-2026)

  • gp3 volumes enhanced (Sept 2025) – Now support up to 64 TiB size (4x increase), 80,000 IOPS (5x increase), and 2,000 MiB/s throughput (2x increase).
  • io2 Block Express – Delivers up to 256,000 IOPS, 4,000 MB/s throughput, 64 TiB capacity with sub-millisecond latency and 99.999% durability.
  • Instance Bandwidth Weighting – New feature allows shifting up to 25% of network bandwidth to EBS for I/O-intensive workloads.
  • io1 → io2 migration recommended – AWS recommends upgrading io1 to io2 for better performance and durability at the same cost.
  • gp2 → gp3 migration recommended – gp3 offers 20% lower cost with better baseline performance (3,000 IOPS, 125 MiB/s).
  • RAID 0 less necessary – With gp3’s increased limits (80,000 IOPS per volume), many workloads no longer require multi-volume striping.

EBS Volume Type Selection for Performance

  • Selecting the right volume type is the most impactful decision for EBS performance.
  • gp3 (General Purpose SSD) – Recommended default for most workloads.
    • Baseline: 3,000 IOPS and 125 MiB/s at any volume size (no burst credits needed)
    • Max: 80,000 IOPS and 2,000 MiB/s throughput
    • Size: up to 64 TiB
    • Performance is provisioned independently of storage capacity
    • 20% lower cost per GB than gp2
  • io2 Block Express (Provisioned IOPS SSD) – For mission-critical, latency-sensitive workloads.
    • Max: 256,000 IOPS, 4,000 MB/s throughput, 64 TiB capacity
    • Sub-millisecond latency (avg. under 500 microseconds)
    • 99.999% durability (vs 99.8-99.9% for gp3)
    • Up to 1,000 IOPS per GiB ratio
    • Multi-Attach support (up to 16 instances simultaneously)
    • Available on all Nitro-based EC2 instances
  • gp2 (Previous Generation General Purpose SSD) – Still available but migration to gp3 is recommended.
    • Max: 16,000 IOPS, 250 MB/s throughput, 16 TiB
    • IOPS scales with volume size at 3 IOPS/GiB
    • Burst credit model for volumes under 1 TiB
  • io1 (Previous Generation Provisioned IOPS SSD) – Migration to io2 Block Express is recommended.
    • Max: 64,000 IOPS, 1,000 MB/s throughput, 16 TiB
    • 50 IOPS per GiB ratio
    • 99.8-99.9% durability

EBS-Optimized or 10 Gigabit Network Instances

  • An EBS-Optimized instance uses an optimized configuration stack and provides additional, dedicated capacity for EBS I/O.
  • Optimization provides the best performance for the EBS volumes by minimizing contention between EBS I/O and other traffic from an instance.
  • EBS-Optimized instances deliver dedicated throughput to EBS depending on the instance type used.
  • All current-generation EC2 instance types are EBS-optimized by default at no additional cost.
  • Some previous-generation instance types support EBS-optimization as an optional feature with an additional hourly fee.
  • When attached to an EBS–optimized instance,
    • General Purpose (gp3) volumes are designed to deliver within 10% of their provisioned performance 99% of the time in a given year.
    • Provisioned IOPS (io2 Block Express) volumes are designed to deliver within 10% of their provisioned performance 99.9% of the time in a given year.
  • The maximum EBS throughput varies by instance type – for example, latest generation instances like C8gd/M8gd/R8gd provide up to 40 Gbps of EBS bandwidth.

Instance Bandwidth Weighting

  • EC2 instances on select Nitro-based instance types support configurable bandwidth weighting between EBS and VPC networking.
  • Using the ebs-1 bandwidth weighting option increases EBS bandwidth by up to 25%, which reduces VPC network bandwidth by the same amount.
  • This is beneficial for I/O-intensive workloads that require higher EBS throughput but have lower network requirements.
  • The total available baseline bandwidth for the instance remains the same; it only shifts the allocation.
  • Network PPS and EBS IOPS specifications are unaffected by bandwidth weighting changes.
  • Can be configured at launch time using launch templates or modified on running instances.

EBS Volume Initialization – Pre-warming

  • Empty EBS volumes receive their maximum performance the moment that they are available and DO NOT require initialization (pre-warming).
  • EBS volumes needed a pre-warming, previously, before being used to get maximum performance to start with. Pre-warming of the volume was possible by writing to the entire volume with 0 for new volumes or reading the entire volume for volumes from snapshots.
  • Storage blocks on volumes that were restored from snapshots must be initialized (pulled down from S3 and written to the volume) before the block can be accessed.
  • This preliminary action takes time and can cause a significant increase in the latency of an I/O operation the first time each block is accessed.
  • To avoid this initial performance hit in a production environment, the following options can be used:
    • Force the immediate initialization of the entire volume by using the dd or fio utilities to read from all of the blocks on a volume.
    • Enable Fast Snapshot Restore (FSR) on a snapshot to ensure that the EBS volumes created from it are fully-initialized at creation and instantly deliver all of their provisioned performance.
  • Fast Snapshot Restore (FSR) considerations:
    • FSR eliminates the latency of I/O operations on first access of snapshot-restored volumes.
    • Available in all commercial AWS regions (expanded to 6 additional regions in August 2024).
    • Not supported with AWS Outposts, Local Zones, and Wavelength Zones.
    • FSR is charged per AZ per hour per snapshot enabled, so cost should be considered.

Elastic Volumes

  • Elastic Volumes allows modifying EBS volume size, type, IOPS, and throughput without detaching the volume or stopping the instance.
  • Supported on all current-generation instances and several previous-generation instances (C1, C3, C4, G2, I2, M1, M3, M4, R3, R4).
  • Modifications include:
    • Increasing volume size (cannot decrease)
    • Changing volume type (e.g., gp2 → gp3, io1 → io2)
    • Adjusting provisioned IOPS and throughput (gp3, io1, io2)
  • Size increases take effect once the modification reaches the “optimizing” state (usually seconds).
  • The file system must be extended within the OS after a size increase.
  • A volume can only be modified once every 6 hours.

RAID Configuration

  • EBS volumes can be striped, if a single EBS volume does not meet the performance requirements.
  • Note: With gp3 volumes now supporting up to 80,000 IOPS and 2,000 MiB/s per volume, many workloads that previously required RAID 0 can now use a single volume, improving resiliency.
  • Striping volumes allows pushing tens of thousands of IOPS beyond single-volume limits.
  • EBS volumes are already replicated across multiple servers in an AZ for availability and durability, so AWS generally recommends striping for performance rather than durability.
  • For greater I/O performance than can be achieved with a single volume, RAID 0 can stripe multiple volumes together; for on-instance redundancy, RAID 1 can mirror two volumes together.
  • RAID 0 allows I/O distribution across all volumes in a stripe, allowing straight gains with each addition.
  • RAID 1 can be used for durability to mirror volumes, but in this case, it requires more EC2 to EBS bandwidth as the data is written to multiple volumes simultaneously and should be used with EBS–optimization.
  • EBS volume data is replicated across multiple servers in an AZ to prevent the loss of data from the failure of any single component.
  • AWS doesn’t recommend RAID 5 and 6 because the parity write operations of these modes consume the IOPS available for the volumes and can result in 20-30% fewer usable IOPS than RAID 0.
  • A 2-volume RAID 0 config can outperform a 4-volume RAID 6 that costs twice as much.
  • Durability consideration: Each additional volume in a RAID 0 stripe reduces effective durability (e.g., 4 gp3 volumes in RAID 0 = ~99.6% effective durability vs. 99.9% for a single volume). With increased gp3 limits, fewer volumes are needed for the same performance.

RAID Configuration

EBS Performance Best Practices Summary

  • Use gp3 as the default volume type – provides better baseline performance than gp2 at 20% lower cost.
  • Use io2 Block Express for critical databases – sub-millisecond latency, 99.999% durability, up to 256K IOPS.
  • Right-size your instance – ensure the instance’s EBS bandwidth limit is not the bottleneck (use CloudWatch EBSIOBalance% and EBSByteBalance% metrics).
  • Use EBS bandwidth weighting for I/O-intensive workloads with lower network needs.
  • Prefer single larger volumes over RAID 0 when gp3 limits (80,000 IOPS, 2,000 MiB/s) are sufficient – simpler and more durable.
  • Enable Fast Snapshot Restore for production volumes restored from snapshots to avoid first-access latency.
  • Monitor with CloudWatch – track VolumeReadOps, VolumeWriteOps, VolumeQueueLength, and BurstBalance (gp2) metrics.
  • Migrate legacy volumes – upgrade gp2 → gp3 and io1 → io2 using Elastic Volumes (no downtime required).

📖 Related: AWS EBS Volume Types – gp3, io2, st1, sc1 Comparison

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user is trying to pre-warm a blank EBS volume attached to a Linux instance. Which of the below mentioned steps should be performed by the user?
    1. There is no need to pre-warm an EBS volume (with latest update no pre-warming is needed)
    2. Contact AWS support to pre-warm (This used to be the case before, but pre warming is not necessary now)
    3. Unmount the volume before pre-warming
    4. Format the device
  2. A user has created an EBS volume of 10 GB and attached it to a running instance. The user is trying to access EBS for first time. Which of the below mentioned options is the correct statement with respect to a first time EBS access?
    1. The volume will show a size of 8 GB
    2. The volume will show a loss of the IOPS performance the first time (the volume needed to be wiped cleaned before for new volumes, however pre warming is not needed any more)
    3. The volume will be blank
    4. If the EBS is mounted it will ask the user to create a file system
  3. You are running a database on an EC2 instance, with the data stored on Elastic Block Store (EBS) for persistence At times throughout the day, you are seeing large variance in the response times of the database queries Looking into the instance with the isolate command you see a lot of wait time on the disk volume that the database’s data is stored on. What two ways can you improve the performance of the database’s storage while maintaining the current persistence of the data? Choose 2 answers
    1. Move to an SSD backed instance
    2. Move the database to an EBS-Optimized Instance
    3. Use Provisioned IOPs EBS
    4. Use the ephemeral storage on an m2.4xLarge Instance Instead
  4. You have launched an EC2 instance with four (4) 500 GB EBS Provisioned IOPS volumes attached. The EC2 Instance is EBS-Optimized and supports 500 Mbps throughput between EC2 and EBS. The two EBS volumes are configured as a single RAID 0 device, and each Provisioned IOPS volume is provisioned with 4,000 IOPS (4000 16KB reads or writes) for a total of 16,000 random IOPS on the instance. The EC2 Instance initially delivers the expected 16,000 IOPS random read and write performance. Sometime later in order to increase the total random I/O performance of the instance, you add an additional two 500 GB EBS Provisioned IOPS volumes to the RAID. Each volume is provisioned to 4,000 IOPS like the original four for a total of 24,000 IOPS on the EC2 instance Monitoring shows that the EC2 instance CPU utilization increased from 50% to 70%, but the total random IOPS measured at the instance level does not increase at all. What is the problem and a valid solution?
    1. Larger storage volumes support higher Provisioned IOPS rates: increase the provisioned volume storage of each of the 6 EBS volumes to 1TB.
    2. EBS-Optimized throughput limits the total IOPS that can be utilized use an EBS-Optimized instance that provides larger throughput. (EC2 Instance types have limit on max throughput and would require larger instance types to provide 24000 IOPS)
    3. Small block sizes cause performance degradation, limiting the I’O throughput, configure the instance device driver and file system to use 64KB blocks to increase throughput.
    4. RAID 0 only scales linearly to about 4 devices, use RAID 0 with 4 EBS Provisioned IOPS volumes but increase each Provisioned IOPS EBS volume to 6.000 IOPS.
    5. The standard EBS instance root volume limits the total IOPS rate, change the instant root volume to also be a 500GB 4,000 Provisioned IOPS volume
  5. A user has deployed an application on an EBS backed EC2 instance. For a better performance of application, it requires dedicated EC2 to EBS traffic. How can the user achieve this?
    1. Launch the EC2 instance as EBS provisioned with PIOPS EBS
    2. Launch the EC2 instance as EBS enhanced with PIOPS EBS
    3. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    4. Launch the EC2 instance as EBS optimized with PIOPS EBS
  6. A company is running an I/O-intensive database on a gp2 EBS volume and experiencing inconsistent performance. The DBA wants to achieve consistent 50,000 IOPS with the lowest cost. Which approach should they use?
    1. Use multiple gp2 volumes in RAID 0 configuration
    2. Migrate to a single gp3 volume and provision 50,000 IOPS
    3. Use an io2 Block Express volume with 50,000 provisioned IOPS
    4. Use multiple gp3 volumes in RAID 0 to aggregate IOPS

    (gp3 now supports up to 80,000 IOPS per volume at a lower cost than io2. For 50,000 IOPS without needing 99.999% durability, gp3 is the most cost-effective choice.)

  7. An application requires 256,000 IOPS with sub-millisecond latency for a critical Oracle database. Which EBS configuration provides the required performance?
    1. Four gp3 volumes with 64,000 IOPS each in RAID 0
    2. Multiple io1 volumes in RAID 0 configuration
    3. A single io2 Block Express volume with 256,000 provisioned IOPS on a Nitro-based instance
    4. Eight gp3 volumes with 32,000 IOPS each in RAID 0

    (io2 Block Express supports up to 256,000 IOPS per volume with sub-millisecond latency. A single volume approach is simpler and provides higher durability (99.999%) than RAID configurations.)

  8. A team has restored an EBS volume from a snapshot and needs to serve production traffic immediately with full provisioned IOPS. What should they do?
    1. Pre-warm the volume by reading all blocks using the dd utility
    2. Wait for 24 hours for background initialization to complete
    3. Enable Fast Snapshot Restore (FSR) on the snapshot before creating the volume
    4. Attach the volume to an EBS-optimized instance to speed up initialization

    (Fast Snapshot Restore ensures volumes created from the snapshot are fully initialized at creation, eliminating first-access latency. This must be enabled before creating the volume.)

  9. An EC2 instance is running an I/O-heavy analytics workload with low network traffic requirements. The team wants to maximize EBS throughput without changing the instance type. What feature can help?
    1. Enable Enhanced Networking on the instance
    2. Configure the instance with ebs-1 bandwidth weighting to increase EBS bandwidth by 25%
    3. Enable placement groups for the instance
    4. Attach additional network interfaces to the instance

    (Instance bandwidth weighting allows reallocating up to 25% of VPC network bandwidth to EBS, beneficial for workloads with high I/O but low networking needs.)

  10. A company wants to migrate their existing io1 volumes to a newer volume type with better durability and performance without application downtime. Which approach is recommended? (Select TWO)
    1. Create new io2 volumes from snapshots and switch
    2. Use Elastic Volumes to modify the volume type from io1 to io2 without detaching
    3. The migration provides 99.999% durability (up from 99.8-99.9%) at the same cost
    4. io1 to io2 migration requires stopping the instance
    5. io2 volumes cost 50% more than io1 for the same IOPS

    (Elastic Volumes supports online type change from io1 to io2. io2 provides higher durability and performance (1,000 IOPS/GiB vs 50 IOPS/GiB) at the same storage and IOPS pricing.)

AWS EBS Volume Types – gp3, io2, st1, sc1 Performance Comparison

EBS Volume Types
~ Last updated on : ~ jayendrapatil ~ 39 Comments

AWS EBS Volume Types

🆕 Major Update – September 2025

Amazon EBS gp3 volumes now support up to 64 TiB size, 80,000 IOPS, and 2,000 MiB/s throughput — a 4X, 5X, and 2X increase respectively over previous limits. Additionally, as of January 2026, Elastic Volumes now supports up to 4 modifications per 24-hour rolling window (previously limited by a 6-hour cooldown between modifications).

  • AWS provides the following EBS volume types, which differ in performance characteristics and price and can be tailored for storage performance and cost to the needs of the applications.
  • Solid state drives (SSD-backed) volumes optimized for transactional workloads involving frequent read/write operations with small I/O size, where the dominant performance attribute is IOPS
    • General Purpose SSD (gp3/gp2)
    • Provisioned IOPS SSD (io2 Block Express/io1)
  • Hard disk drives (HDD-backed) volumes optimized for large streaming workloads where throughput (measured in MiB/s) is a better performance measure than IOPS
    • Throughput Optimized HDD (st1)
    • Cold HDD (sc1)
    • Magnetic Volumes (standard) (Previous Generation)

EBS Volume Types Summary

EBS Volume Types

Solid state drives (SSD-backed) volumes

Solid state drives (SSD-backed) volumes

General Purpose SSD Volumes (gp3/gp2)

  • General Purpose SSD volumes offer cost-effective storage that is ideal for a broad range of workloads.
  • General Purpose SSD volumes deliver single-digit millisecond latencies.
  • General Purpose SSD (gp3) volumes (Recommended)
    • can range in size from 1 GiB to 64 TiB (increased from 16 TiB in September 2025).
    • deliver a consistent baseline rate of 3,000 IOPS and 125 MiB/s, included with the price of storage.
    • additional IOPS (up to 80,000) and throughput (up to 2,000 MiB/s) can be provisioned for an additional cost.
    • the maximum ratio of provisioned IOPS to provisioned volume size is 500 IOPS per GiB.
    • the maximum ratio of provisioned throughput to provisioned IOPS is .25 MiB/s per IOPS.
    • performance is provisioned independently from storage capacity, allowing even small volumes to achieve high performance.
    • provides up to 20% lower price per GB compared to gp2 volumes.
    • Note: On Outposts, gp3 volumes support sizes up to 16 TiB, IOPS up to 16,000, and throughput up to 1,000 MiB/s.
  • General Purpose SSD (gp2) volumes
    • can range in size from 1 GiB to 16 TiB.
    • has a maximum throughput of 250 MiB/s (depending on volume size).
    • provides a baseline performance of 3 IOPS/GiB.
    • provides the ability to burst to 3,000 IOPS for extended periods of time for volume size less than 1 TiB and up to a maximum of 16,000 IOPS (at 5,334 GiB).
    • If the volume performance is frequently limited to the baseline level (due to an empty I/O credit balance),
      • consider using a larger General Purpose SSD volume (with a higher baseline performance level) or
      • switching to a gp3 volume for independent IOPS/throughput provisioning or
      • switching to a Provisioned IOPS SSD volume for workloads that require sustained IOPS performance greater than 80,000 IOPS.
    • AWS recommends migrating gp2 volumes to gp3 for better performance and lower cost.

I/O Credits and Burst Performance (gp2 only)

  • I/O credits represent the available bandwidth that the General Purpose SSD (gp2) volume can use to burst large amounts of I/O when more than the baseline performance is needed.
  • General Purpose SSD (gp2) volume performance is governed by volume size, which dictates the baseline performance level of the volume for e.g. 100 GiB volume has a 300 IOPS @ 3 IOPS/GiB
  • General Purpose SSD (gp2) volume size also determines how quickly it accumulates I/O credits for e.g. 100 GiB with a performance of 300 IOPS can accumulate 180K IOPS/10 mins (300 * 60 * 10).
  • Larger volumes have higher baseline performance levels and accumulate I/O credits faster for e.g. 1 TiB has a baseline performance of 3000 IOPS
  • More credits the volume has for I/O, the more time it can burst beyond its baseline performance level and the better it performs when more performance is needed for e.g. 300 GiB volume with 180K I/O credit can burst @ 3000 IOPS for 1 minute (180K/3000)
  • Each volume receives an initial I/O credit balance of 5,400,000 I/O credits, which is enough to sustain the maximum burst performance of 3,000 IOPS for 30 minutes.
  • Initial credit balance is designed to provide a fast initial boot cycle for boot volumes and a good bootstrapping experience for other applications.
  • Each volume can accumulate I/O credits over a period of time which can be to burst to the required performance level, up to a max of 3,000 IOPS
  • Unused I/O credit cannot go beyond 54,00,000 I/O credits.
  • Note: gp3 volumes do NOT use the I/O credit/burst model — they provide consistent baseline performance of 3,000 IOPS regardless of volume size.

IOPS vs Volume size

  • Volumes till 1 TiB can burst up to 3000 IOPS over and above its baseline performance
  • Volumes larger than 1 TiB have a baseline performance that is already equal to or greater than the maximum burst performance, and their I/O credit balance never depletes.
  • Baseline performance cannot be beyond 16,000 IOPS for gp2 volumes and this limit is reached @ 5,334 GiB

IOPS vs Volume Size

Baseline Performance (gp2)

  • Formula – 3 IOPS i.e. GiB * 3
  • Calculation example
    • 1 GiB volume size = 3 IOPS (1 * 3 IOPS)
    • 250 GiB volume size = 750 IOPS (250* 3 IOPS)

Maximum burst duration @ 3000 IOPS (gp2)

  • How much time can 5400000 IO credit be sustained @ the burst performance of 3000 IOPS. Subtract the baseline performance from 3000 IOPS which would be contributed by the volume size
  • Formula – 5400000/(3000 – Baseline performance)
  • Calculation example
    • 1 GiB volume size @ 3000 IOPS with 5400000 the burst performance can be maintained for 5400000/(3000-3) = 1802 secs
    • 250 GiB volume size @ 3000 IOPS with 5400000 the burst performance can be maintained for 5400000/(3000-3*250) = 2400 secs

Time to fill the 5400000 I/O credit balance (gp2)

  • Formula – 5400000/Baseline performance
  • Calculation
    • 1 GiB volume size @ 3 IOPS would require 5400000/3 = 1800000 secs
    • 250 GiB volume size @ 750 IOPS would require 5400000/750 = 7200 secs

Provisioned IOPS SSD (io2 Block Express / io1) Volumes

  • are designed to meet the needs of I/O intensive workloads, particularly database workloads, that are sensitive to storage performance and consistency in random access I/O throughput.
  • IOPS rate can be specified when the volume is created, and EBS delivers within 10% of the provisioned IOPS performance 99.9% of the time over a given year.

io2 Block Express (Recommended)

  • offers the highest performance block storage among EBS volumes with an average latency of under 500 microseconds for 16KiB I/O operations.
  • can range in size from 4 GiB to 64 TiB.
  • supports up to 256,000 IOPS per volume (16 KiB I/O) — requires Nitro-based instances.
  • supports up to 4,000 MiB/s throughput per volume.
  • provides 99.999% durability (0.001% annual failure rate) — 100X higher durability than io1/gp2/gp3.
  • Ratio of IOPS provisioned to volume size is up to 1,000 IOPS per GiB — 20X higher than io1.
  • Available at the same price as io1.
  • Supports Multi-Attach — allows a single volume to be attached to up to 16 Nitro-based instances simultaneously.
  • Supports NVMe reservations for shared storage cluster coordination.
  • delivers better outlier latency compared to General Purpose volumes, reducing the frequency of IOs exceeding 800 microseconds by over 10X.
  • AWS recommends migrating io1 volumes to io2 Block Express for higher performance, durability, and IOPS/GiB ratio at no additional cost.

io1 (Previous Generation Provisioned IOPS)

  • can range in size from 4 GiB to 16 TiB.
  • have a throughput limit of up to 1,000 MiB/s (at 64,000 IOPS on Nitro instances).
  • can provision up to 64,000 IOPS per volume.
  • Ratio of IOPS provisioned to the volume size requested can be a maximum of 50 IOPS per GiB; e.g., a volume with 5,000 IOPS must be at least 100 GiB.
  • 99.8% – 99.9% durability (0.1% – 0.2% annual failure rate).
  • can be striped together in a RAID configuration for larger size and greater performance.
  • Note: AWS recommends migrating to io2 Block Express for better durability, performance, and IOPS/GiB ratio at the same price.

Hard disk drives (HDD-backed) volumes

Hard disk drives (HDD-backed) volumes

Throughput Optimized HDD (st1) Volumes

  • provide low-cost magnetic storage that defines performance in terms of throughput rather than IOPS.
  • is a good fit for large, sequential workloads such as EMR, ETL, data warehouses, and log processing.
  • do not support boot volumes.
  • can range in size from 125 GiB to 16 TiB.
  • are designed to support frequently accessed data.
  • maximum throughput of 500 MiB/s per volume.
  • maximum IOPS of 500 (1 MiB I/O).
  • uses a burst-bucket model for performance similar to gp2. Volume size determines the baseline throughput of the volume, which is the rate at which the volume accumulates throughput credits. Volume size also determines the burst throughput of your volume, which is the rate at which you can spend credits when they are available.

Cold HDD (sc1) Volumes

  • provide low-cost magnetic storage that defines performance in terms of throughput rather than IOPS.
  • With a lower throughput limit than st1, sc1 is a good fit ideal for large, sequential cold-data workloads.
  • ideal for infrequent access to data and are looking to save costs, sc1 provides inexpensive block storage.
  • do not support boot volumes.
  • can range in size from 125 GiB to 16 TiB.
  • maximum throughput of 250 MiB/s per volume.
  • maximum IOPS of 250 (1 MiB I/O).
  • though are similar to Throughput Optimized HDD (st1) volumes, are designed to support infrequently accessed data.
  • uses a burst-bucket model for performance similar to gp2. Volume size determines the baseline throughput of the volume, which is the rate at which the volume accumulates throughput credits. Volume size also determines the burst throughput of your volume, which is the rate at which you can spend credits when they are available.

Magnetic Volumes (standard) – Previous Generation

Magnetic volumes provide the lowest cost per gigabyte of all EBS volume types. Magnetic volumes are backed by magnetic drives and are ideal for workloads performing sequential reads, workloads where data is accessed infrequently, and scenarios where the lowest storage cost is important.

  • Magnetic volumes can range in size from 1 GiB to 1 TiB
  • These volumes deliver approximately 100 IOPS on average, with burst capability of up to hundreds of IOPS
  • Magnetic volumes can be striped together in a RAID configuration for larger size and greater performance.
  • Note: Magnetic (standard) is a previous generation volume type. AWS recommends using current generation volume types (gp3, io2, st1, sc1) for better performance and cost-effectiveness. For infrequent access cold data, consider sc1 instead.

EBS Volume Types (Previous Generation – Reference Only)

EBS Volume Types Comparison

EBS Elastic Volumes

  • Elastic Volumes allows you to dynamically increase capacity, tune performance, and change the type of live volumes with no downtime or performance impact.
  • (January 2026 Update) You can now modify a volume up to 4 times within a rolling 24-hour window — the previous 6-hour cooldown between modifications has been eliminated.
  • A new modification can be initiated as soon as the previous one completes.
  • Supported modifications include: increasing size, changing volume type, and adjusting provisioned performance (IOPS/throughput).
  • Note: Volume size can only be increased, not decreased. To reduce size, create a new smaller volume and migrate data.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are designing an enterprise data storage system. Your data management software system requires mountable disks and a real filesystem, so you cannot use S3 for storage. You need persistence, so you will be using AWS EBS Volumes for your system. The system needs as low-cost storage as possible, and access is not frequent or high throughput, and is mostly sequential reads. Which is the most appropriate EBS Volume Type for this scenario?
    1. gp1
    2. io1
    3. sc1 (Cold HDD sc1 volumes are designed for infrequently accessed data with lowest storage cost. Note: The original answer was “standard/Magnetic” but for modern deployments, sc1 is the recommended low-cost option for infrequent sequential access. Magnetic (standard) is previous generation.)
    4. gp2
  2. Which EBS volume type is best for high performance NoSQL cluster deployments?
    1. io1/io2 Block Express (Provisioned IOPS SSD volumes are best for: Critical business applications that require sustained IOPS performance, or more than 80,000 IOPS or 2,000 MiB/s of throughput per volume, like large database workloads such as MongoDB. io2 Block Express is now recommended over io1 for up to 256,000 IOPS.)
    2. gp1
    3. standard
    4. gp2
  3. Provisioned IOPS Costs: you are charged for the IOPS and storage whether or not you use them in a given month.
    1. FALSE
    2. TRUE
  4. A user is trying to create a PIOPS EBS volume with 8 GB size and 450 IOPS. Will AWS create the volume?
    1. Yes, since the ratio between EBS and IOPS is less than 50 for io1 (or less than 1000 for io2 Block Express)
    2. No, since the PIOPS and EBS size ratio is less than 50
    3. No, the EBS size is less than 10 GB
    4. Yes, since PIOPS is higher than 100
  5. A user has provisioned 2000 IOPS to the EBS volume. The application hosted on that EBS is experiencing fewer IOPS than provisioned. Which of the below mentioned options does not affect the IOPS of the volume?
    1. The application does not have enough IO for the volume
    2. Instance is EBS optimized
    3. The EC2 instance has 10 Gigabit Network connectivity
    4. Volume size is too large
  6. A user is trying to create a PIOPS EBS volume with 6000 IOPS and 100 GB size. AWS does not allow the user to create this volume. What is the possible root cause for this?
    1. The ratio between IOPS and the EBS volume is higher than 50 (For io1 volumes, maximum ratio is 50 IOPS per GiB. 6000/100 = 60, which exceeds 50. Note: For io2 Block Express, this would be allowed as the ratio limit is 1000 IOPS per GiB.)
    2. The maximum IOPS supported by EBS is 3000
    3. The ratio between IOPS and the EBS volume is lower than 100
    4. PIOPS is supported for EBS higher than 500 GB size
  7. A company needs a database storage solution that provides consistent sub-millisecond latency, 99.999% durability, and supports up to 256,000 IOPS. Which EBS volume type should they choose?
    1. gp3
    2. io1
    3. io2 Block Express (io2 Block Express delivers sub-millisecond latency, 99.999% durability, and supports up to 256,000 IOPS with 4,000 MiB/s throughput per volume.)
    4. st1
  8. A solutions architect needs to consolidate multiple striped gp3 volumes into a single volume for a containerized workload that requires 50,000 IOPS and 30 TiB of storage. Which volume type supports this requirement with a single volume?
    1. gp2
    2. gp3 (Since September 2025, gp3 supports up to 64 TiB size and 80,000 IOPS, allowing consolidation of previously striped volumes into a single gp3 volume.)
    3. io1
    4. st1
  9. What is the maximum IOPS-to-storage ratio for io2 Block Express volumes?
    1. 50 IOPS per GiB
    2. 500 IOPS per GiB
    3. 1,000 IOPS per GiB (io2 Block Express supports up to 1,000 IOPS per GiB, which is 20X higher than io1’s 50 IOPS per GiB ratio.)
    4. 100 IOPS per GiB
  10. Which of the following are advantages of io2 Block Express over io1? (Select THREE)
    1. 100X higher durability (99.999% vs 99.8-99.9%)
    2. 20X higher IOPS-to-storage ratio (1000 vs 50 IOPS/GiB)
    3. 4X higher maximum IOPS (256,000 vs 64,000)
    4. Lower cost per provisioned IOPS
    5. Support for HDD-backed storage

📖 Related: AWS S3 vs EBS vs EFS – Complete Storage Comparison Guide

References

AWS Storage Options – EBS & Instance Store

~ Last updated on : ~ jayendrapatil ~ 7 Comments

AWS Storage Options – EBS & Instance Store

  • Elastic Block Store – EBS and Instance Store provide block-level storage options for EC2 instances.

Elastic Block Store (EBS) volume

  • EBS provides durable block-level storage for use with EC2 instances
  • EBS volumes are off-instance, network-attached storage (NAS) that persists independently from the running life of a single EC2 instance.
  • EBS volume is attached to an instance and can be used as a physical hard drive, typically by formatting it with the file system of your choice and using the file I/O interface provided by the instance operating system.
  • EBS volume can be used to boot an EC2 instance (EBS-root AMIs only), and multiple EBS volumes can be attached to a single EC2 instance.
  • EBS volume can be attached to a single EC2 instance only at any point in time.
  • EBS Multi-Attach volume can be attached to multiple EC2 instances (up to 16 Nitro-based instances in the same AZ). Multi-Attach is supported on io1 and io2 Block Express volumes.
  • EBS provides the ability to take point-in-time snapshots, which are persisted in S3. These snapshots can be used to instantiate new EBS volumes and to protect data for long-term durability
  • EBS snapshots can be copied across AWS regions as well, making it easier to leverage multiple AWS regions for geographical expansion, data center migration, and disaster recovery
  • All EBS volume types are designed for 99.999% availability.

EBS Volume Types

  • Amazon EBS provides six volume types divided into two major categories:
    • SSD-backed storage for transactional workloads (databases, virtual desktops, boot volumes)
    • HDD-backed storage for throughput-intensive workloads (MapReduce, log processing)
  • General Purpose SSD (gp3) — baseline 3,000 IOPS and 125 MiB/s at any size; scales up to 64 TiB, 80,000 IOPS, and 2,000 MiB/s (enhanced Sep 2025). Performance provisioned independently of capacity. 99.8%-99.9% durability.
  • General Purpose SSD (gp2) — burstable performance tied to volume size (3 IOPS/GiB, up to 16,000 IOPS). Being superseded by gp3 for new workloads.
  • Provisioned IOPS SSD (io2 Block Express) — highest performance block storage: up to 256,000 IOPS, 4,000 MiB/s throughput, 64 TiB capacity, sub-millisecond latency. 99.999% durability (100X more durable than gp3). Supports Multi-Attach and NVMe reservations for shared storage fencing.
  • Provisioned IOPS SSD (io1) — previous generation Provisioned IOPS; up to 64,000 IOPS and 1,000 MiB/s. 99.8%-99.9% durability.
  • Throughput Optimized HDD (st1) — low-cost HDD for frequently accessed, throughput-intensive workloads; up to 500 MiB/s. Cannot be a boot volume.
  • Cold HDD (sc1) — lowest cost HDD for less frequently accessed workloads; up to 250 MiB/s. Cannot be a boot volume.
  • Magnetic (standard) — previous generation volume type with lower performance. AWS recommends migrating to current generation volume types.

Ideal Usage Patterns

  • EBS is meant for data that changes relatively frequently and requires long-term persistence.
  • EBS volume provides access to raw block-level storage and is particularly well-suited for use as the primary storage for a database or file system
  • EBS Provisioned IOPS volumes (io2 Block Express) are particularly well-suited for use with databases applications that require a high and consistent rate of random disk reads and writes, such as Oracle, SAP HANA, Microsoft SQL Server, and SAS Analytics.
  • gp3 volumes are ideal for a wide variety of workloads including virtual desktops, medium-sized databases, development/test environments, and boot volumes.
  • st1 volumes are ideal for big data, data warehouses, and log processing.
  • sc1 volumes are ideal for infrequently accessed cold data requiring lowest storage cost.

Anti-Patterns

  • Temporary Storage
    • EBS volume persists independent of the attached EC2 life cycle.
    • For temporary storage such as caches, buffers, queues, etc it is better to use local instance store volumes, SQS, or ElastiCache
  • Highly-durable storage
    • For highly durable storage, use S3 or Glacier which provides 99.999999999% (11 9’s) annual durability per object. EBS io2 Block Express offers 99.999% durability, while gp3/gp2/io1 offer 99.8%-99.9% durability.
  • Static data or web content
    • For static web content, where data infrequently changes, EBS with EC2 would require a web server to serve the pages.
    • S3 may represent a more cost-effective and scalable solution for storing this fixed information and is served directly out of S3.

EBS Performance

  • EBS provides multiple volume types that differ in performance characteristics and pricing, allowing you to tailor storage performance and cost to application needs.
  • EBS Volumes can be attached and striped across multiple similarly-provisioned EBS volumes using RAID 0 or logical volume manager software, thus aggregating available IOPS, total volume throughput, and total volume size.
  • gp3 volumes offer cost-effective storage with independently configurable IOPS and throughput. Baseline: 3,000 IOPS and 125 MiB/s; scalable up to 80,000 IOPS and 2,000 MiB/s (as of Sep 2025).
  • io2 Block Express volumes deliver predictable, high performance for I/O intensive workloads: up to 256,000 IOPS, 4,000 MiB/s throughput, with sub-millisecond latency. Supports 1,000 IOPS per GB provisioned.
  • As EBS volumes are network-attached devices, other network I/O performed by the instance, as well as the total load on the shared network, can affect individual EBS volume performance.
  • EBS-optimized instances deliver dedicated throughput between EC2 and EBS. Latest Nitro-based instances (e.g., C8gn, M8gn, R8gn in 48xlarge/metal sizes) support up to 120 Gbps EBS bandwidth and 480,000 IOPS (as of Apr 2026).
  • Each separate EBS volume can be configured independently with its own type and performance settings.

EBS Durability & Availability

  • EBS volumes are designed to be highly available and reliable.
  • EBS volume data is replicated across multiple servers in a single AZ to prevent the loss of data from the failure of any single component.
  • All EBS volume types are designed for 99.999% availability.
  • io2 Block Express volumes provide 99.999% durability (0.001% annual failure rate) — 100X more durable than other volume types.
  • gp3, gp2, and io1 volumes provide 99.8%-99.9% durability (0.1%-0.2% annual failure rate).
  • EBS snapshots are incremental, point-in-time backups, containing only the data blocks changed since the last snapshot.
  • Frequent snapshots are recommended to maximize both the durability and availability of EBS data.
  • EBS snapshots provide an easy-to-use disk clone or disk image mechanism for backup, sharing, and disaster recovery.

EBS Snapshots Archive

  • EBS Snapshots Archive offers up to 75% lower snapshot storage costs for snapshots stored for 90 days or longer that are rarely accessed.
  • Snapshots in the standard tier are incremental; when archived, they are converted to full snapshots and moved to the archive tier.
  • Archived snapshots can be restored to the standard tier when needed (restoration takes 24-72 hours).
  • AWS Backup now supports EBS Snapshots Archive in backup policies for automated lifecycle management.
  • EBS now displays full snapshot size information in Console and via DescribeSnapshots API (full-snapshot-size-in-bytes field, Feb 2025).

EBS Elastic Volumes

  • Elastic Volumes allows you to dynamically increase capacity, tune performance, and change the type of live volumes with no downtime or performance impact.
  • EBS volumes can be resized dynamically (increased only, cannot be reduced in size).
  • As of Jan 2026, EBS supports up to 4 Elastic Volumes modifications per volume within a rolling 24-hour window (previously limited to 1 modification per 6 hours).
  • Modifications include: increasing size, changing volume type, and adjusting provisioned performance (IOPS/throughput).

EBS Cost Model

  • EBS pricing varies by volume type:
    • gp3: charged per GB-month of provisioned storage, plus separately for provisioned IOPS (above 3,000) and throughput (above 125 MiB/s)
    • gp2: charged per GB-month of provisioned storage (IOPS included based on size)
    • io2/io1: charged per GB-month of provisioned storage and per Provisioned IOPS-month
    • st1/sc1: charged per GB-month of provisioned storage
  • EBS snapshots are charged per GB-month of data stored. Snapshots are incremental and compressed, so storage used is generally much less than volume size.
  • EBS Snapshots Archive tier costs up to 75% less than standard snapshot storage (minimum 90-day retention).
  • EBS snapshot copy is charged for data transferred between regions, plus standard snapshot charges in the destination region.
  • EBS volume storage capacity is allocated at creation time, and you are charged for allocated storage even if not fully used.

EBS Scalability and Elasticity

  • EBS volumes can easily and rapidly be provisioned and released to scale in and out with changing storage demands.
  • EBS volumes can be resized dynamically using Elastic Volumes (increase only, cannot be reduced).
  • Volume type and performance can be changed without detaching the volume or stopping the instance.
  • Up to 4 modifications are allowed per 24-hour rolling window.

Interfaces

  • AWS offers management APIs for EBS through REST-based APIs, AWS CLI, and SDKs, which can be used to create, delete, describe, attach, and detach EBS volumes, as well as to create, delete, and describe snapshots and copy snapshots across regions.
  • Amazon also offers the same capabilities through the AWS Management Console.
  • EBS Direct APIs allow you to read and write data directly to/from EBS snapshots without needing to attach them to an instance — useful for backup, disaster recovery, and data migration.

Instance Store Volumes

  • Instance Store volumes are also referred to as Ephemeral Storage.
  • Instance Store volumes provide temporary block-level storage and consist of a preconfigured and pre-attached block of disk storage on the same physical server as the EC2 instance.
  • Instance storage amount depends on the Instance type; larger instances provide both more and larger instance store volumes.
  • Modern instance store volumes use NVMe SSD storage on Nitro-based instances, delivering high random I/O performance with low latency.
  • Latest generation storage-optimized instances (2025-2026):
    • C8gd, M8gd, R8gd (Graviton4): up to 11.4 TB of NVMe SSD local storage, 3X more than previous generation
    • C8id, M8id, R8id (Intel Xeon 6): up to 22.8 TB of NVMe SSD local storage, 3X more than 6th-gen instances
  • Instance store volumes, unlike EBS volumes, cannot be detached or attached to another instance.
  • Data on instance store volumes persists only during the life of the associated EC2 instance — data is lost when the instance stops, terminates, or the underlying hardware fails.

Ideal Usage Patterns

  • EC2 local instance store volumes are fast, free (included in the price of the EC2 instance) “scratch volumes” best suited for storing temporary data that is continually changing, such as buffers, caches, scratch data, or data that is replicated for durability.
  • NVMe SSD-backed instances are ideally suited for many high performance database workloads. e.g., NoSQL databases like Cassandra, MongoDB, and real-time analytics.
  • High storage instances support much higher storage density per EC2 instance and are ideally suited for applications that benefit from high sequential I/O performance across very large datasets. e.g., data warehouses, Hadoop/Spark storage nodes, distributed file systems.
  • Machine learning training workloads that need fast local scratch storage for datasets and checkpoints.

Anti-Patterns

  • Persistent storage
    • For persistent virtual disk storage similar to a physical disk drive for files or other data that must persist longer than the lifetime of a single EC2 instance, EBS volumes or S3 are more appropriate.
  • Relational database storage
    • In most cases, relational databases require storage that persists beyond the lifetime of a single EC2 instance, making EBS volumes the natural choice.
  • Shared storage
    • Instance store volumes are dedicated to a single EC2 instance, and cannot be shared with other systems or users.
    • If you need storage that can be detached from one instance and attached to a different instance, or if you need the ability to share data easily, EBS volumes, EFS, or S3 are better choices.
  • Snapshots
    • If you need the convenience, long-term durability, availability, and shareability of point-in-time disk snapshots, EBS volumes are a better choice.

Instance Store Performance

  • EC2 instance virtual machine and the local instance store volumes are located on the same physical server, providing very fast access with low latency, particularly for sequential access.
  • Because the bandwidth to the disks is not limited by the network, aggregate sequential throughput for multiple instance volumes can be higher than for the same number of EBS volumes.
  • NVMe SSD instance store volumes provide from tens of thousands to hundreds of thousands of low-latency, random 4 KB IOPS.
  • To further increase aggregate IOPS or improve sequential disk throughput, multiple instance store volumes can be grouped together using RAID 0 (disk striping) software.
  • High storage instances are capable of delivering multi-GB/sec sequential read and write performance.
  • AWS provides detailed NVMe statistics for instance store volumes to help optimize latency-sensitive workloads (available 2025).

Instance Store Durability and Availability

  • EC2 local instance store volumes are NOT intended to be used as durable disk storage.
  • Data persists only during the life of the associated EC2 instance.
  • Data is lost when: instance is stopped or terminated, underlying disk drive fails, or instance hibernates.
  • Always replicate important data to EBS, S3, or other durable storage.

Cost Model

  • Cost of the EC2 instance includes any local instance store volumes if the instance type provides them.
  • While there is no additional charge for data storage on local instance store volumes, data transferred to and from instance store volumes from other AZs or outside an EC2 region may incur data transfer charges.
  • Additional charges apply for any persistent storage used (S3, Glacier, EBS volumes, EBS snapshots).

Scalability and Elasticity

  • Local instance store volumes are tied to a particular EC2 instance and are fixed in number and size for a given EC2 instance type.
  • Scalability and elasticity of this storage are tied to the number of EC2 instances running.

Interfaces

  • Instance store volumes are specified using the block device mapping feature of the EC2 API and the AWS Management Console.
  • To the EC2 instance, an instance store volume appears just like a local disk drive. Use the native file system I/O interfaces of the chosen operating system to read and write data.
  • On Nitro-based instances, instance store volumes are exposed as NVMe block devices.

EBS vs Instance Store Comparison

Feature EBS Instance Store
Persistence Persists independently of instance Ephemeral — lost on stop/terminate
Network Network-attached Physically attached (local)
Snapshots Supported (incremental, cross-region) Not supported
Boot volume Yes No (legacy only)
Resize Yes (Elastic Volumes) Fixed per instance type
Max IOPS 256,000 (io2 Block Express) Millions (NVMe, instance-dependent)
Max size per volume 64 TiB Instance-type dependent (up to 22.8 TB)
Durability 99.999% (io2) / 99.8-99.9% (others) None — ephemeral
Multi-Attach Yes (io1/io2, up to 16 instances) No
Cost Pay per provisioned GB + IOPS/throughput Included in instance price

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following provides the fastest storage medium?
    1. Amazon S3
    2. Amazon EBS using Provisioned IOPS (PIOPS)
    3. SSD Instance (ephemeral) store (SSD Instance Storage provides hundreds of thousands of IOPS on some instance types, much faster than any network-attached storage)
    4. AWS Storage Gateway
  2. A company needs a block storage volume with the highest durability for a mission-critical Oracle database. Which EBS volume type should they choose?
    1. gp3
    2. gp2
    3. io2 Block Express (io2 Block Express provides 99.999% durability — 100X more durable than other volume types, designed for mission-critical applications)
    4. io1
  3. An application requires a single EBS volume with 50,000 IOPS. Which volume type(s) can meet this requirement? (Choose TWO)
    1. gp3 (gp3 now supports up to 80,000 IOPS as of Sep 2025)
    2. gp2 (gp2 max is 16,000 IOPS)
    3. io2 Block Express (io2 Block Express supports up to 256,000 IOPS)
    4. st1 (st1 is HDD-backed and optimized for throughput, not IOPS)
  4. Which statements about EBS Elastic Volumes are correct? (Choose TWO)
    1. You can increase volume size without detaching or stopping the instance
    2. You can decrease volume size dynamically (Volume size can only be increased, not decreased)
    3. Up to 4 modifications are allowed per volume within a 24-hour rolling window
    4. Volume modifications require a reboot to take effect (No downtime or reboot required)
  5. A company wants to reduce costs for EBS snapshots that are retained for compliance for 2 years but rarely accessed. What should they use?
    1. S3 Glacier Deep Archive
    2. EBS Snapshots Archive (EBS Snapshots Archive provides up to 75% lower costs for snapshots stored 90+ days that are rarely accessed)
    3. Delete the snapshots and use AMIs instead
    4. Use sc1 volumes instead of snapshots
  6. Which of the following is true about EC2 Instance Store volumes? (Choose TWO)
    1. Data is lost when the instance is stopped or terminated
    2. Instance store volumes can be detached and attached to another instance (Instance store volumes cannot be detached)
    3. Instance store volumes provide lower latency than EBS because they are physically attached
    4. Instance store volumes support point-in-time snapshots (Snapshots are not supported for instance store)
  7. A company needs to attach a single high-performance EBS volume to 8 EC2 instances in the same AZ for a clustered application. Which solution is appropriate?
    1. Use gp3 with Multi-Attach (Multi-Attach is not supported on gp3)
    2. Use io2 Block Express with Multi-Attach (io2 Block Express supports Multi-Attach to up to 16 Nitro-based instances in the same AZ with NVMe reservations for I/O fencing)
    3. Use instance store volumes shared via NFS
    4. Use st1 with Multi-Attach (Multi-Attach is not supported on HDD volumes)

References

AWS Elastic Block Store Storage – EBS

~ Last updated on : ~ jayendrapatil ~ 61 Comments

EC2 Elastic Block Store – EBS

  • Elastic Block Store – EBS provides highly available, reliable, durable, block-level storage volumes that can be attached to an EC2 instance.
  • EBS as a primary storage device is recommended for data that requires frequent and granular updates e.g. running a database or filesystem.
  • An EBS volume
    • behaves like a raw, unformatted, external block device that can be attached to a single EC2 instance at a time (except with Multi-Attach enabled io1/io2 volumes).
    • persists independently from the running life of an instance.
    • is Zonal and can be attached to any instance within the same Availability Zone and can be used like any other physical hard drive.
    • is particularly well-suited for use as the primary storage for file systems, databases, or any applications that require fine granular updates and access to raw, unformatted, block-level storage.
    • is designed for 99.999% availability and offers 99.999% durability for io2 Block Express volumes (0.001% annual failure rate).

Elastic Block Storage Features

  • EBS Volumes are created in a specific Availability Zone and can be attached to any instance in that same AZ.
  • Volumes can be backed up by creating a snapshot of the volume, which is stored in S3.
  • Volumes can be created from a snapshot that can be attached to another instance within the same region.
  • Volumes can be made available outside of the AZ by creating and restoring the snapshot to a new volume anywhere in that region.
  • Snapshots can also be copied to other regions and then restored to new volumes, making it easier to leverage multiple AWS regions for geographical expansion, data center migration, and disaster recovery.
  • Volumes allow encryption using the EBS encryption feature. All data stored at rest, disk I/O, and snapshots created from the volume are encrypted.
  • Encryption occurs on the EC2 instance, providing encryption of data-in-transit from EC2 to the EBS volume.
  • Elastic Volumes help easily adapt the volumes as the needs of the applications change. Elastic Volumes allow you to dynamically increase capacity, tune performance, and change the type of any new or existing current generation volume with no downtime or performance impact.
  • You can dynamically increase size, modify the provisioned IOPS capacity, and change volume type on live production volumes.
  • EBS now supports up to four Elastic Volumes modifications per volume within a rolling 24-hour window (previously required a 6-hour cooldown between modifications). A new modification can be initiated as soon as the previous one completes.
  • General Purpose SSD (gp3) volumes support up to 80,000 IOPS and 2,000 MiB/s of throughput with up to 64 TiB capacity (increased from 16,000 IOPS, 1,000 MiB/s, and 16 TiB in September 2025).
  • Provisioned IOPS SSD (io2 Block Express) volumes support up to 256,000 IOPS and 4,000 MB/s of throughput with up to 64 TiB capacity and sub-millisecond latency.

EBS Benefits

  • Data Availability
    • Data is automatically replicated in an Availability Zone to prevent data loss due to the failure of any single hardware component.
    • io2 Block Express volumes are designed for 99.999% durability (0.001% annual failure rate), while other volume types provide 99.8%-99.9% durability.
  • Data Persistence
    • persists independently of the running life of an EC2 instance
    • persists when an instance is stopped, started, or rebooted
    • Root volume is deleted, by default, on Instance termination but the behaviour can be changed using the DeleteOnTermination flag
    • All attached volumes persist, by default, on instance termination
  • Data Encryption
    • can be encrypted by the EBS encryption feature
    • uses 256-bit AES-256 and an Amazon-managed key infrastructure.
    • Encryption occurs on the server that hosts the EC2 instance, providing encryption of data-in-transit from the EC2 instance to EBS storage
    • Snapshots of encrypted EBS volumes are automatically encrypted.
    • EBS encryption by default can be enabled at the account level per region, so all new volumes created are automatically encrypted.
  • Snapshots
    • provides the ability to create snapshots (backups) of any EBS volume and write a copy of the data in the volume to S3, where it is stored redundantly in multiple Availability Zones.
    • can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones or Regions.
    • are incremental backups and store only the data that was changed from the time the last snapshot was taken.
    • Snapshot size can probably be smaller than the volume size as the data is compressed before being saved to S3.
    • Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.

EBS Volume Types

Refer blog post @ EBS Volume Types

EBS Volume

EBS Volume Creation

  • Creating New volumes
    • Completely new from console or command line tools and can then be attached to an EC2 instance in the same Availability Zone.
  • Restore volume from Snapshots
    • Volumes can also be restored from previously created snapshots
    • New volumes created from existing snapshots are loaded lazily in the background.
    • There is no need to wait for all of the data to transfer from S3 to the volume before the attached instance can start accessing the volume and all its data.
    • If the instance accesses the data that hasn’t yet been loaded, the volume immediately downloads the requested data from S3, and continues loading the rest of the data in the background.
    • Volumes restored from encrypted snapshots are always encrypted, by default.
    • Provisioned Rate for Volume Initialization (May 2025) allows specifying an initialization rate (up to 300 MiB/s) to accelerate the transfer of snapshot data to new volumes, ensuring fully performant volumes within a predictable time frame.
  • Volumes can be created and attached to a running EC2 instance by specifying a block device mapping

EBS Volume Clones (Oct 2025)

  • EBS Volume Clones allow creating instant point-in-time copies of EBS volumes within the same Availability Zone with a single API call.
  • Cloned volumes are available within seconds and provide immediate access to data with single-digit millisecond latency.
  • Data is copied lazily in the background without impacting the performance of the source volume.
  • Eliminates the previous multi-step process of taking snapshots and creating volumes from them for same-AZ copies.
  • Useful for quickly setting up test/development environments with production data.

EBS Volume Detachment

  • EBS volumes can be detached from an instance explicitly or by terminating the instance.
  • EBS root volumes can be detached by stopping the instance.
  • EBS data volumes, attached to a running instance, can be detached by unmounting the volume from the instance first.
  • If the volume is detached without being unmounted, it might result in the volume being stuck in a busy state and could possibly damage the file system or the data it contains.
  • EBS volume can be force detached from an instance, using the Force Detach option, but it might lead to data loss or a corrupted file system as the instance does not get an opportunity to flush file system caches or file system metadata.
  • Charges are still incurred for the volume after its detachment

EBS Volume Deletion

  • EBS volume deletion would wipe out its data and the volume can’t be attached to any instance. However, it can be backed up before deletion using EBS snapshots
  • Recycle Bin for EBS Volumes (Nov 2025) allows setting retention periods for deleted volumes. Deleted volumes can be recovered within the retention period with all attributes (tags, permissions, encryption status) preserved.

EBS Volume Resize

  • EBS Elastic Volumes can be modified to increase the volume size, change the volume type, or adjust the performance of your EBS volumes.
  • If the instance supports Elastic Volumes, changes can be performed without detaching the volume or restarting the instance.
  • Volumes can be modified up to four times within a rolling 24-hour window (enhanced Jan 2026, previously limited to one modification with a 6-hour cooldown).

EBS Volume Snapshots

Refer blog post @ EBS Snapshot

EBS Snapshot Lock

  • EBS Snapshot Lock (Nov 2023) enables locking snapshots to protect them from inadvertent or malicious deletions for compliance and data retention requirements.
  • Snapshots can be locked for a duration ranging from 1 day to approximately 100 years.
  • Supports WORM (Write Once Read Many) compliance requirements.
  • Locked snapshots cannot be deleted until the lock duration expires.
  • No additional cost for locking snapshots.

EBS Snapshots Archive

  • EBS Snapshots Archive provides a low-cost storage tier for long-term retention of rarely-accessed snapshots.
  • Up to 75% lower cost compared to standard snapshot storage.
  • Archived snapshots can be restored when needed (restoration takes 24-72 hours).
  • Amazon Data Lifecycle Manager can automate archival and retention policies.

Recycle Bin for Snapshots

  • Recycle Bin enables restoration of accidentally deleted EBS Snapshots and EBS-backed AMIs.
  • Supports customized delete protection with exclusion tags (Nov 2024) to exclude non-critical resources.
  • Supports CloudFormation for managing Recycle Bin rules (Nov 2024).
  • Supports IPv6 endpoints (Dec 2024).
  • Now also supports EBS Volumes (Nov 2025) in addition to snapshots and AMIs.

EBS Encryption

  • EBS volumes can be created and attached to a supported instance type and support the following types of data
    • Data at rest
    • All disk I/O i.e All data moving between the volume and the instance
    • All snapshots created from the volume
    • All volumes created from those snapshots
  • Encryption occurs on the servers that host EC2 instances, providing encryption of data-in-transit from EC2 instances to EBS storage.
  • EBS encryption is supported with all EBS volume types (gp3, gp2, io2, io1, st1, and sc1), and has the same IOPS performance on encrypted volumes as with unencrypted volumes, with a minimal effect on latency
  • EBS encryption is available on all current generation instance types and select previous generation types.
  • Volumes created from encrypted snapshots and snapshots of encrypted volumes are automatically encrypted using the same encryption key.
  • EBS encryption uses AWS KMS keys (formerly called customer master keys/CMK) when creating encrypted volumes and any snapshots created from the encrypted volumes.
  • EBS volumes can be encrypted using either
    • the AWS managed key (aws/ebs) created for you automatically in each region.
    • a customer managed key that you created separately using AWS KMS, giving you more flexibility, including the ability to create, rotate, disable, define access controls, and audit the encryption keys used to protect your data.
  • Encryption by default can be enabled at the account level per region. When enabled, all new EBS volumes and snapshot copies are automatically encrypted.
  • Public or shared snapshots of encrypted volumes are not supported, because other accounts would be able to decrypt your data and needs to be migrated to an unencrypted status before sharing.
  • Existing unencrypted volumes cannot be encrypted directly, but can be migrated by
    • Option 1
      • create an unencrypted snapshot from the volume
      • create an encrypted copy of an unencrypted snapshot
      • create an encrypted volume from the encrypted snapshot
    • Option 2
      • create an unencrypted snapshot from the volume
      • create an encrypted volume from an unencrypted snapshot (selecting encryption during volume creation)
  • An encrypted snapshot can be created from an unencrypted snapshot by creating an encrypted copy of the unencrypted snapshot.
  • Unencrypted volume cannot be created from an encrypted volume directly but needs to be migrated

EBS Multi-Attach

  • EBS Multi-Attach allows attaching a single Provisioned IOPS SSD (io1 or io2) volume to up to 16 Nitro System-based EC2 instances within the same Availability Zone.
  • All attached instances have full read and write access to the shared volume.
  • io2 Block Express volumes support NVMe reservations for I/O fencing, enabling shared storage with proper coordination between instances (enabled by default for io2 volumes created after Sept 18, 2023).
  • Multi-Attach can be enabled for io2 volumes after creation (if not attached to any instances). For io1, it must be enabled at creation time.
  • Requires a cluster-aware file system (not standard XFS or EXT4) for data resiliency in production.

Refer blog Post @ EBS Multi-Attach

EBS Performance

Refer blog Post @ EBS Performance

EBS vs Instance Store

Refer blog post @ EBS vs Instance Store

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. _____ is a durable, block-level storage volume that you can attach to a single, running Amazon EC2 instance.
    1. Amazon S3
    2. Amazon EBS
    3. None of these
    4. All of these
  2. Which Amazon storage do you think is the best for my database-style applications that frequently encounter many random reads and writes across the dataset?
    1. None of these.
    2. Amazon Instance Storage
    3. Any of these
    4. Amazon EBS
  3. What does Amazon EBS stand for?
    1. Elastic Block Storage
    2. Elastic Business Server
    3. Elastic Blade Server
    4. Elastic Block Store
  4. Which Amazon Storage behaves like raw, unformatted, external block devices that you can attach to your instances?
    1. None of these.
    2. Amazon Instance Storage
    3. Amazon EBS
    4. All of these
  5. A user has created numerous EBS volumes. What is the general limit for each AWS account for the maximum number of EBS volumes that can be created?
    1. 10000
    2. 5000
    3. 100
    4. 1000
  6. Select the correct set of steps for exposing the snapshot only to specific AWS accounts
    1. Select Public for all the accounts and check mark those accounts with whom you want to expose the snapshots and click save.
    2. Select Private and enter the IDs of those AWS accounts, and click Save.
    3. Select Public, enter the IDs of those AWS accounts, and click Save.
    4. Select Public, mark the IDs of those AWS accounts as private, and click Save.
  7. If an Amazon EBS volume is the root device of an instance, can I detach it without stopping the instance?
    1. Yes but only if Windows instance
    2. No
    3. Yes
    4. Yes but only if a Linux instance
  8. Can we attach an EBS volume to more than one EC2 instance at the same time?
    1. Yes, with Multi-Attach enabled io1/io2 volumes to up to 16 Nitro-based instances in the same AZ
    2. No
    3. Only EC2-optimized EBS volumes.
    4. Only in read mode.

    Note: This answer has been updated. EBS Multi-Attach (available since 2020) allows io1/io2 volumes to be attached to up to 16 Nitro-based instances simultaneously within the same AZ.

  9. Do the Amazon EBS volumes persist independently from the running life of an Amazon EC2 instance?
    1. Only if instructed to when created
    2. Yes
    3. No
  10. Can I delete a snapshot of the root device of an EBS volume used by a registered AMI?
    1. Only via API
    2. Only via Console
    3. Yes
    4. No
  11. By default, EBS volumes that are created and attached to an instance at launch are deleted when that instance is terminated. You can modify this behavior by changing the value of the flag_____ to false when you launch the instance
    1. DeleteOnTermination
    2. RemoveOnDeletion
    3. RemoveOnTermination
    4. TerminateOnDeletion
  12. Your company policies require encryption of sensitive data at rest. You are considering the possible options for protecting data while storing it at rest on an EBS data volume, attached to an EC2 instance. Which of these options would allow you to encrypt your data at rest? (Choose 3 answers)
    1. Implement third party volume encryption tools
    2. Do nothing as EBS volumes are encrypted by default
    3. Encrypt data inside your applications before storing it on EBS
    4. Encrypt data using native data encryption drivers at the file system level
    5. Implement SSL/TLS for all services running on the server
  13. Which of the following are true regarding encrypted Amazon Elastic Block Store (EBS) volumes? Choose 2 answers
    1. Supported on all Amazon EBS volume types
    2. Snapshots are automatically encrypted
    3. Available to all instance types
    4. Existing volumes can be encrypted
    5. Shared volumes can be encrypted
  14. How can you secure data at rest on an EBS volume?
    1. Encrypt the volume using the S3 server-side encryption service
    2. Attach the volume to an instance using EC2’s SSL interface.
    3. Create an IAM policy that restricts read and write access to the volume.
    4. Write the data randomly instead of sequentially.
    5. Use an encrypted file system on top of the EBS volume
  15. A user has deployed an application on an EBS backed EC2 instance. For a better performance of application, it requires dedicated EC2 to EBS traffic. How can the user achieve this?
    1. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    2. Launch the EC2 instance as EBS enhanced with PIOPS EBS
    3. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    4. Launch the EC2 instance as EBS optimized with PIOPS EBS
  16. A user is trying to launch an EBS backed EC2 instance under free usage. The user wants to achieve encryption of the EBS volume. How can the user encrypt the data at rest?
    1. Use AWS EBS encryption to encrypt the data at rest (EBS encryption is supported on all current generation instance types including t2/t3 micro)
    2. User cannot use EBS encryption and has to encrypt the data manually or using a third party tool
    3. The user has to select the encryption enabled flag while launching the EC2 instance
    4. Encryption of volume is not available as a part of the free usage tier
  17. A user is planning to schedule a backup for an EBS volume. The user wants security of the snapshot data. How can the user achieve data encryption with a snapshot?
    1. Use encrypted EBS volumes so that the snapshot will be encrypted by AWS
    2. While creating a snapshot select the snapshot with encryption
    3. By default the snapshot is encrypted by AWS
    4. Enable server side encryption for the snapshot using S3
  18. A user has launched an EBS backed EC2 instance. The user has rebooted the instance. Which of the below mentioned statements is not true with respect to the reboot action?
    1. The private and public address remains the same
    2. The Elastic IP remains associated with the instance
    3. The volume is preserved
    4. The instance runs on a new host computer
  19. A user has launched an EBS backed EC2 instance. What will be the difference while performing the restart or stop/start options on that instance?
    1. For restart it does not charge for an extra hour, while every stop/start it will be charged as a separate hour
    2. Every restart is charged by AWS as a separate hour, while multiple start/stop actions during a single hour will be counted as a single hour
    3. For every restart or start/stop it will be charged as a separate hour
    4. For restart it charges extra only once, while for every stop/start it will be charged as a separate hour
  20. A user has launched an EBS backed instance. The user started the instance at 9 AM in the morning. Between 9 AM to 10 AM, the user is testing some script. Thus, he stopped the instance twice and restarted it. In the same hour the user rebooted the instance once. For how many instance hours will AWS charge the user?
    1. 3 hours
    2. 4 hours
    3. 2 hours
    4. 1 hour
  21. You are running a database on an EC2 instance, with the data stored on Elastic Block Store (EBS) for persistence At times throughout the day, you are seeing large variance in the response times of the database queries Looking into the instance with the isolate command you see a lot of wait time on the disk volume that the database’s data is stored on. What two ways can you improve the performance of the database’s storage while maintaining the current persistence of the data? Choose 2 answers
    1. Move to an SSD backed instance
    2. Move the database to an EBS-Optimized Instance
    3. Use Provisioned IOPs EBS
    4. Use the ephemeral storage on an m2.4xLarge Instance Instead
  22. An organization wants to move to Cloud. They are looking for a secure encrypted database storage option. Which of the below mentioned AWS functionalities helps them to achieve this?
    1. AWS MFA with EBS
    2. AWS EBS encryption
    3. Multi-tier encryption with Redshift
    4. AWS S3 server-side storage
  23. A user has stored data on an encrypted EBS volume. The user wants to share the data with his friend’s AWS account. How can user achieve this?
    1. Create an AMI from the volume and share the AMI
    2. Copy the data to an unencrypted volume and then share
    3. Take a snapshot and share the snapshot with a friend
    4. If both the accounts are using the same encryption key then the user can share the volume directly
  24. A user is using an EBS backed instance. Which of the below mentioned statements is true?
    1. The user will be charged for volume and instance only when the instance is running
    2. The user will be charged for the volume even if the instance is stopped
    3. The user will be charged only for the instance running cost
    4. The user will not be charged for the volume if the instance is stopped
  25. A user is planning to use EBS for his DB requirement. The user already has an EC2 instance running in the VPC private subnet. How can the user attach the EBS volume to a running instance?
    1. The user must create EBS within the same VPC and then attach it to a running instance.
    2. The user can create EBS in the same zone as the subnet of instance and attach that EBS to instance. (Should be in the same AZ)
    3. It is not possible to attach an EBS to an instance running in VPC until the instance is stopped.
    4. The user can specify the same subnet while creating EBS and then attach it to a running instance.
  26. A user is creating an EBS volume. He asks for your advice. Which advice mentioned below should you not give to the user for creating an EBS volume?
    1. Take the snapshot of the volume when the instance is stopped
    2. Stripe multiple volumes attached to the same instance
    3. Create an AMI from the attached volume (AMI is created from the snapshot)
    4. Attach multiple volumes to the same instance
  27. An EC2 instance has one additional EBS volume attached to it. How can a user attach the same volume to another running instance in the same AZ?
    1. Terminate the first instance and only then attach to the new instance
    2. Attach the volume as read only to the second instance
    3. Detach the volume first and attach to new instance
    4. No need to detach. Just select the volume and attach it to the new instance, it will take care of mapping internally
  28. What is the scope of an EBS volume?
    1. VPC
    2. Region
    3. Placement Group
    4. Availability Zone

Additional Practice Questions (Updated 2025-2026)

  1. A company wants to create instant copies of their EBS volumes for testing purposes within the same Availability Zone without using snapshots. Which feature should they use?
    1. EBS Fast Snapshot Restore
    2. EBS Snapshot Copy
    3. EBS Volume Clones
    4. EBS Multi-Attach
  2. Which EBS volume type provides sub-millisecond latency, up to 256,000 IOPS, and 99.999% durability?
    1. gp3
    2. io1
    3. io2 Block Express
    4. gp2
  3. A company needs to protect their EBS snapshots from accidental or malicious deletion to meet regulatory compliance requirements. Which feature should they use?
    1. EBS Encryption
    2. Recycle Bin
    3. AWS Backup
    4. EBS Snapshot Lock
  4. What is the maximum size, IOPS, and throughput for a gp3 volume as of September 2025?
    1. 16 TiB, 16,000 IOPS, 1,000 MiB/s
    2. 64 TiB, 64,000 IOPS, 4,000 MiB/s
    3. 64 TiB, 80,000 IOPS, 2,000 MiB/s
    4. 32 TiB, 32,000 IOPS, 2,000 MiB/s
  5. A team needs to accelerate the initialization of hundreds of EBS volumes from snapshots for a large-scale deployment. Which feature ensures predictable initialization times?
    1. EBS Fast Snapshot Restore
    2. Provisioned Rate for Volume Initialization
    3. EBS Volume Clones
    4. EBS Elastic Volumes
  6. How many times can you modify an EBS volume within a rolling 24-hour window? (as of Jan 2026)
    1. 1 time with 6-hour cooldown
    2. 2 times
    3. 4 times
    4. Unlimited
  7. Which of the following statements about EBS Multi-Attach is correct? (Choose 2)
    1. Multi-Attach is supported on io1 and io2 Provisioned IOPS volumes
    2. Multi-Attach allows attachment to instances across multiple Availability Zones
    3. Multi-Attach enabled volumes can be attached to up to 16 Nitro-based instances
    4. Multi-Attach is supported on gp3 volumes

Reference

Amazon EBS User Guide