Techieonix

12/10/2026

One customer deployed 80 to 90 servers in one go.

(Here is the limit Utho added.)

Manoj Dhanda, Founder and CTO of Utho (a cloud provider), described one customer who went from a few servers to 80 to 90 at once. Many customers create servers with scripts, REST APIs and Terraform. External example, not a Techieonix client.

Utho did two things. It set a default limit of 30 instances per new account (customers can ask for more). And it spread new servers across different clusters, so one cluster does not take everything.

If your scripts or autoscaler can create servers on their own, check three things:
• A maximum number of servers per account
• New servers spread across clusters or zones
• An alert before you reach the maximum

A maximum also caps what a sudden jump can cost you.

How many servers can your automation create in one go today?

09/10/2026

Which feature drove your AWS bill up?

(Cost Explorer stops at the service.)

Your invoice says EC2, RDS, S3. It does not say which feature, tenant, or job sits behind each line.

Group by service, then usage type, then daily view. Match the day it moved to a release or a job. Name the one workload before you cut anything.

Most teams can do this themselves. If untagged or shared costs block you, that is where we help.

Want the workload breakdown steps? Message us.

09/10/2026

Finance wants an owner on every AWS line.

Your resources have no tags.

You can still allocate the bill. Cost Explorer groups spend by service, account, region and usage type. So start by giving every account an owner, then add Cost Categories rules, which do not need tags.

If you are a CTO or platform lead and finance keeps asking who owns what, the full post on how to allocate AWS costs without tags covers these cases:

• A "No tag key" bucket that keeps growing because no one reviews it
• Several teams sharing one account, where the account ID alone tells you nothing
• NAT Gateway and data transfer charges with no single team responsible for them
• ECS or EKS clusters where one instance serves many workloads
• Resources with tags that were never activated for cost allocation, where AWS can backfill up to 12 months of data

For a GCC e-commerce business, a cross-account inventory and cost ownership by business unit were part of an effort that saved about $6,000 a month in 90 days. Most teams can start with Cost Explorer and an account-to-owner table.

Which is the bigger issue on your bill right now: spend with no owner, or spend assigned to the wrong one? Tag the person who gets that question from finance.

07/10/2026

Your AWS bill went up again. Can you say which workload did it?

Dentulu's CTO, Shiva Kumar, says their AWS costs dropped from $30,000 to roughly $3,000 a month after an infrastructure and architecture review.

Most teams only see the total. Database load, traffic, caching, and background jobs rarely need to scale together, but most bills treat them as one number. Swipe for how to break it down by workload.

Want a workload-level review of your own AWS spend? DM or message us.

05/10/2026

HOT TAKE: "Perfect" cloud architecture is still burning $30,000/mo in silent waste.

Usually, the problem is not your system design. It’s that you do not track what each layer actually costs.

Even if your setup looks good, money leaks out quietly:

→ Your database is bigger than you actually need

→ Your cache runs 24/7 when it should scale down

→ Your serverless parts build up hidden idle costs

Dentulu’s CTO, Shivakumar, shared this exact story on "The CTO Story Podcast".

They didn't rewrite any code. They just tracked AWS costs layer by layer.

Their monthly bill went from $30,000 down to $3,000-$5,000.

No magic, just checking where the money was going.

Do you know which layer is taking up most of your AWS bill right now?

25/09/2026

Your Kubernetes bill can show you the total. It can't show you which model is spending it.

Namespace level allocation is where most platform teams stop. It works for chargeback between teams. It stays silent on which model, tenant, or feature actually drove the spend.

Model level attribution has to account for four things separately: GPU memory reserved for weights (billed whether the model is serving or not), active compute during inference, the shared gateway, and KV cache storage. Skip any one of those and you're optimizing a workload you can't actually attribute.

Where does your cost allocation stop today: cluster, namespace, or model? Message us for a copy of the framework.

25/09/2026

Finance asks which AI feature is driving the GPU bill. You open the dashboard and find one namespace total covering three models and four features. There's no answer in that number.

Namespace-level cost works fine for chargeback between teams. It tells you nothing about which model, feature, or customer is actually responsible for the spend sitting inside it. Real cost tracking means separating four things: GPU memory held by model weights, active inference compute, the shared gateway, and KV cache storage. Skip one and your cost-per-token math looks clean next to a bill that doesn't match it.

OpenCost 1.121.0, built with llm-d, now tracks all four at the model level. Getting from model-level to feature-level and customer-level is where the actual product decisions start: does this feature's margin justify its inference cost, should a lower tier get a usage cap.

If your platform team can't name the highest-cost model in production right now and the feature it serves, that's the gap to close first, before touching capacity optimization.

Can you answer that question for your cluster today?

23/09/2026

Your most expensive model might be the one serving the fewest requests.

Reserved GPU memory bills whether or not a request arrives, so Kubernetes inference cost tracking at namespace level misses two cases at once: a model loaded all week and used for four hours, and one running flat out. Both look similar on the report.

There are four levels of allocation. Cluster total tells you what you spent. Namespace narrows it to a team, until two teams share a gateway. Model level needs four components attributed, three of which are shared. At feature level you get cost per successful inference, attributed to the feature that called it.

The pattern we see with multi-tenant inference is a single namespace serving every customer on a plan, producing a cost report that balances while pointing at the wrong team.

OpenCost's llm-d integration now tracks cost at model level, so you can compare two models in the same cluster and see which one your gateway spend is subsidising.

Set allocation rules before you optimise GPU capacity. Most platform teams can define those rules without outside help. We get called when the cluster is multi-tenant and the split has to hold up in front of finance.

Where does your allocation stop today: cluster, namespace, or model?

23/09/2026

Read full post here 👇

AI token cost allocation breaks at column three. Your billing export can show you a meter, a quantity, and a cost. It cannot tell you which product feature made the call, which team shipped that feature, or whether the spend was worth it. That gap is why AI spend forecasting fails. You are forecasti...

21/09/2026

Kubernetes inference cost tracking breaks on shared components.

Per-namespace allocation is where most platform teams stop. It is enough for chargeback and not enough for a product decision, because it cannot tell you which model, tenant, or feature is economically responsible for the spend.

Model level allocation has to account for four things: GPU memory reserved for weights whether or not the model is serving, active compute during inference, the shared gateway, and KV cache storage. OpenCost's integration with llm-d now tracks this at the model level in Kubernetes.

The reason this matters is not reporting. GPU cost per hour cannot tell you whether an AI feature is economical. Cost per successful inference, attributed to a feature, can.

Decide your allocation rules before you optimise capacity. Optimising a workload you cannot attribute is how teams cut GPU spend and lose a product line.

Can you name the highest cost model running in your production cluster right now?