AWS Database Blog

How MoneyLion achieved price predictability and 55% cost-savings using Amazon Aurora I/O-Optimized and optimized RI purchases

This post was co-written with Shubhrajeet Behadi, Director of SRE, at MoneyLion.

MoneyLion is a financial technology ecosystem leader with a mission to empower everyone to make their best financial decisions. The MoneyLion app delivers curated financial content and innovative products, including features to save and invest, integrating offers from over 1,100 enterprise partners. Their enterprise technology enables companies to add embedded finance with AI-backed data and tools. Established in 2013, MoneyLion connects millions with the financial products and content they need.

In this post, we share how MoneyLion achieved cost-optimization using Amazon Aurora I/O- Optimized, a new storage configuration in Amazon Aurora that provides improved price-performance and predictable pricing for I/O-intensive applications.

Amazon Aurora I/O-Optimized

With Amazon Aurora, you can now choose between two storage configurations: Aurora Standard or Aurora I/O-Optimized. For applications with low to moderate I/O, Aurora Standard is a cost-effective option. Aurora I/O-Optimized is a new configuration that provides predictable pricing for all applications and improved price-performance for I/O-intensive applications. You pay a predictable price based on the consumption of your Aurora database instances and storage.

Aurora I/O-Optimized also offers increased throughput and reduced latency to support your most demanding workloads. With I/O-Optimized, there are zero charges for read and write I/O operations in a particular Region— you pay for a “premium” on your compute and storage with zero charges for read/write I/O’s, making it straightforward to predict your database spend. If you’re using Reserved Instances (RIs), you will see even greater cost savings. To learn more, visit Amazon Aurora Pricing, Amazon Aurora storage and reliability &  Estimate cost savings for the Amazon Aurora I/O-Optimized feature using Amazon CloudWatch

In this post, we also see how RI usage gets calculated when you switch to Aurora I/O-Optimized and illustrate through MoneyLion’s examples why we assert that RIs generate increased savings when used with the Aurora I/O-Optimized configuration.

Problem statement

MoneyLion’s data enrichment services use Amazon Managed Streaming for Apache Kafka (Amazon MSK) with Amazon Aurora PostgreSQL-Compatible Edition as its database tier. Their data enrichment service performs large-scale, near-real-time data enhancement, handling millions of data events daily by ingesting an enormous amount of near-real-time data into their platform. MoneyLion initially deployed an Aurora standard database cluster for data enrichment, featuring a pricing structure dependent on compute, storage, and IOPS consumption. The challenge arose from the variable nature of IOPS, making it difficult for MoneyLion to precisely forecast monthly expenses. Intending to optimize costs in the current economic landscape, where unpredictability poses a challenge, MoneyLion sought alternative database solutions. The objective was to explore databases with pricing models less influenced by fluctuating IOPS usage, ensuring cost predictability and alignment with their cost-saving objectives.

MoneyLion’s Architecture

The following diagram illustrates the solution architecture for MoneyLion’s data enrichment service.

MoneyLion's Architecture Digram

Data enrichment service plays a vital role by processing a large amount of near-real-time data through the following steps:

Data Consolidator: Data is collected from multiple source systems in real-time and sent to an Amazon MSK cluster, acting as the streaming layer.

Data Enrichment: The data enrichment engine processes the streaming data from MSK, send the data to a job processor which conducts batch inferencing. It retrieves large batches of raw data from the Aurora PostgreSQL database, processes them through machine learning models to categorize the data and stores the enriched data back into the Aurora database. Their platform enhances the ingested data with valuable insights and classifications. This enriched data is then used by various applications and services downstream for different purposes.

MoneyLion’s Data Enrichment Service consists of a staging and a production environment. After learning about the Aurora I/O-Optimized feature, they switched their staging environment to I/O-Optimized. They waited for few days for AWS Cost Explorer to give them the most up-to-date data. After seeing promising results they made the change to their production environment. They immediately saw cost savings with no performance degradation.

