Hiring an AWS Cost Optimization Consultant? What the Review Should Hand You

This year I watched a SaaS company's AWS bill go from about $12,000 a month in January to about $20,800 in May. Nobody had made a bad decision. Spend had grown about 70% in four months, and nobody could say which part of it bought anything.

That is the usual starting point when someone looks for an AWS cost optimization consultant. The bill is up, finance is asking, and the engineers are busy shipping. So it is worth knowing what a good cost review should hand you at the end, and what should make you walk away.

You should get a baseline you can check

The first thing a review produces is not a list of savings. It is a baseline: what you spent, month by month, split by account, environment, team and service, built from your own billing data. I use twelve months when the data exists, because one month hides seasonality, credits and one-off charges.

If someone shows you savings without a baseline, you have no way to know whether a later drop came from their work, from traffic, or from billing data that had not arrived yet. The last few days in Cost Explorer are often incomplete, which I wrote about in The Cost Drop That Wasn't.

Ask for the baseline in a form your team can open without the consultant.

Each finding should have a number and an owner

A finding like "rightsize your instances" is not a finding. A useful one names the resource or workload, what it costs today, what it would cost after the change, the risk, and who on your team owns it.

On Kubernetes, the biggest finding is often not a resource at all. It is the gap between what workloads ask for and what they use. On one engagement, requested CPU was 7 to 20 times actual use on every cluster, and about 40% of workloads had no requests at all. The node autoscaler buys nodes for requests, not usage, so that gap was most of the bill. I explained the mechanics in Requests, Not Usage, Set Your Kubernetes Bill.

It should tell you what not to cut

This is the part that separates a review from a sales pitch. Some spend is there for a reason: a second availability zone, a bigger database during a launch, on-demand capacity for production.

I learned this one the hard way. After a cost project moved a lot of workloads to interruptible capacity, a reclaim took production down. I moved production back to regular capacity. It costs about $1,000 a month more and it was the right call for a customer-facing product. A good review flags those trade-offs before you make them, not after an incident.

Commitments come last

Savings Plans and Reserved Instances are real savings. They are also the easiest way to lock in waste for a year or three.

If the first recommendation is a large commitment, be careful. Buy commitments on the lean baseline, after the duplicate tools, idle environments and oversized workloads are gone. On the engagement above, the one-year compute commitment was the last step, not the first.

Red flags when you hire

• They want write access to look. A review needs read access to billing and resource data. Nothing more. I describe the access I ask for on the security page.
• Savings only work if you buy their tool. Tools can help. A review should not depend on one, and you should keep every dashboard and script after the engagement ends.
• A percentage promised before they have seen the bill. Every account is different. A credible number comes after the baseline.
• No mention of reliability. If nobody asks what happens to latency, failover or upgrade paths, the savings may come back as incidents.
• Nothing written down. You should get a written plan you can execute with your own team, even if you never call the consultant again.

What the result can look like

On the engagement I mentioned, monthly AWS spend fell from about $20,800 in May to about $9,300 in August, 55% lower, and held through September. Removing a self-hosted metrics stack that duplicated a paid tool saved about $2,500 to $3,000 a month. Moving four EKS clusters out of paid extended support saved about $1,440 a month. Some savings were later spent back on purpose, on regular capacity for production and on a new feature, and spend was still around 40% below May. The full write-up is in Cutting a SaaS Platform's Kubernetes Cloud Bill by 55%.

Your number will be different. The point is that every dollar in that story can be traced to a change, a date and an owner.

Savings that depend on one person come back

The last thing a review should leave behind is a habit, not a report. A dashboard the whole team reads, a short checklist for changes that touch resources, and a session with the engineers who own the services. Without that, the bill drifts back within a few quarters, because new services get copied from old manifests and nobody lowers a request after an incident.

A short checklist before you hire

• Ask for a sample of the baseline and findings format.
• Confirm read-only access, with MFA and no stored credentials.
• Ask how they decide what not to cut.
• Ask when they would recommend commitments, and on what baseline.
• Make sure you keep every dashboard, script and document.

If your AWS bill is growing faster than your product, see how I approach AWS cost optimization. I run an AWS Cost and EKS Review that ends with exactly these things. If you want a quick read first, start with a free Savings Snapshot.

Related serviceCloud Cost & FinOps: Pay for the cloud you use, not the one you forgot.