Finops on LeanerCloud

ElastiCache cost optimization: rightsizing, Valkey, and reserved instances

Tue, 30 Sep 2025 15:23:51 +0000

ElastiCache is where I find the most extreme overprovisioning

Of all the AWS services I optimize, ElastiCache is where I most often find caches provisioned far beyond anything the workload needs. Databases at least tend to grow into their instances. Caches get sized once, generously, and then nobody revisits them.

On one client the ElastiCache clusters were provisioned at 20x to 300x the capacity they actually used. That is not a typo. The smallest available ElastiCache instance was still 2x to 30x larger than what those workloads needed, so even dropping to the floor of the instance range left plenty of headroom. Rightsizing that footprint, together with converting it to Graviton, cut the cost by about 90%, roughly 10x cheaper than before.

Converting Aurora Serverless to provisioned for cost and performance

Wed, 16 Jul 2025 10:26:20 +0000

Serverless is a scaling tool, not a default

Aurora Serverless scales capacity up and down automatically, which is genuinely useful when your load is bursty or unpredictable. The trouble is that it gets adopted as a default for databases whose load is nothing like that, and at scale the per-capacity-unit price makes it an expensive way to run a steady workload.

I think of Aurora Serverless less as a permanent home for a steady database and more as a temporary configuration that helps you discover the capacity a database actually needs, so you can then move it to a right-sized provisioned instance. If a database has been running at a roughly constant capacity for a year, it is not a Serverless workload.

Slashing S3 costs with the right storage class and lifecycle rules

Thu, 29 May 2025 21:31:47 +0000

Most large S3 bills are old data in the wrong tier

When a client has a large S3 bill, the cause is usually not the data they are actively using. It is data they stopped using years ago and kept paying full price to store, because it is sitting in S3 Standard when it should be in a cheaper tier or deleted outright.

On one client, the vast majority of their S3 cost came from buckets storing logs. They had many dozens of terabytes of old log files as S3 Standard, spread across multiple buckets, some of it dating back five years. They only needed a few months of retention. They were paying thousands of dollars a month to keep years of logs they would never look at.

Finding and cutting unused and idle RDS databases

Tue, 08 Apr 2025 11:48:32 +0000

The databases nobody is using anymore

On almost every non-trivial AWS account I look at, some RDS databases are running that nobody uses. They were spun up for a migration that finished, a service that got decommissioned, or a test that became permanent. They still run 24/7, still carry storage, and still show up on the bill every month.

The problem is not that these are hard to fix. Deleting an unused database or dropping an instance a size is a few minutes of work. The problem is finding them. On an account with dozens of databases spread across several regions, the waste is spread thin, and no single database is obviously wrong to an engineer who does not stare at RDS metrics all day.

The cross-AZ data transfer costs hiding in your database traffic

Fri, 20 Sep 2024 22:24:02 +0000

The line item nobody can explain

Cross-AZ data transfer is one of the least understood costs on an AWS bill. It does not map to a resource you can point at, it just shows up as data transfer charges, and it grows silently as traffic increases. A common source is an application instance talking to its database across an Availability Zone boundary, paying per gigabyte in both directions for traffic that could have been free.

Moving bursty Fargate and EC2 workloads to Lambda for 10x savings

Thu, 25 Jul 2024 19:04:45 +0000

Fargate is not always the cheapest place to run a request

Fargate is a good default for containerized services, but for spiky web frontends and REST APIs it can be an expensive one. If your containers spend most of their time idle and then get slammed with requests for a few seconds at a time, you are paying for provisioned capacity that mostly sits waiting, and Fargate is often too slow to scale into the burst anyway, so users see latency spikes on top of the cost.

Cutting CloudWatch Logs costs hiding in a few log groups

Tue, 09 Apr 2024 17:05:18 +0000

A line item that is easy to ignore

CloudWatch Logs rarely shows up as a headline on an AWS bill, which is exactly why it is worth checking. The cost is spread across ingestion, storage, and retention, and it accumulates quietly on log groups that were configured once and never revisited. By the time it is real money, it is buried among hundreds of other log groups.

One log group, $8,000 a year

On one client the biggest single offender was a VPC flow log. Flow logs can be extremely verbose, and this one group had accumulated 2TB of data, costing about $8,000 a year on its own.