GitOps Across Multiple Clouds with ArgoCD

By Khimananda Oli | Last reviewed: August 2026

Managing Kubernetes deployments across AWS EKS, Azure AKS, and Google GKE simultaneously creates massive operational drift without a unified control plane. GitOps Across Multiple Clouds with ArgoCD solves this by establishing a single declarative source of truth that synchronizes state across heterogeneous environments automatically. This guide details the hub-spoke architecture, secure external cluster registration, and ApplicationSet patterns required to operate production-grade multi-cloud infrastructure reliably.

How do you architect GitOps Across Multiple Clouds with ArgoCD?

The only scalable pattern for multi-cloud GitOps is the hub-spoke model. Running independent ArgoCD instances per cloud duplicates effort, fragments observability, and makes cross-cloud policy enforcement nearly impossible. In practice, you deploy a dedicated management cluster—often on your lowest-cost provider or on-premise—that hosts the ArgoCD control plane. This hub never runs business workloads; it exists solely to reconcile Git state against remote clusters.

A common mistake teams make when adopting GitOps with ArgoCD is trying to manage everything through a single kubeconfig file. This approach fails at scale because kubeconfigs contain embedded credentials that expire and cannot be audited properly. Instead, register external clusters using ArgoCD’s native service account mechanism or the newer agent-based registration for private networks. The hub stores only a minimal bearer token scoped to ArgoCD’s namespace, reducing the blast radius if credentials leak.

Your Git repository structure must also evolve. Monolithic repos with hardcoded cloud-specific values break immediately when adding a second provider. Adopt a layered configuration strategy using Kustomize overlays or Helm value files per environment and cloud. A typical production structure separates base manifests from cloud-specific patches:

infra/
├── base/
│   ├── deployment.yaml
│   └── service.yaml
├── overlays/
│   ├── aws-prod/
│   │   ├── kustomization.yaml
│   │   └── patch-storage.yaml
│   ├── azure-prod/
│   │   ├── kustomization.yaml
│   │   └── patch-ingress.yaml
│   └── gke-staging/
│       ├── kustomization.yaml
│       └── patch-resources.yaml

This separation ensures that core application logic remains cloud-agnostic while infrastructure-specific configurations like storage classes, ingress controllers, and resource limits stay isolated. When implementing GitOps Across Multiple Clouds with ArgoCD, this modularity prevents accidental cross-contamination between providers during synchronization.

How do you securely register external clusters in ArgoCD?

Security is the primary constraint in multi-cloud GitOps. Never store full admin kubeconfigs in ArgoCD secrets. Use the CLI to generate least-privilege service accounts automatically:

# Register an AWS EKS cluster from the hub
argocd cluster add arn:aws:eks:us-east-1:123456789:cluster/prod-eks \
  --name aws-prod \
  --kube-context aws-prod-context

# Register an Azure AKS cluster
argocd cluster add /subscriptions/sub-id/resourceGroups/rg/providers/Microsoft.ContainerService/managedClusters/prod-aks \
  --name azure-prod \
  --kube-context azure-prod-context

This command creates a ServiceAccount, ClusterRole, and ClusterRoleBinding on the target cluster with permissions restricted to what ArgoCD actually needs: get/list/watch on most resources, plus create/update/patch/delete only on managed namespaces. For SOC 2 or ISO 27001 compliance, audit these RBAC bindings quarterly. If you require stricter isolation, consider namespace-scoped roles instead of cluster-wide access, though this limits ArgoCD’s ability to manage cluster-scoped resources like CRDs or PersistentVolumes.

For clusters behind firewalls or in air-gapped VPCs where the hub cannot reach the Kubernetes API directly, use the ArgoCD Cluster Agent. The agent runs inside the target cluster and initiates an outbound WebSocket connection to the hub, eliminating inbound firewall rules entirely. This is especially relevant for Nepal-based organizations operating hybrid infrastructure where on-premise data centers coexist with public cloud tenants. The agent maintains a persistent tunnel, and all sync operations flow through this encrypted channel without exposing internal endpoints.

Handling authentication expiry and rotation

Cloud provider tokens expire. AWS IAM authenticator tokens last 15 minutes; Azure AD tokens vary by policy. ArgoCD handles refresh automatically when configured with proper cloud provider integrations, but verify your setup:

• AWS EKS: Ensure the hub’s node role or IRSA has eks:DescribeCluster permissions. ArgoCD calls the EKS API to generate fresh tokens before each sync.
• Azure AKS: Use workload identity federation or managed identity. Avoid service principal secrets that require manual rotation.
• GKE: Configure Workload Identity on the hub cluster to impersonate a GCP service account with container.clusters.get permissions.

