Managing Amazon EKS at Fleet Scale

GitOps at Fleet Scale: Hundreds of EKS Clusters Without Losing Control

A deeper, more current companion to the fleet-management series: how to run dozens or hundreds of EKS clusters through GitOps without losing control — Argo CD’s single pane versus Flux’s distributed pull, the GitOps bridge that wires them to your IaC, the scaling ceilings that actually bite, and the December 2025 managed EKS Capability that changes the build-versus-buy math.

What actually breaks at fleet scale — Three clusters and three hundred are not the same problem

GitOps at three clusters is solved: point one Argo CD or Flux at a repo and move on. "Fleet scale" gets its own playbook because three things stop being free past a few dozen clusters.

The centralized bet — Argo CD hub-and-spoke — one dashboard drives the whole fleet

Hub-and-spoke puts one Argo CD instance — the hub — in charge of many workload clusters, the spokes. The hub holds one Kubernetes Secret per spoke, and Argo's ApplicationSet cluster generator reads those Secrets to produce one Argo Application per matching cluster.¹ That's what makes onboarding automatic: drop a labeled Secret in and the controller deploys everything for that cluster, no further edits.

Label selectors are how you carve the fleet into groups

Argo CD has no native "cluster group" object, so you build groups out of labels on the cluster Secret, and an ApplicationSet's cluster generator uses a label selector to hit only matching clusters.¹ Label a batch tier: canary and one ApplicationSet deploys just to them — a tiered-rollout primitive, straight from a selector. Need per-cluster overlays? Nest a Git generator (enumerating overlay paths) and the cluster generator inside a Matrix generator, and you get the Cartesian product of overlays × clusters.¹

App-of-apps or ApplicationSet — you'll likely use both

Two patterns get conflated. The Argo project steers fleet operators toward the ApplicationSet cluster generator for most bootstrapping, but many teams use both — app-of-apps for the first bootstrap, then ApplicationSets for team self-service on top.²

Wiring the fleet without Terraform fighting you — The GitOps bridge pattern

Here's the problem the hub-and-spoke diagram hides. Cluster add-ons need cloud metadata Terraform owns but Argo CD wants at install time — the IAM role ARN for an IRSA-backed controller, a load balancer's DNS name, the cluster's API endpoint. The tempting fix, running the Helm charts through Terraform's Kubernetes provider, puts Terraform and GitOps in a fight over live cluster state, and you get conflicts.³ The GitOps bridge settles it cleanly: Terraform writes the metadata as labels and annotations on the Argo CD cluster Secret, and stops there.³

AWS's EKS Blueprints reference implementation makes this concrete. Each spoke Secret carries an awsAuthConfig block with the spoke's clusterName and a roleARN the hub assumes to deploy into that spoke — so the hub reaches every spoke by IAM role assumption, with no long-lived credentials copied around.⁴ ApplicationSets for add-ons and workloads then generate a per-spoke app-of-apps (workloads-${env}) for each registered cluster.⁴

Where the single control plane starts to hurt — Argo CD's UI and reconcile limits — and how sharding buys headroom

The centralized model has a ceiling, and it's worth knowing exactly where — the honest answer is "further than you'd guess, but not for free."

The controller scales — with sharding and tuning

Two independent benchmarks put real numbers on it. AWS drove a single Argo CD to 10,000 applications across 97 clusters,⁵ and CNOE pushed to 50,000 applications across 500 clusters on three m5.2xlarge nodes.⁶ The chart shows what sharding the controller and raising client QPS did to full-sync time.

The tuning lessons from those runs are specific and reusable:

• Sharding is the big lever. Set ARGOCD_CONTROLLER_REPLICAS and pick a --sharding-method: legacy (UID-based, uneven), round-robin (even), or consistent-hashing (least reshuffling on topology change). The last two are marked experimental.⁷
• Client QPS/burst mattered most in both benchmarks; CNOE saw a ~52% sync-time cut from QPS tuning alone.⁵⁶
• The status/operation processor knobs barely moved the needle at scale in AWS's test — raise them, but don't expect them to save you.⁵
• Sharding algorithm is a real choice: CNOE measured consistent-hashing-with-bounded-loads causing only 15 shard reassignments when going from 10 shards to 9, versus far more churn from the others.⁶

Worth noting: the official docs set no hard per-instance limit — the guidance is entirely benchmark-driven, with tuning recommendations calibrated "for 1000 applications."⁷

The UI is the softer ceiling

The controller shards; the web UI doesn't, not as gracefully. It starts to drag past about 1,000 applications per instance, and community reports bear that out: the UI goes sluggish at 1,500+ apps, and one instance with roughly 8,000 apps from ~2,000 ApplicationSets took about 35 seconds just to load the application list.⁸ The cause is architectural — the server fetches every application, then filters by RBAC, so the cost grows with total app count no matter what you're viewing; server-side pagination is the fix maintainers are working toward.⁸

When the hub goes down, what goes with it — Central control-plane blast radius

Everything above is the cost of success. The cost of failure is the real argument against centralizing. The hub reaches into every spoke's Kubernetes API to reconcile it — that's the single pane, and what makes the hub a single point of failure holding one very powerful set of credentials with write access to the whole fleet.¹² Compromise or wedge it, and the whole fleet's delivery path goes down with it.

