Managing Hundreds of Amazon EKS Clusters at Fleet Scale · Part 1 of 18

Managing Hundreds of EKS Clusters: The Fleet Reference Architecture

The opener to an 18-part series. Once you run clusters by the hundred, the job stops being "operate a cluster" and becomes "operate a platform that emits clusters." This piece lays out the whole platform shape — GitOps-driven hub-and-spoke — and maps where every later article fits.

Why hundreds of clusters stop being a cluster problem

Running one EKS cluster well is a solved craft: pick a version, size some nodes, wire up IAM, ship workloads. Running three hundred of them is a different job entirely. The unit of thought changes from the cluster to the fleet, and every decision you used to make by hand — version, identity, networking, add-ons, cost — becomes an organization-scale policy problem.

Fleets this size are not hypothetical. Salesforce reported migrating more than 1,000 EKS clusters to Karpenter in a single program¹⁵ (a vendor-reported figure, not an AWS benchmark). When you operate at that count, artisanal per-cluster operations simply don't survive contact with reality — drift, inconsistent upgrades, and one-off IAM wiring turn into incidents.

The cleanest way to feel the shift is the bill. The EKS control-plane fee is a fixed floor of $0.10 per cluster-hour in standard support — about $74/month per cluster. Multiply out to 300 clusters and you're paying roughly $21,900/month (300 × $0.10 × 730 hours) in control-plane fees alone, before a single pod is scheduled.² That number reframes the whole design: your job as a fleet operator is to make the marginal cluster cheap to create, cheap to keep consistent, and cheap to retire. (Pricing current as of 2026-06-30; re-verify at publish time.)

The shape to build toward — GitOps-driven hub-and-spoke

The golden path this whole series argues for is a GitOps-driven hub-and-spoke platform. Git holds the desired state of the fleet. A central Argo CD hub reconciles that state onto many spoke clusters spread across accounts and Regions. No human logs into a spoke cluster to change it; you change Git, and the platform converges the fleet (Figure 1).

The reason to default to Argo CD in the hub is reach from one place. Argo CD ApplicationSets, with cluster generators and label selectors, let you target the entire fleet from a single control plane — "every cluster labeled env=prod gets this add-on" — and you get one pane of glass over the whole estate.⁸

That centralization has a real cost, and it would be dishonest to skip it.

The Argo hub is a blast-radius concern, and its UI is reported to slow past roughly 3,000–5,000 applications (a practitioner figure, not a hard AWS limit).⁸

Flux is the first-class alternative: a distributed pull model with one instance per cluster pointing at a fleet repo, leaner, scaling with the API server, and better for edge or air-gapped clusters — at the cost of the single pane of glass. A common hybrid runs Flux for infrastructure and Argo CD for applications. The full Argo-vs-Flux decision is its own article later in the series.

How a cluster gets born and stays converged — IaC hands off to GitOps

A fleet has two distinct phases, and the whole platform hinges on the seam between them (Figure 2). First a cluster is provisioned; then it is reconciled forever.

For provisioning, AWS now recommends a stable core EKS Terraform module for the cluster itself, with EKS Blueprints patterns reserved for add-ons — explicitly not using Blueprints to provision the core cluster in production.⁷ The Kubernetes-native alternative is Cluster API (CAPA), which gives you declarative, in-cluster lifecycle management but obliges you to run a highly-available management cluster — if it goes down, all cluster operations stop.⁹

The handoff is the part the diagrams usually gloss over. The GitOps bridge pattern has IaC write its generated metadata — IAM role ARNs and similar outputs — into the Argo CD cluster secret, so ApplicationSets and Helm charts can consume real values instead of hard-coded ones.⁷ That secret is the seam where "provision once" hands off to "reconcile forever."

After the bridge, Argo CD or Flux owns the cluster's add-ons and workloads and continuously corrects drift back to what Git says. Provisioning is a one-time act; reconciliation never stops. Fleet provisioning, GitOps management, and golden-path templates each get their own deep-dive later.

What every cluster ships with by default — the golden-path template

