EBS volumes are an essential component in the AWS ecosystem, offering a flexible storage solution for EC2 instances, much like traditional hard drives. However, it is crucial to effectively manage EBS volumes to optimize your AWS costs. These volumes serve as reliable storage options, serving as a viable alternative to permanent and resilient storage solutions due to their dynamic nature.
EBS as a storage often ranks in the Top 15 lists of AWS Services used annually as businesses across the world rely on EBS as a critical component of their infrastructure. gp2, especially, has been a mainstay for many years. But, in late 2020, AWS released gp3 with better capabilities and yet organizations are reluctant to make the shift towards gp3. This blog explains what are the primary differences between gp2 and gp3, and how the update can be made effectively easier with nSwitch Essentials!
What Are The Primary Differences Between gp2 And gp3?
In late 2020, AWS released the gp3 EBS Volume type. Here’s how gp3 was made distinct from the gp2:
- gp3 provides a predictable 3,000 IOPS baseline performance and 125 MiB/s throughput, regardless of volume size, whereas gp2 had a baseline of 3 IOPS/GB (minimum 100 IOPS) and a maximum of 16,000 IOPS.
- With gp3 volumes, you can provision the IOPS and throughput independently, without increasing storage size.
- gp3 volumes allow scaling up to 16,000 IOPS and 1,000 MiB/s for additional fees.
- gp3 volumes cost up to 20% less compared to gp2 volumes with the same storage size.
For a 100GB volume with 16,000 IOPS and 256 MiB/s:
- gp3 would cost $78 per month (i.e. 0.08*100 + 0.005 * (16000-3000) + 0.04 * (256-125))
- an oversized 5TB gp2 would cost $53.
Another common example:
For a 1,000GB volume using baselines:
- gp2 would cost $100/mo
- gp3 would cost $80/mo
One thing to note, as Sibasankar mentions, “you can provision a 1000 GiB gp3 volume with 6000 IOPs (and 250-MB/s throughput to match to gp2) and pay only 100 USD/month, which is 50% cheaper than the 2000 GiB gp2 volume, and still enables the same application performance. Since Elastic Volumes don’t support reducing volume size, migrating from gp2 to gp3 volumes will require you to create a smaller volume and migrate the data to the gp3 volume.” As nOps will only upgrade to the same size storage volume, it will be a non-disruptive change. Due diligence is necessary to prevent adding more work to size down the volume.
Below is a chart from AWS detailing the performance capabilities of EBS volumes:
And while the move from gp2 → gp3 from a storage standpoint can lead to significant cost savings, throughput needs to be considered.
With the added functionality of customizable IOPs and throughput, there is the chance to significantly increase the costs of your volumes. Generally speaking, this is when the volume size sits between 170GB-334GB.
In short, here’s the math calculated behind the scenes for EBS gp2/gp3 volumes:
Input metrics: **throughput = 250 MiB/s, volume_size = [170, 334]**
gp2 price: [170 * 0.1, 334 * 0.1] = [17$, 33.4$]
gp3 price: [170 * 0.08 (Size) + 0 (IOPS) + 0.04*125 (throughput), 334 * 0.08 (Size) + 0 (IOPS) + 0.04*125 (throughput)] = [18.6$, 31.72$].
In the real world, if you require a lot of throughput, moving from gp2 to gp3, it could end up costing you a lot more.
Why Are Organizations Hesitant To Make The Shift Towards gp3?
Many organizations are hesitant to make changes to their infrastructure, specifically within production environments due to the possibility of an outage or issue. This caution is especially evident when it comes to making modifications to operating systems or instance families.
A second reason is cost-awareness. As discussed earlier in the article, there is a chance to incur “net negative” savings. For throughput intensive applications, it can sometimes be more cost effective to remain on gp2.
Another reason why many organizations stick with gp2 volumes is the substantial effort required to identify suitable candidates for an upgrade. However, with the assistance of nSwitch Essentials, this process becomes much more manageable. The platform provides a comprehensive list of gp2 candidates to move to gp3 of the same storage size, the potential savings, and the ability to schedule the volume change.
While AWS has some limitations and exceptions on EBS volume changes, the process is considered non-disruptive. This means you don’t have to worry about it causing a problem. The best part is that these modifications can be performed “on the fly”, without the need to stop the instance or detach the volume. This flexibility allows for convenient upgrades at a time that suits the organization’s operations.
Again, this is considered a non-disruptive change. As AWS mentioned, “Amazon EBS Elastic Volumes enable you to modify your volume type from gp2 to gp3 without detaching volumes or restarting instances (requirements for modification), which means that there are no interruptions to your applications during modification.”
How Can nOps Help With The Automated Upgrade From gp2 To gp3?
To continue with our pay less, use less philosophy, nOps has released Essentials. This module for cost savings will enable you to automate the laborious task of changing candidates from gp2 to gp3 volumes via EventBridge or nSwitch Changeset (for those gp2 volumes that are defined in your terraform configuration file), allowing you to stay focused on innovation.
Once you have reviewed the comprehensive list of gp2 → gp3 candidates in an aggregate view per account, you can set an automated schedule for “now” or in the future for those resources you wish to affect. With easy checkbox attachment or removal of candidates from the list, you can calculate the proposed savings dynamically. The candidates for migration have been evaluated based on the metrics of storage size, IOPs, and throughput. We automatically filter out any net-negative situations, so you can feel confident in your cost optimization decisions.