Naviteq Ltd

30/08/2026

Final days to register for Beyond the Invoice: The Hidden Side of Cloud Costs

Register here: https://us02web.zoom.us/webinar/register/2817852522529/WN_NctIL_UMRz23lyMSMPo3xA #/registration

Cloud costs are rarely about one obvious line item.They are often the result of many smaller infrastructure decisions that build over time.

On 2 September, Motti Shpirer, Danna Oudy and Elad Welner will unpack these decisions in a live webinar for teams that want to understand cloud spend with more clarity.

The session will cover:

◆ The cost layers that are easiest to overlook
◆ The role of data movement, egress and regions
◆ Customer-side lessons from real cloud environments
◆ Practical ways to approach optimization beyond rightsizing

📅 2 September
🕚 11am Israel
📍 Virtual webinar

Join the session before registrations close.

28/08/2026

Your oldest EKS cluster has an expiry date on it. On 20 August - AWS told you when. ⚡

Every EKS cluster created since the 2018 launch got a certificate authority with a ten-year validity period. Clusters from that era are close enough to the end that AWS shipped managed CA rotation to get ahead of it.

The shared responsibility split is where this gets expensive. AWS updates the control plane, Auto Mode and Fargate to trust the successor CA. You update everything else: managed node groups, Karpenter nodes, self-managed nodes, and every external client holding a CA bundle. Kubeconfigs, CI runners, GitOps controllers, the monitoring agent nobody has touched since it was installed.

AWS added safeguards because it expects teams to miss the window. It appends a successor CA if you do not create one, and activates on its own schedule if you do not activate on yours. Both are AWS acting because you did not, and the automatic activation is the one that turns a maintenance task into an incident.

Any competent team can rotate a certificate authority. Far fewer can produce a list of everything that currently trusts the cluster. On a five-year-old estate that list lives in three people's heads, and one of them has left.

Mapping it is unglamorous work we do a lot of, most recently for a security startup pulling two AWS accounts into an Organization with SSO and RBAC.

If your oldest cluster is older than your current platform team, do that inventory before AWS starts the clock for you.

Need help? We are here!
How to contact? → https://www.naviteq.io/contacts/

27/08/2026

Register now for next week's webinar Beyond the Invoice: The Hidden Side of Cloud Costs:

https://us02web.zoom.us/webinar/register/2817852522529/WN_NctIL_UMRz23lyMSMPo3xA #/registration

Motti Shpirer, Danna Oudy and Elad Welner will look beyond basic rightsizing and discuss the cloud cost drivers that providers do not always put front and center.

The session will cover:
◆ Why data movement becomes a hidden cost layer
◆ How location and regional pricing shape cloud economics
◆ What optimization looks like from a customer perspective
◆ How teams can make more strategic infrastructure decisions

📅 2 September
🕚 11am Israel
📍 Virtual webinar

Join us live and get a clearer view of what is really driving cloud spend.

25/08/2026

Amazon Web Services (AWS) EKS has always run the control plane as a black box. On 12 August it opened four parameters on it, and the first one has a bill attached.

Every cluster ever created schedules pods with LeastAllocated. When the scheduler ranks the nodes a pod could run on, it prefers the emptiest one. Pods spread out, every node keeps headroom, and you pay for that headroom on every node in the fleet.

Nobody chose this. It is the upstream default, and until last week a managed control plane gave you no way to change it short of running a second scheduler next to the one AWS runs for you.

MostAllocated inverts the ranking. The fullest node that still fits wins, so the same workloads occupy fewer nodes and the lightly used ones stop attracting new pods, which is what lets Karpenter or Auto Mode consolidate them away.

One API call:

`aws eks update-cluster-config --name "$CLUSTER" --kube-scheduler-config '{"nodeResourcesFit":{"scoringStrategy":{"type":"MostAllocated"}}}'`

Whether it belongs on your cluster comes down to four things:

