Most SaaS teams on AWS that run Kubernetes use a managed Kubernetes service, usually Amazon EKS. The word “managed” leads many founders and CTOs to assume the hard part is handled. It is not. Managed Kubernetes services take the control plane off your hands, and in some modes the nodes as well, but the cluster still needs upgrades, add-ons, networking, security policy, observability, cost control and someone who answers the page. This post explains what each option actually covers, what work remains, who can do it for you, and when you should skip Kubernetes entirely.

What a managed Kubernetes service actually manages

Managed Kubernetes, sometimes sold as Kubernetes as a service, means a provider runs part of the cluster for you. To see which part, it helps to know that a Kubernetes cluster has three layers of work.

The control plane: the Kubernetes API server and the etcd database that stores cluster state.
The data plane: the nodes (EC2 instances or Fargate) where your containers run, plus the networking, storage and load balancing they rely on.
Everything you run on top: your workloads, deploy pipelines, ingress, secrets, policies, monitoring and the add-ons that hold it together.

Amazon EKS always handles layer one. AWS runs the API server and etcd, and charges $0.10 per cluster per hour for a Kubernetes version in standard support. In the default mode, layer two is shared: AWS provides managed node groups, but the EKS documentation is explicit that managed node groups are not automatically upgraded when the control plane is. Layer three is yours.

EKS Auto Mode moves more of layer two to AWS. AWS takes over node provisioning, patching and scaling (using Karpenter), along with load balancer integration, pod networking and block storage drivers. Nodes run a locked-down Bottlerocket-based image and are replaced at least every 21 days. Even so, AWS states that customers keep responsibility for “the application containers, including availability, security, and monitoring,” as well as the VPC and cluster configuration. Auto Mode adds a management fee on top of the EC2 instances it launches, which varies by instance type.

So the honest answer to “what does managed Kubernetes cover?” is: the control plane always, the nodes sometimes, and your applications never.

Option 1: Build it yourself

You can run Kubernetes on EC2 with tools such as kubeadm or kops and own every layer, including etcd backups, control plane certificates and high availability across Availability Zones.

For a SaaS company on AWS, this rarely makes sense. The control plane is the part of Kubernetes where mistakes are hardest to recover from, and EKS charges a small hourly fee to take it away. Self-managing is worth considering only if you have a hard requirement EKS cannot meet, a platform team with deep Kubernetes experience, and a reason to spend their time on the control plane instead of your product. Most teams have none of the three.

Option 2: Buy managed Kubernetes on AWS with EKS

EKS is the default choice for Kubernetes on AWS, and for good reason: it integrates with IAM, VPC networking, load balancers and CloudWatch, and it removes the riskiest operational work.

The decision inside this option is standard mode versus Auto Mode. Standard mode gives you more control over node configuration and costs less in fees. Auto Mode costs more per node but removes node patching, AMI selection and autoscaler maintenance from your list. For a small team without a dedicated platform engineer, Auto Mode is often the better trade. For a team with specific node requirements, such as particular instance families or kernel settings, standard mode with managed node groups may fit better.

Either way, buying EKS is buying a foundation, not an operations team.

Kubernetes cluster management: the work EKS leaves with you

This is the list that surprises teams after their first cluster goes live.

Version upgrades on a fixed clock. Kubernetes releases a new minor version roughly every four months, according to the EKS version lifecycle documentation. EKS gives each version 14 months of standard support, then 12 months of extended support at $0.60 per cluster per hour, six times the standard rate. When extended support ends, EKS upgrades the control plane automatically, at a time it does not announce in advance, and you still have to update add-ons and any nodes not managed by Auto Mode yourself. In practice, someone has to plan and test an upgrade several times a year, including checking for deprecated APIs in your manifests and Helm charts.

Add-ons. The VPC CNI, CoreDNS, kube-proxy, the EBS CSI driver, an ingress or load balancer controller, cert-manager, external-dns, a secrets integration and a metrics pipeline all have their own versions and compatibility rules. Auto Mode absorbs some of these. The rest are yours.

Identity and access. Mapping IAM to Kubernetes RBAC, giving pods scoped AWS permissions, and keeping humans out of cluster-admin.

Networking. IP address planning for pods, security groups, network policies, ingress rules and the NAT and data transfer costs that grow quietly.

Deploys. A GitOps or pipeline-driven deploy process so that nobody runs kubectl apply from a laptop against production.

Observability and on-call. Metrics, logs and traces for the cluster and the workloads, alerts with runbooks, and a person who responds at night.

Cost. Requests and limits that match real usage, node consolidation, Spot where it is safe, and idle environments shut down.

Security. Image scanning, admission policies, secrets handling and patching the workloads themselves.

None of this is exotic. It is simply continuous, and it falls on whoever owns the cluster.

Option 3: Outsource the operations

