AWS Storage Blog

Improve application resiliency with larger and faster Amazon EBS gp3 volumes

Maintaining resiliency and operational clarity while keeping costs low is one of the key things our customers have to balance for their high-performance applications. As customers experience natural growth in capacity and performance needs, at some point they may hit the limits of the existing solutions and have to rethink their architecture. They can do so by moving to more expensive storage solutions, or by adding complexity to their applications by striping data across volumes, sharding it across multiple systems, or switching to entirely new application or database architectures.

Amazon Elastic Block Store (Amazon EBS) customers have long relied on EBS Volumes combined with Amazon Elastic Compute Cloud (Amazon EC2) instances to scale their applications. Over the years, Amazon Web Services (AWS) has introduced newer volume types and increased the limits of existing volume types to help customers scale without having to rethink their storage layout and architecture. With the latest Amazon EBS General Purpose (gp3) volumes, IOPS and throughput are decoupled from volume capacity, so that customers can run faster applications on smaller volumes. With io2 Block Express volumes, capacity, IOPS, and throughput limits have increased four times over the previous generation of Provisioned IOPS volumes—up to 64 TiB, 256,000 IOPS, and 4 GiB/s. This aligns with the enhanced capabilities of our newest high-performance EC2 instances. In both cases, customers can reduce costs while maintaining application resiliency, with gp3 volumes offering 99.9% durability and io2 Block Express volumes delivering 99.999% durability.

However, customers have and will continue to need to scale beyond existing EBS volume limitations, with methods such as RAID-0, or striping, to combine multiple EBS volumes into a larger logical storage array. This approach has been supported and documented by AWS for several years and used by other AWS services such as Amazon Relational Database Service (Amazon RDS) internally. Customers can use striping to go beyond the limits of one volume, and in some cases reach the limits of a particular EC2 instance, with one major caveat: durability and resiliency.

Solution overview

Unlike other forms of RAID, volume striping doesn’t introduce any more redundancy into the storage system, which means the failure of any one volume in the stripe results in loss of data for the application. For example, to reach 4 GiB/s for an application using gp2 volumes, customers would need to combine 16 volumes together, due to a per-volume throughput limit of 250 MiB/s. Volumes have independent fault patterns, thus this combination would result in an effective durability of 98.4%, down from a single-volume durability of 99.9%. Oftentimes, such a low durability isn’t acceptable to customers, necessitating that they implement expensive application replication solutions or other methods to make their application meet their resilience goals. With the launch of gp3 volumes, the same throughput could be achieved with only four volumes, resulting in an effective durability of 99.6%. Although every environment is different, for many customers the goal is >99%, so a gp2-based solution would be unacceptable, while the gp3-based solution would meet and exceed their goal. Striping still necessitates a more complex setup inside the instance, with customer administrators needing to learn how to use LVM or mdraid on Linux, or Software RAID on Windows. All individual volumes in the stripe can be scaled or migrated to newer EBS volume types using the Amazon EBS Elastic Volumes (EV) feature non-disruptively, but only up to the limit of the given volume type, such as 16,000 IOPS or 16 TiB of capacity in the case of gp3. Striping also introduces more operational overhead, with customers needing to manage more volumes as their applications scale and sometimes having to perform full data migrations because they hit the combined volume limits even with the striped array.

Announcement

Amazon EBS recently announced a 4x increase in the maximum capacity of gp3 EBS volumes from 16 TiB to 64 TiB, a 5x increase in maximum IOPS from 16,000 to 80,000, and a 2x increase in maximum throughput from 1 GiB/s to 2 GiB/s, maintaining the durability of even the largest volumes at 99.9%, effectively doubling or quintupling the effective durability of existing RAID-0 gp3 deployments. These performance and capacity improvements streamline the process of running applications that have grown to need larger capacity and higher performance, without sacrificing application resiliency or the need to rearchitect systems to implement volume striping. For applications that already use volume striping, customers get more headroom with the ability to grow these volumes further than before, delaying the need for a full data migration. Newer environments can be deployed with a simpler architecture than before, which is especially important for customers that use distributed applications or ones with horizontal scaling capabilities. Considering the overall durability goal of 99% in the preceding example, customers can deploy storage environments with 640 TiB, 800,000 IOPS, and 20 GiB/s of throughput per EC2 instance. This exceeds the performance of most available EC2 instances and allows for significant headroom for future growth.

The pricing for gp3 volumes remains the same in all dimensions (size, provisioned throughput, and provisioned IOPS), and volumes with the new limits can be created using AWS Management Console, AWS Command Line Interface (AWS CLI), or API without any changes to the interface, by specifying the higher limits, as shown in the following figure.

AWS EC2 console showing the Create volume interface for configuring a new EBS gp3 volume with 65536 GiB storage, 80000 IOPS, and 2000 MiB/s throughput

Existing volumes can also be grown by specifying the new limits when you modify a volume, as shown in the following figure.

AWS EC2 console showing the Modify volume interface for an EBS gp3 volume configured with 65536 GiB storage, 80000 IOPS, and 2000 MiB/s throughput

Conclusion

The recent announcement of increased Amazon EBS gp3 limits, now offering up to 64 TiB capacity, 80,000 IOPS, and 2 GiB/s throughput per volume while maintaining 99.9% durability, means that you can scale your applications higher while significantly reducing architectural complexity. You can use these enhancements to achieve the performance you need with fewer volumes, improving effective durability and streamlining operations whether you’re designing new deployments or extending the capabilities of existing workloads. For many customers, this means replacing complex multi-volume striped configurations with more direct and resilient architectures that can grow with your business without sacrificing performance. To get started with these enhanced capabilities, visit the Amazon EC2 console, explore the Amazon EBS detail page, or review implementation guidance in the Amazon EBS documentation. As always, AWS Support and your account team are available to help you determine the best approach for your specific use cases.

Kirill Davydychev

Kirill Davydychev

Kirill Davydychev is a Solutions Architect at AWS, where he helps customers design and implement scalable storage solutions. With expertise spanning cloud architecture, performance engineering, and infrastructure optimization, he specializes in helping organizations maximize the value of their AWS storage investments. When he's not working, you can find him rock-crawling in his Jeep or tinkering with creative technology projects.

Trang Luong

Trang Luong

Trang Luong is a Product Manager at Amazon Web Services (AWS), where she works on Amazon Elastic Block Store (EBS) in Seattle, Washington. With over 9 years at Amazon, she brings extensive experience in technical product management, focusing on delivering scalable and reliable cloud storage solutions for enterprise customers. When she's not building products, Trang enjoys traveling, hiking, and spending time with family.