Forecast Aurora Storage IO costs
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?
- 最新
- 最多得票
- 最多評論
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.
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 官方已更新 1 年前