→ Packing concentrates blast radius. More pods go down with one node, one AZ, one spot reclaim.
→ Running pods are never moved. Nothing changes until pods reschedule on their own.
→ Under heavy churn, dense nodes fill faster and pods sit Pending while new capacity comes up.
→ Scoring provisions nothing. The saving only lands if your node layer consolidates.

Worth knowing before you type it: AWS ships no reset operation, so returning to the default means setting LeastAllocated explicitly, and Terraform support is still listed as coming soon.

All four parameters, the payloads, the GPU and Neuron weights, and the trade-offs that are hard to undo:
https://www.naviteq.io/blog/eks-opened-up-the-scheduler-mostallocated-is-the-one-with-a-bill-attached/

Amazon EKS now lets you set four control plane parameters directly, including the scheduler scoring strategy. Switching from LeastAllocated to MostAllocated packs pods onto fewer nodes and cuts compute spend. The payloads, the resource weights, and the trade-offs that are hard to undo.

24/08/2026

On 10 August, the Amazon Web Services (AWS) EC2 learned to check whether your application is actually answering. ⚡

Your own protocol, port, path and healthy response codes. Attached by instance ID or by tag. Reported every 60 seconds. If the check fails, an Auto Scaling group replaces the instance.
Useful, and overdue for anyone still running EC2 without a load balancer in front of it.

It is also the shallowest layer of a reliability practice.
The check tells you a process stopped answering about a minute ago. It cannot tell you that checkout got slower for one tenant, that a dependency is timing out at p99 (btw, do you know what is it?) while the health endpoint keeps returning 200, or why the replacement instance will fail the same way in an hour.

Teams reach us after a rough quarter of incidents, and it is rarely bad code. Nobody could see what happened, so the postmortem gets written from guesses and the same incident comes back.

Closing that gap means you can follow one request across metrics, logs and traces. It means alerts fire on what users feel instead of on CPU, and SLOs settle in advance what is worth waking someone for. We build that stack with the handover and the docs, because a setup nobody can operate is a second outage waiting.

Turn the new check on. Just do not file it under observability.
If 3am pages are becoming routine, that is usually a visibility problem rather than a code problem.
Happy to look at what your stack can actually tell you -> https://www.naviteq.io/contacts/

23/08/2026

Wasted cloud spend went up this year. It had been falling for five... What's next?! 💰

Flexera's "2026 State of the Cloud" puts the estimate at 29% of IaaS and PaaS spend, and names the reason: cost complexity from AI and newer services.
Part of that has a very simple shape. An accelerator is billed whole and used in fractions. A model that needs 3 GB of GPU memory still gets a card with 24, and the spare 21 bill at the same rate as the three doing the work.

For instance, the Amazon Web Services (AWS) made that visible 5 days ago. ECS now schedules fractional GPUs on G6f instances, down to an eighth of a card. On hashtag there is no equivalent switch yet. You assemble it yourself out of time-slicing, MIG or DRA, which isolate very different things.

Before any of that, there is a cheaper question: which team spent it?
Most cloud bills we see are visible in total and invisible per workload, so nothing gets cut, because nothing has an owner.

So the boring half comes first. Tag (!!) and allocate (!). Put the guardrails in code, so a budget fails a pull request instead of surfacing in a quarterly review. Then right-size against real usage.

We have run with one of our client that order on CI fleets peaking at 1200 vCPUs and on EKS clusters scaled with Karpenter and KEDA, and it survives a change of device.

If your AI bill is growing faster than the traffic behind it, that is usually a fixable pattern. Happy to compare notes on yours → https://www.naviteq.io/contacts/

21/08/2026

Moving to a new cloud is a risk — unless you're not the one carrying it.
That's what actually stops teams from looking at Oracle Cloud.
Not the pricing. The fear. New console, new IAM model, new networking, new failure modes.
Nobody on the team has run it before, and production isn't where you want to learn.

So don't learn it. We already have.
– OCI isn't a first attempt for us. We run it daily.
– Migrations follow a path we've walked before, not a plan improvised on your production
– Your subscription is handled end to end, billing included
– After go-live the platform stays owned, not handed back with a wiki link

