Context
Increasing gp3 IOPS does not automatically make an EBS-backed application faster. The workload may already be limited by throughput, the EC2 instance's aggregate EBS allowance, synchronous application behavior, or a different dependency. Start with the size and concurrency of real I/O, then identify the smallest active ceiling.
Separate operations from transferred bytes
IOPS counts operations per second. Throughput counts bytes per second. For an illustrative workload, 4,000 operations per second at 16 KiB represents about 62.5 MiB/s of payload. The same operation count at 256 KiB represents about 1,000 MiB/s before accounting for how the platform splits or merges requests.
This arithmetic is a planning approximation, not a measurement of EBS billing or performance. AWS documents the I/O sizes used for different limits. Use those definitions when comparing application requests with EBS metrics. Also distinguish MiB/s from MB/s when moving values between dashboards.
Inspect both the volume and the instance
Record volume type, provisioned IOPS, provisioned throughput, size, attachment, and modification state. gp3 uses provisioned performance rather than gp2's burst-credit model. Do not interpret a missing gp2-style credit graph as a gp3 monitoring failure.
Find the selected instance's baseline and maximum EBS performance and whether its behavior includes an instance-level burst allowance. Other attached volumes share relevant instance limits. A busy backup volume can therefore affect a database volume whose own provisioned settings look sufficient.
Capture volume operations, transferred bytes, queueing, and latency during the customer-visible incident. Correlate these with guest iostat output and application timings. A cumulative counter needs an interval delta; an average graph can conceal a brief saturation event.
Find the workload's actual I/O pattern
A database doing small random reads may reach its operation budget with modest transferred bytes. A large sequential export may hit throughput while reporting relatively few operations. A single synchronous writer may wait for completion after every write and never submit enough work to reach either headline maximum.
Collect queue depth and read/write mix before changing configuration. Low queue depth with high application latency can indicate serialization, CPU work, or another dependency. High queue depth is evidence of waiting work, but does not identify the volume as the only bottleneck.
For volumes created from snapshots, consider initialization behavior separately. A cold first read and a steady-state read are different experiments. Record whether prewarming or the provider's initialization features are involved.
An illustrative export bottleneck
A nightly export reads large blocks and becomes slow after a database migration. The team doubles IOPS, but throughput remains flat. Comparing bytes with operations reveals large average requests; the configured throughput budget is already being reached.
A test raises throughput within supported limits and improves completion time. A second test then reaches the instance's aggregate EBS boundary. The final design accounts for both settings and reschedules a competing backup. Buying more of only one resource would have left part of the problem unresolved.
Quick diagnostic map
| Evidence | Interpretation to test | Next check |
|---|---|---|
| Operations plateau; bytes remain low | Small-I/O operation ceiling | Provisioned IOPS and request size |
| Bytes plateau; operations remain modest | Throughput ceiling | Volume throughput setting |
| Several volumes slow together | Shared instance allowance | Aggregate EBS metrics |
| Low device queue; slow business task | Work submitted serially | Application profile and dependencies |
A focused operator exercise
Reproduce the workload on a disposable, correctly sized test volume using representative data. Record block size, read/write ratio, queue depth, duration, and synchronization settings. Avoid running destructive raw-device benchmarks against production data.
Change one performance setting and repeat the same accepted workload. Compare useful completed work, percentile latency, volume queueing, and aggregate instance activity. Include a run with the expected backup overlap. Preserve the result with the exact instance type and volume configuration so it remains interpretable after a later resize.
Verify the improvement beyond the benchmark
Confirm that the application finishes the same task with correct output and without displacing another workload. Observe a complete business cycle. Extra IOPS or throughput adds cost even when the application cannot use it, so compare provisioned capacity with sustained and peak demand.
Keep data durability settings unchanged during the capacity experiment. Reducing synchronization requirements can make a benchmark faster while changing the recovery contract. That is a separate architecture decision requiring its own evidence.
Frequently asked questions
Does a bigger gp3 volume always provide more performance?
gp3 allows performance to be provisioned separately, subject to documented size and ratio constraints. Inspect the actual settings and current platform limits rather than assuming capacity alone increased performance.
Can two volumes each reach their advertised maximum simultaneously?
Only when the instance and workload can support their combined demand. Verify the aggregate EC2 EBS allowance as well as each volume's settings.
Continue the investigation
- Amazon EBS Resizing: Why the Linux Filesystem Still Looks Full
- Linux Iowait: Connect CPU Accounting to Storage Evidence
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix NAS, SAN & File Server Infrastructure to discuss implementation, validation and operational handover.