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 EFS vs EBS Multi-Attach – Shared Storage Comparison

~ Last updated on : ~ jayendrapatil

AWS EFS vs EBS Multi-Attach

AWS EFS vs EBS Multi-Attach

📝 Post Updated – June 2026

This post has been updated to reflect the latest EFS and EBS enhancements including EFS Archive storage class, Elastic Throughput performance improvements (up to 20 GiB/s read), EBS io2 Block Express with NVMe Reservations for Multi-Attach, and cross-account replication support.

EFS vs EBS Multi-Attach features

  • Elastic File System – EFS is a fully managed, serverless file storage service for use with Amazon compute (EC2, containers, serverless) and on-premises servers. EFS provides a file system interface, file system access semantics (such as strong consistency and file locking), and concurrently accessible storage for up to thousands of EC2 instances.
  • Elastic Block Store – EBS is a block-level storage service for use with EC2. EBS can deliver performance for workloads that require the lowest-latency access to data from a single EC2 instance. EBS Multi-Attach is supported on Provisioned IOPS SSD volumes (io1 and io2) for concurrent access from multiple instances.
  • Service type
    • Elastic File System is fully managed and serverless — automatically scales storage capacity up or down.
    • EBS needs to be managed by the user — requires provisioning capacity upfront.
  • Accessibility
    • EFS can be accessed concurrently from all AZs in the Region via mount targets. Also supports cross-Region and cross-account replication (Nov 2024).
    • EBS Multi-Attach can be accessed concurrently from instances within the same AZ only.
  • Data Scalability
    • EFS provides virtually unlimited data storage — scales automatically to petabytes.
    • EBS Multi-Attach has limits on the storage it can provide (io2 Block Express supports up to 64 TiB per volume).
  • Instance Scalability
    • EFS can be attached to tens, hundreds, or even thousands of compute instances concurrently.
    • EBS Multi-Attach enabled volumes can be attached to up to 16 Linux instances built on the Nitro System.
  • Supported Instances
    • EFS is compatible with all Linux-based AMIs for EC2, uses NFS v4.1 protocol (POSIX-compliant). EFS is not supported on Windows instances.
    • Multi-Attach enabled volumes can be attached to up to 16 instances built on the Nitro System that are in the same AZ. With NVMe Reservations (io2 volumes, Sept 2023), Multi-Attach now supports Windows Server Failover Clusters with I/O fencing for safe write access coordination.
  • Storage Classes
    • EFS offers four storage classes: Standard, Standard-IA (Infrequent Access), One Zone, and One Zone-IA. Additionally, EFS Archive (launched Nov 2023) provides up to 72% lower cost than EFS IA for rarely accessed data with automatic intelligent tiering.
    • EBS Multi-Attach is supported on Provisioned IOPS SSD volumes — io1 and io2 (including io2 Block Express).
  • Performance
    • EFS with Elastic Throughput supports up to 20 GiB/s read throughput and 5 GiB/s write throughput (March 2024 update), with up to 1.5 GiB/s per client (May 2024 update). Supports sub-millisecond latency for Standard storage class.
    • EBS io2 Block Express delivers sub-millisecond latency with up to 256,000 IOPS, 4,000 MB/s throughput per volume.
  • I/O Fencing & Coordination
    • EFS handles file locking and consistency natively via NFS protocol semantics.
    • EBS Multi-Attach with io2 volumes supports NVMe Reservations (Sept 2023), enabling I/O fencing for safe write access coordination across cluster nodes — critical for Windows Server Failover Clusters and clustered databases.
  • Data Protection
    • EFS supports replication (cross-Region and cross-account), AWS Backup integration, and lifecycle management with automatic tiering.
    • EBS supports snapshots, Amazon Data Lifecycle Manager for automated snapshot management, and volume-level encryption.
  • Pricing
    • EFS is priced as per the pay-as-you-use model — only pay for storage consumed.
    • EBS is priced as per the provisioned capacity — pay for allocated storage even if unused.

Recent Updates (2023-2025)

Amazon EFS Updates

  • EFS Archive Storage Class (Nov 2023) – New lowest-cost storage class offering up to 72% lower cost than EFS Infrequent Access for rarely accessed data. Supports automatic intelligent tiering from Standard → IA → Archive.
  • Elastic Throughput – 20 GiB/s (March 2024) – Maximum throughput doubled to 20 GiB/s read (from 10 GiB/s) and 5 GiB/s write (from 3 GiB/s).
  • Per-client Throughput – 1.5 GiB/s (May 2024) – Maximum per-client throughput tripled to 1.5 GiB/s (from 500 MiB/s).
  • Cross-account Replication (Nov 2024) – EFS now supports replicating file systems between AWS accounts for enhanced disaster recovery.
  • 10,000 Access Points per File System (Feb 2025) – Limit increased 10x from 1,000 to 10,000 access points per file system for container and serverless workloads.

Amazon EBS Multi-Attach Updates

  • NVMe Reservations for io2 (Sept 2023) – Enables I/O fencing for Multi-Attach volumes, providing safe write access coordination across cluster nodes. Enabled by default for all Multi-Attach io2 volumes created after September 18, 2023.
  • Windows Server Failover Cluster Support – With NVMe Reservations, EBS Multi-Attach io2 volumes now support Windows Server Failover Clusters (WSFC) with proper I/O fencing, enabling SQL Server Failover Cluster Instances.
  • io2 Block Express Performance – Delivers up to 256,000 IOPS, 4,000 MB/s throughput, 64 TiB capacity per volume with 99.999% durability and sub-millisecond latency.
  • Expanded Instance Type Support (2025) – Multi-Attach support expanded to additional Nitro-based instance types.

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 company wants to organize the contents of multiple websites in managed file storage. The company must be able to scale the storage based on demand without needing to provision storage. Multiple servers across multiple Availability Zones within a region should be able to access this storage concurrently. Which services should the Solutions Architect recommend?
    1. Amazon S3
    2. Amazon EBS Multi-Attach
    3. Amazon EFS
    4. AWS Storage Gateway – Volume gateway
  2. A company requires shared block storage for a clustered database running on multiple EC2 instances within the same Availability Zone. The solution must support I/O fencing to prevent data corruption during failover scenarios. Which solution meets these requirements?
    1. Amazon EFS with General Purpose performance mode
    2. Amazon EBS io2 Multi-Attach with NVMe Reservations
    3. Amazon EBS gp3 with Multi-Attach enabled
    4. Amazon FSx for Windows File Server
  3. A company needs to store large amounts of rarely accessed files that still need to be part of the same file system namespace as their frequently accessed data. The solution must minimize costs while maintaining immediate access when needed. Which storage configuration is MOST cost-effective?
    1. Amazon S3 Glacier Instant Retrieval
    2. Amazon EFS with Standard storage class only
    3. Amazon EFS with lifecycle management using Standard, Infrequent Access, and Archive storage classes
    4. Amazon EBS with Cold HDD (sc1) volumes
  4. A company wants to deploy a Windows Server Failover Cluster on AWS for a SQL Server Always On Failover Cluster Instance. The shared storage must support concurrent access from multiple instances with proper write coordination. Which solution meets these requirements?
    1. Amazon EFS mounted on Windows instances
    2. Amazon EBS gp3 with Multi-Attach
    3. Amazon EBS io2 Multi-Attach with NVMe Reservations
    4. Amazon S3 with S3 File Gateway
  5. A media company runs a video processing workload across hundreds of EC2 instances that need to read and write to a shared file system. The workload requires up to 15 GiB/s of read throughput during peak hours. Which storage solution meets these requirements? (Select TWO)
    1. Amazon EFS with Elastic Throughput mode
    2. Amazon EBS io2 with Multi-Attach
    3. Amazon S3 with S3 Transfer Acceleration
    4. Amazon EFS Regional file system with General Purpose performance mode
    5. Amazon FSx for Lustre

References

Amazon EBS Multi-Attach

~ Last updated on : ~ jayendrapatil ~ 1 Comment

EBS Multi-Attach

  • EBS Multi-Attach enables attaching a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances that are in the same AZ.
  • Multiple Multi-Attach enabled volumes can be attached to an instance or set of instances.
  • Each instance to which the volume is attached has full read and write permission to the shared volume.
  • Multi-Attach helps achieve higher application availability in clustered Linux applications that manage concurrent write operations.
  • There are no additional charges for using Amazon EBS Multi-Attach. Standard Provisioned IOPS SSD (io1 and io2) volume charges apply.

io2 Block Express with Multi-Attach

  • io2 Block Express volumes are recommended over io1 for Multi-Attach due to better performance, durability, and feature support.
  • io2 Block Express provides up to 256,000 IOPS, 4,000 MB/s throughput, and 64 TiB capacity per volume.
  • io2 Block Express offers 99.999% durability (100x higher than io1) and consistent sub-millisecond latency.
  • io2 Block Express volumes are now available in all commercial and AWS GovCloud (US) Regions (expanded in 2025).
  • Customers can upgrade from io1 to io2 Block Express without any downtime using the ModifyVolume API.
  • io2 offers up to 4x IOPS and 4x throughput at the same storage price as io1, and up to 50% cheaper IOPS cost for volumes over 32,000 IOPS.

