Evaluating the Case for LVM in the Modern Cloud Era: 20 Years Later
The Historical Rationale for Using LVM on EBS
Amazon EBS was designed for diverse multi-tenant environments and has some very interesting features and a few quirks when compared to a traditional hardware block storage device used individually or in a RAID configuration.
Back in the early 2000s, multi-processor Linux systems became widespread and software-defined volume management evolved to replace hardware RAID controllers. Linux Logical Volume Management (LVM) grew in acceptance to get comparable performance, capacity, and resilience in a software-defined RAID.
In light of EBS itself being more than 15 years old, we’ve seen it evolve as well. Let’s examine whether it’s worth combining LVM with EBS in this modern era and consider alternatives.
Bridging gp3 Gaps with LVM Striping
Up until recently, gp3 was good enough to use in most workloads but was clearly limited compared to the Provisioned IOPS SSD volumes such as io2 Block Express.
Initially, individual volume capacity was limited to 16 TiB, while io2 BX supports 64 TiB.
Volumes were limited to 16,000 IOPS, compared to 64,000 for io1 and 256,000 for io2 BX and bandwidth was limited to 1 GiB per second, compared to 4 GiB per second on io2 BX.
Some users discovered they could use LVM on gp3 volumes to surpass the performance (bandwidth, IOPS) and capacity of io2 BX volumes at a more attractive price point.
gp3 Now Approaches io2 in Capacity and Performance - is LVM worth the hassle?
In September 2025, Amazon increased several limits on gp3.
Maximum volume capacity now matches io2 BX at 64 TiB, IOPS limits increased fivefold to 80K, and throughput doubled to 2 GiB per second.
As a result, in most cases customers can now achieve their required capacity, IOPS, and bandwidth without relying on LVM striping.
How LVM Previously Helped Bypass ModifyVolume Limitations
Another Amazon EBS challenge was the original six hour cooldown period between ModifyVolume operations.
Even if a ModifyVolume operation completed in less than six hours, customers were required to wait until six hours had elapsed before initiating another operation. This made rapid volume growth painful if the modification was insufficient to match workload demand.
LVM provided a workaround. By placing an EBS volume inside an LVM volume group, additional EBS volumes could later be added to that group. Since creating new EBS volumes had no cooldown restriction, capacity could be expanded without waiting.
However, this introduced additional operational complexity that was not acceptable to all customers and pushed hard on the EBS product and engineering team to provide alternatives to the cooldown.
How the New Cooldown Model Changes Operations
EBS recently changed the cooldown behavior and it has been welcomed by the user community.
Instead of enforcing a six hour waiting period, the new constraint allows up to four ModifyVolume operations in a 24 hour window per volume. There is no longer a requirement to wait six hours between operations.
This significantly reduces friction for most use cases and allows better course correction for rapidly changing workload conditions.
However, some constraints remain. A new ModifyVolume operation cannot begin until the previous one has completed, and an in progress ModifyVolume operation cannot be cancelled.
Practical Guidelines for ModifyVolume Usage
If rapid growth is a priority for a workload on an EBS volume, avoid using ModifyVolume to change volume type or performance characteristics, as those operations may take considerable time. Since most volumes are gp3 and use default gp3 performance settings, this restriction is reasonable in many environments.
When increasing volume size, avoid small incremental growth steps if the workload might accelerate its growth rate. The ModifyVolume duration is proportional to the amount of data written to a volume. Increasing a large volume by a small amount can result in a long operation. Instead, doubling the volume size makes the duration proportional to the newly added storage, reducing the likelihood of running out of space during the operation.
LVM Remains Useful but Is Often No Longer Required
LVM remains a powerful toolkit for a variety of Linux environments.
However, recent improvements in gp3 limits and ModifyVolume behavior mean that in many cases it is no longer necessary. Since LVM adds operational complexity and overhead, customers should reassess whether it is still justified in their current architecture.