Performance problems in cloud architectures frequently originate in storage. An application may have powerful compute and well-tuned databases, but if the underlying storage cannot deliver data fast enough, every layer above it suffers. This section covers the three categories of AWS storage relevant to high-performance design: block storage (EBS), object storage (S3), and file storage (EFS, FSx).
Amazon EBS Volume Types and Performance Characteristics
Amazon Elastic Block Store (EBS) provides persistent block-level storage volumes for EC2 instances. The key performance dimensions for any EBS volume are IOPS (input/output operations per second), throughput (measured in MiB/s), and latency.
EBS offers two families of volume types: SSD-backed for random I/O workloads and HDD-backed for sequential I/O workloads.
SSD-Backed Volumes
General Purpose SSD (gp3) is the recommended default volume type. It delivers a baseline of 3,000 IOPS and 125 MiB/s of throughput at any volume size, with no burst credit mechanism. You can independently provision additional IOPS up to 80,000 and throughput up to 2,000 MiB/s without increasing volume size. gp3 volumes range from 1 GiB to 64 TiB. The ability to decouple performance from capacity is the defining advantage of gp3 over its predecessor gp2.
# Create a gp3 volume with custom IOPS and throughput
aws ec2 create-volume \
--volume-type gp3 \
--size 500 \
--iops 10000 \
--throughput 500 \
--availability-zone us-east-1a
General Purpose SSD (gp2) is the previous generation. Its performance scales with volume size at a rate of 3 IOPS per GiB, with a baseline minimum of 100 IOPS and a maximum of 16,000 IOPS. Volumes smaller than 1,000 GiB can burst to 3,000 IOPS using an I/O credit system. When burst credits are exhausted, performance drops to the baseline. Maximum throughput is 250 MiB/s. gp2 volumes range from 1 GiB to 16 TiB.
💡 Exam Trap: gp3 provides 3,000 IOPS as a sustained baseline at every volume size. gp2 only reaches 3,000 baseline IOPS at 1,000 GiB (3 IOPS x 1,000 GiB). Smaller gp2 volumes can burst to 3,000 IOPS temporarily but fall back to their baseline when credits deplete. If the scenario describes "consistent" or "sustained" IOPS, gp3 is the safer choice.
Provisioned IOPS SSD (io2 Block Express) targets mission-critical workloads that demand the highest performance and durability. io2 Block Express volumes support up to 256,000 IOPS and 4,000 MiB/s throughput per volume. They provide 99.999% durability (compared to 99.8%-99.9% for gp2/gp3) and deliver sub-millisecond average latency. The IOPS-to-GiB ratio is up to 1,000:1. Volume sizes range from 4 GiB to 64 TiB.
Provisioned IOPS SSD (io1) is the older provisioned IOPS type. It supports up to 64,000 IOPS per volume and a 50:1 IOPS-to-GiB ratio. io1 offers 99.9% durability. For new deployments, io2 Block Express is preferred.
Multi-Attach is supported on io2 and io1 volumes. It allows a single EBS volume to be attached to up to 16 Nitro-based EC2 instances within the same Availability Zone simultaneously. The application must manage concurrent write access (for example, using a cluster-aware file system). Multi-Attach does not work across Availability Zones.
💡 Exam Trap: Multi-Attach is only available on io1 and io2 volumes, not on gp2 or gp3. The instances must all reside in the same Availability Zone as the volume.
HDD-Backed Volumes
Throughput Optimized HDD (st1) is designed for frequently accessed, large, sequential workloads such as MapReduce, Kafka log segments, data warehousing, and ETL. Maximum throughput is 500 MiB/s per volume. st1 uses a burst-credit model with a baseline throughput of 40 MiB/s per TiB. Volume sizes range from 125 GiB to 16 TiB. st1 cannot be used as a boot volume.
Cold HDD (sc1) is the lowest-cost EBS option, designed for infrequently accessed sequential workloads. Maximum throughput is 250 MiB/s. Baseline throughput is 12 MiB/s per TiB. sc1 cannot be used as a boot volume.
💡 Exam Trap: Neither st1 nor sc1 can serve as boot volumes. If the question describes a boot volume, the answer must be an SSD type (gp2, gp3, io1, or io2).
EBS Performance and EC2 Instance Limits
The performance of an EBS volume is also constrained by the EC2 instance to which it is attached. Each instance type has a maximum aggregate EBS throughput, IOPS, and bandwidth. For example, even if you provision an io2 volume with 256,000 IOPS, you will only achieve that if the instance type supports it. EBS-optimized instances provide dedicated bandwidth between the instance and EBS. Most current-generation instances are EBS-optimized by default.
Elastic Volumes
EBS Elastic Volumes lets you modify volume type, size, IOPS, and throughput on a live, attached volume without downtime. After modification, the volume enters an "optimizing" state during which the change is applied. You can only modify a volume once every six hours.
Decision Tree: Choosing the Right EBS Volume Type
Amazon S3 Performance Optimization
Amazon S3 (introduced in Chapter 1 for encryption and lifecycle policies) is an object storage service. From a performance perspective, S3 provides several mechanisms to maximize throughput.
Request rate performance. S3 supports at least 3,500 PUT/COPY/POST/DELETE requests per second and 5,500 GET/HEAD requests per second per prefix in a bucket. By distributing objects across multiple prefixes, you can scale read and write throughput linearly.
S3 Transfer Acceleration uses CloudFront edge locations to accelerate uploads over long geographic distances. Data is routed from the client to the nearest edge location over the internet, and then from the edge location to the S3 bucket over the optimized AWS backbone network. Transfer Acceleration is enabled per bucket and adds a distinct endpoint (bucketname.s3-accelerate.amazonaws.com).
# Enable Transfer Acceleration on a bucket
aws s3api put-bucket-accelerate-configuration \
--bucket my-data-bucket \
--accelerate-configuration Status=Enabled
# Upload using the accelerated endpoint
aws s3 cp largefile.zip s3://my-data-bucket/ --endpoint-url https://my-data-bucket.s3-accelerate.amazonaws.com
S3 Multipart Upload is required for objects larger than 5 GiB and recommended for objects larger than 100 MiB. It allows parallel upload of parts, which increases throughput and provides resilience (failed parts can be retried individually). Each part can be between 5 MiB and 5 GiB, and a single upload can consist of up to 10,000 parts.
Byte-range fetches allow a GET request to retrieve only a specific range of bytes from an object. This enables parallel downloads of different segments of a single large object, significantly improving read throughput.
S3 Express One Zone
S3 Express One Zone is a high-performance storage class purpose-built for latency-sensitive applications. It delivers data access up to 10x faster than S3 Standard with consistent single-digit millisecond latency. Data is stored within a single Availability Zone that you select, using a new bucket type called a directory bucket. Directory buckets support up to 2 million requests per second.
Key characteristics of S3 Express One Zone:
- Request costs are up to 50% lower than S3 Standard
- Data is stored in a single AZ, meaning it is susceptible to AZ-level failure
- Uses session-based authorization optimized for low-latency access
- Ideal for ML training data, financial modeling, media processing, and HPC workloads
- Does not support S3 Lifecycle transitions to or from other storage classes
💡 Exam Trap: S3 Express One Zone is stored in a single Availability Zone and uses directory buckets. It does not provide the same multi-AZ durability as S3 Standard (11 nines across multiple AZs). If the question requires high durability and cross-AZ resilience, S3 Standard is the answer. If the question prioritizes lowest latency for frequently accessed data, S3 Express One Zone applies.
S3 Intelligent-Tiering
S3 Intelligent-Tiering automatically moves objects between access tiers based on observed access patterns with no retrieval fees and no performance impact. It includes three automatic tiers: Frequent Access, Infrequent Access (after 30 days of no access), and Archive Instant Access (after 90 days). Optional tiers for Archive Access (after 90-730 days configurable) and Deep Archive Access can be activated. This storage class is suitable when access patterns are unknown or unpredictable.
Shared File Storage: EFS and FSx
Amazon Elastic File System (EFS) is a fully managed, elastic NFS file system that can be mounted concurrently by thousands of EC2 instances and containers across multiple Availability Zones. EFS automatically grows and shrinks as files are added or removed.
EFS offers two performance modes:
- General Purpose (default) - ideal for latency-sensitive workloads such as web serving and content management. Provides the lowest per-operation latency.
- Max I/O - optimized for workloads that require the highest aggregate throughput and can tolerate slightly higher latencies, such as big data analytics and media processing.
EFS offers two throughput modes:
- Elastic (default) - automatically scales throughput up and down based on workload demands. Recommended for spiky or unpredictable workloads.
- Provisioned - lets you specify a fixed throughput regardless of storage size. Useful for workloads that need consistent throughput independent of data stored.
- Bursting - throughput scales with file system size. Small file systems can burst.
💡 Exam Trap: EFS General Purpose performance mode is the default and correct choice for most workloads. Max I/O mode is only necessary when hundreds or thousands of instances need simultaneous access at very high aggregate throughput. Max I/O has higher per-operation latency. If the question describes a web application or CMS, the answer is General Purpose.
Amazon FSx provides fully managed third-party file systems:
- FSx for Windows File Server - fully managed Windows-native (SMB protocol) file system with Active Directory integration, supporting NTFS, DFS, and Windows ACLs. Supports SSD and HDD storage options. Provides up to hundreds of thousands of IOPS and multiple GiB/s throughput.
- FSx for Lustre - high-performance file system designed for compute-intensive workloads such as HPC, ML training, and video processing. Can deliver hundreds of GiB/s throughput and millions of IOPS. Integrates natively with S3: an FSx for Lustre file system can be linked to an S3 bucket, presenting S3 objects as files and lazily loading them on first access.
- FSx for NetApp ONTAP - fully managed shared storage with NetApp ONTAP features, supporting NFS, SMB, and iSCSI protocols. Provides data deduplication, compression, and cloning.
- FSx for OpenZFS - managed OpenZFS file system with NFS access, supporting data compression, snapshots, and cloning.
💡 Exam Trap: FSx for Lustre is the answer when the scenario describes HPC or ML training workloads that need high throughput and low latency with an S3 data lake integration. EFS is the answer for general-purpose Linux shared storage. FSx for Windows File Server is the answer when Windows, SMB, or Active Directory is mentioned.
Storage performance is only one dimension of overall system speed. The next step is ensuring your compute layer can process data as fast as storage can deliver it.