NVMe Reservations (I/O Fencing)

  • Multi-Attach enabled io2 volumes support NVMe reservations, a set of industry-standard storage fencing protocols for data consistency.
  • NVMe reservations enable control and coordination of access from multiple instances to a shared volume.
  • NVMe reservations is enabled by default for all Multi-Attach enabled io2 volumes created after September 18, 2023.
  • For existing io2 volumes created before September 18, 2023, NVMe reservations can be enabled by detaching all instances and then reattaching them.
  • Multi-Attach enabled io1 volumes do not support I/O fencing.
  • Supported NVMe Reservation commands:
    • Reservation Register – registers, unregisters, or replaces a reservation key to associate an instance with a volume.
    • Reservation Acquire – acquires a reservation (Write Exclusive, Exclusive Access, Registrants Only, All Registrants types).
    • Reservation Release – releases or clears a reservation held on a volume.
    • Reservation Report – describes the registration and reservation status of a volume.
  • Supported operating systems for NVMe reservations:
    • Amazon Linux 2 and later
    • RHEL 8.3 and later
    • SUSE Linux Enterprise 12 SP3 and later
    • Windows Server 2016 and later (NVMe driver 1.5.0+)

EBS Multi-Attach Considerations & Limitations

  • Multi-Attach is supported exclusively on Provisioned IOPS SSD volumes (io1 and io2).
  • Multi-Attach enabled volumes can be attached to up to 16 instances built on the Nitro System that are in the same AZ.
  • Linux instances support Multi-Attach enabled io1 and io2 volumes.
  • Windows instances support Multi-Attach enabled io2 volumes only.
  • Multi-Attach for io1 volumes is available in limited Regions only: US East (N. Virginia), US West (Oregon), and Asia Pacific (Seoul). Multi-Attach for io2 is available in all Regions that support io2.
  • io1 volumes with Multi-Attach enabled are not supported with instances built on the Nitro System that support the Scalable Reliable Datagram (SRD) networking protocol only. Use io2 with these instance types.
  • Standard file systems (XFS, EXT4) are not designed to be accessed simultaneously by multiple servers. Use a clustered file system (e.g., GFS2, OCFS2) to ensure data resiliency and reliability for production workloads.
  • Multi-Attach enabled volumes can be attached to one block device mapping per instance.
  • Multi-Attach enabled volumes are deleted on instance termination if the last attached instance is terminated and if that instance is configured to delete the volume on termination.
  • Multi-Attach enabled volumes can’t be created as boot volumes.
  • Multi-Attach can’t be enabled during instance launch using either the EC2 console or RunInstances API.
  • Multi-Attach can’t be enabled or disabled while the volume is attached to an instance.
  • Multi-Attach option is disabled by default.
  • CloudWatch metrics for Multi-Attach volumes are aggregated across all attached instances. Individual instance metrics are not available.

Volume Modification Support

  • io2 Multi-Attach volumes support modifying volume size and provisioned IOPS after creation.
  • io2 Multi-Attach volumes support enabling/disabling Multi-Attach (only while the volume is detached from all instances).
  • io1 Multi-Attach volumes do not support any modifications (size, IOPS, or Multi-Attach state) after creation.
  • Volume type cannot be changed for either io1 or io2 Multi-Attach enabled volumes.

Use Cases

  • Clustered Linux Applications – High availability for applications using clustered file systems like GFS2 or OCFS2.
  • Windows Server Failover Clustering (WSFC) – io2 volumes with NVMe reservations support SQL Server Failover Cluster Instances (FCI) on Windows Server.
  • Amazon EKS Shared Storage – Multi-Attach can share persistent storage across multiple workloads in different EKS clusters within the same AZ.
  • Database High Availability – Enables faster node recovery for clustered databases (e.g., Teradata reported 95% reduction in node recovery time).

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 company runs a clustered database application on multiple EC2 instances within the same Availability Zone. The application requires shared block storage with low latency and high IOPS. The application manages concurrent write operations. Which EBS configuration meets these requirements?
    1. Use a gp3 volume and attach it to multiple instances using Multi-Attach
    2. Use an io2 volume with Multi-Attach enabled and a clustered file system
    3. Use an io1 volume without Multi-Attach and replicate data between instances
    4. Use an EFS file system mounted across all instances

    Answer: 2. Multi-Attach is only supported on Provisioned IOPS SSD volumes (io1/io2). io2 is recommended. A clustered file system is required for concurrent write access.

  2. A company wants to deploy SQL Server Failover Cluster Instances on AWS with shared storage. The solution must provide I/O fencing to prevent data corruption. Which approach should be used?
    1. Use io1 volumes with Multi-Attach enabled
    2. Use io2 volumes with Multi-Attach and NVMe reservations
    3. Use gp3 volumes with Multi-Attach enabled
    4. Use EFS with Windows Server instances

    Answer: 2. io2 volumes with Multi-Attach support NVMe reservations for I/O fencing. io1 does not support I/O fencing. gp3 does not support Multi-Attach. EFS does not support Windows natively for this use case.

  3. Which of the following statements about EBS Multi-Attach are correct? (Choose 3)
    1. Multi-Attach enabled volumes can be attached to instances across multiple AZs
    2. Multi-Attach enabled io2 volumes support NVMe reservations for I/O fencing
    3. Windows instances support Multi-Attach for io2 volumes only
    4. Multi-Attach enabled volumes can be used as boot volumes
    5. io2 Multi-Attach volumes support modification of size and IOPS after creation

    Answer: 2, 3, 5. Multi-Attach is limited to a single AZ. io2 supports NVMe reservations. Windows only supports io2 for Multi-Attach. Multi-Attach volumes cannot be boot volumes. io2 volumes support size and IOPS modifications.

  4. A solutions architect needs to provide shared block storage for a containerized application running on Amazon EKS. Instances are in a single AZ and the application requires high IOPS with consistent low latency. Which storage solution is most appropriate?
    1. Amazon EFS with Provisioned Throughput mode
    2. Amazon FSx for Lustre
    3. EBS io2 Block Express with Multi-Attach via the EBS CSI driver
    4. Instance store volumes shared via NFS

    Answer: 3. EBS io2 Block Express with Multi-Attach provides high IOPS, low latency block storage that can be shared across instances in the same AZ. The EBS CSI driver supports Multi-Attach for EKS workloads.

References

AWS EBS Snapshots – Backup, Copy & Encryption

~ Last updated on : ~ jayendrapatil ~ 38 Comments

EBS Snapshot

  • EBS 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
  • Snapshots are incremental backups and store only the data that was changed from the time the last snapshot was taken.
  • Snapshots can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones.
  • 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 Snapshots can be used to migrate or create EBS volumes in different AZs or regions.
  • Snapshot data is automatically replicated across all Availability Zones in the Region.

Multi-Volume Snapshots

  • Snapshots can be used to create a backup of critical workloads, such as a large database or a file system that spans across multiple EBS volumes.
  • Multi-volume snapshots help take exact point-in-time, data-coordinated, and crash-consistent snapshots across multiple EBS volumes attached to an EC2 instance.
  • It is no longer required to stop the instance or to coordinate between volumes to ensure crash consistency because snapshots are automatically taken across multiple EBS volumes.

EBS Snapshot creation

  • Snapshots can be created from EBS volumes periodically and are point-in-time snapshots.
  • Snapshots are incremental and only store the blocks on the device that changed since the last snapshot was taken
  • Snapshots occur asynchronously; the point-in-time snapshot is created immediately while it takes time to upload the modified blocks to S3. While it is completing, an in-progress snapshot is not affected by ongoing reads and writes to the volume.
  • Snapshots can be taken from in-use volumes. However, snapshots will only capture the data that was written to the EBS volumes at the time the snapshot command is issued excluding the data which is cached by any applications of OS.
  • Recommended ways to create a Snapshot from an EBS volume are
    • Pause all file writes to the volume
    • Unmount the Volume -> Take Snapshot -> Remount the Volume
    • Stop the instance – Take Snapshot (for root EBS volumes)
  • EBS volume created based on a snapshot
    • begins as an exact replica of the original volume that was used to create the snapshot.
    • replicated volume loads data in the background so that it can be used immediately.
    • If data that hasn’t been loaded yet is accessed, the volume immediately downloads the requested data from S3 and then continues loading the rest of the volume’s data in the background.

EBS Snapshot Deletion

  • When a snapshot is deleted only the data exclusive to that snapshot is removed.
  • Deleting previous snapshots of a volume does not affect the ability to restore volumes from later snapshots of that volume.
  • Active snapshots contain all of the information needed to restore your data (from the time the snapshot was taken) to a new EBS volume.
  • 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.
  • Snapshot of the root device of an EBS volume used by a registered AMI can’t be deleted. AMI needs to be deregistered to be able to delete the snapshot.

