Published IOPS do not predict application speed. Effective performance stops at the lowest limit.
That limit may be the disk, VM, network path, cache, filesystem, size, or queue depth. Measure sustained latency, IOPS, and throughput.
AWS EBS or Azure disks by workload
For general SSD storage, compare AWS gp3 with Premium SSD v2. For sustained database I/O, compare io2 Block Express with Ultra Disk.
Use equal capacity, provisioned limits, VM class, and region. Otherwise, the result compares two different systems.
General apps: gp3 or Premium SSD v2
Choose gp3 for configurable Amazon EC2 storage. It includes 3,000 IOPS and 125 MiB/s.
It can scale to 80,000 IOPS and 2,000 MiB/s. Volume size and instance support must allow those limits.
Choose Premium SSD v2 for Azure VMs needing separate capacity, IOPS, and throughput settings. Its usable speed still depends on uncached VM limits.
Databases: io2 Block Express or Ultra Disk
Choose io2 Block Express for AWS databases that need up to 256,000 IOPS. It can also reach 4,000 MiB/s with low latency.
The EC2 family must supply enough EBS bandwidth. A fast disk cannot bypass a slow VM connection.
Choose Ultra Disk for Azure databases needing up to 400,000 IOPS and 10,000 MB/s. Regional availability and VM support must permit it.
Lower-cost boot and archive tiers
Use Standard SSD or Premium SSD for normal boot disks. Use Standard HDD, AWS st1, or AWS sc1 for cold or sequential data.
These HDD tiers accept high latency. They do not fit transaction paths.
A useful block storage choice starts with the workload, not headline disk IOPS. Use gp3 or Premium SSD v2 for boot disks and app volumes.
They also fit Kubernetes persistent volumes and moderate databases. Confirm that measured p95 latency stays within your target.
Put OLTP data and write-ahead logs on io2 Block Express or Ultra Disk only when needed. The VM must also consume the provisioned performance.
In other words, the workload should set the disk tier.
VDI needs steady read IOPS and enough total VM bandwidth during login storms. Analytics and backup jobs often value large-block throughput more than low random-I/O latency.
Standard SSD usually fits low-use operating-system disks. HDD tiers fit archives and long sequential scans, not transaction paths.
Choose gp3 or Premium SSD v2 for most mixed workloads. The next section shows why VM limits can erase their paper advantage.
Disk tiers cannot override VM ceilings. Add demand from boot, logs, database, and backup volumes.
Then compare that total with Amazon EC2 EBS limits. On Azure, compare it with cached and uncached disk limits.
| Comparable tier | Published disk ceiling | US list-price components | Best fit |
|---|
| EBS gp3 | 80,000 IOPS, 2,000 MiB/s | $0.08/GB-month; first 3,000 IOPS and 125 MiB/s included | General app, boot, moderate DB |
| Premium SSD v2 | 80,000 IOPS, 1,200 MB/s | About $0.08/GB-month; IOPS and MB/s billed separately above included levels | General-purpose SSD |
| io2 Block Express | 256,000 IOPS, 4,000 MiB/s | $0.125/GB-month; IOPS commonly start near $0.065 per IOPS-month | Latency-sensitive OLTP |
| Ultra Disk | 400,000 IOPS, 10,000 MB/s | About $0.12/GiB-month; IOPS and MB/s are separate charges | Very high I/O Azure databases |
Find throttling before resizing
A steady queue, rising p95 latency, and flat IOPS point to throttling. These signs are more useful than a brief CPU spike.
Check AWS volume and instance data. Check Azure disk usage against cached and uncached VM caps.
Cache can distort comparisons
Azure host caching can speed up repeated reads. Warm-cache results do not show uncached transaction write latency.
Record the cache mode. Report separate read and write results.
Cost example: A 1 TiB gp3 volume at its included 3,000 IOPS costs about $81.92 per month in US East before snapshots. Raising it to 16,000 IOPS adds roughly $65 monthly. That spend is wasted if the EC2 instance cannot deliver the combined IOPS.
Compare monthly cost as a full configuration. Do not compare only the disk-price line.
For each option, add capacity charges and IOPS above included levels. Also add throughput, snapshots, backup copies, and the required VM price.
A gp3 volume with 16,000 provisioned IOPS may cost less than io2. Its real price rises if the workload needs a larger EC2 instance.
VM limits often create the hidden bill.
Premium SSD v2 and Azure Ultra Disk also charge separately for capacity, IOPS, and throughput. A small but I/O-heavy database can cost more than its size implies.
Calculate cost per sustained usable IOPS. Also calculate cost for the validated p95 latency target.
Choose the tier that your VM can actually feed. Next, test whether that configuration holds speed under real load.
Benchmark equal disks under sustained load
Compare the same operating system, filesystem, VM class, capacity, and provisioned limits. Use the same production region.
Measure p50, p95, and p99 latency. Published maximums do not guarantee p99 latency.
Use production-shaped fio tests
Use fio with direct I/O, real block sizes, and real queue depth. Run separate read, write, and mixed tests.
Run each test for 30 to 60 minutes after warm-up. Record IOPS, throughput, CPU, queue depth, and latency percentiles.
Record the whole I/O path
Record VM SKU, vCPUs, RAM, controller, filesystem, and mount options. Record cache mode, RAID layout, and CSI version.
Kubernetes attach limits and zone affinity can restrict persistent-volume speed. Filesystem choices can also change the result.
Pass rule: Keep the disk and VM pair only if one-hour p99 write latency meets the application's target. IOPS and throughput should remain below 80% of the tested VM ceiling. Leave room for backups, checkpoints, and growth.
Plan migration validation
Validate snapshots, encryption, recovery, and rollback before moving production data. Service agreements and compliance certifications do not guarantee a specific query latency target.
This approach works in theory, but short tests often hide sustained throttling. The common mistake is testing an empty volume with an unrealistic queue depth.
Test the whole path, not just the disk.
Do not make disk performance comparisons the main decision for stateless apps. The same applies to apps using Amazon S3 or Azure Blob Storage, as well as apps with very low I/O. If CPU, RAM, egress, licenses, or regional access limit you, compute and architecture matter more.
Treat provider specifications as ceilings, not expected app results. Included baseline performance needs no extra provisioning on tiers such as EBS gp3.
Some tiers offer burst allowances. A burst can make a short test look better than a sustained production run.
Effective AWS EBS and Managed Disks performance stops at the lowest active limit. Limits include disk settings, VM caps, EBS bandwidth, block size, queue depth, and host caching.
Record whether throttling starts after warm-up. Compare requested and delivered IOPS, throughput, queue depth, and p95 latency.
Use at least one sustained test window. A brief published maximum does not equal steady performance during backups and mixed I/O.
Choose based on sustained latency under your own load. The questions below address the most common edge cases.
What people ask
Is Azure faster than AWS for disk storage?
Azure is not inherently faster than AWS. VM caps, tier, cache mode, region, and I/O pattern set sustained p95 and p99 latency.
What is Azure's equivalent of AWS EBS?
Managed Disks is the closest equivalent to Amazon EBS. Premium SSD v2 broadly compares with gp3, while Ultra Disk compares with io2 Block Express.
How do I fix high AWS EBS latency?
Check instance EBS limits, queue depth, burst status, and read/write mix before adding IOPS. Then test a larger instance or separate data and log volumes.
Does SSD always beat HDD for cloud databases?
SSD is safer for database data because random I/O latency is much lower. HDD still suits backups, archives, and long sequential scans.
Kubernetes can reduce effective performance through CSI behavior, attach limits, filesystem choices, and zone affinity. Measure inside both the pod and node.
Is io2 Block Express worth its cost?
It is worthwhile when gp3 misses a tested p99 write target and the VM supports required IOPS. It is excessive for lightly used workloads.
Does a CDN lower EBS or Azure disk latency?
A CDN does not lower database disk latency because it caches web content, not VM block reads. CloudFront and Azure Front Door address delivery latency instead.
Choose the disk your VM can consume
Start with gp3 on AWS or Premium SSD v2 on Azure. They fit boot disks, app data, Kubernetes volumes, and moderate databases.
Move to io2 Block Express or Ultra Disk only when sustained tests prove premium performance is needed.
- The essential point: Disk performance stops at the weakest layer, often the VM instead of the volume.
- The useful default: Start with gp3 on AWS or Premium SSD v2 on Azure. Measure sustained latency.
- The premium path: Use io2 Block Express or Ultra Disk only when p99 write latency requires it.
- The migration rule: Validate cache mode, CSI behavior, snapshots, recovery, and one-hour workload-shaped tests before cutover.
Related sources
These articles can help you explore the topic in more depth:
