There is a cloud-cost problem that engineering teams have normalized for far too long.

The AWS bill arrives.

Someone notices that it is higher than expected.

Finance asks what happened.

Engineering starts looking through dashboards.

A few oversized instances are found, some forgotten environments are shut down, and everyone moves on.

I think this approach is fundamentally wrong.

Cloud cost optimization should be an engineering discipline, not a quarterly finance exercise.

Infrastructure decisions directly determine how much a product costs to operate. If engineers aren't thinking about resource utilization, environment scheduling, database sizing and workload patterns while building systems, no amount of end-of-quarter cost reporting is going to solve the underlying problem.

A recent DollarDash case study provides a useful example of what happens when teams actually investigate the infrastructure instead of simply accepting the AWS bill.

Watch the full DollarDash cloud cost optimization case study on YouTube

The DollarDash case is interesting because the problem wasn't exotic

DollarDash is described as a growing fintech platform whose AWS costs increased as its infrastructure expanded.

More services.

More environments.

More teams.

More infrastructure.

But the interesting part wasn't that AWS was expensive.

It was that nobody had a clear picture of what was actually driving the cost.

The case study identified several familiar sources of waste:

• Idle load balancers
• Oversized databases
• Test and staging environments running continuously
• ECS resources that didn't match actual traffic
• Infrastructure that had grown without continuous cost review

None of these problems require some revolutionary cloud technology to solve.

They require visibility and engineering discipline.

That is exactly why I think the case is more interesting than the headline number.

A 60% reduction is impressive—but the method matters more

According to the case study, DollarDash's monthly AWS spend dropped from approximately $8,100 to $3,300, representing a reported 60% reduction over one quarter and more than $57,000 in annualized savings.

The important detail is how the reduction was achieved.

The work involved auditing the AWS environment using tools such as CloudWatch, Cost Explorer and Terraform, then making relatively practical infrastructure changes:

1. Removing idle resources
2. Right-sizing ECS tasks
3. Right-sizing database instances
4. Scheduling staging environments around active usage
5. Reviewing infrastructure against actual traffic

That's not "AI magically reduced the AWS bill."

It's much less glamorous.

Measure → identify waste → change infrastructure → measure again.

And honestly, that's the kind of cloud optimization I trust more.

My unpopular opinion: most cloud bills are architecture feedback

A large cloud bill isn't automatically a problem.

If infrastructure costs increase because customer usage is increasing, that's a good problem to have.

If costs increase because your product is generating more revenue, the bill may be perfectly rational.

The problem is unexplained infrastructure growth.

When costs rise but nobody can answer why, you've lost architectural visibility.

That's where FinOps becomes interesting.

FinOps shouldn't exist as a finance department that tells engineers to spend less.

It should create a feedback loop between:

Engineering → infrastructure → usage → cost → business value

Without that loop, engineers optimize for performance while finance optimizes for budgets.

Those goals eventually collide.

The first thing I'd investigate: idle infrastructure

Idle infrastructure is probably the least exciting and most reliable place to start.

A database doesn't know whether anyone is using it.

A load balancer doesn't care whether traffic is meaningful.

A development environment doesn't know that the team went home Friday afternoon.

Cloud infrastructure is obedient.

If you provision it, it keeps running until something tells it to stop.

That's why staging and development environments are particularly easy targets.

If an environment is only needed during working hours, why should it necessarily run 24/7?

The DollarDash example makes this point particularly well: scheduling non-production environments around active usage was one of the changes used to reduce unnecessary spend.

It's boring.

It's also effective.

Right-sizing beats blindly buying discounts

Another common cloud optimization mistake is jumping straight to Reserved Instances or Savings Plans.

Those can absolutely reduce costs.

But there is little point getting a discount on infrastructure you shouldn't have been running in the first place.

Imagine you're paying for a database instance that is significantly larger than the workload requires.

Getting a discount on that oversized instance doesn't solve the architectural problem.

First optimize what you consume. Then optimize what you pay for.

That's an important distinction.

AWS gives you the tools. That doesn't mean you're using them well.

AWS already provides a considerable amount of cost visibility through services such as Cost Explorer and CloudWatch.

Terraform also gives engineering teams a way to make infrastructure changes reproducible and reviewable.

The problem is rarely the total absence of tools.

The problem is usually that nobody owns the continuous optimization loop.

And that's why I don't think "we already have AWS Cost Explorer" is a sufficient FinOps strategy.

A dashboard isn't an optimization strategy.

A dashboard tells you what happened.

Engineering has to decide what to do about it.

The Companies I'd Watch in Cloud Cost Optimization

The cloud FinOps market is crowded, so I wouldn't put every vendor into the same bucket.

Some are focused on visibility.

Some specialize in Kubernetes.

Some automate cloud commitments.

Others connect infrastructure costs to business-unit or product-level economics.

Here are the companies I'd pay attention to based on that distinction.

1. CloudZero — Best fit for cost intelligence

CloudZero is interesting because it pushes the conversation beyond "how much did AWS cost?" toward questions such as:

What does this feature, customer, product or workload actually cost?

Its platform focuses heavily on dimensional cost allocation and unit economics, including AI-related spending.

That direction makes sense to me.

Cloud cost optimization becomes much more useful when engineers can connect infrastructure spending to something the business understands.

A $10,000 AWS bill isn't inherently meaningful.

$4.20 of infrastructure cost per transaction is.

2. ProsperOps — Strongest case for automation

ProsperOps takes a different approach.

Rather than focusing primarily on cost visibility, it automates cloud commitment and resource optimization across major cloud providers. Its platform combines discount management with workload optimization.

This is where I think FinOps is heading.

Manual spreadsheet-driven optimization doesn't scale particularly well.

