If you’re running high-performance databases or SAN-style workloads on AWS, your default move is probably Amazon EBS. It makes sense on the surface. EBS is simple, it’s "right there," and it’s been the backbone of EC2 for over a decade.
But let’s be real: EBS is a disk management strategy, not a data management strategy.
When you attach an EBS volume to an instance, you’ve basically just plugged in a virtual cable. You are now responsible for that disk’s performance, its sizing, and its specific lifecycle. If you want that data elsewhere, you have to snapshot it, move it to S3, and rehydrate it into a new volume. It’s a lot of manual "plumbing."
If you’re starting to feel the weight of managing thousands of individual volumes, it’s time to look at Amazon FSx for NetApp O…
If you’re running high-performance databases or SAN-style workloads on AWS, your default move is probably Amazon EBS. It makes sense on the surface. EBS is simple, it’s "right there," and it’s been the backbone of EC2 for over a decade.
But let’s be real: EBS is a disk management strategy, not a data management strategy.
When you attach an EBS volume to an instance, you’ve basically just plugged in a virtual cable. You are now responsible for that disk’s performance, its sizing, and its specific lifecycle. If you want that data elsewhere, you have to snapshot it, move it to S3, and rehydrate it into a new volume. It’s a lot of manual "plumbing."
If you’re starting to feel the weight of managing thousands of individual volumes, it’s time to look at Amazon FSx for NetApp ONTAP (FSxN) as your iSCSI block storage layer.
The "Shared Nothing" Trap The biggest limitation of EBS is that it is fundamentally a "pinned" resource. Even with Multi-Attach on io2 volumes, you are limited in how you can share that block storage across a cluster.
FSxN treats block storage as a Fabric. You create an iSCSI LUN, and it’s immediately available to your entire cluster. You aren’t managing a disk; you’re managing a namespace. This is a massive shift for anyone running Windows Failover Clusters, SQL Server, or VMware Cloud on AWS.
What EBS Simply Can’t Do There are three things that EBS even at its highest performance levels, simply cannot do:
Block-Level Tiering: With EBS, you pay the SSD price for every gigabyte, even if 80% of your database is historical "cold" data. FSxN moves those cold blocks to S3-priced storage automatically. You keep the performance for the active rows, but you slash the bill for the rest.
Global Efficiency: EBS has no concept of deduplication or compression across volumes. If you have ten volumes with similar OS data or database structures, you pay for that redundancy ten times. FSxN dedupes everything at the cluster level.
Instant Writable Clones: If you need a writable copy of a 10TB production database for a dev team, EBS requires a snapshot and a full rehydration. That takes time and doubles your storage cost. FSxN uses FlexClone to create that writable copy in seconds, using zero space until changes are made.
The Management Trade-off I won’t sugarcoat it: EBS is easier to set up. It’s a one-click operation. FSxN requires you to understand Storage Virtual Machines (SVMs), LUNs, and networking paths. It’s a sophisticated engine, and it requires a bit of "storage IQ."
However, the "ease" of EBS is a trap that scales poorly. Is it easier to manage 500 individual EBS volumes with 500 different snapshot schedules, or one FSx for ONTAP filesystem that handles all of them with global policies?
The Math: Performance for Pennies When you start looking at io2 or even high-provisioned gp3 volumes, the costs escalate quickly. Because FSxN combines SSD performance with S3-priced capacity and then adds deduplication on top, the "blended" cost per GB is often 50-70% lower than a comparable high-IOPS EBS setup.
The verdict? Use EBS for simple, standalone boot volumes. But for the heavy lifting - the databases, the clusters, the enterprise apps - stop managing disks.