Same Oracle Cloud. The difference is you're not figuring it out alone.

We're an Oracle Cloud partner and reseller. We don't just sell you the cloud — we run it.

Thinking about OCI but unsure who'd operate it? Let's talk.

20/08/2026

Two weeks until our webinar Beyond the Invoice: The Hidden Side of Cloud Costs
Register here: https://tinyurl.com/4s9dmxnw

Speakers:
Motti Shpirer, VP Infrastructure & Technology at Start.io
Danna Oudy, Sales Leader, OCI Cloud Native at Oracle
Elad Welner, Chief Executive Officer at Naviteq

Motti, Danna and Elad will look beyond basic rightsizing and unpack the cloud cost layers that providers do not always put front and center.

The webinar will cover:
◆ Why data movement can become a hidden cost layer
◆ How location and regional pricing affect cloud economics
◆ What cloud optimization looks like from a customer perspective
◆ How to make more strategic infrastructure decisions at scale

Date: 2 September 2026
🕚 11am Israel
📍 Virtual webinar

19/08/2026

One of our client has the CI that could burn 1200 vCPUs at peak. We were asked to cut what that cost, without slowing down a build that already took close to 46 hours.
The client builds Chromium-based browsers for , Linux and Android. Ten to twenty times a day they spin up more than a hundred machines for roughly twenty minutes each. That shape punishes every default you can pick.

Part of the answer was commercial. The underlying infrastructure moved to Microsoft Azure, where partnership discounts applied, and that is the lever most teams reach for first. On its own it would have left the real problem untouched: a fleet sized for the peak is also paid for at the trough. Idle was the default state, and no discount fixes a default.

What we changed:
→ Self-hosted GitHub Actions runners onto AKS, scaling out to dozens of concurrent executions and back down to nothing
→ Windows builds containerized to run inside the cluster, which is where most teams give up
→ Spot instances underneath, because a build that can be retried is a build that can be interrupted
→ and for all of it, so the cluster is reproducible rather than hand-tuned

The cost curve started following the build queue instead of the calendar.

The same shape is now showing up one device down. A GPU is billed whole and used in fractions, and Kubernetes offers four ways to divide one: time-slicing, MPS, MIG and DRA. They separate on isolation rather than on speed. Time-slicing shares GPU memory, so one pod can starve its neighbours. MIG partitions in hardware but disables NCCL and needs a node reboot to repartition.

All four, with the working config and the trade-off that picks between them: https://www.naviteq.io/blog/sharing-a-gpu-on-eks-time-slicing-mps-mig-and-dra/

18/08/2026

Your EKS bill went up 6x last Wednesday. Nobody sent an email. 💰

On 29 July, Kubernetes 1.33 left standard support on EKS. Every cluster still running it moved onto extended support automatically, without anyone opting in or approving anything (or you missed this email).

The control plane fee goes from $0.10 to $0.60 per cluster-hour. That is roughly $4,380 per cluster per year, and it holds for the next twelve months. Run ten clusters and you are paying about $43,800 a year to postpone an upgrade.

The invoice lands weeks after the change, which is why most teams reading this have not noticed yet.

Clusters rarely get stuck because the upgrade is hard. They get stuck because a control plane upgrade used to be a one-way door, and nobody wanted to own that call on a Tuesday night. So the cluster sits where it is until a billing date moves without asking.

AWS closed that particular door in July. EKS can now roll a control plane back to the previous minor version within seven days of an upgrade, which changes the risk calculation on the next one.

Cluster version lifecycle is part of the platform work we do for teams running EKS at scale. It belongs in a maintenance window, not on an invoice.

If you are not certain which of your clusters are sitting on 1.33 right now, that is the thing to check today. Happy to compare notes on what the upgrade path looks like from where you are → https://www.naviteq.io/contacts/

hashtag hashtag hashtag hashtag hashtag