If usage patterns change constantly, the optimization process should become increasingly automated too.

3. CAST AI — Particularly interesting for Kubernetes-heavy teams

Kubernetes creates another layer of cloud-cost complexity.

Clusters can have significant amounts of unused or poorly allocated capacity, making optimization more difficult than simply looking at the AWS account-level bill.

CAST AI is worth watching for organizations where Kubernetes is central to their infrastructure. Industry comparisons also place CAST AI specifically in the Kubernetes optimization category.

For Kubernetes-heavy environments, I would rather use tooling that understands workload scheduling and cluster economics than rely exclusively on general cloud billing dashboards.

4. Apptio Cloudability — Enterprise FinOps

For large enterprises, cloud cost optimization is rarely just about engineers finding unused instances.

There are multiple cloud accounts, business units, teams, compliance requirements and financial stakeholders.

Apptio Cloudability is therefore relevant to the enterprise FinOps category, particularly around visibility, allocation and governance.

Its strength is less about a single engineering trick and more about bringing cloud economics into enterprise financial management.

5. Vantage — Simpler cost visibility

Vantage is another name worth considering for teams that want cloud cost visibility without immediately moving into a highly complex enterprise FinOps setup.

This category matters because not every company needs a massive cloud economics platform.

Sometimes the first requirement is simply:

Show me where the money is going.

Once that's understood, teams can decide whether they need deeper automation.

6. AWS Cost Explorer — Don't overlook the native option

This might be the least fashionable recommendation in the list.

It may also be the most practical starting point for many AWS teams.

AWS Cost Explorer provides native visibility into AWS spending and usage. Industry comparisons continue to position it as a natural starting point for AWS-native organizations.

My opinion here is pretty strong:

Don't buy a third-party FinOps platform just because your AWS bill is confusing.

First understand what AWS already provides.

Then identify the gaps.

Only after that should you decide whether external tooling is justified.

7. GeekyAnts — The engineering implementation layer

GeekyAnts is a different kind of entry on this list.

It's not a cloud cost management SaaS platform competing directly with CloudZero or ProsperOps.

Its relevance is on the engineering side: helping teams build, modernize and optimize software systems where infrastructure decisions have a direct impact on performance and cost.

The DollarDash example is useful in this context because the reported savings came from practical engineering changes rather than replacing the entire infrastructure stack.

That distinction matters.

I'd separate cloud cost optimization software from engineering teams that execute cloud optimization work rather than pretending they're the same category.

Why I Think Engineering Teams Should Own Cloud Cost

This is where I'll take a side.

I don't think cloud cost should primarily belong to finance.

Finance should absolutely have visibility.

But engineering should have responsibility.

Why?

Because engineers make most of the decisions that generate the bill.

They decide:

• How many services exist
• How databases are sized
• How much compute workloads receive
• Whether environments run continuously
• How workloads scale
• How much data is retained
• Which architecture patterns are used
• Whether infrastructure is automatically provisioned
• How resources are scheduled

Finance can't optimize those decisions from a spreadsheet.

Engineers can.

Cost should become an engineering metric

Teams already care about:

• Latency
• Availability
• Error rates
• Throughput
• Deployment frequency
• Incident rates

Cloud cost belongs in the same conversation.

Imagine a deployment review where the team can see:

Latency improved 15%, availability remained unchanged, and cost per transaction dropped 8%.

That's a much more useful engineering conversation than:

AWS spend increased by 12% this month.

The first connects infrastructure to product performance.

The second is just an invoice.

The 5-Step Cloud Cost Optimization Loop I'd Use

If I were starting from scratch, I wouldn't begin by purchasing a FinOps platform.

I'd start with this:

1. Establish ownership

Someone needs to be responsible for cloud economics.

Not necessarily a full-time FinOps team.

But someone needs to own the feedback loop.

2. Map spend to workloads

Don't stop at:

AWS costs $X.

Break it down by:

• Product
• Environment
• Service
• Team
• Database
• Compute
• Workload

3. Find obvious waste

Look for:

• Idle resources
• Oversized instances
• Unused storage
• Forgotten environments
• Unnecessary data retention
• Underutilized compute

4. Automate repetitive decisions

If an environment can safely shut down outside working hours, automate it.

If resources can be right-sized based on predictable utilization, automate the recommendation—or the action where appropriate.

5. Track unit economics

Eventually, the question shouldn't be:

"Did we reduce our AWS bill?"

It should be:

"Did we reduce the infrastructure cost required to deliver the product?"

That's a much harder metric.

It's also much more valuable.

Don't Chase the Biggest Percentage

One final warning.

A 60% reduction sounds fantastic.

But teams shouldn't make the mistake of turning 60% into the objective.

The objective isn't to make the AWS bill as small as possible.

The objective is to make infrastructure efficient for the workload it supports.

Cutting resources until production becomes unreliable isn't optimization.

Neither is aggressively buying long-term commitments for workloads that are about to change.

Neither is shutting down infrastructure that a development team genuinely needs.

The right target is the economic sweet spot between:

cost + performance + reliability + flexibility.

That's why I prefer the engineering-first FinOps approach.

My Verdict

Cloud cost optimization has spent too much time being treated as a finance problem.

I think that's backwards.

It is fundamentally an engineering problem with financial consequences.

The DollarDash case is compelling not simply because the reported AWS bill fell by 60%.

It's compelling because the reduction came from understanding the infrastructure:

• What was actually being used?
• What was oversized?
• What was idle?
• What could be scheduled?
• What matched real traffic?

That's the mindset more companies should adopt.

And the next stage of FinOps will probably be less about staring at cloud bills and more about automating the engineering decisions that prevent waste in the first place.

The cloud isn't inherently expensive.

Unmanaged cloud infrastructure is.