How do you choose a managed Kubernetes service?
Choose a managed Kubernetes service by checking a fixed set of criteria against your workloads: CNCF conformance, what the SLA covers and on which tier, how long versions are supported and what extended support costs, how nodes are provisioned, where nodes and the control plane can run, how pricing scales and what leaving costs. The ranking that matters is yours, because a service that is right for a single-cloud web app can be wrong for GPU training or EU-only data.
Start from your constraints
Before comparing vendors, write down the constraints that rule options out:
- Where data and workloads are allowed to run: countries, specific providers, your own data centers.
- Which hardware you need: GPU models, ARM, high-memory or bare-metal machines.
- Which clouds you already use and have commitments with.
- How many clusters you expect and how large they get.
- Which availability you promise your own customers.
These usually narrow the list faster than a feature comparison.
The evaluation checklist
The table works as a starting point for an RFP. Ask each vendor to answer every row with a link to their documentation, not a sales summary.
| Criterion | What to ask | Why it matters |
|---|---|---|
| Conformance | Is the service listed as Certified Kubernetes for the versions it offers? | Conformance is the baseline for running standard manifests, Helm charts and operators without changes. |
| SLA scope | Which component does the SLA cover, which tier carries it, what is the percentage and what is the remedy? | Most SLAs cover only the API server, and free tiers often have none. See what a Kubernetes SLA covers. |
| Version window | How many months is a minor version supported? What does extended support cost, and does it start automatically? | Extended support can raise the control plane fee sixfold on some services. See the version support lifecycle. |
| Upgrade control | Are there release channels, maintenance windows and exclusions? What happens at end of support? | Forced upgrades at end of support can break workloads that still use removed APIs. |
| Node model | Fixed node groups, node auto-provisioning that picks instance types per workload, or serverless Pods? | Determines how much capacity planning you do and how well nodes fit your requests. |
| Hardware | Which GPU, ARM and spot or preemptible options exist, in which regions? | Availability differs more between regions than between providers. |
| Where nodes can run | Only the provider’s regions, or also other clouds, edge sites and your own servers? | Decides whether hybrid or multi-cloud needs one cluster or several. |
| Control plane location | In which region does the control plane and its data store run? Who operates it, under which jurisdiction? | Cluster state includes Secrets and configuration. See how to keep data inside the EU. |
| Networking | Which CNI is used or allowed? Are network policies enforced? Is node-to-node traffic encrypted? | Changing the network plugin later usually means rebuilding the cluster. |
| Identity | OIDC or SAML single sign-on for users? Workload identity for cloud API access without static keys? | Static credentials in clusters are a common source of incidents. |
| Pricing model | Per cluster, per node, per vCPU or per Pod request? Which line items are separate: load balancers, NAT, egress, logs? | The model decides whether many small clusters or bursty workloads get expensive. See what managed Kubernetes costs. |
| Support terms | Response times by severity, which plan includes them and what it costs? | Support is usually a separate contract from the uptime SLA. |
| Exit cost | Which features are proprietary? What does it cost to move data out? | Lock-in comes from add-ons and integrations, not from the Kubernetes API. |
How to weigh the answers
Not every row carries equal weight. Three rows tend to decide the outcome.
Where nodes can run. If you need nodes in more than one cloud or in your own data center, a service limited to one provider’s regions forces you into several clusters and a separate multi-cluster layer. If you will stay on one cloud, this row matters little.
Version window and upgrade control. Teams that upgrade three times a year rarely pay for extended support. Teams with slow change processes, regulated release cycles or many clusters often do, and the fee applies per cluster.
Pricing model against your shape. Many small clusters favor services without a per-cluster fee. A few large, steady clusters favor flat per-cluster pricing with committed-use discounts on nodes. Spiky workloads favor models that bill for requested resources over models that bill for provisioned nodes.
Plan the exit before you sign
Ask how you would leave. A cluster that uses only standard Kubernetes APIs, open source add-ons and portable storage moves with its manifests. Proprietary identity bindings, provider-specific load balancer annotations and managed databases tied to one cloud need rework.
In the EU, the Data Act (Regulation (EU) 2023/2854) sets rules for switching between data processing services, including cloud services. Under Chapter VI, from 12 January 2027 providers may no longer impose any switching charges on customers who move to another provider, as the Bundesnetzagentur summarizes. The details are in what the EU Data Act changes for switching. See how to avoid cloud vendor lock-in for the technical side.
Comparing specific services
For a side-by-side of the two largest providers, see the Amazon EKS vs Google GKE comparison. For AWS users deciding whether to use Kubernetes at all, see Amazon ECS vs Amazon EKS.
Where Cloudfleet fits
Cloudfleet Kubernetes Engine is a conformant managed service whose clusters can include nodes from several clouds and your own servers at the same time. Pro clusters have a 99.95% monthly control plane uptime SLA, multi-zone control plane replication and release channels, and Enterprise adds a 99.99% SLA with custom terms and extended support for older Kubernetes versions. See cluster types for the full comparison.