FinOps Is a DevOps Skill: Two Small Changes Worth ~$4,400 a Year
The point of this article isn’t the two changes. It’s that on big accounts, cost is an operational property, like latency or availability, and DevOps engineers are the ones who set it, usually without realising.
I ran a FinOps assessment on a large, multi-service AWS account. Out of hundreds of cost drivers, the first two changes I shipped were boring: slowing down a monitoring agent’s collection interval, and deleting a load balancer nobody was using. Together they save roughly $4,400 a year on a non-production environment. Neither needed a redesign, a migration, or a new tool. Both were invisible to anyone who wasn’t looking at the bill, and both had been sitting there because they were the defaults.
The point of this article isn’t the two changes. It’s that on big accounts, cost is an operational property, like latency or availability, and DevOps engineers are the ones who set it, usually without realising.
Nobody chose these costs
Here is the uncomfortable part about cloud spend on large accounts: most of it was never decided by anyone.
- A managed add-on ships with a sensible default and gets enabled during a cluster build.
- A Kubernetes
Serviceof typeLoadBalancergets applied once, for a demo or a since-retired app, and the controller dutifully provisions a real AWS resource. - A crawler schedule, a log retention, a metric resolution: each copied from a previous project because it worked.
Each of these is a reasonable engineering decision at the moment it’s made. The trouble is that infrastructure keeps billing long after the reasoning behind it has been forgotten. In a small account you notice. In a large one, with hundreds of billing lines across dozens of services, nobody can hold it all in their head, so defaults become policy by accident.
That’s why I argue FinOps belongs in the DevOps toolbox. Not as a finance discipline you hand to a separate team, but as the same instinct you already apply to reliability: know what your system is doing, and why.
How I found them: measure everything, then rank
I didn’t start by hunting for waste. I started by measuring the whole bill and ranking the drivers by money. In this account there were hundreds of distinct cost lines, and the ranking looked like every large account I’ve seen: a long tail, and a few fat items at the top.
The number-one line, at roughly 16% of the whole monthly bill, was not compute, storage or data transfer. It was CloudWatch metric observations. Not the workload: the monitoring of the workload.
That ordering matters. If you optimise by intuition, you go after EC2 right-sizing, because that’s what the blogs talk about. If you optimise by evidence, you look at the top of the ranked list and ask “why is this here?” The answer is often a default.
The process is deliberately unglamorous:
- Baseline the recurring monthly spend from full billing months (not a partial month, not a one-off spike).
- Rank every driver by cost and trend.
- For each material driver, find the mechanism: what configuration produces this line?
- Price the lever (what changes, what it saves, what it costs to do, what could break).
- Apply a threshold before spending anyone’s time: is the total opportunity large enough relative to the bill to justify the work?
Step 5 is the one people skip, and it’s what stops FinOps turning into a hobby. An assessment that says “NO-GO, the account is already lean” is a perfectly good result.
Change #1: the monitoring that costs more than it should
The default. The EKS cluster ran the managed CloudWatch observability add-on with enhanced Container Insights. Enhanced mode emits detailed per-pod, per-container, per-node metrics, and it emits them at the agent’s collection interval, which defaults to 60 seconds. CloudWatch bills these as observations, so the number of billed observations scales with how often the agent samples.
The lever. Change the collection interval from 60 to 300 seconds through the add-on’s configuration. Five times fewer samples per metric.
The numbers. The observation line went from about $469/month to about $133/month, a saving of $336/month, ~$4,000/year. Notice that it’s not a clean 5x reduction. CloudWatch pricing is tiered, so removing the volume removes the cheaper tiers first and the effective saving is smaller than the raw sample ratio suggests. This is exactly the kind of thing you only get right by pricing the change against the real rate card instead of dividing by five in your head.
The catch, and this is where the DevOps mindset matters. A cost change to a monitoring pipeline is also a reliability change. While validating it, I found an alarm on node CPU utilisation evaluating five out of five datapoints at a 60-second period. At a five-minute collection interval:
- that alarm can flip to
INSUFFICIENT_DATA, because there's no longer a datapoint every minute, and - time-to-alarm on a real CPU problem stretches from about five minutes to about twenty-five.
So the change isn’t “edit one number”. It’s “edit the interval and retune the alarm period in the same deployment, then compare dashboards and alarms for a week”. A pure FinOps view would have missed this. A pure DevOps view would never have looked, because nobody was asking about the monitoring bill. You need both hats on at once.
Lesson: every cost lever has a blast radius. The savings number is the easy half of the work; the what-else-depends-on-this check is the professional half.
Change #2: the load balancer with no one behind it
The default. An internet-facing Network Load Balancer was provisioned automatically by a Kubernetes ingress controller. It had zero healthy targets for fourteen days. Nobody was using it, but a provisioned NLB bills by the hour whether or not it serves a single packet.
The lever. Remove it. But how you remove it is the whole story.
If you simply delete the load balancer in the console, the ingress controller sees the desired state (a Service of type LoadBalancer), recreates it, and you’re back to paying, plus you’ve created drift. The right fix is to remove the Kubernetes Service/Ingress and the Terraform resource at the source, so the controller has nothing left to reconcile.
The numbers. About $27/month, $324/year. Small on its own.
Why it still matters. It’s a class of finding, not a one-off. Idle load balancers, orphaned volumes, unattached IPs and forgotten endpoints are the residue of normal engineering work: things that were created for a reason that later went away. Any large account accumulates them. And unlike a rightsizing exercise, there’s no performance risk to weigh, just a check that nothing still points at it (DNS records, external clients, manifests) and a rollback plan (re-apply the manifest from version control).
$4,400 a year isn’t the story
I know how that number sounds. For a company with a serious AWS footprint it’s a rounding error. Here’s why I still think it’s the most useful result of the exercise:
- It came from a non-production environment. Production tends to run the same add-on with the same defaults, often at larger scale. The finding is a pattern; the pattern repeats.
- It took hours, not weeks. Both changes were small, configuration-level, and reversible. The payback period is essentially the time it takes to open a pull request.
- It scales with the account. In a big organisation, “the same default in every environment and every cluster” is exactly how a few hundred dollars a month becomes a five-figure line. Cost is a multiplier on decisions; the earlier you fix the decision, the more you save.
- It compounds as a habit. The second time you review a cluster, you check the observability interval before anyone asks.
Closing
The most valuable thing I did in this assessment wasn’t finding the two changes. It was being able to say, with evidence, why those two mattered more than the other several hundred lines, what each would save, what could break, and how to roll it back. That’s an engineering skill. It sits right next to observability, IaC and incident response, and on a big account it pays for itself faster than most of them.
Next time you enable a managed add-on, spend thirty seconds on its pricing page. It’s the cheapest optimisation you’ll ever do.
Written by: Matheus Sabaudo, AWS Data & Cloud Engineer
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article