September 10, 2025

From Overspend to Optimized: Transforming Infrastructure Costs

Challenge	Approach	Results
AWS costs scaling faster than revenue 40% of spend concentrated in database costs Unreliable data pipelines affecting operations	Deep analysis of actual vs. provisioned capacity Strategic right-sizing with safety margins Selective migration from managed services	$9,640 monthly savings ($112K annually) Improved reliability and performance Better operational control

The Challenge: Growth at What Cost?

During our quarterly budget review, leadership highlighted a critical issue: our AWS costs were scaling faster than revenue. With our community finance platform serving nearly 2 million users in underserved communities, we needed to optimize infrastructure without compromising reliability or user experience.

For an infrastructure team, this translated to an exciting challenge: How do you identify opportunities to run infrastructure more efficiently while simultaneously improving reliability and demonstrating clear ROI?

This represented an opportunity for smart resource management and strategic thinking that would align efficiency with fiscal responsibility. The possibilities included – (1) infrastructure that operated more efficiently while maintaining reliability, (2) optimized resource allocation that could improve our unit economics, and (3) systems that performed better while costing less to operate.

At SoLo, every system decision impacts real people. When our platform is responsive, community members can access financial assistance quickly, often during emergencies when time matters most.

Next Steps: Strategic Infrastructure Analysis

To deliver meaningful cost reductions without compromising user experience, we needed to first understand where our infrastructure resources were being used and where we could operate more efficiently. This wasn’t about cutting corners but it was about smart resource allocation that would maintain reliability while reducing unnecessary spending.

Our approach was methodical: identify the biggest opportunities, analyze usage patterns thoroughly, and make changes that would improve both efficiency and cost-effectiveness. The goal was to optimize our way to better financial performance, not optimize our way to reduced capabilities.

Starting with the Biggest Line Items

Like most growing fintech companies, our AWS bill had several significant categories, but RDS Aurora immediately stood out as our largest single expense in Cost Explorer. When you’re running a financial platform processing millions of peer-to-peer transactions, database costs add up quickly, but the magnitude surprised us.

The initial Cost Explorer analysis revealed that RDS accounted for approximately 40% of our total AWS spend, making it the obvious starting point for optimization efforts.

My approach was methodical:

AWS Cost Explorer analysis – Break down costs by service and usage type
RDS cost deep-dive – Analyze the components driving database expenses
Resource inventory – Map every database instance to its business function
Usage pattern analysis – Understand actual vs. provisioned capacity

The I/O Discovery

Cost Explorer revealed something interesting: our Aurora instances were generating substantial I/O charges alongside the base instance costs. This wasn’t immediately obvious from our monthly summaries, but the detailed breakdown showed I/O operations as a significant cost driver.

The next question: Was this a temporary spike or a consistent pattern?

I pulled 6 months of CloudWatch metrics to establish a baseline. The data clearly showed a consistently high I/O usage across multiple Aurora instances. Our workloads were genuinely I/O-intensive, serving the real-time financial data needs of our community lending platform.

The Decision Matrix

Here’s where it got interesting. AWS offers I/O-optimized Aurora instances that include I/O operations in the base price, but they cost roughly 30% more than the standard instance price.

The analysis looked like this:

Current State (Standard Aurora):

Base instance cost: $X/month
I/O charges: $Y/month (significant portion)
Total: $X + $Y

Option 1 (I/O Optimized):

Instance cost: ~$1.3X/month
I/O charges: $0 (included)
Total: ~$1.3X

Option 2 (I/O Optimized + Reserved Instances):

Migrate to I/O-optimized storage tiers (includes I/O operations)
Commit to 1-year reserved capacity for predictable workloads
Right-size underutilized replicas
Optimize auto-scaling parameters
Keep current instance family (r6)

The math favored Option 2, but only if we could accurately predict our baseline capacity needs and execute right-sizing without impacting performance.

Engineering Decisions and Trade-offs

Decision 1: Reserved Instance Strategy

Rather than doubling our instance costs with I/O optimization, we chose to commit to reserved instances for our baseline capacity. This required confidence in our usage patterns, but our 6-month analysis gave us that confidence.

Our implementation approach:

Purchase 1-year reserved instances for predictable baseline workloads
Continue using on-demand instances for traffic spikes
Stick with r6 instance family for operational consistency

The risk calculation: Reserved instances require commitment, but our community lending platform has predictable base traffic patterns with well-understood peak behaviors.

Result: $2,500/month in savings on database instances.

Decision 2: Right-Sizing Read Replicas

Our analysis revealed a classic over-provisioning pattern: 8xlarge read replicas that were underutilized.

The right-sizing process:

Analyzed connection counts, memory usage, and CPU utilization over our 3-month baseline period
Calculated buffer requirements for peak loads during high-volume lending periods
Scaled down from 8xlarge to 4xlarge for specific read replicas
Updated auto-scaling policies from 4xlarge to 2xlarge maximum

