3.2 Amazon EBS Performance Metrics & Volume Tuning

AWS Certified CloudOps Engineer – Associate SOA-C03

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Monitoring & Observability Infrastructure

1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms

2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation

2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda

3 Chapter 3: Performance Optimization for Compute, Storage & Databases

3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance

4 Chapter 4: Compute & Database Scalability and Elasticity

4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB

5 Chapter 5: High Availability, Fault Tolerance & Load Balancing

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments

6 Chapter 6: Backup, Data Protection & Disaster Recovery

6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience

7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK

7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures

8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC

8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows

9 Chapter 9: Systems Manager & Event-Driven Operations Automation

9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation

10 Chapter 10: Identity, Access Management & Governance

10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs

11 Chapter 11: Data Security, Encryption & Vulnerability Management

11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings

12 Chapter 12: VPC Architecture, Endpoints & Network Protection

12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing

13 Chapter 13: DNS, Route 53 Routing & Content Delivery

13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator

14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity

14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting

3.2 Amazon EBS Performance Metrics & Volume Tuning

Key Takeaways Explain This Topic AI

Amazon EBS gp3 volumes provide a baseline performance of 3,000 IOPS and 125 MB/s throughput independently of storage capacity, eliminating gp2's requirement to overprovision disk size to obtain I/O performance.

Mission-critical workloads requiring sub-millisecond latency and extreme I/O performance use io2 Block Express, delivering up to 256,000 IOPS, 4,000 MB/s throughput, and 99.999% durability.

Key CloudWatch metrics for identifying EBS bottlenecks include VolumeQueueLength, VolumeThroughputPercentage, and BurstBalance, with high queue length and elevated latency signaling I/O starvation.

Micro-bursting occurs when rapid I/O bursts exhaust volume or instance bandwidth limits within sub-minute intervals, often masked by standard 1-minute or 5-minute CloudWatch metric averages.

Elastic Volumes allow online modification of volume size, IOPS, and volume type with zero downtime, subject to a 6-hour cooldown period between modifications on a single volume.

Last updated: October 2026

3.2 Amazon EBS Performance Metrics & Volume Tuning

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests operational mastery of Amazon EBS storage systems: evaluating volume performance profiles, interpreting CloudWatch storage metrics, diagnosing micro-bursting and instance limits, and executing zero-downtime volume modifications with Elastic Volumes.

Amazon EBS Storage Fabric Architecture

Amazon Elastic Block Store (EBS) delivers persistent block storage for Amazon EC2 compute instances. EBS volumes are network appliances operating within an Availability Zone. Every I/O request traverses internal instance buses, passes through the hypervisor or AWS Nitro card, and crosses network links to replicated storage servers. Performance is bounded by both volume specifications and host EC2 instance limits.

EBS Volume Types & Performance Characteristics

Selecting the appropriate EBS volume type requires matching workload I/O profiles (random vs. sequential, small-block vs. large-block) against throughput, IOPS baselines, and cost: +-------------------------------------------------------------------------+

| Amazon EBS Volume Taxonomy |
+------------------------------------+------------------------------------+
| Solid State Drives (SSD) | Hard Disk Drives (HDD) |
| (Transactional, Small-Block I/O) | (Throughput, Large Sequential) |
+------------------+-----------------+------------------+-----------------+
| General Purpose | Provisioned IOPS| Throughput Opt. | Cold HDD |
| (gp3 / gp2) | (io2 / io2 Block| (st1) | (sc1) |
| | Express) | | |
+------------------+-----------------+------------------+-----------------+
1. General Purpose SSD: gp3 vs. gp2

gp3 (Recommended Default): Decouples storage capacity from performance. Every gp3 volume includes 3,000 IOPS and 125 MB/s throughput across all sizes (1 GiB to 64 TiB). Engineers can provision up to 80,000 IOPS (500 IOPS per GiB) and 2,000 MiB/s throughput without moving to another volume type, saving 20% per GB compared to gp2.

gp2 (Legacy Burst Model): Couples performance to storage at 3 IOPS per GB . Volumes under 1,000 GB burst to 3,000 IOPS using I/O credits. When depleted, performance collapses to baseline (e.g., 100 GB drops to 300 IOPS). Guaranteeing 6,000 IOPS on gp2 required provisioning 2,000 GB, wasting capacity.

2. Provisioned IOPS SSD: io2 & io2 Block Express

