Managing multiple EKS clusters: why cluster #3 is the wall

Do the arithmetic before you read the rest of this.

Count the people on your team who need access to a cluster. Multiply by the number of clusters you run. That result is how many access decisions somebody is maintaining by hand today. Now add one cluster and run it again.

The jump between those two numbers is why cluster #3 feels different from cluster #2. Not harder in kind. Harder in a way your existing habits stop absorbing.

Where I am standing: my own hands are on QA and development environments, and most weeks I am in conversations with people who run fleets for a living. The failure modes below are not war stories from a bridge call at three in the morning. They are what platform engineers and SREs describe to me over and over, in the same order, until you can predict the sequence.

One cluster is not a problem

With one Amazon EKS cluster, everything is where you left it. One context. One set of access entries. One place to look when something is wrong. Policy cannot drift because there is nothing to drift from. This is EKS doing what it was built to do, which is run a Kubernetes control plane in AWS so you do not have to. Nothing here argues against that.

Two clusters is a habit

The second cluster is usually production and staging, or two teams, or two regions. Annoying rather than difficult.

You keep two contexts. You copy the access configuration from the first cluster and change three lines. Most teams absorb this with copy-paste and discipline, and they are right to. Building a management layer for two clusters is over-engineering.

The trap is that copy-paste and discipline feel like a solution rather than a deferral.

Three is where the habit stops working

Three things break at roughly the same time, and none of them announces itself.

Access becomes a copy job with no source of truth. Adding one engineer across three clusters is three operations. Removing them is three operations, and the third is the one that gets missed, because whoever does it works from memory or a wiki page rather than from a system. Put it in Terraform, as plenty of teams do, and you get the same maintenance with better version control. You still have no single answer to who can reach production, only a repository you have to read to find out.

Environments drift, and you find out late. Production is locked down because somebody hardened it deliberately. Staging is not, because staging went up quickly and nobody revisited it. Nobody decided the two should differ. They just did, one exception at a time. This is the failure I see earliest, since preproduction is where drift starts, and it stays invisible until an auditor asks or an incident makes the difference matter.

Every upgrade happens N times. Control plane version, node groups, add-ons. Three clusters means three maintenance windows, three validation passes, three chances to land on three different add-on versions. Not intellectually hard. Repetitive and manual, which is where mistakes live.

Figure 1. The cluster count is the visible number. The one that actually grows is clusters multiplied by the people who need access to them.

The workarounds hold until cluster #4

Most teams I talk to have built the same three things, independently, without comparing notes.

A script that syncs access configuration across clusters. An internal wiki page explaining which context is which and what to run before you touch production. A naming convention doing the job policy enforcement should be doing, so a resource called prod- gets treated carefully because everyone agreed to treat it carefully.

These work. That is the awkward part. They work well enough that nobody has a reason to replace them, right up until the fourth cluster arrives, or the person who wrote the script leaves, or someone asks for a list of everyone with admin access and the honest answer is a day of work.

This is a boundary, not a defect

EKS RBAC is cluster-local by design. Access entries and role bindings live inside a cluster, because that is what the Kubernetes API models. There is no native cross-cluster identity layer in EKS and there was never meant to be one. AWS built a service that runs a cluster well.

EKS runs clusters. EKS cluster fleet management is a different job on a different layer, and most of that layer still does not ship with your clusters. AWS has filled parts of it: the EKS Dashboard aggregates cluster, node group and add-on inventory across an AWS Organization, and EKS Capabilities runs a managed Argo CD that can deploy to clusters across accounts and regions. What is still not there is a cross-cluster identity and access layer, and it was never in scope. But the moment you cross into it the work becomes yours, and it arrives as unpaid hours rather than a line on a bill. Worth being precise about, because the version of this argument that says EKS is inadequate is both wrong and easy to dismiss.

What fills that layer

SUSE Rancher for AWS is a solution built for this case: teams running Amazon EKS who want fleet-level control without operating another control plane to get it. It is SaaS. Nothing for you to deploy, patch or upgrade.

The scope is narrow on purpose. It manages Amazon EKS clusters. Self-managed Kubernetes on EC2, EKS Anywhere, other clouds and on-premises are outside it. If your estate is mixed, self-hosted SUSE Rancher Prime is the better fit and you can stop reading here. If EKS is your platform and you intend to keep it that way, the narrowness is what makes this something you consume instead of something you run.

Against the three failures above: roles defined once and enforced across every imported cluster, with single sign-on (SSO) and LDAP, so adding or removing an engineer is one operation rather than N. One EKS multi-cluster view that reaches workloads, not just the cluster, node group and add-on inventory where the EKS Dashboard stops. Fleet for GitOps, so the same manifests reach every cluster from one place, which is also what stops environments diverging. Alongside those, an AI assistant built on Amazon Bedrock for natural language troubleshooting, and t-shirt sizing to approximate cost before you commit to a shape.

If you work through the API, the CLI and Terraform rather than a console, evaluate that path first. The console earns its place for delegation, access review and audit evidence, which is exactly the work that hurts today.

One honest note on getting started. Importing existing clusters is the path most teams need, since these are clusters already in production rather than greenfield. Setup is a few steps and account provisioning is not instant, so plan an afternoon rather than a coffee break. Better you hear that now than find out at step two.

Pricing is $168 per month for a 24 managed vCPU base, then $7 per additional managed vCPU. Your EKS cluster costs are billed separately by AWS, as usual.

Where to go next

If you are still deciding whether you need a fleet layer at all, the previous post in this series is the honest version of that question: Do you really need more than EKS?

If you already know the answer, import two clusters and see what a single view tells you. Search AWS Marketplace for Rancher and you will find more than one listing, including a third-party consulting offering and a separate usage-based Rancher Prime listing. Make sure you land on the SUSE Rancher for AWS listing. Start your 30-day free trial of SUSE Rancher for AWS on AWS Marketplace.