Azure AKS, AWS EKS and Google GKE are “managed Kubernetes” in a narrow sense: the cloud provider runs the control plane. Most of what keeps a production cluster healthy is still yours. That includes node and add-on upgrades, ingress, certificates, monitoring, backups, security policies and incident response. This split, the shared responsibility model, is what teams moving to Kubernetes most often misunderstand.
We run clusters on all three clouds, plus Intermax IKS and on-premises. The split below holds everywhere, with small differences per provider.
What does the cloud provider manage?
All three providers take care of the same core:
- The control plane. The Kubernetes API server, the scheduler and the controller manager. They run them and keep them available.
- Control plane upgrades, when you trigger them or when an auto-upgrade channel does.
- Node images. They publish patched OS images for worker nodes.
- Integration with the cloud. Load balancers, disks and identity.
They also offer a growing set of tools on top: managed Prometheus, managed certificates for their own load balancers, and other add-ons.
Each provider documents its side of the deal: AKS support policies, the AWS shared responsibility model and GKE shared responsibility.
What is still your responsibility?
| Area | AKS / EKS / GKE provide | You (or your managed provider) |
|---|---|---|
| Control plane availability | Fully managed | |
| Kubernetes version upgrades | Upgrade tooling and auto-upgrade channels | Deciding when, testing, fixing what breaks |
| Deprecated APIs | Detection before an upgrade | Updating your manifests and charts |
| Cluster add-ons (CNI, CoreDNS, CSI drivers) | Managed add-ons | Keeping versions compatible with each upgrade |
| Node pool upgrades | Node images and surge upgrades | Planning, PodDisruptionBudgets, validation |
| Ingress / Gateway API | Cloud load balancers and basic ingress options | Choice, configuration, upgrades |
| TLS certificates | Managed certificates for their own load balancers | Certificates for in-cluster ingress, renewal monitoring |
| Monitoring and alerting | Managed Prometheus, basic dashboards | Alerts that mean something, and someone to act on them |
| Backups | Backup services | What to back up, and testing restores |
| Network policies | The policy engine | The policies themselves |
| Pod security and admission | Built-in policy options | Choosing and enforcing your baseline |
| Access and RBAC | Identity integration | Who gets which access, access reviews |
| Capacity and autoscaling | Autoscalers | Tuning requests, limits and node sizes |
| Audit evidence | Certifications covering their side | Evidence for your cluster: changes, access, configuration |
| Incident response at 3am | Support for their platform | Your cluster and your workloads |
The pattern is the same in every row: the provider delivers the tooling, you make the decisions and carry the consequences. Somebody still has to decide when to upgrade, test what happens, and fix it when it breaks.
The audit row deserves extra attention in healthcare, fintech and government. Your cloud provider’s ISO 27001 certificate covers their data centers and their control plane. It does not cover how your cluster is configured, who has access to it, or what changed last Tuesday. That evidence has to come from you.
What breaks when nobody owns it?
The failures we see most on clusters we take over are not exotic. They are the gaps in the right-hand column:
- Overcommitted nodes. Workloads run without resource requests and limits, so the scheduler packs too many pods onto one node. Under load the node runs out of memory, containers get OOM-killed and the kubelet starts evicting pods. It looks like an application bug until someone checks the node.
- Metrics without alerts. Managed Prometheus collects the metrics, but nobody wrote alerts for nodes running out of disk, pods stuck in a crash loop or deployments that never became ready.
- Security left at the defaults. Everyone has cluster-admin, because that was quickest during setup. Pod Security Standards are not enforced, so containers run as root or privileged without anyone noticing.
- Forced upgrades. The cluster falls off the provider’s support window, and the provider upgrades it on its own schedule. A workload using a removed API stops deploying.
- Backups that were never restored. The cluster had backups. Nobody had ever tested a restore, and the volume snapshots turned out to be incomplete.
Does GKE Autopilot or EKS Auto Mode solve this?
Partly. Autopilot and Auto Mode take node provisioning, node upgrades and some add-ons off your plate. That’s a real improvement. They don’t decide your ingress architecture, write your alerts, test your restores, enforce network segmentation between teams, or answer the page when your application can’t reach its database.
They also tie more of your platform to one provider’s way of working. Node configuration, scaling behavior and supported add-ons differ per cloud and per mode. That matters if you run on more than one cloud, or want to keep the option to move.
How does a managed Kubernetes provider fill the gap?
A managed Kubernetes provider takes over the right-hand column. At Guida, every cluster gets the same platform stack, whatever the cloud:
- Traffic management: Cilium, Gateway API with Envoy Gateway
- Certificate management: Cert Manager
- Observability: Prometheus, Grafana and Loki or integration with Elastic
- GitOps: FluxCD
- Backup and restore: Velero
- Security: Default-deny network policies, Pod Security Standards, Vulnerability Scanning, Container Security
We plan and run the upgrades, triage CVEs and handle incidents 24/7. Your team keeps ownership of its applications and gets a direct line to our engineers.
Why does cloud agnostic matter?
Because the right-hand column doesn’t change when you switch clouds, your platform shouldn’t either. We run the same stack on Azure AKS, AWS EKS, Google GKE, Intermax IKS and on-premises. Your developers use the same deployment workflow on all of them. Adding a second cloud or moving to a sovereign one becomes an infrastructure project, not a retraining project.
The bottom line
AKS, EKS and GKE are a solid foundation. They are not a platform team. Before you go to production, decide who owns each row in the table above.
Not sure who owns each row today? A Kubernetes Review maps it for your clusters. Or see what’s included in Guida managed Kubernetes.