The point of a fleet platform is that a new cluster is never a blank slate. It comes off the line with the same opinionated defaults, so consistency is the path of least resistance rather than a review checklist. Four defaults define the template.

Compute: Karpenter. Karpenter is the fleet standard for autoscaling — groupless, workload-aware, provisioning best-fit EC2, mixing Spot and On-Demand in a single NodePool, and consolidating idle nodes.⁶ One honest caveat up front: AWS states there is no SLA for Karpenter; you own its operation. EKS Auto Mode is the managed alternative (a fee of roughly 12% on top of EC2 cost), covered later in the autoscaling article.

Identity: EKS Pod Identity. For EKS-in-cloud, EKS Pod Identity is the recommended default over IRSA — no per-cluster OIDC provider, IAM roles reusable across clusters, and IAM decoupled from cluster administration.³ IRSA doesn't go away: you still need it for Fargate, Windows, and portability to non-EKS or self-managed clusters.⁴ The identity article goes deep on the split.

Access: access entries. Cluster access is granted through EKS access entries, which replace the deprecated aws-auth ConfigMap and let you manage authorization as an AWS-native, auditable API rather than a hand-edited in-cluster map.⁵

Guardrails: policy-as-code. A golden-path template is only as good as what stops a team from stepping off it. Policy-as-code — Kyverno (YAML policies) or OPA/Gatekeeper (Rego) — enforces the baseline: no privileged pods, no host namespaces, no privilege escalation.¹⁰ Roll it out in audit mode first, then enforce, and manage the policies through the same GitOps flow as everything else.

The three decisions that will hurt — many-vs-few, IP exhaustion, cost drift

Most of the fleet is mechanical once the platform exists. Three decisions are not — they're expensive to reverse and each has a hard number behind it, so each earns its own article (Figure 3).

How many clusters? The control-plane floor (300 clusters ≈ $21,900/month²) pushes hard toward fewer, larger clusters. Isolation, blast radius, and compliance push the other way — and AWS's own scalability guidance is to use separate clusters for dev, test, and prod rather than namespaces for hard environment isolation.¹⁴ Getting that balance right is the many-vs-few article.

Will you run out of IP addresses? This one ambushes teams. On an m5.large you get only 29 pod IP addresses without prefix delegation, and 110 with it.¹¹¹² The trap: an EKS cluster is permanently bound to its creation-time VPC and subnets — you cannot migrate it to another VPC later.¹³ Addressing is a decision you make once, at the start, or pay for forever. That's the networking article.

Are you falling behind on upgrades? A version gets 14 months of standard support, then 12 months of extended support at a 6× control-plane price — $0.10 rises to $0.60 per cluster-hour.¹² Let a fleet drift into extended support and the bill compounds across every lagging cluster. Upgrades and cost management are two later articles that share this math. (Version calendar and pricing current as of 2026-06-30; re-verify before acting.)

How the rest of the series maps onto this architecture

Every later article is a component of the platform in Figure 1. Read them in order and they build the fleet layer by layer; dip into one and you'll know exactly which part of the architecture it fills in.

When this shape is right — and when to build something smaller

Here's the decision to carry out of this piece. Build the full GitOps hub-and-spoke platform when you have dozens or more clusters spread across teams, accounts, and Regions, and you need consistency, compliance, and an auditable trail for every change. That's the situation the rest of the series is written for.

Don't build it for three clusters and one team. Standing up an Argo hub, a golden-path template, and policy-as-code for a handful of clusters is overhead you'll feel and won't recoup; a single Terraform repo with managed add-ons is enough at that size. The platform earns its keep at fleet scale, not before.

But adopt the defaults early even when you stay small: EKS Pod Identity, access entries, and Karpenter cost nothing extra to choose on day one, and retrofitting identity, policy, and GitOps onto a sprawling fleet later is the genuinely expensive path. Start on the golden path; grow the platform around it as the cluster count climbs.

The next article takes the first hard decision head-on: how many clusters should you actually run, and where the isolation-versus-cost line really falls.