The choice for Aurora I/O-Optimized

MoneyLion aimed to reduce costs and bring price predictability associated with their Aurora PostgreSQL usage without compromising on the database performance. The SRE team at MoneyLion swiftly recognized the cost-saving and price predictability advantages by transitioning to Aurora I/O-Optimized. The outcome of this initiative was a remarkable 55% reduction in their monthly Aurora expenditure.

Other databases with fixed I/O costs provision a certain number of IOPS, or get throttled after a certain number of IOPS. With Aurora I/O-Optimized MoneyLion could tap into the same Aurora’s configuration with virtually unlimited I/O throughput without having to worry about the I/O cost. In addition, choosing the I/O-Optimized configuration didn’t present any tradeoffs in performance compared to Aurora Standard; same unlimited I/Os, same throughput, and a lower price for this particular use case. This was rigorously validated through performance tests conducted by the MoneyLion’s SRE team in staging environment. The online nature, with zero downtime, of the switch to Aurora I/O-Optimized contributed to the ease of the transition, further influenced their decision to adopt this new configuration. Following successful testing phases, MoneyLion made the decision to convert their production environment to Aurora I/O-Optimized configuration.

“The process of switching to Aurora I/O-Optimized is as simple as flipping a switch—a seamless and efficient operation. The AWS recommendations on cost optimization played a pivotal role, providing invaluable insights that guided informed decision-making and resulted in substantial savings. These savings, in turn, empowered MoneyLion to invest in innovation, ultimately enhancing their ability to better serve their customers.”

— Shubhrajeet Behadi, Director of SRE, at MoneyLion

Benefits of switching to Aurora I/O-Optimized

The detailed cost breakdown for the Aurora service is visible in AWS Cost Explorer, providing insights into the tangible cost-savings and price predictability realized by MoneyLion in their Aurora usage.

MoneyLion made the transition to Aurora I/O-Optimized mid-September, 2023. Both of the following graphs depict the monthly Aurora costs over a span of 6 months—3 months preceding and 3 months after the transition to Aurora I/O-Optimized.

The graph in Figure 1 illustrates the monthly Aurora costs, showcasing a reduction in costs from September onwards (reflecting a partial month billing for Aurora Standard and I/O-Optimized) and, subsequently, from October to December, with full billing optimizations using Aurora I/O-Optimized.

Figure1

The graph in Figure 2 further delineates the monthly Aurora costs, categorizing them by usage type. Notably, Aurora:StorageIOUsage is evident in the months of July to September. In contrast, from October to December, there is an absence of Aurora:StorageIOUsage, resulting in a more predictable overall cost structure.

Figure2

The graphs clearly demonstrate that after transitioning to Aurora IO-Optimized from Aurora Standard, MoneyLion consistently realized an average cost reduction of 55% month over month.

How Reserved Instance usage gets calculated in an Aurora I/O-Optimized configuration

One of the questions MoneyLion had, what happens to my Reserved Instances once we switch to Aurora I/O-Optimized. Let’s try to understand through MoneyLion’s example how RIs gets calculated in Aurora I/O-Optimized Configuration.

When a DB cluster has an Aurora I/O-Optimized configuration, it uses the same RIs as when using Aurora Standard, with no need to cancel your current RIs. The main difference is that, it uses 1.3 normalized units for each 1 normalized unit that it would have used for the same DB instance class in the Aurora Standard configuration.

The following table shows the number of normalized units per hour for each DB instance size

Instance Size NU/hr in Aurora Standard Mode NU/hr in Aurora I/O-Optimized Mode
24xlarge 192 249.6
12xlarge 96 124.8
8xlarge 64 83.2
4xlarge 32 41.6
2xlarge 16 20.8
xlarge 8 10.4
large 4 5.2

After learning about Size-flexible reserved DB instances, MoneyLion wanted to precisely calculate and procure additional RI’s needed to cover the gap to increase the saving even further.