Why this worked: Our data showed actual resource utilization was well below provisioned capacity, even during peak lending activity. The 4xlarge instances provided adequate headroom for growth while eliminating waste.

The confidence factor: We kept detailed monitoring in place and had rollback procedures ready, but the utilization data was clear enough to make this a calculated move rather than a risky guess.

Result: Additional $2,400/month in savings.

Decision 3: When Managed Services Become Cost Drains

Moving to our data pipeline analysis, our FiveTran our contract was coming up for renewal while simultaneously facing increasingly frequent reliability issues.

This created an ideal opportunity to evaluate alternatives from both cost and operational perspectives. FiveTran reliability problems had become increasingly frequent over the past 2 months, with daily connector failures affecting our business operations.

Our PostgreSQL to Snowflake data synchronization had become unreliable with frequent connector failures. These weren’t isolated incidents – we were regularly seeing sync delays of 3-4 hours during FiveTran outages, right when we needed to decide whether to renew at existing pricing levels.

The business impact was significant:

Leadership couldn’t access real-time insights for strategic planning
Our growth team couldn’t trigger timely user engagement campaigns based on current user behavior

The migration decision process: We evaluated several alternatives but settled on Airflow on ECS with Astronomer for key reasons:

Complete operational control during incidents (no waiting for vendor resolution)
Easier SSH debugging capabilities compared to AWS MWAA’s
Better DBT integration through Astronomer packages
Flexible scaling for our data volume and transformation complexity
Predictable cost structure vs. Fivetran’s usage-based pricing

Implementation approach:

Migrated critical PostgreSQL → Snowflake pipelines to Airflow first
Maintained parallel systems during transition to ensure data continuity

The cost improvement: Moving from expensive managed service costs to self-hosted infrastructure with predictable pricing and better operational control.

Result: $2,000/month in cost savings, plus reliable data pipelines that our business teams can depend on for critical decisions.

The Complete Optimization Results

Total Monthly Savings: $9,352 ($112,224 annually)

Database Optimization:

Reserved instance strategy: $2,500/month

Storage Optimization:

Moved standard-tier database to I/O-optimized storage tier: $4,200/month
Better matched storage performance to actual workload requirements

Pipeline and Tool Optimization:

Migration of larger tables from FiveTran to Airflow: $2,000/month
Consolidated monitoring tools (removed redundant Postman and Sentry subscriptions): $588/month
Replaced Airbyte with Airflow for simpler data movement tasks: $252/month
Ongoing MQ broker to Kafka migration: ~$400/month

Reinvesting Savings for Growth

The infrastructure optimizations we implemented created opportunities for strategic reinvestment in platform capabilities which included –

Improved infrastructure automation that ensures more reliable service
Improved monitoring that prevent issues before they impact our community
Better resource scaling to maintain performance while supporting growth

Key Takeaways for Engineering Teams

Baselines are crucial. Confident infrastructure decisions require good data. Invest the time upfront to understand your actual usage patterns and performance characteristics.

Right-sizing is an ongoing practice, not a one-time project. Build monitoring and analysis capabilities that help you continuously optimize your infrastructure as your product and user base evolve.

Document everything. Your future self (and your teammates) will thank you for clearly documenting the reasoning behind infrastructure decisions, especially when those decisions involve trade-offs between cost, performance, and operational complexity.

Replicable Infrastructure Optimization Methodology

The approach we used can be applied to any infrastructure optimization challenge:

Step	Action	Tools/Metrics	Expected Outcome
1. Identify	Break down costs by largest line items	AWS Cost Explorer, service breakdown	RDS as 40% of total spend – clear starting point
2. Deep-Dive	Analyze components driving expenses	RDS cost analysis, I/O charge breakdown	I/O operations as 70% of daily RDS costs
3. Establish Baseline	Gather 6+ months of usage data	CloudWatch metrics, utilization patterns	Predictable lending cycles, over-provisioned replicas
4. Decision Matrix	Compare optimization options with trade-offs	Reserved vs I/O-optimized analysis	Option 2: I/O-optimized + Reserved instances
5. Phased Implementation	Execute with monitoring and rollback plans	Reserved instances, right-sizing, vendor evaluation	$9,640/month savings with maintained reliability

The SoLo Mission Connection

At SoLo Funds, we’re building technology that serves underserved communities – people who traditional financial services often overlook. We facilitate peer-to-peer lending that helps community members access financial assistance when they need it most.

Through strategic infrastructure optimization, we created a win-win situation: our platform operates more efficiently and reliably while reducing costs that can be reinvested in platform improvements and competitive pricing. Every optimization we implement serves a dual purpose – maintaining excellent service for our current community while ensuring long-term sustainability.

The cost optimizations enabled focus on user value:

Predictable infrastructure costs support stable pricing for our community
Reliable platform performance ensures our community can access financial assistance without technical barriers
Investment into newer technology to serve our users better with more personalized info

When you’re building technology for people who have been underserved by traditional systems, efficiency isn’t just about cost management, it’s about maximizing every resource to serve your community more effectively and sustainably.