The third route is a Kubernetes management service: an outside team that operates the cluster and the delivery path on top of EKS. Note the distinction from the first two options. You still buy EKS from AWS. What you outsource is the work in the previous section.

This fits teams that need Kubernetes but cannot justify a dedicated platform engineer, or that have one engineer carrying all of it alone. Managed Kubernetes providers of this kind differ a lot in scope, so ask:

Do you handle version upgrades end to end, including add-ons, deprecated APIs and testing in staging first?
Is everything in code in our repositories? Cluster configuration, Helm charts or manifests, and pipelines should live in your Git, not the provider’s.
Who is on call, and what is the response process? Get specifics.
How do changes reach production? Look for pull requests, review and an automated pipeline.
What happens if we leave? You should be able to hand the cluster to another team with its documentation intact.

When you don’t need Kubernetes at all

Many SaaS teams run Kubernetes because it is the default, not because they need it. On AWS there is a simpler path that covers a large share of web applications and APIs.

Amazon ECS is AWS’s own container orchestrator. There is no additional charge for ECS orchestration; you pay for the compute it runs on. With Fargate there are no nodes to patch, and there are no cluster version upgrades of the Kubernetes kind to schedule. ECS Express Mode goes further: you provide a container image and two IAM roles, and ECS sets up a Fargate service, a load balancer with TLS, auto scaling and networking.

AWS App Runner used to be the other simple option, but AWS has closed App Runner to new customers. Existing customers can keep using it, and AWS recommends ECS Express Mode for migrations. If you are starting today, plan on ECS.

Kubernetes starts to earn its overhead when:

You run many services with different scaling and scheduling needs, and the team wants one consistent platform for all of them.
You need the Kubernetes ecosystem specifically: operators for stateful systems, a service mesh, or tools that only ship as Helm charts.
You need portability across clouds or into customer environments, for example a product that customers install in their own clusters.
You already have engineers who know Kubernetes well and would be slower on anything else.

If none of those apply, ECS on Fargate is usually less work for the same result. A team of eight engineers running a handful of services on ECS is not behind; it has more time to work on its product.

How the options compare

	Self-managed on EC2	EKS (standard)	EKS Auto Mode	ECS on Fargate
Control plane	You	AWS	AWS	AWS (no fee)
Nodes and patching	You	You, with managed node groups	AWS	AWS (Fargate)
Version upgrades	You	You plan; AWS forces at end of support	You plan; nodes update automatically	No Kubernetes versions
Add-ons and ingress	You	You	Partly AWS	Not applicable
Workloads, deploys, on-call	You	You	You	You
Good fit	Rare, specialist teams	Teams needing node control	Small teams that need Kubernetes	Most web apps and APIs

The “workloads, deploys, on-call” row is the one that matters: in every option, someone still owns your workloads, deploys and on-call. Choosing a managed Kubernetes service decides how much infrastructure that someone also has to carry.

For a broader view of what AWS runs for you versus what a DevOps provider does, see our post on AWS managed services and managed DevOps.

Frequently asked questions

Is Kubernetes still relevant in 2026?

Yes, for teams that need what it offers: many services with different scaling needs, the Kubernetes ecosystem of operators and Helm charts, or portability across clouds and customer environments. What has changed is that it is no longer the automatic choice. On AWS, ECS on Fargate covers many web apps and APIs with less operational work.

What are the downsides of using Kubernetes?

The main downside is continuous operational work. Even on a managed service, someone has to plan version upgrades several times a year, keep add-ons compatible, manage identity, networking and cost, and answer the page. Extended support on EKS also costs six times the standard control plane rate if upgrades fall behind.

What are the four types of services in Kubernetes?

Kubernetes defines four Service types: ClusterIP, the default, which exposes a service only inside the cluster; NodePort, which exposes it on a static port on each node; LoadBalancer, which uses the cloud provider’s load balancer to expose it externally; and ExternalName, which maps the service to an external DNS name. On EKS, LoadBalancer services are typically backed by AWS load balancers.

Where Webera fits

Webera is a DevOps subscription for SaaS teams on AWS, with senior engineers working alongside nine AI agents. The agents do the watching, routing and first analysis around the clock; the engineers make the calls and ship the fixes. Whether you run EKS, ECS or are deciding between them, the work in this post goes into the same request queue, with 24/7 monitoring and incident response on every plan.

Pro, $4,999 a month: unlimited requests with two active at a time and an average 36-hour turnaround.
Elite, $9,999 a month: a named engineer, a customer success manager, a compliance concierge for SOC 2, HIPAA and PCI, and an average 24-hour turnaround.
Platform, $14,999 a month: a team working inside your sprints, with multi-account and Kubernetes operations and knowledge transfer to your engineers.

Every plan has a three-month minimum, billed monthly, then continues month to month, and you own all the code. If Kubernetes operations are taking more of your team’s time than your product is, compare the plans on our pricing page.

Managed Kubernetes Services: Build It, Buy It, or Outsource It