Nobody wants to manage Kubernetes nodes. The patching, the capacity planning, the 2 AM alert because an autoscaler did not scale. Every cloud provider knows this, which is why AWS, Google Cloud, and Azure all sell some version of “serverless Kubernetes” where you submit pods and they figure out the rest.
But “serverless Kubernetes” means something different on each provider. EKS Fargate runs every pod in its own microVM. GKE Autopilot manages nodes you never see. AKS Virtual Nodes offload pods to Azure Container Instances. The tradeoffs, the restrictions, and the pricing are different for each one.
This post breaks down what each provider actually gives you, what they take away, and how to decide whether serverless Kubernetes fits your workloads.
What serverless Kubernetes actually means
Regular managed Kubernetes (EKS, GKE Standard, AKS) gives you a managed control plane but you still manage the worker nodes. You pick the instance types, configure autoscaling, patch the operating system, and monitor node health.
Serverless Kubernetes removes the worker node layer. You submit pods and the provider runs them on infrastructure you never see. No node pools to configure. No OS to patch. No capacity to plan.
The three major implementations:
| Provider | Product | How it works | Pricing model |
|---|---|---|---|
| AWS | EKS Fargate | Each pod runs in its own isolated microVM. No shared nodes. | Per-pod: $0.04456/vCPU/hour + $0.004865/GB/hour |
| Google Cloud | GKE Autopilot | Google manages nodes, scaling, security patches, and resource optimization. You define pods. | Per-pod resource requests (vCPU, memory, ephemeral storage) |
| Azure | AKS Virtual Nodes | Pods run on Azure Container Instances (ACI). No node VMs provisioned. | Per-pod: based on vCPU and memory consumed per second |
GKE Autopilot is the most opinionated. You never see or interact with nodes at all. EKS Fargate isolates each pod in its own microVM, which is the strictest isolation model but also the most restrictive. AKS Virtual Nodes is the most flexible, since you can mix virtual nodes with regular node pools in the same cluster.
What you give up
Every serverless Kubernetes option removes node management. But they also remove things you might not expect to lose. The restrictions vary by provider:
| Limitation | EKS Fargate | GKE Autopilot | AKS Virtual Nodes |
|---|---|---|---|
| DaemonSets | Not supported | Limited (system DaemonSets only) | Not supported on virtual nodes |
| Privileged containers | Not supported | Not supported | Not supported |
| HostNetwork / HostPort | Not supported | Not supported | Not supported |
| GPU workloads | Not supported | Supported (with Autopilot GPU pods) | Not supported on virtual nodes |
| Persistent volumes (EBS/PD) | EFS only, no EBS | Supported | Azure Files only, no Azure Disk |
| Pod resource ceiling | 4 vCPU, 30 GB memory | 28 vCPU, 256 GB memory (with compute class) | Varies by ACI region |
| Pod startup time | 30-60 seconds (microVM boot) | Similar to standard GKE | 15-30 seconds |
| eBPF-based tools | Not supported | Not supported | Not supported |
| Node Exporter metrics | Not available | Not available | Not available |
That last row is the one that matters most if you run an observability stack. Node Exporter is how Prometheus collects CPU, memory, disk, and network metrics at the node level. On serverless Kubernetes, those metrics do not exist because you do not have nodes.
The observability gap
On standard Kubernetes, a typical monitoring setup looks like this:
- Prometheus scrapes Node Exporter for node-level metrics (CPU, memory, disk I/O, network)
- Prometheus scrapes kube-state-metrics for pod and deployment metadata
- A logging agent (Fluentd, Fluent Bit, Promtail) runs as a DaemonSet to collect logs from every node
- A tracing agent (OpenTelemetry Collector) runs as a DaemonSet to collect traces
On serverless Kubernetes, two of those four stop working out of the box. Node Exporter metrics are gone. DaemonSets either do not run or are restricted.
What you lose and how to compensate:
Node-level metrics are gone. You cannot see CPU, memory, or disk utilization per node because there are no visible nodes. The replacement: use the Kubernetes API and cAdvisor metrics to get per-pod resource usage. On GKE Autopilot, Google exposes pod-level metrics through their managed Prometheus. On EKS Fargate, you need to scrape metrics from sidecar containers or use CloudWatch Container Insights.
DaemonSet-based log collection breaks. Fluentd, Fluent Bit, and Promtail typically run as DaemonSets. On Fargate and AKS Virtual Nodes, they cannot. The replacement:
- Run logging agents as sidecar containers alongside your application pods
- Use the provider’s native log routing (CloudWatch Logs on Fargate, Cloud Logging on GKE, Azure Monitor on AKS)
- Forward native logs to your self-hosted Loki or ELK stack
DaemonSet-based tracing breaks too. Same problem. The OpenTelemetry Collector typically runs as a DaemonSet. The replacement: run OTel Collector as a sidecar per pod, or deploy it as a standalone Deployment that pods send traces to over the network.
eBPF-based observability tools do not work. Tools like Cilium Hubble, Pixie, and Coroot that rely on eBPF for kernel-level visibility cannot run on serverless Kubernetes. You lose network-level observability and automatic service map generation. There is no clean workaround for this one. If you need eBPF, you need real nodes.
When serverless Kubernetes makes sense
Serverless Kubernetes is a good fit for a specific set of workloads. Not all workloads.
Good candidates:
- Stateless web services with variable traffic. The provider handles scaling. You pay only for what runs. If traffic drops to zero, cost drops to near zero.
- Batch jobs and cron jobs. Short-lived compute that spins up, processes data, and terminates. No idle nodes between runs.
- Dev and staging environments. Lower traffic, no need for fine-tuned node configuration, cost savings from not running idle nodes.
- Teams with no platform engineering capacity. If nobody has time to patch nodes, tune autoscalers, or manage node pools, removing that responsibility is a real benefit.
Bad candidates:
- Workloads that need GPU. Fargate and AKS Virtual Nodes do not support GPUs. GKE Autopilot added GPU pod support, but at a premium.
- Workloads that need eBPF or kernel access. Security tools, network observability tools, and performance profilers that need kernel-level access will not run on serverless Kubernetes.
- High-throughput, steady-state services. If your workload runs 24/7 at consistent load, reserved instances on regular nodes will almost always be cheaper than per-pod serverless pricing.
- Workloads with large persistent storage needs. EBS and Azure Disk are not available. You are limited to EFS or Azure Files, which have different performance characteristics (higher latency, lower IOPS).
The cost question
Serverless Kubernetes pricing is per-pod (CPU + memory + time). Standard Kubernetes pricing is per-node (instance cost regardless of utilization).
Which one is cheaper depends entirely on your utilization:
| Scenario | Cheaper option | Why |
|---|---|---|
| Average utilization below 40% | Serverless | You are paying for idle capacity on standard nodes |
| Average utilization above 60% | Standard nodes | Per-pod pricing exceeds per-node pricing at high utilization |
| Highly variable traffic (spiky) | Serverless | Scales to zero between spikes, no idle nodes |
| Steady traffic, predictable load | Standard nodes with reserved instances | Reserved pricing beats per-pod pricing when utilization is consistent |
| Small clusters (under 20 pods) | Serverless | The per-node overhead of standard K8s is proportionally high |
| Large clusters (200+ pods) | Standard nodes | Per-pod pricing adds up fast; node-level economies of scale kick in |
A rough comparison from Oracle’s 2026 analysis: at 200 nodes, EKS costs about $46,200/month, GKE Autopilot about $51,700/month, and AKS about $43,000/month. But if utilization drops below 60%, Autopilot’s pod-based billing often undercuts the per-node model (Oracle: Serverless Kubernetes Costs for EKS, AKS, GKE, and OKE).
The real cost to factor in goes beyond compute. It includes the engineering time you spend (or do not spend) managing nodes. If your team spends 10-15 hours per month on node patching, autoscaler tuning, and capacity planning, serverless Kubernetes buys that time back.
The hybrid approach most teams end up with
In practice, most teams that try serverless Kubernetes end up running a hybrid setup: some workloads on serverless, some on managed node groups.
A common pattern on EKS:
- System components (monitoring agents, ArgoCD, ingress controllers) run on a small EC2 managed node group, because they need DaemonSets or persistent storage
- Application workloads that are stateless and variable run on Fargate
- GPU workloads run on dedicated EC2 GPU node groups
This gives you the best of both: application teams get the simplicity of “deploy a pod and forget about nodes,” while the platform team keeps the system-level components on infrastructure they can monitor properly.
The observability stack (Prometheus, Grafana, Loki, Tempo) typically lives on the managed node group. From there, it scrapes pod metrics across both the node group and Fargate pods using the Kubernetes API. You lose node-level depth on the Fargate side, but you keep full pod-level visibility.
How to decide
Three questions that determine whether serverless Kubernetes is right for your team:
1. Do you need eBPF, DaemonSets, or privileged containers? If yes, standard nodes. No exceptions. Serverless Kubernetes does not support any of these.
2. Is your traffic variable or steady? Variable traffic with periods of low or zero usage = serverless wins on cost. Steady high traffic = standard nodes with reserved instances win.
3. Do you have a platform team that can manage nodes? If yes, standard nodes give you more control and better observability. If no, serverless removes a class of operational work that nobody has time for, and the observability gaps are an acceptable tradeoff.
Most teams land on the hybrid approach. Serverless for application pods, managed nodes for system components and monitoring. That gets you the operational simplicity without completely losing visibility.
Where Obsium fits
If your team is running serverless Kubernetes and struggling with monitoring blind spots, book a free 30-minute observability consultation. No sales deck, just an engineer-to-engineer chat about your stack.
