Argo CD or Flux for Amazon EKS — which should we pick?

Both are CNCF-graduated, pure-GitOps tools that use Git as the single source of truth and continuously reconcile cluster state to the repo with automatic drift correction, and AWS Prescriptive Guidance is explicit that both handle most GitOps scenarios capably — so this is a fit decision, not a winner. Lean Argo CD when you want a visual UI and application dashboard, an application-centric mental model, strong multi-cluster management from a central control plane, and built-in enterprise RBAC/SSO for a larger org; EKS also exposes a native Argo CD capability with cluster registration and Application manifests. Lean Flux when you want a lightweight, CLI-driven, modular set of controllers with strong native multi-tenancy and built-in image-update automation, and you do not need a bundled UI. The wrong move is running both against the same workloads — two reconcilers fighting over the same manifests is a drift incident waiting to happen.

How do we handle secrets with GitOps without committing them to Git?

Never put plaintext secrets in the GitOps repository — it is the single most common and most damaging GitOps mistake, because the repo is replicated, backed up, and visible to everyone with read access. Use one of the established patterns: External Secrets Operator backed by AWS Secrets Manager (or AWS Systems Manager Parameter Store), which syncs secrets into the cluster at runtime so only a reference lives in Git; SOPS with AWS KMS, which stores encrypted secrets in Git that only the cluster can decrypt; or Sealed Secrets. Combine that with EKS Pod Identity or IRSA so the operator and your workloads get scoped IAM permissions to read those secrets rather than long-lived access keys. The rule is simple: Git holds references and encrypted material, never plaintext credentials.

What is the App-of-Apps pattern and why does it matter?

App-of-Apps is an Argo CD pattern where a single root Application points at a directory of child Application manifests, so the entire fleet of applications (and their target clusters) is described declaratively in Git. It matters because it turns onboarding a new app or cluster into a Git commit rather than a series of console or CLI clicks — the root app reconciles the children, and Argo CD self-heals any drift. Without it, teams end up hand-creating Applications one by one, which does not scale past a handful and reintroduces the manual, drift-prone workflow GitOps was supposed to eliminate. Flux achieves the equivalent through Kustomization and HelmRelease composition. Either way, the principle is the same: bootstrap the fleet from one declarative entry point so growth is a commit, not click-ops.

Should CI run kubectl apply, or should the GitOps controller deploy?

The GitOps controller should deploy; CI should not run kubectl apply. The correct boundary is: CI builds and tests the application, pushes the container image to Amazon ECR, and opens a pull request that bumps the image tag in the GitOps repo; on merge, the GitOps controller (Argo CD or Flux) reconciles the cluster to match. If CI runs kubectl apply directly, you have two systems writing to the cluster — the pipeline and the reconciler — which reintroduces exactly the drift GitOps eliminates, and the cluster state no longer matches Git. Keeping CI on the build-and-PR side of the line and the controller on the deploy side is what makes Git a trustworthy single source of truth and makes rollbacks a simple Git revert.

When is GitOps the wrong choice for an EKS workload?

GitOps is the wrong choice when its overhead exceeds its benefit or when the workload does not map to a reconcile loop. A single tiny cluster running one application with one operator may not justify standing up and maintaining a GitOps controller — a reviewed Helm or pipeline-based deploy can be perfectly adequate. Workloads that need imperative, ordered, human-in-the-loop steps — certain stateful database migrations, for example — do not map cleanly to a continuous reconcile-to-desired-state model and are better handled by a controlled, gated pipeline. GitOps shines when you have multiple apps and/or clusters, want auditable version-controlled state, easy rollbacks via Git revert, and automatic drift correction; it is overhead when you have none of those needs. Match the tool to the topology, not the trend.

How does GitOps on EKS relate to drift detection and infrastructure as code?

