Your AWS bill went up and somebody has asked what you are going to do about it. There are three answers, and most of the advice you will find is written by whoever sells one of them.
I sell the third one. Weigh what follows accordingly. I have tried to write the version I would want to read before spending money, which means the honest answer is often that you should not spend any.
First, the free option nobody runs
Before you evaluate anything, spend an afternoon in the tooling AWS already ships. It is not marketing to say this catches a real share of the problem, and skipping it is how people end up paying a vendor to tell them about idle instances.
AWS Cost Optimization Hub consolidates more than 18 types of recommendation across your accounts and Regions in one dashboard: EC2 rightsizing, Graviton migration, idle resource detection, RDS and Aurora recommendations, and Savings Plans coverage.
AWS Compute Optimizer is explicit that "there is no additional charge" for the base service. The optional enhanced infrastructure metrics, which widen the analysis window from a couple of weeks to three months so it can see quarterly patterns, cost $0.0003360215 per resource per hour. That is about $0.25 a month for a resource running continuously.
If a vendor's pitch is essentially "we surface idle and oversized resources", you are being sold a nicer interface over recommendations you already have. That is sometimes worth paying for. It is worth knowing that is what you are buying.
The three options, side by side
| Reaches | Costs | Fails when | |
|---|---|---|---|
| In-house | Anything, in principle | Salary time, and the opportunity cost of what that person is not building | Nobody owns the bill, so it is everyone's fourth priority and nobody's first |
| Automated tool | Rightsizing, idle resources, commitment coverage, anomaly alerts | Typically a share of spend or of realised savings | The waste is in how a workload is designed, which no agent can safely rewrite |
| Outside specialist | Design-level change: partitioning, file layout, job shape, engine choice | A fixed scope or a day rate | The problem was genuinely just rightsizing, and you paid a person to do a tool's job |
The rows are not competitors so much as different reach. A tool operates on resources. A specialist operates on decisions. Your bill is some mix of both, and the mix is what decides where the money goes.
The number that decides it
There is one diagnostic worth running before anything else. Open your Cost Explorer, group by service, and look at how concentrated the spend is.
- Flat and broad, with no single service above roughly 20% and a long tail of small line items, means your waste is probably distributed: idle resources, oversized instances, missing commitments. That is exactly what automation is good at, and it scales in a way a person does not.
- Sharp and concentrated, with one or two services carrying most of the bill, means the money is in a small number of workloads. Automation will trim the edges. The actual saving is in how those workloads are built, and that is a design problem.
Concentrated bills are the common case in data engineering, because ETL tends to pile spend into Glue, EMR, Athena or the warehouse. It is also the case where automated tools disappoint people, and the reason is structural rather than a failure of the products.
What automated tools genuinely do well
Credit where it is due. A good cost tool beats a human at three things and it is not close.
It never stops watching. A consultant leaves. A tool notices the anomaly at 3am on a Sunday, three weeks after the engagement ended.
It handles breadth. Four hundred accounts is a data problem, not a judgement problem. Nobody should be auditing that by hand.
It manages commitments continuously. Savings Plans and Reserved Instance coverage shifts as your usage does, and keeping it optimal is an ongoing arithmetic job that suits software.
If your bill is EC2, RDS and storage across a lot of accounts, buy the tool. You will get more from it than from me, and I would rather say so than take the work.
Where they stop, and why
An automated optimiser can only act on things it can change safely without understanding your business. That boundary is real and it is not a criticism.
Take a Glue job that reprocesses your full history every night. A tool can tell you the job is expensive. It might suggest a smaller worker type. What it cannot do is look at the job and conclude that the pipeline should be incremental, that the table wants partitioning by ingest date, that the 40,000 small files landing in S3 are the actual problem, or that this job should not be Glue at all.
Those changes need someone to read the code and understand what the data means. On a three-tier Glue, S3 and Redshift pipeline I rebuilt, the fix was moving from full reloads to incremental and SCD loads. Runtime dropped 20% and throughput rose 30%. Glue bills by DPU-hour, so a runtime cut is a bill cut that keeps paying every night afterwards. No optimiser suggests "restructure your load strategy", because no optimiser can know whether that is safe.
The distinction worth holding onto: a tool tunes what you built. A person can tell you that you built the wrong thing. Those are different products and the second one is not automatable yet.
If you want to know which category your Glue spend falls into, the Glue cost calculator will show you what worker count and runtime are costing you per month, and where the bill actually goes covers the mechanics in detail.
Where in-house genuinely wins
The default answer should be in-house, and it fails for one specific reason that has nothing to do with capability.
Your team can do this. They know the systems better than any outsider will in a fortnight. What they usually do not have is ownership and uninterrupted time. Cost work is never the most urgent thing in the sprint, it competes with shipping features, and it is the first thing dropped when something breaks. So it gets picked up, half done, and abandoned at the point where the interesting part starts.
In-house wins when you can name the person who owns the bill and protect their calendar. If you cannot do both, in-house is not really an option you are choosing. It is one you are deferring.
There is also a genuine argument against outsourcing that is worth stating plainly: the knowledge leaves with the contractor. Mitigate it by making the handover a deliverable rather than a courtesy, or accept it as part of the price.
Where an outside specialist wins
Three situations, in order of how clear-cut they are.
The bill is concentrated and the fix is architectural. One or two workloads carry the spend and the answer is a redesign. This is the strongest case, because the saving is large, one-off and permanent.
Nobody in-house has done this specific thing before. Not a skill gap so much as a pattern-recognition gap. Someone who has optimised twenty Glue jobs knows within an hour which of five likely causes it is. That speed is most of the value.
You need the answer to be independent. If the person recommending the change also owns the system that caused it, the recommendation is harder to trust and harder to act on politically.
And the case against, honestly: if you cannot articulate what you want done, you are not ready to buy. An open-ended "look at our AWS bill" is how engagements drift and how people conclude consultants are expensive.
What each actually costs
Rough shapes rather than quotes, because the real number depends on scope.
- In-house is the salary cost of the days spent, plus whatever those days would otherwise have shipped. It looks free on the budget and is not.
- Automated tools usually price as a share of spend or of realised savings. Read which. A share of spend charges you the same whether or not it finds anything.
- A specialist is a fixed scope or a day rate. UK contract data engineering runs at a £500 median day rate, with AWS-specific roles at £513, and a focused cost engagement is usually 5 to 15 days rather than a retainer.
The comparison that matters is against the size of the problem, not against each other. Flexera's 2026 State of the Cloud report, from a survey of 753 cloud decision-makers, puts estimated wasted cloud spend at 29%, the first increase in five years, driven largely by AI workloads. On a $40,000 monthly bill, a quarter of the waste is worth more than any of these three options costs.
The rule I would use
- Run Cost Optimization Hub and Compute Optimizer. Free, an afternoon, and it sets your baseline. Do not skip to step 2.
- Look at concentration. Broad and flat means buy a tool. Sharp and concentrated means the money is in design.
- Ask whether anyone owns the bill. If yes, and they have time, do it in-house. If no, no tool will fix that, because tools produce recommendations and recommendations need an owner.
- Bring someone in for the concentrated, architectural part only. Fixed scope, defined finish, measured against a baseline you captured in step 1.
Most organisations that are unhappy with their cost tooling skipped step 1, bought at step 2, and never did step 3.
Frequently asked questions
Is AWS cost optimisation worth outsourcing?
It depends on where the spend sits. If your bill is spread thinly across many accounts and resources, an automated tool covers it better and more cheaply than a person. If most of the bill is concentrated in a few workloads such as Glue, EMR or Athena, the saving is usually in how those workloads are designed, which is architectural work an automated optimiser cannot do safely. Concentrated bills are worth outsourcing. Broad, flat ones usually are not.
Are automated AWS cost tools better than hiring a consultant?
They are better at different things. Tools win on continuous monitoring, breadth across many accounts, and keeping Savings Plans coverage optimal, all of which are ongoing arithmetic. A consultant wins where the fix requires understanding what the data means: making a pipeline incremental, repartitioning a table, consolidating small files, or moving a job to a different service. A tool tunes what you built. A person can tell you that you built the wrong thing.
Can I reduce my AWS bill without hiring anyone?
Often, yes. AWS Cost Optimization Hub consolidates more than 18 types of recommendation across accounts and Regions, and AWS Compute Optimizer carries no additional charge for its base service. Between them they surface idle resources, oversized instances and commitment gaps, which is a meaningful share of typical waste. Run both before paying anyone, including me. They also give you the baseline you will need to prove any later work actually saved money.
How much does an AWS cost optimisation engagement cost?
A focused engagement is usually 5 to 15 days rather than an open-ended retainer, because the analysis is bounded by what the bill already tells you. UK contract rates for data engineering sit at a £500 daily median, with AWS-specific roles at £513 in the six months to August 2026. The figure that matters more is what the waste costs you per month while it goes unfixed, since a recurring saving compounds and a one-off fee does not.
Should I hire a contractor or use AWS Professional Services?
AWS Professional Services brings deep product access and AWS accountability, and it is scoped around AWS services. An independent contractor is scoped around your bill, which sometimes means recommending you use less of AWS or a different service entirely. For a regulated, large-scale programme the former often fits better. For a targeted "why did this workload triple" question, the latter is usually faster and cheaper.
What is the first thing to check when an AWS bill jumps?
Open Cost Explorer, group by service, and compare the current period against the previous one rather than looking at totals. A jump is nearly always one service, and often one workload inside it. Identify that before forming any theory, because the intuitive answer is wrong often enough to waste a week. Only once you know where the money went is it worth deciding whether the fix is a setting, a tool, or a redesign.
The honest summary
Run the free tooling. Look at whether your spend is broad or concentrated. Work out whether anyone actually owns the bill, because that answer decides more than the choice between a tool and a person.
If it turns out the money is concentrated in a Glue or Athena workload and the fix is structural, tell me what the bill is doing and I will tell you whether it is a five-day problem, a redesign, or something you can fix yourself this week.
Mirza Hammad Tariq
Data & Automation Engineer with 5+ years on AWS: ETL pipelines, backend APIs and automation workflows in Python, SQL and FastAPI, built to cost less to run.