EBS Snapshot Copy

  • Snapshots are constrained to the region in which they are created and can be used to launch EBS volumes within the same region only
  • Snapshots can be copied across regions to make it easier to leverage multiple regions for geographical expansion, data center migration, and disaster recovery
  • Snapshots are copied with S3 server-side encryption (256-bit Advanced Encryption Standard) to encrypt the data and the snapshot copy receives a snapshot ID that’s different from the original snapshot’s ID.
  • User-defined tags are not copied from the source to the new snapshot.
  • First Snapshot copy to another region is always a full copy, while the rest are always incremental.
  • When a snapshot is copied,
    • it can be encrypted if currently unencrypted or
    • can be encrypted using a different encryption key. Changing the encryption status of a snapshot or using a non-default EBS KMS key during a copy operation always results in a full copy (not incremental)

Time-based Snapshot Copy

  • Time-based Copy (launched Nov 2024) allows specifying a desired completion duration (15 minutes to 48 hours) when copying a snapshot within or between AWS Regions and/or accounts.
  • Helps meet time-based compliance and business requirements such as Recovery Point Objectives (RPOs) for disaster recovery.
  • Duration can range from 15 minutes to 48 hours in 15-minute increments, specified on a per-copy basis.
  • Maximum per-snapshot throughput is 500 MiB/second; default per-account limit is 2000 MiB/second between each source and destination pair.
  • If the copy cannot be completed within the specified duration, an EventBridge copyMissedCompletionDuration event is sent.
  • Available in all AWS Regions.

EBS Snapshot Sharing

  • Snapshots can be shared by making them public or with specific AWS accounts by modifying the access permissions of the snapshots
  • Encrypted snapshots cannot be made available publicly.
  • Encrypted snapshots can be shared with specific AWS accounts by sharing the customer managed KMS key used to encrypt it.
  • Cross-account permissions may be applied to a KMS key either when it is created or at a later time.
  • Users, with access to snapshots, can copy the snapshot and create their own EBS volumes based on the snapshot while the original snapshot remains unaffected
  • AWS prevents you from sharing snapshots that were encrypted with the default AWS managed key (aws/ebs). Only snapshots encrypted with customer managed KMS keys can be shared.
  • To share an encrypted snapshot cross-region, copy the snapshot to the destination region first and then share the copy.

EBS Snapshot Encryption

  • EBS snapshots fully support EBS encryption.
  • Snapshots of encrypted volumes are automatically encrypted
  • Volumes created from encrypted snapshots are automatically encrypted
  • All data in flight between the instance and the volume is encrypted
  • Volumes created from an unencrypted snapshot owned or have access to can be encrypted on the fly.
  • Unencrypted snapshots can be encrypted during the copy process.
  • Encrypted snapshots that you own or have access to, can be encrypted with a different key during the copy process.
  • First snapshot of an encrypted volume that has been created from an unencrypted snapshot is always a full snapshot.
  • First snapshot of a re-encrypted volume, which has a different KMS key compared to the source snapshot, is always a full snapshot.

EBS Fast Snapshot Restore (FSR)

  • Fast Snapshot Restore (FSR) eliminates the need for the traditional initialization process when creating a volume from a snapshot.
  • Volumes created from FSR-enabled snapshots instantly deliver all of their provisioned performance without the latency penalty of lazy loading blocks from S3.
  • FSR is enabled on selected snapshots in specific Availability Zones.
  • FSR is disabled for a snapshot by default. When enabled or disabled, the changes apply to your account only.
  • FSR is useful for workloads requiring rapid provisioning such as VDI (Virtual Desktop Infrastructure), backup & restore, test/dev volume copies, and booting from custom AMIs.
  • FSR supports io2 Block Express volumes.
  • FSR is not supported with AWS Outposts, Local Zones, and Wavelength Zones.
  • FSR-enabled snapshots shared with your account can be used with FSR enabled in your account independently.
  • Additional charges apply for each minute that FSR is enabled on a snapshot in a particular AZ.

EBS Snapshot Archive

  • EBS Snapshots Archive is a low-cost storage tier for rarely accessed snapshots that provides up to 75% lower storage costs.
  • Designed for snapshots retained for 90 days or longer that do not require frequent or fast retrieval.
  • When a snapshot is archived, the incremental snapshot is converted to a full snapshot and moved to the archive tier.
  • Archived snapshots have a minimum retention period of 90 days.
  • To use an archived snapshot, it must first be restored to the standard tier, after which it can be used like any other snapshot.
  • Restoring from archive takes 24-72 hours depending on the snapshot size.
  • EBS Direct APIs cannot be used with archived snapshots.
  • Snapshot locks can be applied to snapshots that have already been archived.
  • Amazon Data Lifecycle Manager can automatically archive snapshots based on policies.
  • AWS Backup supports EBS Snapshots Archive in backup policies.

EBS Snapshot Lock

  • EBS Snapshot Lock (launched Nov 2023) protects snapshots from inadvertent or malicious deletions, including ransomware attacks.
  • Locked snapshots cannot be deleted until the lock expires or is released.
  • Lock duration can range from one day to approximately 100 years.
  • Two lock modes are available:
    • Governance mode – Protects from deletion by all users. With proper IAM permissions, the lock duration can be extended/shortened, the lock deleted, or mode changed to Compliance.
    • Compliance mode – Protects from deletion by all users including the root user. After a cooling-off period (up to 72 hours), neither the snapshot nor the lock can be deleted until the lock expires. Lock duration can only be extended, not shortened.
  • Snapshots in either mode can still be shared, copied, or archived.
  • Supports WORM (Write Once Read Many) compliance requirements.
  • No additional charges for using Snapshot Lock; standard snapshot storage rates apply.
  • Available in all commercial AWS Regions.
  • If using customer managed KMS keys for encryption, ensure the key remains valid for the lifetime of the locked snapshot.

Recycle Bin for EBS Snapshots

  • Recycle Bin enables recovery of accidentally deleted EBS snapshots and EBS-backed AMIs.
  • Retention rules specify a retention period (1 day to 1 year) during which deleted snapshots are retained before permanent deletion.
  • A recovered snapshot retains all its attributes including tags, permissions, and encryption status.
  • Recovered snapshots can be used immediately for creating volumes.
  • Rule Lock can be applied to Recycle Bin retention rules to prevent them from being modified or deleted, providing additional protection.
  • Recycle Bin also supports EBS-backed AMIs and EBS Volumes (added 2025).

EBS Direct APIs

  • EBS Direct APIs allow creating EBS snapshots, writing data directly to snapshots, reading snapshot data, and identifying differences between two snapshots.
  • Key operations include:
    • ListSnapshotBlocks – Returns block indexes and block tokens of blocks in a snapshot.
    • ListChangedBlocks – Returns blocks that are different between two snapshots of the same volume.
    • GetSnapshotBlock – Returns data in a block for a given snapshot.
    • StartSnapshot – Creates a new snapshot (can be used to create snapshots from on-premises data).
    • PutSnapshotBlock – Adds data to a started snapshot in the form of individual blocks.
    • CompleteSnapshot – Completes a snapshot after all blocks have been written.
  • Enables backup of on-premises data directly into EBS snapshots without needing an EC2 instance.
  • Useful for incremental backup solutions and disaster recovery from on-premises to AWS.
  • Does not support public snapshots or archived snapshots.

Local Snapshots

  • Local Snapshots allow creating and storing snapshots in AWS Local Zones and Dedicated Local Zones.
  • By default, snapshots of EBS volumes in a Local Zone are stored in S3 in the parent Region.
  • With Local Snapshots, backups can be stored within the same geographical boundary as the EBS volumes, helping meet data residency and data isolation requirements.
  • Snapshot copy is supported for Local Zones, allowing copies to be sent to the Region or another Local Zone.
  • EBS Direct APIs do not support local snapshots on Outposts.

EBS Snapshot Lifecycle Automation

  • Amazon Data Lifecycle Manager (DLM) can be used to automate the creation, retention, and deletion of snapshots taken to back up the EBS volumes.
  • Automating snapshot management helps you to:
    • Protect valuable data by enforcing a regular backup schedule.
    • Retain backups as required by auditors or internal compliance.
    • Reduce storage costs by deleting outdated backups.
    • Automatically archive snapshots to the Archive tier based on policies.
  • AWS Backup provides a centralized, policy-based approach to manage EBS snapshot backups across AWS accounts and regions.
  • AWS Backup supports EBS Snapshots Archive in backup policies for cost-optimized long-term retention.

