Forecast Aurora Storage IO costs

1

My customer already has a regular RDS instance and thinking about elevating to Aurora for better MAZ/RR dual purposing. I would like to use metrics from their existing RDS to forecast the aurora storage IO cost?

I am thinking something like this

  • Cloudwatch
  • Volume Read IOPs
  • Volume Write IOPs
  • Sum over 30 days

However, I am unsure if the metrics stored in cloudwatch have the right data to use as an estimate for aurora.

I am concerned the statistics CW captures current IOPs @ at a point in time (not ideal for aurora), or is cloudwatch capturing the sum of IOPs between and including points in time(ideal for aurora)

What’s the best approach here?

2 Answers
0
Accepted Answer

Not sure about the accuracy of the estimate you are looking, but if you're looking for a ballpark figure, this calculation I use seems to match the AWS cost calculator estimates.

The most difficult part is calculating the average IOs per day, as this number fluctuates. If you can approximate that on a daily basis, then:

Total monthly IO cost = ((Average Read IOPS + Average Write IOPS)*86400*30)/1000000 x {cost per million IO-month}

For example: for a system that does 250 Read IOPS and 500 Write IOPS per day, at $0.20 per million IOs/month = $388.80

Again, this is a ballpark figure made with those assumptions. This number would be accurate if we could sum-aggregate the number of IOs per day.

answered 4 years ago
profile picture
EXPERT
reviewed 22 days ago
0

Here is a deep dive on the Aurora-specific reasons why there could be different numbers of I/Os in Aurora than in RDS: https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/

The way Aurora batches together the I/O operations could reduce the number of I/Os substantially from what you see in RDS. Certain features like Aurora PostgreSQL cluster cache management or Aurora parallel query could bump the I/O number back up somewhat. X2 instances have twice as much RAM as the comparable R instances and so can have bigger buffer caches; that can be another way to bring the I/O numbers down.

AWS
answered a year ago
profile picture
EXPERT
reviewed 22 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions