Exposing Argo CD behind an AWS ALB: when your team needs it
Your platform team has Argo CD running in an AWS cluster, and engineers need it reachable through both the web UI and the argocd CLI. An Application Load Balancer works for this only when you add a separate Kubernetes service that uses the GRPC protocol and configure conditional routing so CLI traffic reaches that service while browser traffic reaches the UI. Classic Elastic Load Balancers and Network Load Balancers operate at layer 4, so they pass the connection through without that routing split and are the simpler alternatives when you do not need layer 7 features on the entry point.
Argo CD is released under the Apache License 2.0 (SPDX: Apache-2.0), and the project itself offers no paid edition, so there is no license fee to plan for. The cost of this work is the engineering time to design the ingress, validate it and operate it, along with the AWS resources the load balancer consumes. Those resources sit in your own AWS account, and the load balancer, certificates and target groups are yours to manage. Confirm your current AWS load balancer quotas and pricing with AWS, since those figures change and are not part of this page.
Before choosing a load balancer type, decide where TLS ends and whether the team needs the UI and CLI on one hostname or two. Ask your DeployOpen team, or your own engineers, to confirm which Argo CD version you run and which ingress settings that version expects, because the TLS mode determines whether server.insecure is set on the API server. The Argo CD ingress configuration guide is the reference to check against your planned design.
Choosing between an ALB, a classic ELB and an NLB
An Application Load Balancer works at layer 7, so it reads HTTP requests and can route them by host, path or headers. For Argo CD this means the web UI and the gRPC-based CLI traffic usually need different backends. Argo CD's ingress guide describes a separate service that uses the GRPC protocol and conditional routing, so requests from the CLI reach the gRPC service while browser traffic goes to the standard HTTP service. This keeps the ALB as the single public entry point and gives you control over listener rules.
- Two services: You create one service for the UI and one for gRPC, and each needs its own target configuration.
- Conditional routing: Listener rules match the CLI traffic pattern and send it to the gRPC target group.
- TLS at the edge: The ALB can terminate TLS, which pairs with
server.insecureon the Argo CD side in many designs. - More moving parts: Rule priority, health checks and certificate attachment all need review when the Argo CD version changes.
- Controller dependency: The AWS Load Balancer Controller creates these resources, so its version and IAM permissions are part of the design.
Confirm the exact annotations and protocol settings against the current ingress guide and your controller version before you build the rules.
A classic Elastic Load Balancer can be used as a layer 4 load balancer, which means it forwards TCP connections without reading the HTTP content. The supplied guidance says classic ELBs and NLBs can serve Argo CD in this role. Because the balancer does not route on HTTP paths, you do not need a separate gRPC service or conditional rules. The traffic reaches the Argo CD server and the handling of HTTP and gRPC happens there, so the design has fewer components to maintain.
- One listener path: Web and CLI traffic follow the same route to the Argo CD API server.
- Fewer objects: No separate gRPC service or listener rule set is required for the balancer.
- TLS placement: With layer 4 forwarding, TLS is usually handled by Argo CD itself rather than the balancer, so plan certificates on the cluster.
- Fewer routing features: You cannot send requests to different backends based on path or header at this layer.
- Confirm support: Check with AWS which load balancer type fits your account, Region and controller version, since classic ELBs are an older option.
Confirm how the balancer type, health checks and certificate handling interact with your chosen Argo CD TLS model before you commit.
A Network Load Balancer also works at layer 4 and forwards TCP traffic to targets. It fits the same pass-through pattern as a classic ELB, with Argo CD receiving the connection and handling HTTP and gRPC itself. Teams often choose it when they want the balancer to stay out of protocol decisions and when they expect traffic that is not limited to HTTP. Because the load balancer does not inspect requests, the work of separating UI and CLI paths is not needed on the balancer side.
- Protocol-agnostic forwarding: The balancer passes connections through without reading HTTP or gRPC frames.
- TLS passthrough or termination on the cluster: Certificates and their renewal stay with the Argo CD ingress or server configuration.
- Simpler listener model: Listeners and target groups map directly to the Argo CD service port.
- Less request-level visibility: You get connection-level metrics, so request-based debugging moves to Argo CD and cluster logs.
- Operational check: Confirm target health checks, cross-zone behavior and client source IP handling for your environment.
Verify the listener and target settings in your environment and in the ingress guide before you choose this path.
Some teams cannot settle the choice until the rest of the platform is clear. The right answer depends on which ingress controllers are already in use, whether the organization has standard load balancer patterns, how certificates are issued and who owns the balancer. If the cluster will move to the Kubernetes Gateway API or another ingress model later, a decision that is cheap now may be costly to reverse. Treat the choice as provisional until these facts are confirmed with the platform, security and networking owners.
- Existing standards: Check whether your AWS account already uses one balancer type for internal services.
- Ownership: Confirm who manages listener rules, certificates and controller upgrades.
- Future ingress plans: Ask whether the platform team expects to change ingress models within the next release cycle of Argo CD.
- Certificate workflow: Decide where certificates are stored and renewed before choosing where TLS ends.
- Testing path: Plan a CLI login test and a browser test in a non-production cluster before you publish the endpoint.
If the answers are unclear, prototype the CLI path first, since it is the constraint most likely to force a change later.
Configuration options and when each fits
This table compares the four ways to place Argo CD behind AWS load balancing, from ALB routing with a separate gRPC service to layer 4 pass-through. Read each row against your CLI usage, your TLS policy and the controllers you already run, then confirm the items in the last column before you choose.
| Option | When it fits | What to confirm |
|---|---|---|
| Separate gRPC service with GRPC protocol | You want the ALB to serve the web UI and the CLI from one hostname and the team uses the argocd CLI heavily | The AWS Load Balancer Controller version supports the GRPC protocol target setting, and the ALB listener uses HTTPS with a valid certificate |
| Conditional routing on gRPC content type or path | You need one listener to send CLI calls to the gRPC service and browser traffic to the UI service without a second hostname | Rule priorities match the controller's annotations, and the gRPC content type header reaches the target unchanged |
| TLS termination at the ALB with server.insecure on argocd-server | Your security standard requires the ALB to hold the certificate and the cluster network is trusted between the ALB and the pods | How traffic is encrypted between the ALB and argocd-server, and whether your policy accepts plaintext inside the VPC |
| Layer 4 classic ELB or NLB with Argo CD serving its own TLS | You want end-to-end encryption, no HTTP rules to maintain, and the CLI and UI to use the same TLS endpoint | Health checks, source IP handling and the certificate lifecycle inside the cluster, plus whether your ingress team supports this pattern |
| Operational overhead | Choose the option your team can troubleshoot, upgrade and monitor without a separate support path | Who owns the load balancer, the controller version and the rules, and how changes are tested before rollout |
Setup sequence for the ALB, the gRPC service and TLS
This sequence takes an Argo CD installation from a confirmed version to a working web login, CLI login and test sync through an Application Load Balancer, with each step closed by a check you can run. It keeps the web UI and the gRPC CLI traffic on separate, deliberately routed paths.
Confirm the Argo CD version and matching ingress guide
The platform or cluster engineer records the exact Argo CD version you will install and reads the ingress guide for that version before touching the load balancer. Patch support is limited to the three most recent minor versions, so pick a version on that list and note the release you chose. Check that the manifests or Helm chart you plan to use match this version. Done when you have a written version and a link to the matching ingress documentation saved with your change record.
Decide the hostname and issue the certificate in ACM
The network or platform owner picks one public hostname for Argo CD, such as argocd.example.internal (illustrative), and requests a certificate for it in AWS Certificate Manager in the same region as the ALB. Confirm that DNS validation or your internal certificate authority process can complete in your environment. Decide whether the ALB is internet facing or internal, since this changes who can reach the CLI. Done when the certificate status is issued and the hostname resolves to the ALB address from the intended network.
Set server.insecure and accept its consequences
The platform engineer sets server.insecure to true in the argocd-cmd-params-cm ConfigMap so the API server serves plain HTTP behind the load balancer and the ALB terminates TLS. Be clear with the team that traffic between the ALB and the pod is then unencrypted unless you add encryption inside the cluster, and that the server must not be reachable directly from outside. Restart the argocd-server deployment to apply the change. Done when the argocd-server pods are ready and their logs show the server listening without TLS.
Create the web service and a separate gRPC service
Keep the existing argocd-server Service for the web UI and REST API, then create a second Service that targets the same pods and uses the GRPC protocol for the CLI. The ALB needs both targets so that browser traffic and gRPC calls can be routed independently. Confirm the port names and selectors match the argocd-server pods. Done when both Services list the argocd-server endpoints and kubectl get endpoints shows the same pod addresses for each.
Configure listener rules for conditional CLI routing
The network engineer creates target groups for the web service and the gRPC service, then sets up an HTTPS listener on the ALB with a default rule for the web target group. Add a higher priority rule that forwards CLI traffic to the gRPC target group based on a request header or path condition that your CLI configuration can send, and confirm that condition with the Argo CD ingress guide for your version. Done when the listener rules list in priority order and a test request with the CLI condition is shown in ALB access logs or target metrics as going to the gRPC target group.
Register targets and confirm health checks
Register the argocd-server pod IPs or instances as targets in both target groups, using the ports your Services expose. Set the health check path and protocol to match what the server answers with server.insecure enabled, and confirm the gRPC target group uses the protocol version your ALB configuration requires. Done when every target in both groups reports healthy in the ALB console or CLI output.
Verify web login, CLI login and a test sync
Sign in through the browser at the chosen hostname using the initial admin account or your configured SSO, then run argocd login against the same hostname with the CLI options the guide specifies. Create or use a small test application from a repository you control and run a sync from the UI and from the CLI. Done when the browser login succeeds, argocd login returns a successful session, and the test application reaches Synced and Healthy. Record these results as the acceptance evidence for the change, and disable the admin account later once SSO or local users are in place.
Security controls at the load balancer edge
The ALB is one layer in front of Argo CD, not the whole control. Argo CD still authenticates API requests, redacts credentials and depends on its own RBAC, so the controls below cover the edge itself, the path from the load balancer to the pods, and the Argo CD settings that must match what the edge promises.
Do not rely on the ALB alone
Argo CD authenticates API requests only with JSON Web Tokens, so every request that reaches the API server still needs a valid token. Treat the ALB as a traffic filter and keep Argo CD's own login, RBAC and project boundaries fully configured. Check that the ALB forwards all traffic to the Argo CD service without an authentication action that a misconfigured listener could bypass.
Restrict security groups and listener sources
Limit the ALB security group to the networks that need the UI and CLI, and restrict the security group on the pod or node side so that only the ALB can reach the Argo CD service ports. Confirm which corporate ranges, VPN egress points or CI runner networks must reach Argo CD, and document the list so reviewers can compare it with the deployed rules.
Decide where TLS ends
Choose whether the ALB terminates TLS with an ACM certificate and forwards to Argo CD over HTTP, or re-encrypts to the pod. When the ALB terminates TLS, Argo CD runs with server.insecure set to true, so the internal hop must be protected by the VPC design and the security group rules. Write down this decision before the listener is built, because it changes certificate handling and the CLI's protocol path.
Re-encrypt inside the cluster when required
If your network policy requires encryption between the ALB and the pod, keep Argo CD serving TLS and configure the ALB target group to use HTTPS to the backend. Argo CD uses TLS for traffic between its own components, so this design extends encryption to the last hop. Confirm the certificate chain the ALB trusts for the backend and plan its renewal alongside the public certificate.
Disable the admin user after SSO
The built-in admin user is meant for initial setup only. Once local users or SSO are working, set admin.enabled to false so that a password-based login cannot be attempted through the public listener. Test a break-glass path first, such as a named local account or a documented recovery procedure, so you do not lock yourself out.
Keep Argo CD within supported versions
Patch releases are published only for the three most recent minor versions, so an ALB that is working is not a reason to stay on an older release. Track the release cadence, schedule upgrades before a minor version drops out of support, and test each upgrade against your ingress configuration, since gRPC routing and TLS settings are the parts most likely to change behavior.
What the ALB path costs you in routing complexity
The ALB route adds moving parts that must stay in step with each other. You maintain a separate Service for the gRPC protocol alongside the one serving the web UI, and a listener rule that sends CLI traffic to that gRPC Service while everything else goes to the HTTP path. Each Argo CD upgrade can change the Service names, ports or the way the API server listens, so the routing set must be checked after every version move, not only the Deployment. Ask your platform team who owns that check, and add it to the upgrade runbook before the first upgrade rather than after the first broken login.
Setting server.insecure moves TLS responsibility from Argo CD to the load balancer. The ALB terminates HTTPS with your certificate, and traffic from the ALB to the Argo CD pods travels without TLS on the server side. That is a deliberate design choice, and it means the certificate lifecycle, the listener security policy and the backend trust boundary now sit with the AWS account owners, not the Argo CD administrators. Confirm who renews the certificate, who reviews listener changes, and whether traffic inside the cluster network is acceptable under your own encryption-in-transit policy. Argo CD's security documentation describes TLS between its own components, so the trade-off should be recorded as a decision with an owner.
The argument for this route only holds if the CLI keeps working. The argocd CLI speaks gRPC, so a listener rule that sends gRPC requests to the HTTP Service, or that fails to match the gRPC traffic, produces errors that look like login or network faults rather than routing faults. Test the CLI login and a basic argocd app list from a workstation and from your CI runner after every change to the listener rules or the Service definitions. Confirm with your AWS and Argo CD documentation how the ALB handles the protocol version for each target group, because that detail decides whether the rule works at all.
Limits to confirm in your AWS environment
The ALB path for Argo CD depends on settings that change with the Argo CD version, your cluster shape and your AWS account controls. Treat each card below as a question to answer in your own environment before you commit to a design.
gRPC behavior on the ALB
The ALB must route the CLI's gRPC traffic to a separate service that uses the GRPC protocol, while the web UI goes to the standard service. Confirm how your chosen Argo CD version and your listener rules handle the gRPC path, including the header match used for conditional routing. Test argocd login and a sync from a workstation outside the cluster network before you call the design done, because a UI that loads does not prove the CLI works.
IPv6-only clusters
The Argo CD high availability documentation states that IPv6-only clusters are not supported for the HA manifests. If your VPC or node groups are IPv6-only, or you plan to move to that model, the ALB design and the HA layout both need review. Confirm the addressing model of your cluster before you choose the manifest set.
Three nodes for anti-affinity
HA manifests need at least three nodes because of pod anti-affinity rules. Check that your node groups span enough nodes and availability zones to schedule the replicas without pods staying pending. If the cluster is smaller, the ALB may still work, but the high availability claim does not hold until the node count is met.
Certificate and hostname ownership
Someone on your team must own the DNS record, the certificate in AWS Certificate Manager or on the cluster, and the renewal process. Confirm who can change the hostname and who approves certificate issuance. Where TLS ends at the ALB, the internal hop to Argo CD runs without its own certificate, so your security review should cover that segment explicitly.
Landing zone load balancer rules
Your AWS landing zone or service control policies may restrict which load balancer types, listener settings or public subnets you can create. Ask the cloud platform team whether an ALB, a classic ELB or a layer 4 NLB is permitted in the target accounts. Layer 4 options can be simpler when the ALB path is blocked, but they move routing and TLS decisions into Argo CD or the cluster.
Questions teams ask before exposing Argo CD on AWS
What does it cost to expose Argo CD behind an AWS Application Load Balancer?
The cost comes from the work, not from a fixed package: the ALB and its associated resources in your AWS account, the time to design and verify routing, and the people who build and test it. Your AWS bill covers the load balancer, certificates and any data transfer, and those charges recur for as long as the endpoint runs. The one-time part is design, configuration, and testing of the CLI and UI paths. Ask any provider for a written scope that lists the routing design, the TLS setup, the identity integration, and the verification steps, because those items drive the quote more than the number of Argo CD instances. DeployOpen does not publish prices and provides a quote from the written scope.
How long does an ALB setup for Argo CD take?
Duration depends on the steps and checks, and on how many environments must be prepared. The work follows a sequence: confirm the DNS name and certificate, create a separate service that uses the GRPC protocol for CLI traffic, define conditional routing so gRPC requests reach that service while browser traffic reaches the UI, set server.insecure where TLS ends at the load balancer, then test the UI login, the CLI login, and a sync from each path. Teams with existing AWS landing zones and approved certificate processes usually move faster. Ask for the step list and the acceptance checks in the written scope rather than a single duration.
What must our team provide before the work starts?
Plan to provide four things: access to the AWS account or accounts where the cluster and load balancer will run, with rights to create load balancers, target groups, security groups and listener rules; a TLS certificate for the Argo CD hostname, issued from a source your security team accepts; DNS control for that hostname; and the identity provider settings if single sign-on is in scope, including the callback URL and the group claims you intend to map. Also name who approves changes to ingress in production. Missing any of these usually delays the start more than the technical work itself.
Can our internal platform team do this without a partner?
Yes, if the team already runs Kubernetes ingress on AWS and understands how the ALB handles HTTP/2 and gRPC. The hard parts are routing and testing, not the commands. Routing needs a separate gRPC service and rules that send CLI calls to it, and a mistake can make the UI work while the CLI fails, which is easy to miss. Check whether your team can run and document the acceptance tests for both paths, plan the change to server.insecure, and maintain the setup through upgrades. If one of those gaps exists, a fixed-scope engagement can close it while your team keeps ownership of the result.
When is a Network Load Balancer or classic ELB simpler than an ALB?
A layer 4 load balancer is simpler when you want Argo CD to terminate TLS itself, or when you need one listener that passes both gRPC and web traffic without routing rules. The Argo CD ingress guide notes that classic ELBs and NLBs can be used as layer 4 load balancers. With a layer 4 design, you avoid conditional routing and the separate gRPC service, but you take on certificate handling inside Argo CD and must confirm how health checks and client IP preservation behave in your environment. Choose the ALB when you need layer 7 features such as host or path rules, WAF integration, or centralized certificate management in AWS.
How do Argo CD upgrades change an ALB setup?
Upgrades can change the service names, ports, and the way TLS and the API server are configured, so the ALB rules must be checked on every version change. Argo CD releases a minor version four times a year and patches only the three most recent minor versions, so plan to move regularly. Before each upgrade, review the official upgrade notes for the target version, confirm the gRPC service and listener rules still match the chart or manifests, and rerun the UI and CLI acceptance tests. Keep the load balancer configuration in version control next to the Argo CD values so the change is reviewed and reversible.
What breaks most often after the ALB is in place?
The most common failure is that the browser works and the CLI does not. Requests from the CLI use gRPC, and if they reach the UI target group or are not routed to the gRPC service, logins and syncs fail with errors that look like authentication problems. Other frequent causes are a certificate that does not match the hostname, a missing server.insecure setting when TLS ends at the ALB, and health checks that point at the wrong path or port. Build tests for login, sync, and logout through both the browser and the CLI, and alert on failed health checks so the problem appears before users report it.
How this fits the wider Argo CD exposure decision
The ALB decision is really a choice about where TLS ends and which layer routes the gRPC traffic. Argo CD serves its web UI and its gRPC API from the same API server, and the argocd CLI depends on gRPC. Behind an ALB you run a separate gRPC-protocol service with conditional routing, and you usually set server.insecure so the API server accepts plaintext from the load balancer while TLS terminates at the ALB. Compare that with the NGINX, Traefik and Gateway API pages, where the same two traffic types are handled by an ingress controller or route object inside the cluster. If your organization already standardizes on one of those controllers, the ALB adds a second routing model to operate and troubleshoot, and that cost should be weighed against the benefit of managed AWS load balancing.
Use the layer 4 option to avoid gRPC routing rules entirely. The topic guidance notes that classic ELBs and NLBs can serve as layer 4 load balancers, which passes the gRPC stream through without application-layer rules. Confirm with your AWS architecture team which load balancer types your accounts and network design permit, and whether TLS must reach the API server itself, since that decides between passthrough and termination. The Argo CD ingress configuration guide is the reference to check against each controller's setup before you pick one. Document the choice with the path prefix, if any, because the subpath page covers the rootpath and basehref settings that change once Argo CD is not served at the root.
When an implementation partner adds value to this work
An implementation partner adds the most value when the ALB design has to be settled before anyone touches the cluster. DeployOpen would plan this work as a written scope covering the ALB design, the separate gRPC service and its conditional routing, the TLS decisions, SSO configuration and verification, all delivered inside your own AWS account. The scope names the load balancer type, the target group protocol, the listener rules that send CLI traffic to the gRPC service, the hostnames, the certificate source and the identity provider settings. Deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that scope.
Ask any partner, including DeployOpen, to show how the scope handles the decisions that usually stall internal teams: whether the ALB terminates TLS while Argo CD runs with server.insecure, how the CLI reaches the gRPC endpoint, and whether a classic ELB or a layer 4 Network Load Balancer is the simpler fit for your traffic pattern. Each choice changes the Kubernetes service definitions, the health checks and the certificate handling. Confirm with your AWS team which load balancer controller version and account constraints apply, because those details decide what the design can use.
Verification is where outside help is easiest to measure. The scope should list the checks that prove the setup works: UI login through the ALB, CLI login and sync over the gRPC path, admin access disabled once SSO is working, and a documented rollback if a listener rule breaks. Your own team keeps ownership of the AWS account, the identity provider and the change process after handover. Ask for the verification steps and the handover documents in the written scope, not as an afterthought.
How DeployOpen scopes and supports Argo CD exposure on AWS
DeployOpen plans and builds the ALB, listener, target group and Argo CD service layout inside your own AWS accounts and clusters. We start from your routing, TLS and access requirements, then document and hand over what was built so your team can operate it.
How we scope
- Confirm which hostnames serve the web UI and the gRPC CLI, and who needs each one.
- Record where TLS ends, which certificates are used and how they are renewed.
- Agree in writing whether an ALB, classic ELB or NLB fits your network and audit needs.
How we build
- Configure the separate gRPC-protocol service and conditional routing so CLI traffic reaches Argo CD.
- Set server.insecure only where TLS terminates at the load balancer, and verify the backend path.
- Test login, CLI sync and health checks through the load balancer before cutover.
How we hand over
- Deliver the routing diagram, listener and target group settings and the values used in the install.
- Document the TLS termination point, certificate renewal steps and rollback procedure.
- Walk your platform team through failure checks, including health check failures and CLI connection errors.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Ask for a quote based on the written scope, which covers your AWS accounts, clusters and hostnames.