GitOps applies the same desired-state-in-Git principle to Kubernetes workloads that infrastructure-as-code applies to cloud resources, and both fight the same enemy: configuration drift between what is declared and what is running. A GitOps controller continuously reconciles cluster manifests and self-heals manual changes, which is drift detection and correction for the in-cluster layer. For the AWS resources around the cluster (the EKS control plane, node groups, VPC, IAM), you still use IaC — Terraform or CloudFormation/CDK — and its own drift-detection mechanisms, and tools like Crossplane or AWS Controllers for Kubernetes (ACK) can extend the GitOps model to provision AWS managed services declaratively from the cluster. The clean separation most teams settle on is IaC for the cluster and surrounding infrastructure, GitOps for what runs inside it.

GitOps on Amazon EKS 2026: Argo CD vs Flux, App-of-Apps, Secrets, Drift

GitOps on Amazon EKS (2026): Argo CD vs Flux, App-of-Apps, and the Decisions That Actually Bite

Quick summary: AWS Prescriptive Guidance says Argo CD and Flux both handle most GitOps scenarios capably — so picking one is a fit decision, not a winner. The decisions that actually cause incidents are the ones underneath: plaintext secrets in the GitOps repo, CI running kubectl apply and reintroducing drift, no App-of-Apps so onboarding is click-ops, and repo topology you can't change later. Here is the Argo CD vs Flux matrix, an App-of-Apps example, and the five traps independent of tool.

Key Takeaways

AWS Prescriptive Guidance says Argo CD and Flux both handle most GitOps scenarios capably — so picking one is a fit decision, not a winner
AWS's own Prescriptive Guidance says Argo CD and Flux both handle most GitOps scenarios capably — so the question "which is better
This is for platform and DevOps engineers running Amazon EKS who want GitOps done right, not the GitOps section of a general DevOps practices post repeated
Benchmark pattern (not a cited client) — A composite platform onboarding apps onto EKS by hand-creating Argo CD Applications one at a time, with a CI job that also ran "to be safe
EKS exposes a native Argo CD capability (cluster registration + Application manifests)

AWS’s own Prescriptive Guidance says Argo CD and Flux both handle most GitOps scenarios capably — so the question “which is better?” is the wrong one, and arguing it is how teams burn a week before writing a single manifest. Both are CNCF-graduated, both use Git as the single source of truth, both reconcile continuously and self-heal drift. Picking one is a fit decision. The decisions that actually cause incidents on Amazon EKS are underneath the tool choice: plaintext secrets in the repo, CI running kubectl apply and quietly reintroducing drift, no App-of-Apps so every new app is click-ops, and a repo topology you can’t change later without pain. This post covers the fit decision quickly and the traps thoroughly.

This is for platform and DevOps engineers running Amazon EKS who want GitOps done right, not the GitOps section of a general DevOps practices post repeated. We ship an Argo CD vs Flux decision matrix and an Argo CD App-of-Apps example.

Benchmark pattern (not a cited client) — A composite platform onboarding apps onto EKS by hand-creating Argo CD Applications one at a time, with a CI job that also ran kubectl apply “to be safe.” Representative shape, not a billed result: two systems wrote to the cluster, so live state drifted from Git and a rollback-by-Git-revert silently did nothing (the pipeline had already re-applied the old state). Moving to App-of-Apps (onboarding = a commit) and removing kubectl apply from CI (build + push to ECR + PR-bump only) made Git authoritative again — at which point git revert became a real rollback. The fix was process, not a tool swap.

The fit decision (do this in an afternoon, not a quarter)

Run the decision matrix. The honest summary:

Argo CD — when you want a visual UI / app dashboard, an application-centric model, strong multi-cluster from a central control plane, and enterprise RBAC/SSO. EKS exposes a native Argo CD capability (cluster registration + Application manifests).
Flux — when you want lightweight, CLI-driven, modular controllers, strong multi-tenancy, and built-in image-update automation, and you don’t need a bundled UI.

Opinionated take: if your org is larger, multi-team, and values a UI for “what’s deployed where,” start with Argo CD — the application-centric model and dashboard reduce onboarding friction. If you’re a lean, CLI-native platform team that wants composable controllers and automated image updates, Flux fits. Either is fine. Don’t run both against the same workloads.

The five traps that actually cause incidents (independent of tool)

