Switching Ameba's Aurora MySQL to I/O Optimized cut costs in half
#SRG(Service Reliability Group) is a group that mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
This article summarizes how we were able to reduce our database costs by approximately half by using Aurora I/O Optimized.
I hope this helps in some way.
First, the results of switching on AmebaWhat is Aurora I/O Optimized?Use Cost Explorer to see if switching to I/O Optimized is worth itCalculation results based on tentative conditionsDisplaying the break-even point for I/O volume using Datadog graphsSwitch to I/O OptimizedConclusion
First, the results of switching on Ameba
At the end of October, we switched the Aurora MySQL cluster used by a certain microservice at Ameba to I/O Optimized.
Below is a graph showing the costs for the Aurora MySQL cluster over the last four months.

We can see that the cost in November was half of the cost from August to October.
What is Aurora I/O Optimized?
This is the new pricing structure for Aurora cluster storage announced by Amazon in May 2023.
How to useAurora MySQL version 3.03.1 or laterIt must be a version of
Aurora's standard pricing structure involves the following three costs:
I/Oオペレーション量の費用
I/O costs are charged per million requests, making it difficult to estimate the exact amount in advance.
By switching to Aurora I/O Optimized, we will eliminate I/O costs, allowing us to provide a more accurate estimate.
Additionally, costs can be optimized by switching over currently running clusters that have high I/O costs.
RDS Aurora pricingHere are some specs excerpted from:


Since there is no I/O charge, the instance and storage costs are set at a premium.
の増額)
As mentioned on the release page for this feature, it is important to note that if you apply I/O Optimized to an Aurora cluster that does not have a lot of I/O, the cost may actually be higher.
Use Cost Explorer to see if switching to I/O Optimized is worth it
You can use Cost Explorer to determine whether you should switch your running cluster to I/O Optimized.
First, you can use Cost Explorer's cost allocation tags to view the cost for each cluster by setting appropriate tags.
Next, open Cost Explorer and set the filter menu on the right as follows:
Date Range:The period you want to compare
Particle size:By month
dimension:Usage Type
service:Relation Database Service(RDS)
tag:[Name tag of the cluster you want to check the cost for]

Applying this filter will display the graph below, allowing you to see the amount and breakdown of your RDS costs.

Additionally, use the "Usage Type" filter to narrow down the storage-related usage fees for Aurora in the Tokyo region.
APN1-Aurora:StorageIOUsage(IOs)
APN1-Aurora:StorageUsage(GB-Month)

The charges displayed here are I/O charges and storage usage charges.
The higher the percentage of I/O charges in your overall RDS bill, the more likely it is that you would benefit from switching to Aurora I/O Optimized.
Calculation results based on tentative conditions
Since we cannot provide the cost for the actual environment, we calculated it using Aurora MySQL under the following conditions.
Region | Tokyo Region |
---|---|
Instance type | db.r6g.xlarge |
Number of units in operation | 3 units |
Cluster storage usage | 500GB |
Overall average monthly RDS costs | 3,300 USD |
Average monthly I/O charge | 1,900 USD |
RDS instance pricing for the relevant specifications
Standard rate (per hour) | I/O Optimized (per hour) | |
---|---|---|
r6g.xlarge | 0.627USD | 0.815USD |
RDS storage pricing
Standard fee (monthly) | I/O Optimized (monthly) | |
---|---|---|
Storage fees | 0.12USD / GB | 0.27USD / GB |
In this clusterUSD 3,300 per monthRDS costs are incurred,Of that, 1,900 USD is I/O chargesThat is the assumption.
If you switch this to I/O Optimized, the calculation is as follows:
The I/O Optimized price for db.r6g.xlarge is $0.815 per hour, so the cost for three units is $1,760, as calculated below.
500GB of storage usage costs $60, calculated at the I/O Optimized storage rate of $0.27/GB.
The combined cost of the instance and storage is $1,820.
Since it is I/O Optimized, I/O charges are included in the price.
In other words, in this scenario, by switching to I/O Optimized,
The RDS fee, which was 3,300 USD per month, can be reduced to 1,820 USD per month, resulting in a savings of 1,480 USD per month.
We were able to calculate that:
Displaying the break-even point for I/O volume using Datadog graphs
Nakajima-san, who wrote the article on Mob Cost Analysis in the CA SRE Advent CalendarHe taught me how to display monthly I/O volume and the break-even point for I/O Optimized on a Datadog graph.
In this graph example, we assume a configuration of three db.r6g.large instances with one year of reserved instance fully paid for in advance.

In this example, we can immediately see that switching to I/O Optimized would be cheaper given the I/O volume over the past month.
On the other hand, if the results are as shown in the graph below, it will be more expensive to switch to I/O Optimized.

This graph can be reproduced by editing the following JSON appropriately.
For the section below where the cost break-even point is drawn, you will need to calculate the monthly instance fee for your cluster yourself.
Switch to I/O Optimized
You can change this on the configuration screen of the target RDS cluster from the console.

Standard is currently selected, so select "Aurora I/O Optimization" and apply it.
This change can be applied online with essentially no downtime.
Other points to note are as follows:
スタンダード から I/O Optimizedへの変更は30日間に1回まで
I/O Optimized から スタンダードへの変更はいつでも可能
NVMeベースのDBインスタンスの場合はダウンタイムが伴う再起動が必要な場合がある
Please refer to the official documentation for more information.
Conclusion
Ameba has been working on upgrading to Aurora MySQL version 3 since last year, and after upgrading, we were finally able to take advantage of Aurora I/O Optimized.
In this example, we were able to halve the cost, but the effect will vary depending on your I/O usage, so please try calculating it in your own environment!
SRG is looking for people to work with us.
If you're interested, please contact us here.