Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Bills Now Meter Kubernetes Control Plane Requests
Transcript
- Lucas: So there's a billing shift that's been rolling out across the big three cloud providers over the past year, and it's catching a lot of teams off guard. I'm talking about metering for Kubernetes control plane API requests. Luna: Wait, they're charging per API call now? I thought that was bundled into the cluster management fee. Lucas: That was the old model, yeah. But as of this quarter — August 2026 — AWS, Azure, and Google Cloud have all introduced line items for control plane requests beyond a free tier. Think of it like the DNS query charges we covered back in episode one fifty-one, but for the kube-apiserver. Luna: So a simple 'kubectl get pods' could cost money? That sounds like it adds up fast. Lucas: It can, but the real driver isn't humans typing commands. It's automated systems — controllers, operators, CI/CD pipelines — hammering the API server thousands of times per minute. I've seen a real example from a mid-size fintech team: their monthly cloud bill jumped about forty percent after they tweaked a deployment script that accidentally triggered a full resync of every namespace every five minutes. Luna: Ouch. So what exactly gets metered? Just the requests, or also the data? Lucas: Both, actually. The providers meter each API request by type — reads like list and get, writes like create and update — and they also charge for the etcd storage reads and writes that back those requests. The pricing varies, but a typical rate might be one or two cents per ten thousand read requests, and a bit more for writes. But the kicker is that watch streams, which keep clients in sync, are billed per event delivered, and those can balloon quickly. Luna: So a controller that watches a custom resource and gets an event for every change — that's a lot of individual charges. Lucas: Exactly. And Kubernetes is designed around that pattern. Almost every controller uses watch to maintain state. So the more dynamic your cluster, the more events, the higher the bill. Luna: Is there a practical way to cut down on those watch events, or are you just stuck with them? Lucas: There are real levers. The first one is to use informers instead of raw watch requests. Informers batch and cache results, so you get fewer API calls overall. Another is to avoid frequent list operations — if you're doing a full list every minute, you're doubling your read costs. A lot of teams are moving to a pull-based model where they query only the resources they need, not everything. Luna: And what about the control plane itself? Is the cost the same for managed services like EKS or GKE? Lucas: The structure is similar, but the free tiers differ. AWS gives you a hundred thousand requests per month free, then charges per request after that. Google Cloud has a similar tier, but they also meter the etcd storage separately. Azure's a bit different — they bundle it into the cluster's management cost, but they're planning to move to per-request metering later this year. Luna: So this is very much a work in progress across the industry. Lucas: Right. And the pricing models are still stabilizing. But the direction is clear: compute and storage are becoming commodities; the API surface is the new premium. Luna: Before we dive deeper into optimization, Lucas, I want to pause for a second. A handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and honestly, that's what funds making this many episodes without ads. Lucas: Yeah, it's true. We keep the show independent and ad-free, and that's only because of that small group. So if you're getting value from these deep dives, that's the simplest way to keep them coming. Luna: No pressure, just if it's useful. Now, back to saving money on those API calls — what's the biggest mistake you see teams making? Lucas: The biggest one is not setting resource requests and limits properly. When a pod has no limits, the kubelet might restart it frequently, triggering reconciliation loops that spam the API server. I've seen clusters where a single misconfigured deployment generated more than a million API requests in a day. Luna: A million requests – what would that cost on the new pricing? Lucas: Let's say half are reads, half writes. At roughly two cents per ten thousand reads and five cents per ten thousand writes, that's about four dollars for reads and twenty-five dollars for writes — just for that one misconfigured app. Over a month, that's easily eighty dollars, which is more than a small cluster's base control plane fee. Luna: And that's just one app. Multiply that by dozens of services and you've got a real line item. Lucas: Exactly. And it's not just about the base API calls. The etcd storage costs can sneak up too. Every object you store in etcd – like config maps, secrets, custom resources – has a storage cost that's metered separately. So cleaning up unused resources and setting TTLs on custom resources can make a dent. Luna: I've also heard that a lot of CI/CD tools can create a burst of API calls when they start up. Is that true? Lucas: Absolutely. Every time a pipeline runs, it might do a discovery request, a list of deployments, then create a job. That's maybe fifty requests per run. If you run a hundred builds a day, that's five thousand requests – not huge, but it adds up. The fix is to use service accounts with limited scope and avoid doing full cluster-wide lists in your scripts. Luna: So the metering is pushing teams to be more intentional about how they interact with the API. Lucas: It's forcing a shift from 'just make it work' to 'make it efficient.' And that's actually a good thing for the industry, even if it stings on the invoice. Luna: What about the control plane components themselves? Are they also being metered, like the scheduler or the controller manager? Lucas: Not directly, but they generate API calls, and those are metered. So if you have a custom scheduler, it's making API calls on your behalf, and you pay for them. That means you should minimize how often your scheduler polls the API server – use caching and event-driven triggers instead of polling every few seconds. Luna: Got it. So the real takeaway is that every API interaction has a cost, and the best way to reduce it is to reduce the number of interactions. Lucas: Exactly. And there are a few more tips: use server-side apply instead of client-side to reduce round trips, batch your updates, and consider using the Kubernetes API aggregator to consolidate multiple small requests into one. Luna: One thing that surprised me in my research is that some providers are offering a discount if you commit to a certain number of API requests per month. Have you seen that? Lucas: Yes, Azure has started offering committed use discounts on API calls if you sign a one-year contract. It's like the reserved instance model, but for API operations. If your workloads are steady, that can cut costs by up to thirty percent. Luna: So it's not all bad news. There are ways to adapt. Lucas: Definitely. The key is to monitor your API usage. All three clouds now give you metrics in their cost management tools. You can see which namespaces or service accounts are generating the most requests. That's the first step – you can't optimize what you can't see. Luna: And for teams that are just starting to use Kubernetes, is there anything they should know from day one? Lucas: Set up a budget alert from day one. And design your controllers to use informers and avoid polling. It's easier to build it right from the start than to retroactively fix it. Luna: So, Lucas, a month from now, what's the one thing you'd want every listener to remember from this episode? Lucas: That the Kubernetes API is not a free resource anymore. The control plane is now a metered service, and the teams that treat it like a scarce resource will be the ones who keep their cloud bills under control. Luna: That's a great closing thought. Thanks for listening, everyone.