Aurora I/O-Optimized: Cut Costs for I/O-Intensive Workloads

When running an Amazon Aurora cluster, the costs typically consist of following main components:

Instance costs: The compute resources running your database
Storage costs: The volume of data stored in your Aurora cluster
IO costs: Charges for read and write operations to your database
Others: Snapshots and data transfer

For IO-intensive applications, the IO costs can quickly become a substantial—and often unpredictable—portion of your total database spend. This is where Amazon Aurora IO-Optimized configuration comes in as a great option that could significantly reduce your costs while providing more predictable pricing.

What is Aurora IO-Optimized?

Aurora IO-Optimized is a cluster configuration that eliminates charges for read and write IO operations. When switching to IO-Optimized, expect the following cost changes:

IO Cost: Reduced to zero (100% savings)
Storage Cost: Increases by approximately 125% (to 225% of original)
Instance Running Hours Cost: Increases by approximately 30%
Snapshots and Data Transfer: No change

Beyond cost savings, Aurora IO-Optimized also enhanced overall database performance for IO-intensive applications. This is done by simplifying IO processing between Aurora storage and Aurora instances, thus improved the write commit latency, resulting in higher write operation throughput.

A rough estimation suggests that if the IO cost is at least 1/3 of the total cluster cost, switching to IO-Optimized could generate savings.

How to Onboard?

Switching to IO-Optimized can be done by modifying cluster configuration in AWS Management Console or using CLI.

But here are some of the limitations:

Aurora cluster must meet these requirements: Aurora PostgreSQL version 13.10 or above, or Aurora MySQL version 3.03.1 or above, check here for updates https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html
You can switch between standard and IO-Optimized configurations once per month, giving you flexibility to adjust as your workload patterns change.

For most instances, Changes take effect immediately without any downtime. But there is Exception for NVMe-based instances (provisioned clusters), which may require restart of instances.

Should I Use I/O-Optimized?

A rough estimate is by looking at all clusters as a whole in an account. From Cost Explorer, filter Service to “Relational Database Service (RDS)”, set Dimension to “Usage type”, calculate the subtotal cost of usage type “%-Aurora:StorageIOUsage“, and compare it with the total cost of aurora clusters.

For example, in the following accounts, one account has Aurora IO cost exceeding 1/3 of the total Aurora cost of that account, and it has a potential saving of $8k+. But if the account has multiple Aurora clusters, a safer way is to analyze the cost saving at the cluster level.

How to Identify Clusters for I/O-Optimized?

Pre-requisites

You have setup Cost and Usage Report for your AWS organization
You are able to run AWS CLI to describe RDS resources

In AWS, we are able to get detailed cost by usage types in Cost and Usage Report (CUR). However, the usage types for Aurora don't clearly fall into "io", "storage", "instance" and "others" categories. Additionally, in CUR, cost items for clusters and instances in the cluster are listed separately without any indication of which instance belongs to which cluster.

Therefore, there are 2 main challenges to achieving a more accurate saving estimation for each cluster:

Grouping the costs of all usage types into "io", "storage", "instance" and "others"
Associating instance costs to their respective clusters

Challenge 1: Grouping Usage Types into Categories

Here are the grouping of usage types into categories, where % represents wildcard.

IO Cost:

Storage Cost:

Instance Cost:

Using Athena, we can run following SQL statements to query Aurora cost from Cost Usage Report by grouping usage types into categories (cost_types).

Challenge 2: Associate Instances Cost to Clusters

Since the cost for clusters and instances are listed separately in CUR, and there is no way to link them using CUR alone, we will need to get the cluster info and respective instances outside CUR.

Following script uses AWS CLI to list all RDS instances with their instances in an account and a region. If you need to gather data from multiple regions and accounts, update the script and run it multiple times.

Google Sheet to Rescue

After we gather data from CUR and using AWS CLI, how can we put them together to get recommendations on which Aurora clusters to turn on I/O-Optimized? I put in a Google Spreadsheet to help us some work.

1. Clone a copy of this Spreadsheet, which has 5 tabs. https://docs.google.com/spreadsheets/d/1lkXtJdaY_cYaMoaL1iaTABIFhQ9WGtOeklHpGHm-68w/edit?usp=sharing

2. Copy the CUR query result into cur-data .
3. Copy the CSV file content into cluster-info . This is only required if you need cluster level analysis.
4. Examine the recommendations in summary-accounts and/or summary-clusters.

Example Result

Recommendation by Accounts

Recommendation by Clusters

FAQ

1. If my aurora cluster is covered by Reserved Instances, how will the cost of instances change?

Since the instance cost increases by 30%, the additional cost is the on-demand cost. Assume this cluster is fully covered by Reserved Instances, you will need to purchase additional 30% of its RI commitment to keep it fully covered.

2. Will it cause any downtime to the cluster?

For non-NVMe-based DB instances, there is no downtime. However, for NVMe-based DB instances, switching between Aurora I/O-Optimized and Aurora Standard storage options requires a database engine restart, which may cause a brief period of downtime.

3. Can I switch between I/O-Optimized and Standard configurations in future?

Customers can switch their existing database clusters to I/O-Optimized once per month. They can also switch back from I/O-Optimized to the standard configuration once per month.

Conclustion

Amazon Aurora I/O-Optimized configuration eliminates charges for database read/write operations while modestly increasing storage costs (by 125%) and instance costs (by 30%). This option typically benefits workloads where I/O costs represent at least one-third of total database expenses. Beyond cost savings, I/O-Optimized enhances performance by streamlining I/O processing, improving write latency and throughput. The article provides detailed methods to analyze your clusters using Cost and Usage Reports and AWS CLI to determine potential savings before switching configurations.

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Site Terms, Privacy, and more.