Secrets do not go in Git. Use External Secrets Operator backed by AWS Secrets Manager (or SOPS+KMS, or Sealed Secrets). Git holds references and encrypted material, never plaintext.
Pod identity, not access keys. Use EKS Pod Identity / IRSA so the controller and workloads get scoped IAM — the same least-privilege discipline as IAM best practices.
App-of-Apps (or ApplicationSets) for scale. A root app pointing at child apps makes onboarding a commit, not click-ops — see the example. Flux: Kustomization/HelmRelease composition.
Repo topology, decided up front. Mono-repo vs per-team; environment-per-branch vs environment-per-directory. Changing it later is painful; pick deliberately.
The CI/reconcile boundary. CI builds, tests, pushes to ECR, and opens a PR bumping the image tag. The controller deploys on merge. CI must not run kubectl apply — that reintroduces drift and breaks Git-as-source-of-truth.

What broke — A team committed a Kubernetes Secret manifest with a base64-encoded (not encrypted) database password to the GitOps repo, reasoning “the repo is private.” A contractor with read access — legitimately granted for a different service — now had the prod DB credential, and base64 is encoding, not encryption. Caught in a routine access review, not by tooling. They rotated the credential, moved to External Secrets Operator backed by Secrets Manager (Git now holds only an ExternalSecret reference), and added a pre-commit secret scanner. base64 in a manifest looks opaque; it protects nothing.

Where GitOps stops and IaC starts

GitOps handles what runs inside the cluster. The cluster itself (EKS control plane, node groups, VPC, IAM) stays in Terraform or CDK with its own drift detection. Crossplane or AWS Controllers for Kubernetes (ACK) can extend the GitOps model to provision AWS managed services declaratively — useful, but keep the boundary clear: IaC for infrastructure, GitOps for workloads.

What to do this week

Pick one tool with the matrix and commit — stop debating Argo CD vs Flux.
Audit the repo for plaintext secrets (base64 counts as plaintext). Move them to External Secrets + Secrets Manager.
Pull kubectl apply out of CI. CI builds + pushes to ECR + opens a tag-bump PR; the controller deploys on merge.
Bootstrap App-of-Apps so the next app onboards as a commit, using the example.

What this post doesn’t cover

EKS cluster provisioning, autoscaling, and cost — see EKS + Karpenter cost-optimized autoscaling and Karpenter vs Cluster Autoscaler.
A full GitOps install walkthrough — this is the decision and trap guide, not a step-by-step; AWS Prescriptive Guidance has install detail.
Progressive delivery internals (Argo Rollouts / Flagger canary mechanics) — see also blue-green vs canary.
Exact feature parity between Argo CD and Flux — both evolve; confirm specifics in each project’s upstream docs.

If you only do one thing: Pull kubectl apply out of your CI pipeline and let the GitOps controller be the only thing that writes to the cluster. Until Git is the single writer, your “single source of truth” is a story, and your rollbacks are unreliable.

GitOps on Amazon EKS (2026): Argo CD vs Flux, App-of-Apps, and the Decisions That Actually Bite

The fit decision (do this in an afternoon, not a quarter)

The five traps that actually cause incidents (independent of tool)

Where GitOps stops and IaC starts

What to do this week

What this post doesn’t cover

Recommended Reading

How to Host n8n on AWS EKS: A Production-Ready Deployment Guide

What DevOps Guides Don't Tell You About Production AWS

10 AWS DevOps Practices We Actually Use in Production in 2026

From One FIS Experiment to a Resilience Program (2026): AWS Fault Injection Service, Stop Conditions, and GameDays That Actually Change Behavior

AI & assistant-friendly summary

Summary

Key Facts

Entity Definitions

Related Content

The fit decision (do this in an afternoon, not a quarter)

The five traps that actually cause incidents (independent of tool)

Where GitOps stops and IaC starts

What to do this week

What this post doesn’t cover

Related reading

Recommended Reading

How to Host n8n on AWS EKS: A Production-Ready Deployment Guide

What DevOps Guides Don't Tell You About Production AWS

10 AWS DevOps Practices We Actually Use in Production in 2026

From One FIS Experiment to a Resilience Program (2026): AWS Fault Injection Service, Stop Conditions, and GameDays That Actually Change Behavior