The expensive part was not traffic. It was an architecture that charged the company repeatedly for work the product did not need.
When we first reviewed the platform, its AWS invoice had been climbing every month. User growth was healthy, but infrastructure spending was growing much faster than revenue. The accepted explanation was simple: scale costs money.
The data told a different story.
Most of the bill came from idle capacity, overly expensive managed services, and database reads caused by the same information being requested again and again. The system was paying enterprise prices for startup traffic.
We measured before changing anything
Cost optimization becomes dangerous when teams begin by deleting resources. We began with a full map of the system:
- cost by AWS service and environment;
- CPU, memory, network, and database utilization;
- request volume by endpoint;
- slow and repeated queries;
- resources that were running but serving no production traffic.
This separated real capacity requirements from architectural waste.
1. Right-sizing the compute layer
Several application instances were provisioned for peak traffic that had never occurred. Average CPU utilization remained below 12%, including during busy periods.
We moved the workloads to smaller instances, enabled autoscaling around measured thresholds, and separated background jobs from user-facing requests. The application retained headroom without paying for unused capacity every hour of the month.
2. Removing duplicate database work
One dashboard triggered the same relational queries for every component and every refresh. A single page view could generate hundreds of reads even though most results changed only a few times per day.
We introduced deliberate caching with explicit invalidation rules. Frequently requested reference data moved to Redis, while user-specific data stayed in the primary database. We also combined repeated queries and added the missing indexes revealed by execution plans.
The goal was not to cache everything. It was to stop purchasing the same answer repeatedly.
3. Simplifying managed infrastructure
Managed services are valuable when they remove operational work that a team genuinely has. They become expensive when selected only because an architecture diagram looks more sophisticated.
We replaced two lightly used managed endpoints with a simpler deployment that matched the team's real availability requirements. Backups, monitoring, patching, and recovery tests remained in place; unnecessary service premiums did not.
4. Making cost visible to engineering
The lasting improvement was organizational. We added cost checks to the normal engineering workflow:
- budgets and anomaly alerts for each environment;
- ownership tags on every resource;
- a monthly cost-per-active-user metric;
- review of estimated infrastructure impact for major features.
After the migration stabilized, the monthly AWS bill was 60% lower. Response times improved because fewer redundant queries reached the database, and the team gained a system it could understand and operate confidently.
Cloud cost is an architectural signal. Measure the work your system performs, then pay only for the work your users need.