"We're on managed Kubernetes. AWS handles that."
Maybe AWS handles that particular component. But who handles your application failing because its readiness probe is wrong, its database is unavailable, or every replica is scheduled into one failure domain?
A managed control plane is not a managed product experience.
Separate what the provider owns from what you own
Managed Kubernetes offerings vary in how they handle control planes, worker nodes, upgrades, networking, and add-ons. You need to read the exact provider and service documentation for your configuration.
But across EKS, GKE, and AKS, a core truth remains: application code, deployment behavior, workload configuration, data recovery expectations, and incident response don't disappear just because the API server is provider-operated.
Five responsibilities that stay on your side
- Workload availability. Replica placement, probes, resource requests, and service dependency behavior still determine whether customers can use the product.
- Identity and application security. Kubernetes RBAC, workload permissions, secrets handling, and application vulnerabilities need explicit ownership.
- Release safety. The cloud provider does not know whether a new version breaks your checkout flow.
- Data recovery. Managed cluster recovery and recovering your application's database, storage, or external state are different problems.
- Monitoring and incident response. Someone still needs to know that users are impacted and decide what to do.
A simple shared-responsibility exercise
Take your last incident and draw a line through every layer involved: cloud provider, Kubernetes control plane, nodes, networking, ingress, application, database, and third-party systems.
Put a named owner and an escalation path next to each. If an area has "the cloud" as its only owner, verify that assumption against your provider's documentation.
Then test one likely failure: node unavailability, an application rollout gone wrong, or the restore of critical state. The exercise should demonstrate who acts, not just that an SLA document exists.
Don't confuse provider uptime with your service SLO
A provider's control-plane availability commitment can be valuable, but your customers care about the service they interact with. Measure it separately with user-facing availability and latency indicators.
Managed Kubernetes is often the right engineering decision because it removes undifferentiated control-plane work. It just doesn't transfer accountability for everything above it.
Discussion: What's the most painful Kubernetes production problem you've had on a managed cluster—despite the control plane being healthy?
If you run EKS, GKE, or AKS but still struggle with production reliability, explore Kubernetes consulting or request a discovery call.