Engineered for mission-critical transactional databases (SAP HANA, Oracle, SQL Server) requiring sub-millisecond latency.

io2 Block Express: Powered by the AWS Nitro System, delivers up to 256,000 IOPS , 4,000 MB/s throughput , and up to 64 TB volumes with 1,000 IOPS per GB. Durability is 99.999% (a 100x improvement over standard SSDs).

3. Magnetic Hard Disk Drives: st1 & sc1

Throughput Optimized HDD (st1): Low-cost magnetic storage for frequent, large sequential I/O (MapReduce, Kafka logs, data warehouses), delivering up to 500 MB/s using burst credits.

Cold HDD (sc1): Lowest-cost block storage for infrequently accessed sequential workloads.

Operational Restriction: Neither st1 nor sc1 can serve as bootable root volumes.

Volume Type Max IOPS Max Throughput Latency Target Common Workload
gp3 80,000 2,000 MiB/s Single-digit ms Web servers, dev environments, medium DBs
gp2 16,000 250 MB/s Single-digit ms Legacy deployments (migrating to gp3)
io2 Block Express 256,000 4,000 MB/s Sub-millisecond Core enterprise transactional databases
st1 500 500 MB/s Tens of ms Sequential streaming, big data, log processing
sc1 250 250 MB/s Tens of ms Infrequent sequential archives, cold data
Critical CloudWatch EBS Performance Metrics

Monitoring EBS performance requires tracking volume-level CloudWatch metrics:

VolumeReadOps & VolumeWriteOps : Completed I/O operations per period. Average IOPS equals total operations divided by period duration in seconds.

VolumeReadBytes & VolumeWriteBytes : Data transferred. Throughput (MB/s) equals total bytes divided by period duration.

VolumeTotalReadTime & VolumeTotalWriteTime : Total time executing operations. Dividing total elapsed time by total operations yields average I/O latency .

VolumeQueueLength : Number of outstanding read and write requests waiting in queue. A sustained high queue length combined with elevated latency signals storage saturation.

VolumeThroughputPercentage : Percentage of provisioned throughput consumed.

BurstBalance : Percentage of remaining burst credits (0% to 100%) for burstable volumes (gp2, st1, sc1). Depletion to 0% throttles performance to baseline.

Troubleshooting Bottlenecks: Micro-bursting vs. Instance Limits

When disk latency degrades performance, engineers must isolate the constraint:

Micro-bursting

Applications often execute sharp bursts of I/O lasting milliseconds. Standard CloudWatch 1-minute or 5-minute averages flatten these spikes, reporting an average utilization of only 30%. However, during those fractional seconds, operations exceed limits and queue up, stalling application threads. Engineers detect micro-bursting by tracking VolumeQueueLength spikes or inspecting operating system tools like iostat -xz 1 for elevated %util and await .

Instance-Level EBS Bandwidth Throttling

Every EC2 instance type possesses dedicated EBS-optimized bandwidth and IOPS limits . Attaching a gp3 volume provisioned for 10,000 IOPS and 500 MB/s to an m5.large instance results in hypervisor-level throttling, because that instance size sustains only a baseline of 3,600 IOPS and 650 Mbps (81.25 MB/s) of EBS bandwidth, bursting to 18,750 IOPS and 4,750 Mbps (593.75 MB/s) for a limited period each day. Excess I/O queues before reaching storage, resulting in elevated VolumeQueueLength while the volume appears underutilized in CloudWatch.

Elastic Volumes: Dynamic Tuning & Cooldown Constraints

Amazon EBS Elastic Volumes allows administrators to modify volume size, adjust provisioned IOPS and throughput, or alter volume types (e.g., gp2 to gp3) dynamically without unmounting filesystems, detaching volumes, or rebooting instances.

The Elastic Volume Lifecycle

Modifying: The modification request is registered by the EBS control plane.

Optimizing: Performance characteristics adjust. New capacity and baseline IOPS are immediately available, while background block restriping continues.

Completed: Background restriping completes. [Trigger Modification] ---> [Modifying State] ---> [Optimizing State] ---> [Completed State]

(Capacity Active) (Background restripe) (Cooldown active)

Warning

Once a modification begins, AWS enforces a mandatory 6-hour cooldown period before another modification can be initiated on the same volume.

Operating System Filesystem Expansion

After Elastic Volumes expands the block allocation, the operating system filesystem must be extended online using partition utilities ( growpart ) and filesystem tools ( xfs_growfs for XFS or resize2fs for ext4) without downtime.