Kubernetes Cloud: Cloud services for Kubernetes, practical mini guide

Amazon EKS, Google GKE, and Azure AKS remain the dominant managed Kubernetes platforms – but in 2026 they look very different from just a few years ago.

The three major managed Kubernetes services – Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS) – still account for the vast majority of production Kubernetes workloads worldwide. If you manage infrastructure for clients or run containerized applications at scale, chances are you are already using at least one of them.

All three handle the fundamentals: the cloud provider takes care of the control plane (etcd clustering, API server high availability, master node patching) so you can focus on deploying workloads. But the definition of “managed” has expanded significantly. Today, each provider also offers an opinionated, highly automated mode that manages the data plane (worker nodes) as well – reducing or even eliminating the need to configure, patch, and scale nodes manually. Understanding these differences is essential to making the right platform choice.

Let’s take a closer look at each service and what has changed.

Amazon Elastic Kubernetes Service (EKS)

Amazon EKS has been generally available since 2018 and has matured into a powerful, flexible platform deeply integrated with the AWS ecosystem. EKS lets you run Kubernetes applications in AWS cloud regions worldwide or on-premises through EKS Anywhere.

The most significant recent addition is EKS Auto Mode, AWS’s answer to fully managed Kubernetes. Auto Mode automates data-plane provisioning, patching, and scaling using Karpenter and Bottlerocket under the hood. Instead of managing traditional node groups, AWS provisions right-sized nodes on demand based on your pod requirements, handles bin-packing, and replaces nodes automatically. It strikes a balance between automation and the flexibility that AWS-native teams expect.

EKS also introduced Pod Identities, a streamlined mechanism for granting pods secure access to AWS services – replacing the older, more complex IRSA (IAM Roles for Service Accounts) setup in most scenarios.

One detail MSPs should be aware of: AWS offers Extended Support for older Kubernetes versions, but the rate jumps from $0.10 to $0.60 per hour per cluster (a 6x increase). For teams managing multiple clusters that may not upgrade promptly, this cost can add up fast. Staying on a supported version is not just a best practice – it is a cost control decision.

EKS remains ideal for organizations already invested in the AWS ecosystem and for platform teams that want granular control over infrastructure. The trade-off is a steeper operational surface compared to GKE Autopilot or AKS Automatic, particularly around VPC CNI networking and IAM configuration.

Google Kubernetes Engine (GKE)

Google Kubernetes Engine benefits from Google’s unique position as the creator of Kubernetes itself. GKE consistently tracks upstream Kubernetes releases faster than its competitors – typically within two weeks through its Rapid release channel – and remains one of the most advanced managed Kubernetes platforms available.

GKE’s key differentiator is Autopilot, a fully managed, “nodeless” operating mode. With Autopilot, you define your pods and Google handles everything else: node provisioning, bin-packing, OS patching, upgrades, and scaling. You pay for the CPU, memory, and ephemeral storage your pods actually request, not for idle node capacity. This model eliminates node-level overprovisioning and is particularly cost-effective for variable or bursty workloads.

Autopilot has matured considerably and now supports NVIDIA A100/H100 GPUs and Google TPUs, making it viable for AI/ML inference and training workloads as well. GKE also uses Dataplane V2, built on eBPF, which handles packet routing and network policy enforcement directly in the kernel – bypassing iptables entirely for better scalability at large cluster sizes.

GKE offers structured Release Channels (Rapid, Regular, Stable) with automated upgrades. Clusters enrolled in the Extended release channel can remain on an older Kubernetes minor version for up to approximately 30 months, but an additional cluster management fee of $0.50 per cluster per hour applies during the extended support period. This fee is waived for clusters running on GKE Enterprise edition, which includes extended support in its per-vCPU pricing.

The trade-off with Autopilot is reduced flexibility: it restricts privileged containers, certain DaemonSet configurations, and custom eBPF-based tools. If your stack requires kernel-level access or elevated Linux capabilities, GKE Standard (the traditional self-managed node mode) is the appropriate choice.

Azure Kubernetes Service (AKS)

Microsoft AKS has grown into a fully mature platform with a significant advantage for budget-conscious teams: the AKS base control plane is free. You pay only for the worker nodes and associated resources, which makes a meaningful difference for organizations running many clusters – a common scenario for MSPs.

The most notable recent development is AKS Automatic, which reached general availability in September 2025. AKS Automatic is Microsoft’s take on a fully managed Kubernetes experience: it applies opinionated default configurations for security, scaling, and networking out of the box, dramatically lowering the operational barrier. Like GKE Autopilot and EKS Auto Mode, it automates node management, but it preserves more Kubernetes-level flexibility than Autopilot’s stricter guardrails. AKS Automatic uses a dedicated SKU with a control plane fee of $0.16 per hour per cluster – higher than the $0.10/hour Standard tier, but competitive given the level of automation included.

AKS is organized into three tiers: Free (managed control plane, no SLA), Standard ($0.10/hour per cluster, 99.95% uptime SLA for zone-redundant clusters), and Premium (adds Long-Term Support with up to 24 months on select Kubernetes versions and advanced fleet management). The Premium tier’s LTS option is particularly relevant for enterprise environments and MSPs who need longer upgrade windows.

AKS integrates tightly with the Microsoft ecosystem through Workload Identity with Entra ID for secure, secretless pod authentication to Azure resources, Azure Policy for AKS for governance enforcement, and native integration with Azure DevOps and GitHub Actions for CI/CD pipelines.

AKS is the natural fit for organizations running Windows-based workloads alongside Linux containers, and for teams already operating within the Azure and Microsoft 365 ecosystem.

Quick Comparison

	EKS	GKE	AKS
Control plane cost	$0.10/hr ($73/month)	$0.10/hr (Standard and Autopilot)	Free (base), $0.10/hr (Standard), $0.16/hr (Automatic), $0.60/hr (Premium)
Fully managed mode	EKS Auto Mode	GKE Autopilot	AKS Automatic
New K8s version adoption	4-8 weeks after upstream	1-2 weeks (Rapid channel)	3-6 weeks
Extended support	+12 months ($0.60/hr total, vs $0.10/hr standard)	Up to 30 months ($0.50/hr extra; free with Enterprise edition)	Up to 24 months (Premium tier)
Serverless/nodeless option	Fargate (per-pod), Auto Mode	Autopilot (fully nodeless)	AKS Automatic
Best fit	AWS-native teams, max flexibility	Fastest upgrades, AI/ML workloads	Cost-conscious, Microsoft ecosystem

The Rise of “No-Ops” Kubernetes

The most important trend in managed Kubernetes over the past two years is the shift toward what many call “No-Ops” modes. GKE Autopilot pioneered this approach, and both EKS Auto Mode and AKS Automatic have followed. The premise is the same: the provider manages the entire infrastructure lifecycle so that platform teams can focus exclusively on workloads.

For MSPs and sysadmins managing Kubernetes across multiple clients, these modes act as a force multiplier. Instead of patching nodes, tuning AMIs, and managing autoscaler configurations for each cluster, you define pod specifications and let the provider handle the rest. The trade-off is less customization at the node level, but for the majority of standard workloads, that is a trade-off well worth making.

It is worth noting that “No-Ops” does not mean “no responsibility.” You still own resource request sizing, application-level security, network policies, and upgrade planning. The automation redistributes operational burden; it does not eliminate it.