Converting EBS gp2 to gp3: Why Large Volumes Save Less Than 20 Percent

- If you are listening to this deep dive, you've probably got an open Jira ticket sitting in your backlog right now. - Yeah, the classic upgrade your AWS EBS volumes from GP2 to GP3 ticket. - Right, exactly. And like on paper, it looks like a total no brainer to cut your infrastructure bill. But before you just run that migration script, we really need to unpack why that seemingly obvious upgrade is actually a billing trap.

- Right, it silently eats your cost reductions. So let's get into it. Start with the math. - Sure, so the problem starts with the baseline unit maths. Like a standard GP2 volume costs about 10 cents per gigabyte month.

And AWS gives you three IOPS per gigabyte of storage. But the newer GP3 is cheaper. It is about eight cents per gigabyte month. Plus it includes a generous flat baseline of 3000 IOPS and 125 megabytes per second of throughput. - Regardless of how small the volume is, right?

- Exactly, regardless of size. - So this sounds like switching from, you know, pay per mile car lease to a flat rate one that is somehow actually cheaper per month. - Yeah, that is exactly how they pitch it. But if GP3 is definitively cheaper and better, why isn't the switch saving everyone 20%? - Right, where is the catch?

- The catch is the modify volume action. It is an incredibly useful API call because it changes the volume type in place while it is attached and completely in use. - Which is great for uptime. - It is. However, if you convert without specifying your IOPS or throughput, AWS tries to be helpful.

EBS just automatically keeps the higher of your GP2's current performance or the GP3 baseline. - Wait, so AWS tries to be helpful by matching my old provision specs, but that help is exactly what kills the cost reduction. - You nailed it. - Okay. - Because remember, GP2 gives you three IOPS per gigabyte.

So a massive GP2 volume was automatically granted massive provisioned IOPS whether you actually use them or not. - Oh, I see. - So any IOPS or throughput above that GP3 baseline is billed separately. Large GP2 volumes silently rack up these extra performance charges. - Meaning they often save way less than 20%.

- Exactly. It just sits invisibly on the per service bill. - Since AWS defaults to matching that provision size rather than actual usage, how do we correctly and safely make the switch? I mean, I imagine I can't just click upgrade and hope for the best. - No, definitely don't do that.

The signal is in the metrics. You have to check each volume's CloudWatch read and write metrics to see your actual usage. - Right, before you do anything. - Yeah, and then you set the GP3 performance deliberately based on those actual metrics, completely ignoring the old GP2 size. - Okay, that makes sense.

But what is the risk here? If I can't cancel a modification and there is a limit on how soon I can modify it again, I am basically locked in for hours if I configure the performance incorrectly, right? - Completely locked in. A modification cannot be canceled once it starts and it can literally take hours on large volumes. - Oh, wow.

- Plus there is that cool down limit. So a quick revert is simply not available. If you throttle your production database by accident, you are stuck waiting. - That is terrifying. And we should probably add that you can never assume a resource is provably or guaranteed unused just because the read and write metrics look dead in CloudWatch.

- Exactly. No check makes modifying or deleting risk-free. A volume might seem completely idle, but it could still be relied upon by an ID reference. - Or like a rollback state, right? - Yeah, a rollback state for a legacy app or a scale out template.

You just have to be careful. - Checking CloudWatch manually for every single volume sounds tedious though. - It is incredibly tedious. But there is a free source available scanner you can get just by running pip install cloudcostwise. - Oh, nice.

- Yeah, it runs read only locally on your own machine, flags this exact GP2 to GP3 pattern and sends absolutely nothing to CloudWise. - That is super handy. It really makes you stop and think about the mechanics of cloud billing. We rely on so many automated default settings to keep things running smoothly. - We really do.

It leaves you pondering how many other helpful defaults in your infrastructure are secretly optimizing for maximum cost rather than efficiency.