MoneyLion has two db.r5.24xlarge RIs and one db.r6g.12xlarge RI configured in a Aurora Standard cluster. Based on the table above, below table shows how many additional NU/hr MoneyLion’s would need to convert Aurora Standard to I/O-Optimized Cluster Configurations

Instance Type Number of Instances (A) Reserved NU/hr per Instance (B) Total Reserved NU/hr (C=A*B) I/O-Optimized NU/hr per Instance (D) Total I/O-Optimized NU/hr (E=A*D) NU/hr Gap (E-C)
db.r5.24xlarge 2 192 384 249.6 499.2 115.2
db.r6g.12xlarge 1 96 96 124.8 124.8 28.8

Customers have the option to compensate for these additional units by using either on-demand (OD) instances or RIs of different sizes and taking advantage of flexible sizing. In essence, you need to procure approximately 30% more RIs to cover the entire hourly usage. The detailed approach involves determining the exact number of normalized units per hour (NU/hr) being consumed and strategically covering these with a mix of flexible-size RIs and OD rates.

Options to bridge NU/hr Gap through Size-Flexible Reserved DB Instances

For db.r5.24xlarge Instances

Gap (NU/hr) Options to Bridge the Gap Total NU/hr from Option
115.2  7 db.r5.2xlarge instances (16 NU/hr each) 112
 1 db.r5.large instance (4 NU/hr) OR 4
 On-Demand (OD) pricing for remaining 3.2 NU/hr 3.2

For db.r6g.12xlarge Instances

Gap (NU/hr) Options to Bridge the Gap Total NU/hr from Option
28.8 7 db.r6g.large instances (4 NU/hr each) 28
 On-Demand (OD) pricing for remaining 0.8 NU/hr 0.8

Upon securing additional RIs to cover the gap in usage, MoneyLion would enjoy an additional 11% cost savings on monthly instance usage, resulting in an overall savings exceeding 55%.

With Size-Flexible reserved DB Instances option available, through this example, it is evident that reserved Instances yield greater cost savings when used in conjunction with the Aurora I/O-Optimized configuration. RI provide additional savings because Aurora I/O-Optimized charges customers for compute and storage with no additional I/O charges. I/O charges are bundled into the storage and compute pricing dimensions. Therefore, customers using RIs for I/O-Optimized get a 40-60% discount on compute and the portion of the I/O charges bundled into their instance costs.

Conclusion

In this post, we discussed how MoneyLion was able to take advantage of cost-savings without performance degradation using Aurora I/O-Optimized. Based on their use case and I/O-intensive workloads, MoneyLion was a perfect fit to migrate their workloads to Aurora I/O-Optimized while saving about 55% of their total Aurora spend. Lastly, MoneyLion was able to create price predictability and optimize their RI purchase, enabling them to plan for future workloads to be moved to Aurora I/O-Optimized.

If you have any questions or comments, leave them in the comments section.


About the Authors

Shubhrajeet

Shubhrajeet Behadi is a Director of SRE at MoneyLion. He has a keen focus on optimizing infrastructure, ensuring seamless service delivery, and driving strategic cost-optimization initiatives, he leads a dynamic team responsible for the platform’s reliability and efficiency. Based in Kuala Lumpur, Shubhrajeet loves traveling, hiking, and cooking. He is also a sports enthusiast and values quality time with his wife and son.

Mukesh

Mukesh Agrawal is a Senior Database Specialist Solutions Architect at Amazon Web Services. He works with our customers to provide guidance and technical assistance on database projects, helping them improve the value of their solutions when using AWS.

Amit

Amit Narang is a Senior Solutions Architect at Amazon Web Services. He helps our customers design and operate Well-Architected solutions. Driven by his passion for technology, his role involves assisting customers in crafting and implementing solutions that fully embrace the potential of the AWS Cloud.