EKS cost audit: 12 things worth checking before your Kubernetes bill gets out of control
C Amazon EKS there is often a very prosaic story. The cluster has been raised, services are spinning, releases are coming, everything seems to be normal. And then the bill arrives, and it turns out that infrastructure is becoming more expensive much faster than you expected. It's usually not one big mistake. This is a set of small distortions that no one touched for a long time.
It is important here that this is not just an editorial retelling of the topic FinOps. AWS already has a fairly comprehensive set of materials on the topic. Yes Best Practices on cost optimization for EKS. There is a separate Cost Optimization Framework. And there is practical analysis of data-driven EKS cost optimization, where the idea is very simple: don’t start with scissors, start with understanding the load.
This is the main thing that has changed. Teams no longer have the excuse of “we don’t understand where to start with a cost audit in EKS.” AWS has already shown quite directly where money is most often lost.
Where to even start EKS cost audit
The most common mistake is to immediately open an account and look for something to immediately turn it off. AWS in its practical guide suggests going in a different order: first understand the behavior of workloads, then analyze the price.
This is an important development. The team doesn't know yet:
- which services are really loaded;
- which ones just take up space;
- where there is a reserve of CPU and memory;
- which environments are hardly used;
- which can be translated to another type of calculation,
any cost cutting turns into a guessing game.
12 things to check first
Below is not a magic formula or a promise of “minus 40% per evening.” This is simply a workable checklist that can be conveniently used as a basis for internal cost auditing EKS.
1. Are requests and limits similar to actual consumption?
This is the first thing to check almost always. If requests are set “with reserve”, scheduler reserves more resources than the service actually needs. As a result, the clusters swell, but this does not add performance.
2. Are there services that live on nodes almost idle?
When there are a lot of microservices in a cluster, it’s easy not to notice that some of them do almost nothing, but stably keep the CPU and memory to themselves. These things rarely look dramatic on their own. But in total they easily turn into a noticeable expense line.
3. Is autoscaling configured correctly?
The very fact that you have autoscaling enabled does not guarantee anything. It may scale too early, too late, or too roughly. B AWS Prescriptive Guidance on cost optimization for EKS this is separately emphasized: the scaling policy should take into account the behavior of workloads, and not just exist “for show”.
4. Where is your production, and where is your expensive test zoo?
Very often, money flows not from production, but from review environments, old stands, temporary namespaces and forgotten internal services. They seem to be needed “sometimes,” but they always live on the bill.
5. Do all workloads really need On-Demand instances?
B AWS EKS best practices they directly recommend looking at what workloads can be transferred to Spot. But here it is important not to overdo it: if the service is critical to interruptions, cheaper does not always mean better.
6. Do you live on one type of node just out of habit?
For many teams, the mix of instances develops historically. What they once lifted is what they sit on. Then it turns out that some tasks would work better on a different family, a different architecture, or even a different class of computing.
7. Does it make sense? Karpenter, or do you just have it “installed”?
Karpenter can greatly help with the effective selection of nodes, but by itself it does not cure costs. If workloads are described roughly, requests are incorrect, and the capacity selection policy is not thought out, there will be no savings, just scaling will become more automatic.
8. Are you overpaying for storage?
When they talk about Kubernetes cost, everyone usually looks at compute. But EBS volumes, snapshots and careless storage also quietly eat up money. If a volume has not been needed for a long time, but is still alive, it continues to cost the same as a useful one.
9. What's going on with your network cost?
Cross-AZ traffic, data transfer and a noisy service network can easily take a toll on your score. This is especially noticeable in SaaS products with a large number of internal calls between services.
10. Is the cost visible at least at the namespace or service level?
For now all EKS looks like one big sum, the team argues at the level of sensations. As soon as a breakdown by namespace, service, tenant or environment appears, the conversation becomes substantive.
11. Do you understand the unit economics of your platform?
It is useful to calculate not only “how much a cluster costs”, but also how much it costs:
- one active client;
- one thousand operations;
- one tenant;
- one product module.
Then you can see not just “the infrastructure is expensive,” but where exactly it begins to eat up the margin.
12. Do you have a regular audit cycle rather than a one-time event?
This is often the most important thing. If a cost audit is done once after the shock of an invoice, the result does not last long. After a couple of months, the cluster grows again, temporary solutions become permanent, and everything returns to normal.
What AWS Recommends You Do After the Initial Audit
If you put all three core AWS materials together, the logic is pretty mundane.
First:
- parse workloads;
- measure real consumption;
- find idle and oversized parts;
- separate critical and non-critical services.
Then:
- adjust requests and limits;
- improve autoscaling;
- choose a more suitable mix capacity;
- transfer part of the load to where it lives cheaper and safely;
- review storage and network patterns.
And only after that does it make sense to take more aggressive steps.
Where teams most often go wrong
This theme has some very typical failures.
The first is to try to “save on Kubernetes” without understanding how the product itself lives.
The second is to treat the cost only through the compute and not look at storage, network and test environments.
The third is to think that Spot, Karpenter or Fargate by themselves already mean mature cost optimization.
Fourth, do not link technical costs to product economics. As long as the platform lives separately from unit economics, decisions will be either too cautious or too drastic.
For whom is this article especially useful?
First of all, for those who already have:
- SaaS on
AWS; - several production and non-production environments;
- Kubernetes is not an experiment, but an everyday platform;
- a growing bill that is already beginning to interfere with the economics of the product.
At the search level, the article closes normal queries: EKS cost audit, как снизить расходы EKS, Kubernetes cost optimization, FinOps для SaaS, как проверить лишние расходы AWS.
If the team has a broader task and we are talking not only about one cluster, but about system automation of the platform, analytics and infrastructure processes, this already fits in with integration of AI into business processes.
Useful on the topic
- Google AI Mode and query fan-out: why one strong page is no longer enough for SEO
- How to get into ChatGPT answers: GEO and AI SEO
- Case on the topic
- Profile service
FAQ
Where to start EKS cost audit if time is short?
From real resource consumption, requests/limits and the list of idle workloads. This almost always produces the first finds the fastest.
Is Spot a required step?
No. This is a good tool, but not a universal solution. For some services it is suitable, for others it is not.
What is the main mistake?
Cutting costs blindly, without understanding which services are really important and how they use the cluster.
When should a cost audit be considered successful?
When the score decreases without degradation of reliability and the team understands why the savings were achieved, and is not just happy about the random drop in the amount.