Amazon’s new managed Argo CD on EKS promises to reduce operational overhead, but is it worth migrating from a battle-tested self-hosted setup? A senior DevOps engineer weighs the pros, cons, and migration strategies for teams considering the switch.

Amazon’s New EKS Capability for Argo CD: A Senior Engineer’s Unfiltered Opinion

I still remember the 3 AM PagerDuty alert. The `argocd-repo-server` on our main production cluster, `prod-us-east-1-main-cluster`, was in a constant crash loop. A junior engineer had tried to apply a “minor” version bump to our self-hosted Argo CD instance during a maintenance window, but a subtle incompatibility with one of our custom plugins brought everything to a grinding halt. We spent the next four hours untangling dependencies and rolling back Helm charts, all while deployments were completely frozen. That night, I wasn’t thinking about the power of GitOps; I was thinking about the operational burden of keeping the GitOps engine itself running. So when Amazon announced a managed Argo CD as an EKS Capability, you bet I was interested.

So, What’s the Real Problem We’re Solving?

Let’s be honest, Argo CD is a fantastic tool. It has become the de-facto standard for GitOps in the Kubernetes world for a reason. But running it yourself, especially at scale, means you’ve adopted another complex, stateful application. It’s not just a `helm install` and you’re done. You own the whole lifecycle:

• Upgrades: As my war story shows, this is a major source of pain. You have to track CVEs, test breaking changes, and orchestrate the rollout.
• High Availability: Are you running enough replicas of the server, repo server, and application controller? Have you configured Redis correctly?
• Security: Managing permissions, SSO integration, and locking down the instance is on you. It’s another attack surface you need to defend.
• Monitoring & Backups: You’re responsible for observability and ensuring you can restore the state of your applications if something catastrophic happens.

In short, our self-hosted Argo CD had become a “pet,” not “cattle.” We had to nurse it, care for it, and worry about it. The appeal of a managed service is turning that pet back into cattle, letting someone else handle the care and feeding.

Your Options: The Good, The Bad, and The Realistic

As I see it, you have three main paths forward now that this EKS add-on is on the table. There’s no single right answer; it all depends on your team’s maturity, risk tolerance, and existing setup.

Solution 1: The “If It Ain’t Broke” Approach (Stick with Self-Hosted)

This is the path of least resistance. You do nothing. Your current, self-managed Argo CD instance keeps running. This is a perfectly valid choice, especially if your setup is highly customized or if you’re not ready to introduce a major change.

When to choose this:

• You rely heavily on custom plugins or a specific version of Argo that isn’t supported by the managed offering yet.
• Your team has a well-oiled process for managing Argo CD and the operational cost is acceptable.
• You need absolute, fine-grained control over every configuration knob and setting.

Warning: Don’t mistake “doing nothing” for “no cost.” You are actively choosing to carry the operational debt. Make sure you’re budgeting time for maintenance. That CVE patch for the Argo CD API server won’t apply itself.

Solution 2: The “Embrace the Future” Migration (Move to EKS Managed Argo CD)

This is the “permanent fix.” You plan and execute a migration from your self-hosted instance to the new EKS managed capability. The goal is to offload the undifferentiated heavy lifting of managing the control plane to AWS so you can focus on defining your applications in Git.

The process would look something like this (highly simplified):

1. Setup the Add-on: First, you’d enable the Argo CD EKS add-on for your target cluster. This is typically done via the AWS console, CLI, or IaC like Terraform.

   
   aws eks create-addon \
       --cluster-name prod-us-east-1-main-cluster \
       --addon-name argo-cd
       

2. Read-Only Mode: Put your old, self-hosted Argo CD in a “read-only” or “dry-run” mode to prevent conflicting deploys. You don’t want two operators fighting over the same resources.
3. Export & Import: Export your core application definitions and project configurations. The tricky part here is that a simple `kubectl get app -o yaml` might not be enough. You’ll need to re-create them in a way the new managed instance can consume, likely by applying the GitRepository and Application CRDs directly.
4. Cutover: Once you’ve validated the new instance is syncing correctly, you can perform the cutover and decommission the old self-hosted Argo CD pods.

The payoff is huge in the long run, but don’t underestimate the migration effort. It’s a real project, not a weekend task.

Solution 3: The “Nuclear” Option (Re-evaluate Your Tooling)

Sometimes, a big announcement like this is a great catalyst to ask a bigger question: Is Argo CD still the right tool for us? This is the “nuclear” option because it involves questioning your core GitOps strategy.

Maybe the simplicity of a tool like Flux CD, which is also a CNCF graduated project, is a better fit for your team. It tends to be more minimalistic and declarative in its own configuration.

Here’s a quick comparison table to get you thinking:

Choosing this path means going back to the drawing board. It’s the most disruptive, but it can also lead to a better long-term solution if your needs have changed since you first adopted Argo CD.

My Final Take

For us at TechResolve, the new EKS Managed Argo CD is incredibly compelling. That 3 AM outage is a scar I don’t want to repeat. We’re starting with a pilot migration for our non-production clusters to iron out the process. The promise of shedding the operational burden of managing the tool and just focusing on using it is the holy grail of DevOps. It won’t be a simple flip of a switch, but I’m excited to trade late-night firefighting for a good night’s sleep.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions