At an AWS event recently, someone asked me a question I get constantly. He ran three Amazon EKS clusters. He wanted to know, plainly, whether a management layer on top was worth it or whether he was about to be sold something he did not need.
I did not pitch him. I gave him the distinction I actually believe in, that is EKS runs clusters. Managing a fleet of them is a different layer with different problems. Whether he needed that layer had very little to do with how good EKS is, and almost everything to do with how many people and environments were touching those three clusters.
By the end of the conversation he had his answer, and it took about four minutes.
What EKS gives you
Start with what is genuinely good, because a lot of content on this topic skips it.
EKS runs the Kubernetes control plane for you. AWS patches it, upgrades it, and keeps it available. You get managed node groups and Fargate if you want to stop thinking about instances. You get integration with the AWS services you already use like IAM for identity, VPC CNI for networking, ELB for ingress, ECR for images, EBS and EFS for storage. Add-ons like CoreDNS, kube-proxy and the VPC CNI are managed per cluster.
EKS was designed to run one Kubernetes cluster in AWS. Well. it does that.
Where it stops
The gaps show up when the second and third clusters arrive, and they are consistent enough that I can almost predict the order.
Visibility is per cluster. Each one is its own world. Answering “what is running where” means switching contexts and stitching the picture together in your head.
RBAC is cluster-local by design. Access entries, IAM mappings and role bindings live inside each cluster. There is no native layer that says “this person is a viewer everywhere and an admin in staging only.” You end up maintaining that by hand, or in Terraform, which is the same maintenance with better version control.
Policy drifts. You define it per cluster, so staging and production diverge quietly until something breaks or an auditor finds it.
Self-service does not exist. Every access request routes through whoever holds cluster-admin.
Cost is visible per cluster, not across the fleet. You can see what each one bills. Seeing where the waste is across all of them is a project.
None of this is a flaw in EKS. EKS is infrastructure. This is a common issue that arises when managing multiple Kubernetes clusters that leads to cluster sprawl. Fleet operations sit on a different layer, and the moment you cross into that layer the problem becomes yours to solve.
EKS works vertically, one cluster at a time. The problems come with a fleet run horizontally across all of them.
The part that actually decides it
Here is where these conversations usually turn, and it is the part I care most about.
Once you accept that the cluster sprawl problem is real, you go looking for something to solve it. Most options answer the question by handing you a new thing to operate. Install Rancher yourself and you now run a management cluster: you patch it, you back it up, you upgrade it, and it joins the on-call rotation. For teams that want full control, that trade is worth making, and plenty of them make it happily.
But it means the real question is not “do I need a management layer.” Past two clusters, most teams eventually do. The question is what getting one costs you to run.
That is the good news if you are all-in on EKS, because that is the one case where you can get the layer without taking on the infrastructure.
When it pays off
Count how many of these are true for you today.
- More than one cluster and more than one team touching them
- You copy RBAC or policy config between environments by hand
- Developers open tickets to get cluster access
- Someone asks who has admin on every cluster and you cannot answer in five minutes
- You cannot say what is running where in under a minute
- You can see cost per cluster but not waste across the fleet
None or one. EKS on its own is doing the job today. Come back to this when the next cluster lands.
Two or more. You are already paying for the missing layer, in hours rather than dollars. That is the point where testing something makes sense.
What SUSE Rancher for AWS is
SUSE Rancher for AWS is a solution built for teams running Amazon EKS who want fleet-level control without adding infrastructure to maintain.
It is SaaS. There is no control plane for you to deploy, patch or upgrade. SUSE Rancher for AWS is also deliberately narrow. It manages Amazon EKS clusters. That is the scope. Self-managed Kubernetes on RKE, EKS Anywhere, other clouds and on-prem clusters are outside it, and if that is your shape then self-hosted Rancher is the better fit. If EKS is your platform and you plan to keep it that way, the narrowness is the whole point, because it is what lets this be a service you consume rather than a system you run.
I have been running SUSE Rancher for AWS for a while. Importing existing EKS clusters is the part I would point at first, because it is what most people actually need. These are teams with clusters already in production, not greenfield. Once they are in, you get one view across them.
I have also been driving Fleet included in SUSE Rancher for AWS for GitOps deployments. Fleet is Rancher’s GitOps engine that you point it at a Git repository and it keeps every cluster you choose in sync with what is in there. This is where the multi-cluster story stops being a diagram and starts being useful, because you apply the same manifests across clusters from one place instead of cluster by cluster.
Get quick intuitive access to Fleet from the UI of the Rancher Manager, a centralized RBAC that plugs into whichever SSO provider you already run, defined once and enforced across clusters, an AI assistant built on Amazon Bedrock for natural language troubleshooting, and t-shirt sizing to your clusters to approximate cost before you commit to a shape.
Pricing and availability. Take a 30 day free trial.
Get it on the AWS Marketplace in a few clicks. It bills to the AWS account you already have, with no new vendor to onboard and no separate procurement cycle. Apply your committed spending if you have available.
Pricing is $168 per month for a 24 managed vCPU base, then $7 per additional managed vCPU, metered hourly so you pay for what you actually run. Your EKS cluster costs are separate and billed by AWS as usual.
Take a 30-day trial for SUSE Rancher for AWS to make sure it will provide value for you.
The honest close
For one cluster, EKS on its own is the right answer and I would tell you so.
For three, it depends much less on the number than on how many people touch them, how many environments you keep in sync, and how long it takes you to answer a question about access. That is what I told the person at the event, and he left able to make the call himself, which was the point.
If the list above landed for you, import two clusters and see what the single view tells you. An afternoon is enough to know.
Related Articles
Mar 13th, 2025
What is monitoring sprawl and what to do about it?
Nov 17th, 2024
Announcing SUSE AI: An Enterprise ready AI platform
Apr 15th, 2025