EBS Snapshot Resource-Level Permissions

  • Enhanced resource-level permissions (2025) allow specifying additional resource-level authorization in IAM policies for source snapshots when creating volumes (CreateVolume) or copying snapshots (CopySnapshot).
  • Enables fine-grained access control over which snapshots can be used as sources for volume creation or copy operations.

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. An existing application stores sensitive information on a non-boot Amazon EBS data volume attached to an Amazon Elastic Compute Cloud instance. Which of the following approaches would protect the sensitive data on an Amazon EBS volume?
    1. Upload your customer keys to AWS CloudHSM. Associate the Amazon EBS volume with AWS CloudHSM. Remount the Amazon EBS volume.
    2. Create and mount a new, encrypted Amazon EBS volume. Move the data to the new volume. Delete the old Amazon EBS volume.
    3. Unmount the EBS volume. Toggle the encryption attribute to True. Re-mount the Amazon EBS volume.
    4. Snapshot the current Amazon EBS volume. Restore the snapshot to a new, encrypted Amazon EBS volume. Mount the Amazon EBS volume (Need to create a snapshot, create an encrypted copy of snapshot and then create an EBS volume and mount it)
  2. Is it possible to access your EBS snapshots?
    1. Yes, through the Amazon S3 APIs.
    2. Yes, through the Amazon EC2 APIs
    3. No, EBS snapshots cannot be accessed; they can only be used to create a new EBS volume.
    4. EBS doesn’t provide snapshots.
  3. Which of the following approaches provides the lowest cost for Amazon Elastic Block Store snapshots while giving you the ability to fully restore data?
    1. Maintain two snapshots: the original snapshot and the latest incremental snapshot
    2. Maintain a volume snapshot; subsequent snapshots will overwrite one another
    3. Maintain a single snapshot the latest snapshot is both Incremental and complete
    4. Maintain the most current snapshot, archive the original and incremental to Amazon Glacier.
  4. Which procedure for backing up a relational database on EC2 that is using a set of RAIDed EBS volumes for storage minimizes the time during which the database cannot be written to and results in a consistent backup?
    1. Detach EBS volumes, 2. Start EBS snapshot of volumes, 3. Re-attach EBS volumes
    2. Stop the EC2 Instance. 2. Snapshot the EBS volumes
    3. Suspend disk I/O, 2. Create an image of the EC2 Instance, 3. Resume disk I/O
    4. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Resume disk I/O
    5. Suspend disk I/O, 2. Start EBS snapshot of volumes, 3. Wait for snapshots to complete, 4. Resume disk I/O
  5. How can an EBS volume that is currently attached to an EC2 instance be migrated from one Availability Zone to another?
    1. Detach the volume and attach it to another EC2 instance in the other AZ.
    2. Simply create a new volume in the other AZ and specify the original volume as the source.
    3. Create a snapshot of the volume, and create a new volume from the snapshot in the other AZ
    4. Detach the volume, then use the ec2-migrate-volume command to move it to another AZ.
  6. How are the EBS snapshots saved on Amazon S3?
    1. Exponentially
    2. Incrementally
    3. EBS snapshots are not stored in the Amazon S3
    4. Decrementally
  7. EBS Snapshots occur _____
    1. Asynchronously
    2. Synchronously
    3. Weekly
  8. What will be the status of the snapshot until the snapshot is complete?
    1. Running
    2. Working
    3. Progressing
    4. Pending
  9. Before I delete an EBS volume, what can I do if I want to recreate the volume later?
    1. Create a copy of the EBS volume (not a snapshot)
    2. Create and Store a snapshot of the volume
    3. Download the content to an EC2 instance
    4. Back up the data in to a physical disk
  10. 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
  11. Amazon EBS snapshots have which of the following two characteristics? (Choose 2.) Choose 2 answers
    1. EBS snapshots only save incremental changes from snapshot to snapshot
    2. EBS snapshots can be created in real-time without stopping an EC2 instance (the snapshot can be taken real time however it will not be consistent and the recommended way is to stop or freeze the IO)
    3. EBS snapshots can only be restored to an EBS volume of the same size or smaller (EBS volume restored from snapshots need to be of the same size of larger size)
    4. EBS snapshots can only be restored and mounted to an instance in the same Availability Zone as the original EBS volume (Snapshots are specific to Region and can be used to create a volume in any AZ and does not depend on the original EBS volume AZ)
  12. 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 (Refer link)
    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
  13. A sys admin is trying to understand EBS snapshots. Which of the below mentioned statements will not be useful to the admin to understand the concepts about a snapshot?
    1. Snapshot is synchronous
    2. It is recommended to stop the instance before taking a snapshot for consistent data
    3. Snapshot is incremental
    4. Snapshot captures the data that has been written to the hard disk when the snapshot command was executed
  14. When creation of an EBS snapshot is initiated but not completed, the EBS volume
    1. Cannot be detached or attached to an EC2 instance until me snapshot completes
    2. Can be used in read-only mode while me snapshot is in progress
    3. Can be used while the snapshot is in progress
    4. Cannot be used until the snapshot completes
  15. You have a server with a 5O0GB Amazon EBS data volume. The volume is 80% full. You need to back up the volume at regular intervals and be able to re-create the volume in a new Availability Zone in the shortest time possible. All applications using the volume can be paused for a period of a few minutes with no discernible user impact. Which of the following backup methods will best fulfill your requirements?
    1. Take periodic snapshots of the EBS volume
    2. Use a third-party Incremental backup application to back up to Amazon Glacier
    3. Periodically back up all data to a single compressed archive and archive to Amazon S3 using a parallelized multi-part upload
    4. Create another EBS volume in the second Availability Zone attach it to the Amazon EC2 instance, and use a disk manager to mirror me two disks
  16. A user is creating a snapshot of an EBS volume. Which of the below statements is incorrect in relation to the creation of an EBS snapshot?
    1. Its incremental
    2. It can be used to launch a new instance
    3. It is stored in the same AZ as the volume (stored in the same region)
    4. It is a point in time backup of the EBS volume
  17. A user has created a snapshot of an EBS volume. Which of the below mentioned usage cases is not possible with respect to a snapshot?
    1. Mirroring the volume from one AZ to another AZ
    2. Launch an instance
    3. Decrease the volume size
    4. Increase the size of the volume
  18. What is true of the way that encryption works with EBS?
    1. Snapshotting an encrypted volume makes an encrypted snapshot; restoring an encrypted snapshot creates an encrypted volume when specified / requested.
    2. Snapshotting an encrypted volume makes an encrypted snapshot when specified / requested; restoring an encrypted snapshot creates an encrypted volume when specified / requested.
    3. Snapshotting an encrypted volume makes an encrypted snapshot; restoring an encrypted snapshot always creates an encrypted volume.
    4. Snapshotting an encrypted volume makes an encrypted snapshot when specified / requested; restoring an encrypted snapshot always creates an encrypted volume.
  19. Why are more frequent snapshots of EBS Volumes faster?
    1. Blocks in EBS Volumes are allocated lazily, since while logically separated from other EBS Volumes, Volumes often share the same physical hardware. Snapshotting the first time forces full block range allocation, so the second snapshot doesn’t need to perform the allocation phase and is faster.
    2. The snapshots are incremental so that only the blocks on the device that have changed after your last snapshot are saved in the new snapshot.
    3. AWS provisions more disk throughput for burst capacity during snapshots if the drive has been pre-warmed by snapshotting and reading all blocks.
    4. The drive is pre-warmed, so block access is more rapid for volumes when every block on the device has already been read at least one time.
  20. Which is not a restriction on AWS EBS Snapshots?
    1. Snapshots which are shared cannot be used as a basis for other snapshots (Snapshots shared with other users are usable in full by the recipient, including but limited to the ability to base modified volumes and snapshots)
    2. You cannot share a snapshot containing an AWS Access Key ID or AWS Secret Access Key
    3. You cannot share snapshots encrypted with the default AWS managed key (NOTE: Encrypted snapshots CAN be shared with specific accounts if encrypted with a customer managed KMS key. Only snapshots encrypted with the default aws/ebs key cannot be shared.)
    4. Snapshot restorations are restricted to the region in which the snapshots are created
  21. There is a very serious outage at AWS. EC2 is not affected, but your EC2 instance deployment scripts stopped working in the region with the outage. What might be the issue?
    1. The AWS Console is down, so your CLI commands do not work.
    2. S3 is unavailable, so you can’t create EBS volumes from a snapshot you use to deploy new volumes. (EBS volume snapshots are stored in S3. If S3 is unavailable, snapshots are unavailable)
    3. AWS turns off the DeployCode API call when there are major outages, to protect from system floods.
    4. None of the other answers make sense. If EC2 is not affected, it must be some other issue.