That's not a reason to never centralize. Running clusters keep running — a dead hub doesn't delete your workloads. But it freezes all deployment, drift correction, and self-heal across the fleet at once — exactly the shared fate a distributed model refuses to accept.

The distributed bet — Flux — one controller per cluster, no shared fate

Flux flips the topology. In the standalone model each cluster runs its own Flux controllers, pulling its own slice of a fleet repo directly. As Flux maintainer Stefan Prodan puts it, this "minimizes attack surface and blast radius" and lets clusters "function autonomously even during outages."¹² There's no central plane holding fleet-wide credentials, and no hub whose death freezes the rest.

The price is exactly what centralization was buying: the single pane. Each cluster is bootstrapped and watched on its own, so fleet-wide sync status comes from aggregated metrics, not one dashboard.¹² Flux can run hub-and-spoke too — a central Flux reaching into spoke API servers — but that hands back the single point of failure and networking complexity you distributed to avoid.¹²

Edge and air-gapped clusters make the choice for you

For edge, IoT, and air-gapped or classified clusters, distributed isn't a preference — it's close to a requirement. Argo's central control plane must reach every managed cluster's Kubernetes API, exactly what a strict air-gap forbids. Flux's per-cluster controller pulls locally, needs no central API server, and travels lighter on resource-constrained nodes.¹³ AWS's prescriptive guidance points to Flux for "edge computing or IoT scenarios where resources might be constrained."¹¹

How you lay out the repo for a fleet — Structure is the part people underestimate

Both tools live or die by repo structure. The Flux fleet repository splits into three top-level trees.¹⁴

The pattern that scales: onboard a new cluster by wiring the Flux Terraform provider into the cluster-provisioning pipeline, so the cluster bootstraps itself against its clusters/<name> path as it's created.¹² The Argo equivalent is the GitOps bridge — the cluster registers by having a labeled Secret, and the ApplicationSet cluster generator takes it from there.

Shipping safely across the fleet — Progressive delivery and drift correction

Drift detection and self-heal — the everyday guarantee

Both tools continuously reconcile Git against live state. In Argo CD, automated sync with prune: true and selfHeal: true reverts manual changes back to Git (retried after a 5-second self-heal timeout) and prunes anything you deleted from Git.¹⁵ That's the real GitOps guarantee at fleet scale — not "we deployed it once" but "the cluster is continuously dragged back to the repo," on every one of the hundreds of clusters, with nobody watching.

Progressive delivery — Argo Rollouts vs Flagger

Neither Argo CD nor Flux does canary analysis itself; each pairs with a progressive-delivery controller, and the choice usually follows the ecosystem you already picked.

The practical read: if your fleet runs Argo CD, reach for Argo Rollouts and get the integrated UI; if it runs Flux, Flagger's zero-touch, metric-driven promotion is the natural fit.¹⁶

The answer most large fleets reach — The hybrid — Flux for infra, Argo for apps

Once you've felt both sides, the hybrid stops looking like a compromise and starts looking like the point: Flux runs inside every cluster for the platform layer — resilient, distributed, no shared fate for the infrastructure everything else leans on — while one central Argo CD owns application releases, giving developers the dashboard and app-centric view they want.¹⁷ AWS's prescriptive guidance maps onto the split: Argo CD for visual, app-centric, multi-cluster management with enterprise RBAC and SSO; Flux for lightweight, strongly multi-tenant, IaC-driven platform management.¹¹

What AWS just changed — The managed EKS Capability for Argo CD (December 2025)

The build-versus-buy math for the Argo hub shifted in late 2025. AWS launched the Amazon EKS Capability for Argo CD: a fully managed Argo CD running in AWS-managed service accounts outside your clusters, with AWS handling scaling, upgrades, inter-cluster communication, and token refresh.¹⁸ It takes over exactly the hardest parts of self-managed hub-and-spoke:

• Cross-account and cross-region reach via EKS Access Entries — without VPC peering — including clusters with private API endpoints.¹⁸
• Identity through IAM Identity Center instead of hand-rolled OIDC.¹⁸
• Native ECR and Secrets Manager integration, including automatic ECR authentication without the token-refresh workarounds self-managed hubs need.¹⁸

It's still Argo CD — ApplicationSets, the hub-and-spoke topology, the single pane — so everything above about UI limits and blast radius still applies conceptually. What changes is you no longer operate, scale, or patch the hub yourself. If you're standing up fleet GitOps on EKS in 2026, this is the first option to price out before you self-host.

Choose this when — Decision thresholds, not vibes

Common pitfalls — The failures that actually bite fleets

• Treating the Argo UI ceiling as the controller ceiling. The controller shards to tens of thousands of apps; the UI degrades around 1,000. Plan instance-splitting around the UI, not the controller.⁸
• Running Terraform's Helm/Kubernetes providers against a GitOps-managed cluster. It causes state conflicts — that's the exact problem the GitOps bridge exists to avoid.³
• Letting a central Argo hub become an un-budgeted single point of failure. If a hub outage freezing all fleet deployment is unacceptable, you wanted the distributed model.¹²
• Hybrid without a repo ownership boundary. Two controllers writing the same resource is an outage you built yourself.¹⁷
• Assuming a central control plane can reach air-gapped clusters. It can't; that's a Flux job.¹³