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

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

Tópico: What If You Need Two ArgoCD Instances in One EKS Cluster?
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
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 ArgoCD environments:

• A Custom ArgoCD instance for the Platform Team

• A Managed ArgoCD instance for Application Teams

The Custom ArgoCD would manage infrastructure components such as:

• cert-manager

• external-dns

• monitoring

• ingress controllers

While the Managed ArgoCD would be used by application teams to deploy:

• APIs

• frontends

• microservices

• business applications

The challenge was figuring out how to keep both environments isolated while still sharing the same EKS cluster, Cognito User Pool, and AWS Application Load Balancer.

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

And on top of that:

• Single Sign-On

• Fully automated provisioning

• Infrastructure as Code

• Minimal AWS cost

The Final Architecture

The final design consisted of:

Developer
|
| HTTPS
v

Shared AWS ALB
(group.name = argocd)

|
+---------------------+
| |
v v

argocd argocd2

Platform Team Application Teams

| |
+----------+----------+
|
v

AWS Cognito User Pool

Both ArgoCD instances run inside the same EKS cluster.

The difference is that each lives in its own namespace.

argocd
argocd-managed

This gives logical separation without requiring another cluster.

Why Cognito?

Before choosing Cognito, I looked at AWS IAM Identity Center.

Identity Center is generally the preferred enterprise solution.

However, for this learning exercise I wanted everything automated using Terraform.

My ideal deployment process was:

terraform apply

and automatically create:

• User Pool

• App Clients

• Groups

• Users

• Passwords

without opening the AWS Console.

Cognito made that surprisingly easy.

Building the Authentication Layer

The first step was creating a Cognito User Pool.

Each ArgoCD instance gets its own App Client.

Visually, it looked like this:

Cognito User Pool

├── App Client
│ └── ArgoCD Platform
│
└── App Client
└── ArgoCD Managed

Here's what it looked like in AWS.

One thing I particularly liked was eliminating manual user creation.

Terraform creates:

• User Pool

• Domain

• App Clients

• Groups

• Admin User

Everything becomes Infrastructure as Code.

No temporary passwords.

No manual console work.

No forgotten setup steps.

Connecting ArgoCD to Cognito

ArgoCD supports OIDC natively.

That means Cognito can act as the identity provider.

The authentication flow becomes:

User
|
v
ArgoCD
|
v
Cognito Hosted UI
|
v
Authentication
|
v
OIDC Callback
|
v
ArgoCD Dashboard

Once logged in, ArgoCD reads the Cognito groups from the token and maps them to ArgoCD roles.

That means administrators are controlled centrally through Cognito instead of managing users inside ArgoCD itself.

The Shared ALB Experiment

This was probably the most interesting part.

Initially I considered creating two separate Application Load Balancers.

One for each ArgoCD instance.

That would work.

But it also means:

• More AWS resources

• More management

• More cost

Then I remembered the AWS Load Balancer Controller supports Ingress Groups.

That changed everything.

Instead of:

ALB #1 → ArgoCD
ALB #2 → ArgoCD Managed

I could use:

One ALB
Two Hostnames
Two ArgoCD Instances

The ALB creates listener rules based on the hostname.

And from Kubernetes:

Both ingress resources point to the same ALB.

The routing happens automatically based on the Host header.

A nice cost optimization with very little additional complexity.

The Problem Nobody Warned Me About

The first ArgoCD deployment worked perfectly.

The second one failed immediately.

The error looked something like this:

customresourcedefinitions.apiextensions.k8s.io already exists

At first it wasn't obvious.

Then it clicked.

ArgoCD installs CRDs.

CRDs are cluster-scoped resources.

The first installation already created them.

The second installation attempted to create them again.

Kubernetes refused.

The fix was simple:

crds:
install: false

Once I disabled CRD installation for the second ArgoCD instance, everything worked.

It was one of those issues that takes a while to understand but only seconds to fix.

The Login Experience

After deployment, the user experience was exactly what I wanted.

First, users see the ArgoCD login screen.

Selecting the Cognito login option redirects users to the Hosted UI.

After successful authentication, users land directly inside ArgoCD.

No local accounts.

No shared admin credentials.

No Kubernetes secret lookups.

Just SSO.

Another Small Gotcha

While testing Applications, I ran into this error:

app path is not a directory

I had accidentally pointed ArgoCD to a YAML file instead of a directory.

ArgoCD expects:

path: manifests/

not:

path: manifests/app.yaml

A small detail, but one that can waste a surprising amount of time when you're learning.

What I Learned

The most valuable lesson wasn't about Cognito.

It wasn't about Terraform.

It wasn't even about ArgoCD.

It was about ownership.

As environments grow, separating responsibilities becomes more important than simply making things work.

Running two ArgoCD instances gave:

• Better operational boundaries

• Cleaner RBAC

• Better team separation

• Reduced risk of accidental changes

And because both instances share a single ALB, the cost impact remained minimal.

Would I Do This Again?

For a small team?

Probably not.

A single ArgoCD instance is easier to manage.

For organizations with dedicated platform teams and application teams?

Absolutely.

The pattern scales nicely, provides cleaner ownership boundaries, and integrates well with SSO.

Most importantly, the entire environment can be created with a single:

terraform apply

which is exactly what I wanted from the beginning.

If you've experimented with multiple ArgoCD instances or different GitOps multi-tenancy approaches, I'd love to hear how you've solved it.

Happy GitOps 🚀

GitHub Repository

https://github.com/jayakrishnayadav24/eks-argocd-cognito-sso