New Practice Questions – EBS Snapshot Features (2021-2025)

  1. A company needs to ensure that critical EBS snapshots cannot be deleted by any user, including the root user, for a period of 5 years to meet regulatory compliance. Which feature should be used?
    1. AWS Backup Vault Lock
    2. Recycle Bin with 5-year retention
    3. EBS Snapshot Lock in Compliance mode
    4. EBS Snapshot Lock in Governance mode
  2. A company wants to reduce storage costs for EBS snapshots that are retained for compliance but rarely accessed. The snapshots need to be kept for at least 2 years. Which approach provides the lowest cost?
    1. Keep snapshots in standard tier and use lifecycle policies to delete after 2 years
    2. Move snapshots to EBS Snapshots Archive tier
    3. Copy snapshots to S3 Glacier
    4. Use Recycle Bin with a 2-year retention period
  3. An organization accidentally deleted an EBS snapshot that was needed for disaster recovery. Which AWS feature could have prevented permanent data loss?
    1. EBS Snapshot Lock
    2. Multi-volume snapshots
    3. Recycle Bin for EBS Snapshots
    4. Fast Snapshot Restore
  4. A company needs to copy an EBS snapshot to another region and must ensure the copy completes within 2 hours to meet their RPO requirements. Which feature should they use?
    1. Fast Snapshot Restore
    2. Time-based Snapshot Copy with a 2-hour completion duration
    3. EBS Direct APIs
    4. Standard cross-region copy with CloudWatch monitoring
  5. A company runs a VDI environment and needs volumes created from snapshots to deliver full provisioned performance immediately without any initialization penalty. Which feature should be enabled?
    1. EBS Snapshot Archive
    2. Time-based Snapshot Copy
    3. EBS Direct APIs
    4. Fast Snapshot Restore (FSR)
  6. A backup solution needs to create EBS snapshots directly from on-premises block storage data without using an EC2 instance as an intermediary. Which approach enables this?
    1. AWS Storage Gateway
    2. AWS DataSync
    3. EBS Direct APIs (StartSnapshot, PutSnapshotBlock, CompleteSnapshot)
    4. S3 Transfer Acceleration with snapshot import
  7. What happens when an EBS snapshot is archived? (Choose 2)
    1. The incremental snapshot is converted to a full snapshot
    2. The snapshot remains incremental in the archive tier
    3. The snapshot is moved from the standard tier to the archive tier
    4. The snapshot is automatically deleted after 90 days
    5. The snapshot can still be used directly to create volumes without restoration

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).

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

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 S3 vs EBS vs EFS – Storage Comparison Guide

~ Last updated on : ~ jayendrapatil ~ 2 Comments

S3 vs EBS vs EFS

EFS, EBS, and S3 are AWS’ three different storage types that are applicable for different types of workload needs.

🆕 Major Updates (2024-2026)

  • Amazon S3 Files (April 2026) – S3 buckets can now be mounted as NFS file systems, blurring the line between S3 and EFS.
  • Amazon S3 Tables – Native Apache Iceberg table storage in S3 for analytics workloads (GA 2024).
  • Amazon S3 Vectors (GA Dec 2025) – Native vector storage and similarity search in S3 for AI/ML workloads.
  • EBS gp3 Enhanced (Sept 2025) – gp3 volumes now support up to 64 TiB size, 80,000 IOPS, and 2,000 MiB/s throughput.
  • EFS Performance (2024) – Up to 60 GiB/s read throughput, 2.5 million IOPS per file system, and 10,000 access points per file system.
  • EFS Archive Storage Class (Nov 2023) – Up to 50% lower cost than EFS IA for rarely accessed data.

S3 vs EBS vs EFS Comparison

S3 vs EBS vs EFS

Simple Storage Service – S3

  • is an object store with a simple key, value store design, and good at storing vast numbers of backups or user files.
  • offers pay for the storage you actually use. Offers cost-saving storage classes ideal for infrequently accessed data or for data archival.
  • provides unlimited storage – as of March 2026, S3 stores more than 500 trillion objects across hundreds of exabytes of data.
  • provides durability as the data is replicated and stored across at least three geographically dispersed AZs with a maximum of 99.999999999% (11 9’s).
  • provides high availability with a maximum of 99.99%.
  • provides security with a range of access control mechanisms and abilities to encrypt data at rest and in transit. SSE-C is now disabled by default on new buckets (April 2026).
  • data can be accessed programmatically or directly from services such as AWS CloudFront.
  • provides backup capability using versioning and cross-region replication.
  • offers multiple storage classes: S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA, S3 Express One Zone, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive.
  • S3 Express One Zone provides up to 10x faster data access and 50% lower request costs than S3 Standard for latency-sensitive workloads.
  • 🆕 S3 Files (April 2026) – provides native NFS v4.2 file system access to S3 buckets, enabling EC2 instances, Lambda, EKS, and ECS to mount S3 as a file system with ~1ms latencies and full POSIX semantics. Data never leaves S3.
  • 🆕 S3 Tables – provides native Apache Iceberg table support with automatic compaction, snapshot management, and Intelligent-Tiering for analytics workloads.
  • 🆕 S3 Vectors (GA Dec 2025) – first cloud object storage with native vector support, enabling storage and similarity search of up to 2 billion vectors per index at up to 90% lower cost than specialized vector databases.

Elastic Block Storage – EBS

  • delivers high-availability block-level storage volumes for EC2 instances.
  • offers pay for the provisioned storage, even if you do not use it.
  • provides limited storage capability – gp3 volumes now support up to 64 TiB (previously 16 TiB), io2 Block Express supports up to 64 TiB.
  • stores data on a file system which can be retained after the EC2 instance is shut down.
  • provides durability by replicating data across multiple servers in an AZ to prevent the loss of data from the failure of any single component.
  • designed for 99.999% availability.
  • provides low-latency performance – io2 Block Express volumes deliver sub-millisecond (under 500 microseconds) average latency for 16KiB I/O operations. gp3 volumes now deliver up to 80,000 IOPS and 2,000 MiB/s throughput (Sept 2025 update).
  • provides secure storage with access control and providing data at rest and in transit encryption.
  • is only accessible from EC2 instances in the particular AWS region and AZ.
  • provides Multi-Attach option to share io1/io2 volumes across up to 16 Nitro-based EC2 instances within the same AZ. io2 volumes also support NVMe Reservations for I/O fencing.
  • provides backup capability using backups and snapshots.
  • 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).
  • 🆕 Elastic Volumes Enhanced (Jan 2026) – the 6-hour cooldown period after modifications has been eliminated; now supports up to 4 modifications per volume within a rolling 24-hour window.
  • 🆕 Higher EBS-Optimized Performance (2026) – C8gn, M8gn, R8gn instances support up to 120 Gbps EBS bandwidth and 480,000 IOPS (doubled from previous generation).

Elastic File Storage – EFS

  • scalable file storage, also optimized for EC2.
  • offers pay for the storage you actually use. There’s no advance provisioning, up-front fees, or commitments.
  • multiple instances can be configured to mount the file system.
  • allows mounting the file system across multiple regions and instances.
  • is designed to be highly durable and highly available. Data is redundantly stored across multiple AZs for Regional file systems.
  • provides elasticity – scales up and down automatically, even to meet the most abrupt workload spikes.
  • provides performance that scales to support any workload: EFS now supports up to 2.5 million read IOPS, 500,000 write IOPS (10x increase, Nov 2024), and up to 60 GiB/s read throughput (Oct 2024).
  • provides accessible file storage, which can be accessed by on-premises servers and EC2 instances concurrently.
  • provides security and compliance – access to the file system can be secured using IAM, VPC, or POSIX permissions.
  • provides data encryption in transit or at rest.
  • allows EC2 instances to access EFS file systems located in other AWS regions through VPC peering.
  • a file system can be accessed concurrently from all AZs in the region where it is located, which means the application can be architected to failover from one AZ to other AZs in the region in order to ensure the highest level of application availability.
  • used as a common data source for any application or workload that runs on numerous instances.
  • offers two file system types: Regional (Multi-AZ, recommended) and One Zone (single AZ, lower cost).
  • provides three storage classes: EFS Standard (sub-millisecond latency), EFS Infrequent Access (IA), and EFS Archive (up to 50% lower cost than IA, at $0.008/GB-month for rarely accessed data).
  • 🆕 Supports up to 10,000 access points per file system (10x increase from previous 1,000 limit, Feb 2025).

S3 Files vs EFS – Key Differences

