Usually, when AWS releases new hardware, we can see some kind of a cost reduction in the new service. But, in some cases, the pricing model changes completely and we need to understand how to adjust
When the new gp3 was announced, AWS did something they don’t usually do - they wrongly advertised a baseline assumption for those who are not reading the fine print of the new pricing model. From the announcement above: “Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.”
That sentence is not accurate and I wanted to shed some light on it.
In the GP3 pricing model you have 3 cost vectors:
Storage costs
IOPs cost (3,000 IOPS baseline included with any storage size)
Bandwidth cost (125 MiB/s - baseline included with any storage size)
The 20% lower price is only for the storage costs, meaning that if you need more IOPs or Bandwidth you’ll have to pay more, reducing the cost difference from 20% to (sometimes) much lower.
To understand the cost impact on those new EBS volumes, we’ll take two commonly used scenarios
A 5,334GB gp2 for databases using the maximum IOPS for gp2
gp2 that is smaller than 1TB (with burstable IOPS up to 3k)
But what's better now, you'll be able to adjust your needs. Think of a database consuming 300GB but requires 16k IOPS? We're now comparing $533 on gp2 to the astounding number of $93.92, a difference of 82.38% from the gp2 pricing.
Conclusion
The gp3 are keeping the AWS “tradition” of lowering prices when releasing a new generation, and moving your workloads to gp3 in most common cases makes sense financially. The % of the discount however is lower than 20% as advertised when comparing apples to apples, and you should plan based on the workloads migrating to the new EBS. But please note - with the right FinOps approach, the savings can be so much more than just the storage costs.
Having said that - the actual power of the gp3 instances will come from the ease of migration (customers can easily migrate gp2 volumes to gp3 volumes using Elastic Volumes, which is an existing feature of Amazon EBS) but most importantly, from the fine-tune (that can be auto-tuned) of the volume metrics based on utilization and needs.
Do you need to run a migration of a database? You no longer need to move your EBS to IO1 disks to support it, just scale up the relevant EBS trait you need and scale it down when done.
[Edit 1] - I'm not talking about performance in this article, but worth mentioning that we get single digit latency with IO1. The example I gave was a migration process that needs the IO, not to replace critical DB workload with untested EBS volume which leads me to point number (2) - do not just migrate to those volumes without having to test exactly your use-cases and make sure it fits your needs :)