If syncs fail intermittently with 401 errors, check token refresh logs first. A frequent oversight is granting initial access but forgetting renewal permissions. Review our Kubernetes secrets management guide for patterns on handling dynamic credentials safely.

How do ApplicationSets automate multi-cloud deployments?

Manually creating one Application resource per cluster defeats the purpose of GitOps. ApplicationSets generate Applications dynamically based on metadata, making GitOps Across Multiple Clouds with ArgoCD truly scalable. Define clusters as generators, and ArgoCD creates matching Applications automatically when new clusters are registered.

Here is a practical ClusterGenerator example that targets all registered clusters with a specific label:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-cloud-api
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'api-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/org/platform.git
        targetRevision: main
        path: overlays/{{metadata.labels.cloud}}-prod
      destination:
        server: '{{server}}'
        namespace: api
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

This single manifest replaces dozens of individual Application definitions. When you register a new production cluster labeled env: production, ArgoCD automatically creates a corresponding Application. Combine this with the Kustomize templating approach to inject cloud-specific variables without duplicating YAML. For more advanced scenarios, merge multiple generators (Git directories + clusters) to deploy different apps to different subsets of infrastructure.

How does ArgoCD compare to other multi-cloud GitOps tools?

Choosing the right tool matters for long-term maintainability. While Flux CD is a strong alternative, ArgoCD’s UI and ApplicationSet maturity give it an edge for teams managing three or more clouds. Below is a functional comparison based on 2026 stable releases:

ArgoCD wins for GitOps Across Multiple Clouds with ArgoCD primarily because of its visualization layer. When debugging why a deployment succeeded in AWS but failed in Azure, seeing both states side-by-side in the UI saves hours of log diving. Flux excels in high-security environments where any web interface is prohibited, but for most engineering teams, ArgoCD’s balance of automation and observability is optimal. See our detailed FluxCD vs ArgoCD comparison for nuanced trade-offs.

What are common pitfalls in multi-cloud ArgoCD setups?

Even experienced teams stumble on these issues when scaling beyond two clouds:

1. Ignoring cloud-specific API rate limits: ArgoCD polls every 3 minutes by default. With 20+ clusters, you may hit AWS EKS DescribeCluster or Azure ARM throttling. Increase timeout.reconciliation and enable caching aggressively.
2. Drift caused by cloud controllers: AWS Load Balancer Controller and Azure Disk CSI modify resources after ArgoCD applies them. Add ignoreDifferences rules for annotations and status fields these controllers manage, or ArgoCD will perpetually fight them.
3. Secret sprawl across clouds: Never replicate secrets manually. Use External Secrets Operator or Sealed Secrets with cloud-native backends (AWS Secrets Manager, Azure Key Vault). Each cluster fetches its own secrets at runtime; Git stores only references.
4. Over-permissioned service accounts: Granting cluster-admin to ArgoCD simplifies setup but violates least privilege. Audit RBAC bindings regularly. Use namespace-scoped roles where possible.
5. Missing health checks for cloud resources: ArgoCD considers a Deployment healthy when pods are ready, but underlying cloud resources (RDS instances, S3 buckets) may still be provisioning. Write custom Lua health scripts that query cloud APIs or check operator status conditions.

Addressing these early prevents painful rework later. Monitor sync durations and error rates using Prometheus metrics exported by ArgoCD itself. Set alerts on argocd_app_sync_total{phase="Failed"} grouped by cluster to catch provider-specific issues before they cascade. Understanding the four golden signals helps prioritize which sync failures actually impact users versus cosmetic drift.

Implementing GitOps Across Multiple Clouds with ArgoCD

Start small: pick one non-critical workload and deploy it across two clouds using the hub-spoke pattern above. Validate authentication, sync behavior, and rollback procedures before expanding. Document cloud-specific quirks in your Git repo’s README—future engineers will thank you. Once stable, adopt ApplicationSets to eliminate manual Application creation and enforce consistent policies.

Remember that GitOps is a discipline, not just a tool. Your Git repository must remain the authoritative source; manual kubectl apply commands undermine the entire system. Enforce this culturally and technically through RBAC restrictions and automated drift detection. If your team struggles with adoption, revisit fundamentals in our ArgoCD GitOps for Kubernetes primer before scaling further.

Ready to design a compliant, auditable multi-cloud GitOps pipeline tailored to your infrastructure? Contact me to discuss architecture reviews, security hardening, or migration planning for your AWS, Azure, and GKE environments.