With the launch of Amazon S3 Files in April 2026, S3 now offers NFS file system access similar to EFS. Here are the key differences:

  • Data Location: S3 Files keeps data in S3 (object storage pricing at ~$0.023/GB-month); EFS stores data natively as files (~$0.30/GB-month for Standard).
  • Performance: EFS offers sub-millisecond latency for hot data; S3 Files offers ~1ms latency for small files with high-performance caching.
  • Use Case: S3 Files is ideal when data already lives in S3 and you need file system access without migration; EFS is purpose-built for shared file storage with full POSIX compliance.
  • Connections: S3 Files supports up to 25,000 simultaneous connections; EFS supports thousands of concurrent connections.
  • Protocol: Both support NFS v4. S3 Files uses NFS v4.2; EFS uses NFS v4.0/v4.1.
  • Pricing: S3 Files access charges match EFS pricing ($0.30/GB storage for file operations, $0.03/GB reads, $0.06/GB writes), but underlying S3 storage is cheaper.

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 company runs an application on a group of Amazon Linux EC2 instances. The application writes log files using standard API calls. For compliance reasons, all log files must be retained indefinitely and will be analyzed by a reporting tool that must access all files concurrently. Which storage service should a solutions architect use to provide the MOST cost-effective solution?
    1. Amazon EBS
    2. Amazon EFS
    3. Amazon EC2 instance store
    4. Amazon S3
  2. A new application is being deployed on Amazon EC2. The Application needs to read write up to 3 TB of data to an external data store and requires read-after-write consistency across all AWS regions for writing new objects into this data store.
    1. Amazon EBS
    2. Amazon S3 Glacier Flexible Retrieval
    3. Amazon EFS
    4. Amazon S3
  3. To meet the requirements of an application, an organization needs to save a constantly increasing volume of files on a cloud storage system with the following features and abilities. What below AWS service will meet these requirements?
      1. Pay only for the storage used
      2. Create different security policies for different groups of files
      3. Allow access to the public
      4. Retrieve the files at any time
      5. Store an unlimited number of files
    2. Amazon EBS
    3. Amazon S3
    4. Amazon S3 Glacier Flexible Retrieval
    5. Amazon EFS
  4. An administrator runs a highly available application in AWS. A file storage layer is needed that can share between instances and scale the platform more easily. The storage should also be POSIX compliant. Which AWS service can perform this action?
    1. Amazon EBS
    2. Amazon S3
    3. Amazon EFS
    4. Amazon EC2 Instance store
  5. A company needs to store and query AI vector embeddings for a recommendation engine. They want the lowest cost solution with high durability and the ability to scale to billions of vectors. Which AWS service should they use?
    1. Amazon OpenSearch Service
    2. Amazon EFS
    3. Amazon RDS with pgvector
    4. Amazon S3 Vectors
  6. A data engineering team has petabytes of data stored in Amazon S3 and needs to run interactive analytics queries directly on this data using Apache Iceberg table format. Which S3 feature provides native, managed Iceberg table support with automatic compaction?
    1. S3 Select
    2. S3 Object Lambda
    3. S3 Tables
    4. S3 Glacier Instant Retrieval
  7. A company has an existing application that reads and writes files using standard POSIX file operations. The application data is currently stored in Amazon S3. The team wants to avoid code changes while accessing S3 data as files with low latency. Which solution meets these requirements?
    1. Amazon EFS with DataSync to S3
    2. AWS Storage Gateway File Gateway
    3. Mountpoint for Amazon S3
    4. Amazon S3 Files
  8. A solutions architect needs to select block storage for an I/O-intensive database that requires consistent sub-millisecond latency and up to 80,000 IOPS. The storage must be cost-effective. Which EBS volume type should they choose?
    1. gp2
    2. gp3
    3. io2 Block Express
    4. st1

References

AWS Storage Services Cheat Sheet

~ Last updated on : ~ jayendrapatil ~ 17 Comments

AWS Storage Services Cheat Sheet

AWS Storage Services

Simple Storage Service – S3

  • provides key-value based object storage with unlimited storage, unlimited objects up to 5 TB for the internet
  • offers an extremely durable, highly available, and infinitely scalable data storage infrastructure at very low costs.
  • is Object-level storage (not a Block level storage) and cannot be used to host OS or dynamic websites (but can work with Javascript SDK)
  • provides durability by redundantly storing objects on multiple facilities within a region
  • regularly verifies the integrity of data using checksums and provides the auto-healing capability
  • S3 resources consist of globally unique buckets with objects and related metadata. The data model is a flat structure with no hierarchies or folders.
  • As of March 2026, S3 stores more than 500 trillion objects, serves more than 200 million requests per second globally across hundreds of exabytes of data.
  • S3 Replication enables automatic, asynchronous copying of objects across S3 buckets in the same or different AWS regions using SRR or CRR. Replication needs versioning enabled on either side.
  • S3 Transfer Acceleration helps speed data transport over long distances between a client and an S3 bucket using CloudFront edge locations.
  • S3 supports cost-effective Static Website hosting with Client-side scripts.
  • S3 CORS – Cross-Origin Resource Sharing allows cross-origin access to S3 resources.
  • S3 Access Logs enables tracking access requests to an S3 bucket.
  • S3 notification feature enables notifications to be triggered when certain events happen in the bucket.
  • S3 Inventory helps manage the storage and can be used to audit and report on the replication and encryption status of the objects for business, compliance, and regulatory needs.
  • Requestor Pays help bucket owner to specify that the requester requesting the download will be charged for the download.
  • S3 Batch Operations help perform large-scale batch operations on S3 objects and can perform a single operation on lists of specified S3 objects.
  • Pre-Signed URLs can be used shared for uploading/downloading objects for a limited time without requiring AWS security credentials.
  • Multipart Uploads allows
    • parallel uploads with improved throughput and bandwidth utilization
    • fault tolerance and quick recovery from network issues
    • ability to pause and resume uploads
    • begin an upload before the final object size is known
  • Versioning
    • helps preserve, retrieve, and restore every version of every object
    • protect from unintended overwrites and accidental deletions
    • protects individual files but does NOT protect from Bucket deletion
  • MFA (Multi-Factor Authentication) can be enabled for additional security for the deletion of objects.
  • Integrates with CloudTrail, CloudWatch, and SNS for event notifications
  • S3 Object Lock
    • provides Write-Once-Read-Many (WORM) protection for S3 objects
    • prevents objects from being deleted or overwritten for a fixed amount of time or indefinitely
    • Governance Mode – users with specific IAM permissions can remove the lock
    • Compliance Mode – no user, including the root account, can remove the lock until retention period expires
    • supports Legal Hold which prevents object deletion indefinitely until explicitly removed
    • requires versioning to be enabled on the bucket
  • S3 Storage Classes
    • S3 Standard
      • default storage class, ideal for frequently accessed data
      • 99.999999999% durability & 99.99% availability
      • Low latency and high throughput performance
      • designed to sustain the loss of data in two facilities
    • S3 Intelligent-Tiering
      • automatically moves data between access tiers based on access patterns with no retrieval charges
      • includes Frequent Access (default), Infrequent Access (after 30 days, 40% lower cost), and Archive Instant Access (after 90 days, 68% lower cost) tiers
      • optional Archive Access (90-730 days) and Deep Archive Access (180-730 days) tiers can be enabled
      • 99.999999999% durability & 99.9% availability
      • ideal for data with unknown or changing access patterns
      • small monthly monitoring and automation charge per object; no retrieval charges
    • S3 Express One Zone
      • high-performance storage class launched in November 2023
      • delivers up to 10x better performance than S3 Standard with consistent single-digit millisecond latency
      • request costs up to 50% lower than S3 Standard
      • uses directory buckets (a new bucket type) stored in a single Availability Zone
      • supports up to 2 million requests per second per directory bucket
      • ideal for ML training, interactive analytics, financial modeling, and real-time advertising
      • allows co-locating storage and compute in the same AZ for optimal performance
    • S3 Standard-Infrequent Access (S3 Standard-IA)
      • optimized for long-lived and less frequently accessed data
      • designed to sustain the loss of data in two facilities
      • 99.999999999% durability & 99.9% availability
      • suitable for objects greater than 128 KB kept for at least 30 days
    • S3 One Zone-Infrequent Access (S3 One Zone-IA)
      • optimized for rapid access, less frequently accessed data
      • ideal for secondary backups and reproducible data
      • stores data in a single AZ, data stored in this storage class will be lost in the event of AZ destruction.
      • 99.999999999% durability & 99.5% availability
    • S3 Reduced Redundancy Storage (Not Recommended)
      • designed for noncritical, reproducible data stored at lower levels of redundancy than the STANDARD storage class
      • reduces storage costs
      • 99.99% durability & 99.99% availability
      • designed to sustain the loss of data in a single facility
    • S3 Glacier Instant Retrieval
      • lowest-cost storage for long-lived data that is rarely accessed but requires milliseconds retrieval
      • ideal for medical images, news media assets, or genomics data accessed once per quarter
      • 99.999999999% durability & 99.9% availability
      • Minimum storage duration of 90 days
      • up to 68% lower cost than S3 Standard-IA
    • S3 Glacier Flexible Retrieval (formerly S3 Glacier)
      • suitable for low cost data archiving, where data access is infrequent
      • provides retrieval time of minutes to hours
        • Expedited – 1 to 5 minutes
        • Standard – 3 to 5 hours
        • Bulk – 5 to 12 hours (free)
      • 99.999999999% durability & 99.9% availability
      • Minimum storage duration of 90 days
    • S3 Glacier Deep Archive
      • provides lowest cost data archiving, where data access is infrequent
      • 99.999999999% durability & 99.9% availability
      • provides retrieval time of several (12-48) hours
        • Standard – 12 hours
        • Bulk – 48 hours
      • Minimum storage duration of 180 days
      • supports long-term retention and digital preservation for data that may be accessed once or twice a year
  • Lifecycle Management policies
    • transition to move objects to different storage classes and Glacier
    • expiration to remove objects and object versions
    • can be applied to both current and non-current objects, in case, versioning is enabled.
  • Data Consistency Model
    • provides strong read-after-write consistency for PUT and DELETE requests of objects in the S3 bucket in all AWS Regions
    • updates to a single key are atomic
  • S3 Security
    • IAM policies – grant users within your own AWS account permission to access S3 resources
    • Bucket and Object ACL – grant other AWS accounts (not specific users) access to S3 resources
    • Bucket policies – allows to add or deny permissions across some or all of the objects within a single bucket
    • S3 Access Points simplify data access for any AWS service or customer application that stores data in S3.
    • S3 Glacier Vault Lock helps deploy and enforce compliance controls for individual S3 Glacier vaults with a vault lock policy.
    • S3 VPC Gateway Endpoint enables private connections between a VPC and S3, without requiring that you use an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
    • Support SSL encryption of data in transit and data encryption at rest
    • S3 Block Public Access – provides settings to block public access at the account and bucket level (enabled by default on new buckets)
    • SSE-C disabled by default – as of April 2026, Server-Side Encryption with Customer-Provided Keys (SSE-C) is disabled by default on all new general purpose buckets for enhanced security
  • S3 Data Encryption
    • supports data at rest and data in transit encryption
    • All new objects are encrypted by default with SSE-S3 (Amazon S3-managed keys)
    • Server-Side Encryption
      • SSE-S3 – encrypts S3 objects using keys handled & managed by AWS (default)
      • SSE-KMS – leverage AWS Key Management Service to manage encryption keys. KMS provides control and audit trail over the keys.
      • SSE-C – when you want to manage your own encryption keys. AWS does not store the encryption key. Requires HTTPS. Disabled by default on new buckets since April 2026.
      • DSSE-KMS – Dual-layer Server-Side Encryption with KMS keys, provides two layers of encryption for compliance requirements
    • Client-Side Encryption
      • Client library such as the S3 Encryption Client
      • Clients must encrypt data themselves before sending it to S3
      • Clients must decrypt data themselves when retrieving from S3
      • Customer fully manages the keys and encryption cycle
  • S3 Best Practices
    • use parallel threads and Multipart upload for faster writes
    • use parallel threads and Range Header GET for faster reads
    • for list operations with a large number of objects, it’s better to build a secondary index in DynamoDB
    • use Versioning to protect from unintended overwrites and deletions, but this does not protect against bucket deletion
    • use VPC S3 Endpoints with VPC to transfer data using Amazon internal network
    • use S3 Object Lock for WORM compliance and ransomware protection

