What If You Need Two ArgoCD Instances in One EKS Cluster?

POTHURAJU JAYAKRISHNA YADAV Posted on May 30           What If You Need Two ArgoCD Instances in One EKS Cluster? # aws # kubernetes # argocd # terraform Most ArgoCD tutorials start the same way: Deploy ArgoCD. Connect a Git repository. Create an Application. Done. But what happens when multiple teams start sharing the same Kubernetes cluster? Recently I was exploring a scenario where a single Amazon EKS cluster needed to support two different groups: A Platform Team managing infrastructure components Application Teams deploying business workloads At first, I thought: Why not just use a single ArgoCD instance? The more I thought about it, the more questions came up. How do we separate responsibilities? How do we avoid accidental changes? How do we provide SSO? How do we keep costs under control? That led me down an interesting path: Can we run two ArgoCD instances inside the same EKS cluster, authenticate both using Cognito SSO, and still share the same ALB? Turns out we can. This article walks through the architecture, challenges, lessons learned, and a few surprises along the way. The Scenario Imagine you have a Kubernetes cluster used by multiple teams. The Platform Team owns: cert-manager external-dns monitoring ingress controllers cluster add-ons The Application Teams own: APIs frontends microservices business applications A single ArgoCD instance technically works. But should both groups operate from the same GitOps control plane? For smaller environments, probably yes. For larger environments, things start getting messy. Different permissions. Different ownership boundaries. Different operational responsibilities. That was the motivation behind splitting ArgoCD into two instances. The Goal The architecture I wanted looked like this: EKS Cluster ├── ArgoCD (Platform Team) │ ├── cert-manager │ ├── external-dns │ └── monitoring │ └── ArgoCD (Application Teams) ├── frontend ├── backend └── business applications Enter fullscreen mode Exit f