S3 Bucket Types

  • General Purpose Buckets – traditional S3 buckets for most workloads with flat storage namespace
  • Directory Buckets – used with S3 Express One Zone storage class, organized with a hierarchical directory structure for low-latency workloads
  • Table Buckets – purpose-built for storing tabular data in Apache Iceberg format (launched December 2024), with automatic compaction, snapshot management, and garbage collection
  • Vector Buckets – optimized for durable, low-cost vector storage for AI embeddings (GA December 2025), supports up to 2 billion vectors per index with dedicated APIs for storing, accessing, and querying vectors

S3 Files (2026)

  • provides fully-featured, high-performance NFS file system access to S3 data
  • first cloud object store to provide full file system semantics without data ever leaving S3
  • enables accessing S3 objects using file-based protocols for applications requiring file system interfaces

Instance Store

  • provides temporary or ephemeral block-level storage for an EC2 instance
  • is physically attached to the Instance
  • deliver very high random I/O performance, which is a good option when storage with very low latency is needed
  • cannot be dynamically resized
  • data persists when an instance is rebooted
  • data does not persist if the
    • underlying disk drive fails
    • instance stops i.e. if the EBS backed instance with instance store volumes attached is stopped
    • instance terminates
  • can be attached to an EC2 instance only when the instance is launched
  • is ideal for the 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.

Elastic Block Store – EBS

  • is virtual network-attached block storage
  • provides highly available, reliable, durable, block-level storage volumes that can be attached to a running instance
  • provides high durability and are redundant in an AZ, as the data is automatically replicated within that AZ to prevent data loss due to any single hardware component failure
  • persists and is independent of EC2 lifecycle
  • multiple volumes can be attached to a single EC2 instance
  • can be detached & attached to another EC2 instance in that same AZ only
  • volumes are Zonal i.e. created in a specific AZ and CAN’T span across AZs
  • snapshots
  • for making volume available to different AZ, create a snapshot of the volume and restore it to a new volume in any AZ within the region
  • for making the volume available to different Region, the snapshot of the volume can be copied to a different region and restored as a volume
  • Multi-Attach enables attaching a single Provisioned IOPS SSD (io1 or io2) volume to multiple instances that are in the same AZ.
  • EBS Volume Types:
    • General Purpose SSD (gp3) – default and recommended for most workloads
      • baseline 3,000 IOPS and 125 MiB/s throughput included (independent of volume size)
      • as of September 2025, supports up to 64 TiB (4x previous 16 TiB), 80,000 IOPS (5x previous 16,000), and 2,000 MiB/s throughput (2x previous 1,000 MiB/s)
      • 99.9% durability
      • 20% lower cost than gp2 with ability to independently provision IOPS and throughput
    • General Purpose SSD (gp2) – legacy, still supported
      • IOPS scales with volume size (3 IOPS per GiB), up to 16,000 IOPS
      • suitable for boot volumes, dev/test environments
      • recommended to migrate to gp3 for cost savings
    • Provisioned IOPS SSD (io2 Block Express) – highest performance
      • up to 256,000 IOPS, 4,000 MiB/s throughput, 64 TiB volume size
      • 99.999% durability (100x higher than io1)
      • sub-millisecond latency
      • 1,000 IOPS per GiB ratio (20x higher than io1)
      • supports Multi-Attach
      • same price as io1, recommended as replacement
      • available in all commercial and GovCloud regions (2025)
    • Provisioned IOPS SSD (io1) – legacy, being superseded by io2
      • up to 64,000 IOPS, 50 IOPS per GiB
      • 99.9% durability
      • recommended to upgrade to io2 Block Express for better performance at same cost
    • Throughput Optimized HDD (st1)
      • low-cost HDD for frequently accessed, throughput-intensive workloads
      • big data, data warehouses, log processing
      • max throughput 500 MiB/s, max IOPS 500
      • cannot be a boot volume
    • Cold HDD (sc1)
      • lowest cost HDD for less frequently accessed workloads
      • max throughput 250 MiB/s, max IOPS 250
      • cannot be a boot volume

EBS Encryption

  • allows encryption using the EBS encryption feature.
  • All data stored at rest, disk I/O, and snapshots created from the volume are encrypted.
  • uses 256-bit AES algorithms (AES-256) and an Amazon-managed KMS
  • Snapshots of encrypted EBS volumes are automatically encrypted.
  • EBS encryption by default can be enabled at the account level for all new volumes

EBS Snapshots

  • helps create backups of EBS volumes
  • are incremental
  • occur asynchronously
  • are regional and CANNOT span across regions
  • can be copied across regions to make it easier to leverage multiple regions for geographical expansion, data center migration, and disaster recovery
  • can be shared by making them public or with specific AWS accounts by modifying the access permissions of the snapshots
  • support EBS encryption
    • Snapshots of encrypted volumes are automatically encrypted
    • Volumes created from encrypted snapshots are automatically encrypted
    • All data in flight between the instance and the volume is encrypted
    • Volumes created from an unencrypted snapshot owned or have access to can be encrypted on the fly.
    • Encrypted snapshot owned or having access to, can be encrypted with a different key during the copy process.
  • can be automated using AWS Data Lifecycle Manager (DLM)
  • EBS Snapshots Archive – move rarely-accessed snapshots to a low-cost archive tier (up to 75% cheaper), with retrieval taking 24-72 hours
  • Recycle Bin – protects against accidental deletion by retaining deleted snapshots for a configurable retention period

EBS vs Instance Store

Refer blog post @ EBS vs Instance Store

EFS

  • fully-managed, easy to set up, scale, and cost-optimize 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 in multiple AZs simultaneously
  • highly durable, highly scalable and highly available.
    • stores data redundantly across multiple Availability Zones
    • grows and shrinks automatically as files are added and removed, so there is no need to manage storage procurement or provisioning.
  • uses the Network File System version 4 (NFS v4) protocol
  • is compatible with all Linux-based AMIs for EC2, POSIX file system (~Linux) that has a standard file API
  • does not support Windows AMI (use FSx for Windows 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 datacenter as well as EC2 instances in the Amazon VPC
  • supports up to 10,000 access points per file system (10x increase from previous 1,000 limit, February 2025)
  • Performance
    • Elastic Throughput (recommended) – automatically scales throughput up or down based on workload
      • up to 60 GiB/s read and 10 GiB/s write throughput (October 2024 increase)
    • Provisioned Throughput – specify throughput independent of storage
    • Bursting Throughput – scales with file system size
    • supports up to 2.5 million read IOPS and 500,000 write IOPS per file system (November 2024, 10x increase)
  • Storage Classes
    • EFS Standard – for frequently accessed files, multi-AZ redundancy
    • EFS Standard-IA (Infrequent Access) – lower cost for infrequently accessed files, multi-AZ redundancy
    • EFS One Zone – single-AZ, lower cost for frequently accessed data
    • EFS One Zone-IA – single-AZ, lowest cost for infrequent access
    • Lifecycle Management automatically moves data between storage classes based on access patterns
  • EFS Replication – enables automatic replication of file systems to another AWS Region or within the same Region for disaster recovery
  • EFS is a shared POSIX system for Linux systems and does not work for Windows

Amazon FSx for Windows File Server

  • is a fully managed, highly reliable, and scalable Windows file system share drive
  • supports SMB protocol & Windows NTFS
  • supports Microsoft Active Directory integration, ACLs, user quotas
  • built on SSD, scale up to 10s of GB/s, millions of IOPS, 100s PB of data
  • is accessible from Windows, Linux, and MacOS compute instances
  • can be accessed from the on-premise infrastructure
  • can be configured to be Multi-AZ (high availability)
  • supports encryption of data at rest and in transit
  • provides data deduplication, which enables further cost optimization by removing redundant data.
  • data is backed-up daily to S3

Amazon FSx for Lustre

  • provides easy and cost effective way to launch and run the world’s most popular high-performance file system.
  • is a type of parallel distributed file system, for large-scale computing
  • Lustre is derived from “Linux” and “cluster”
  • Machine Learning, High Performance Computing (HPC) esp. Video Processing, Financial Modeling, Electronic Design Automation
  • scales up to 100s GB/s, millions of IOPS, sub-ms latencies
  • seamless integration with S3, it transparently presents S3 objects as files and allows you to write changed data back to S3.
  • can “read S3” as a file system (through FSx)
  • can write the output of the computations back to S3 (through FSx)
  • supports encryption of data at rest and in transit
  • can be used from on-premise servers

Amazon FSx for NetApp ONTAP

  • fully managed shared storage built on NetApp’s popular ONTAP file system
  • supports NFS, SMB, and iSCSI protocols — accessible from Linux, Windows, and macOS
  • provides enterprise features: snapshots, cloning, replication, compression, deduplication, and tiering
  • supports Multi-AZ deployments for high availability
  • ideal for migrating on-premises NetApp/NAS workloads to AWS
  • second-generation file systems (July 2024) deliver up to 6 GBps throughput per HA pair
  • supports S3 Access Points (2025) — access file data through S3 APIs for AI/ML and analytics workloads without moving data
  • supports Autonomous Ransomware Protection (ARP) (April 2025) — detects unusual activity and generates automatic snapshots
  • can be accessed from on-premises via Direct Connect or VPN

Amazon FSx for OpenZFS

  • fully managed shared file storage built on the OpenZFS file system
  • supports NFS protocol (v3, v4, v4.1, v4.2)
  • delivers up to 1 million IOPS with sub-millisecond latencies
  • provides data management capabilities: snapshots, cloning, compression
  • ideal for migrating Linux-based file servers and applications to AWS
  • supports S3 Access Points (2025) — seamless access to file data through S3 APIs
  • accessible from Linux, Windows, and macOS compute instances

CloudFront

  • provides low latency and high data transfer speeds for distribution of static, dynamic web or streaming content to web users
  • delivers the content through a worldwide network of data centers called Edge Locations (700+ locations globally)
  • keeps persistent connections with the origin servers so that the files can be fetched from the origin servers as quickly as possible.
  • dramatically reduces the number of network hops that users’ requests must pass through
  • supports multiple origin server options, like AWS hosted service for e.g. S3, EC2, ELB or an on premise server, which stores the original, definitive version of the objects
  • single distribution can have multiple origins and Path pattern in a cache behavior determines which requests are routed to the origin
  • supports Web distribution for static, dynamic web content, on demand using progressive download & HLS and live streaming video content
    • RTMP Streaming distribution was deprecated and removed on December 31, 2020
  • supports HTTPS using either
    • dedicated IP address, which is expensive as dedicated IP address is assigned to each CloudFront edge location
    • Server Name Indication (SNI), which is free but supported by modern browsers only with the domain name available in the request header
  • For E2E HTTPS connection,
    • Viewers -> CloudFront needs either self signed certificate, or certificate issued by CA or ACM
    • CloudFront -> Origin needs certificate issued by ACM for ELB and by CA for other origins
  • Security
    • Origin Access Control (OAC) is the recommended method to restrict S3 origin access to CloudFront only. OAC supports SSE-KMS, all S3 bucket types, and dynamic requests (PUT/DELETE).
      • Origin Access Identity (OAI) is legacy — deprecated for new distributions as of March 2026. Migrate to OAC.
    • VPC Origins (November 2024) – enables CloudFront to connect directly to ALBs, NLBs, or EC2 instances in private subnets, making CloudFront the single point of entry without exposing origins to the internet
    • supports Geo restriction (Geo-Blocking) to whitelist or blacklist countries that can access the content
    • Signed URLs
      • to restrict access to individual files, for e.g., an installation download for your application.
      • users using a client, for e.g. a custom HTTP client, that doesn’t support cookies
    • Signed Cookies
      • provide access to multiple restricted files, for e.g., video part files in HLS format or all of the files in the subscribers’ area of a website.
      • don’t want to change the current URLs
    • integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configured based on IP addresses, HTTP headers, and custom URI strings
    • integrates with AWS Shield (Standard included free) for DDoS protection
  • Edge Compute
    • CloudFront Functions – lightweight functions executing at 700+ edge locations with sub-millisecond startup, for simple request/response manipulations (URL redirects, header manipulation, cache key normalization)
    • Lambda@Edge – runs at 13 Regional Edge Caches, supports longer execution (up to 30 seconds), network access, and larger packages for complex logic
    • CloudFront KeyValueStore (2023) – globally distributed low-latency data store for CloudFront Functions, enabling data lookups without network calls (A/B testing, feature flags, geo-routing)
    • Connection Functions (November 2025) – functions for mutual TLS (mTLS) viewer authentication
  • supports GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE to get object & object headers, add, update, and delete objects
    • only caches responses to GET and HEAD requests and, optionally, OPTIONS requests
    • does not cache responses to PUT, POST, PATCH, DELETE request methods and these requests are proxied back to the origin
  • object removal from cache
    • would be removed upon expiry (TTL) from the cache, by default 24 hrs
    • can be invalidated explicitly, but has a cost associated, however might continue to see the old version until it expires from those caches
    • change object name, versioning, to serve different version
  • supports adding or modifying custom headers before the request is sent to origin which can be used to
    • validate if user is accessing the content from CDN
    • identifying CDN from which the request was forwarded from, in case of multiple CloudFront distribution
    • for viewers not supporting CORS to return the Access-Control-Allow-Origin header for every request
  • supports Partial GET requests using range header to download object in smaller units improving the efficiency of partial downloads and recovery from partially failed transfers
  • supports compression to compress and serve compressed files when viewer requests include Accept-Encoding: gzip in the request header
  • supports different price class to include all regions, to include only least expensive regions and other regions to exclude most expensive regions
  • CloudFront Pricing Plans (2025) – flat-rate plans (Free, Pro $15/mo, Business $200/mo, Premium $1000/mo) combining CDN, WAF, DDoS protection, bot management, Route 53, and S3 credits into predictable monthly pricing
  • Origin Shield – additional caching layer between edge locations and origin that reduces origin load and improves cache hit ratios
  • Continuous Deployment – enables safe deployment of CloudFront configuration changes using staging distributions for testing with a subset of traffic
  • supports access logs which contain detailed information about every user request

AWS Import/Export & Data Transfer

⚠️ AWS Import/Export Disk is a legacy service and has been superseded by the AWS Snow Family. AWS Snow Family devices (Snowball Edge) are no longer available to new customers as of November 7, 2025.

Alternatives for new customers:

  • AWS DataSync — for online data transfers
  • AWS Data Transfer Terminal — for secure physical transfers
  • AWS Partner solutions — for specialized migration needs
  • AWS Outposts — for edge computing needs

AWS Snow Family (Existing Customers Only)

  • physical devices for transferring large amounts of data into and out of AWS
  • Snowball Edge Storage Optimized – 80 TB usable storage, 40 vCPUs
  • Snowball Edge Compute Optimized – 28 TB usable storage, 104 vCPUs, optional GPU
  • suitable for large-scale data migrations, disaster recovery, and edge computing
  • supports S3-compatible storage and EC2 compute instances at the edge
  • No longer available to new customers as of November 7, 2025

AWS Data Transfer Terminal (2024)

  • secure, physical locations where customers bring their storage devices for high-speed data transfer to/from AWS
  • provides at least two 100 Gigabit Ethernet (100 GbE) ports per terminal
  • supports transfer to Amazon S3, EFS, and other AWS endpoints
  • available in multiple locations globally (US, Europe, etc.)
  • reservation-based model — book date and time through AWS Console
  • ideal replacement for Snow Family for physical data transfer use cases
  • charges based on number of ports used during reservation (per port-hour)

AWS DataSync

  • online data transfer service that simplifies, automates, and accelerates moving data between on-premises storage and AWS
  • supports transfer to/from S3, EFS, FSx, and between AWS storage services
  • automatically handles many transfer tasks: network optimization, data integrity validation, encryption
  • can transfer up to 10 Gbps over a Direct Connect link
  • recommended alternative to Snow Family for online transfers

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