Cross-Cluster Object Replication (HA) Architecture Guide
Reference Environment: EKS 1.32+, ArgoCD 2.13+, Flux v2.4+, Velero 1.15+
1. Overview
A service that depends on one EKS cluster can become unavailable if that cluster fails. Cross-Cluster Object Replication keeps Kubernetes objects—such as ConfigMaps, Secrets, RBAC resources, CRDs, and NetworkPolicies—consistent across clusters so another cluster has the required configuration. Service availability also depends on data replication, traffic failover, and application recovery; object replication alone does not provide it.
Current State
EKS does not provide managed Cross-Cluster Object Replication. Therefore, you must implement it yourself by combining open-source tools and architecture patterns. This guide compares the pros and cons of each pattern and provides selection criteria based on workload types.
Scope of This Guide
Table 1. What this guide covers and does not cover
| Included | Not Included |
|---|---|
| K8s object replication (ConfigMap, Secret, CRD, RBAC, etc.) | Application data replication (DB replicas) |
| GitOps-based declarative synchronization | Service mesh-based traffic routing |
| Stateful object backup/restore (Velero) | Storage layer replication (EBS, EFS) |
| DNS failover strategies | Application-level HA patterns |
2. Multi-Cluster Architecture Pattern Comparison
There are three core patterns for implementing Cross-Cluster Object Replication.
Pattern 1: API Proxy (Push Model)
A central routing layer directly proxies CRUD requests to each cluster's API Server.
Figure 1. Request flow of the API Proxy (Push model)
- How it works: Direct API calls from a central point to each cluster
- Pros: Lightweight and intuitive
- Cons: Credential security vulnerabilities, no multi-cluster Watch support, increasing connection complexity
Pattern 2: Multi-cluster Controller (Kubefed-style)
A central controller monitors each cluster's state via Informer-based List-Watch and synchronizes through CRDs.
Figure 2. List-Watch synchronization structure of the Multi-cluster Controller
- How it works: Central controller monitors and synchronizes each cluster's state
- Pros: Dynamic cluster discovery, federation policies
- Cons: Watch event overflow at ~10+ clusters, Informer cache size limits, plaintext credential storage risk
Kubefed (v2) is effectively in maintenance mode by the Kubernetes SIG. It is not recommended for new projects.
Pattern 3: Agent-based Pull Model (Recommended)
Agents in each cluster pull the desired state from a central source (Git or hub cluster) and reconcile locally. This follows the same principle as kubelet receiving Pod specs and running them locally.
Figure 3. Reconcile flow of the Agent-based Pull model
- How it works: Each cluster agent independently pulls the desired state and reconciles locally
- Pros: High scalability, eventual consistency, local operation continues even during central failures
- Cons: Requires agent deployment on all clusters
Pattern Comparison Summary
Table 2. Operation, scalability, and security comparison of the three replication patterns
| Aspect | API Proxy | Multi-cluster Controller | Agent-based Pull |
|---|---|---|---|
| Operation | Central → Cluster Push | Central Watch + CRD Sync | Cluster → Central Pull |
| Scalability | Low (proportional to connections) | Medium (~10 clusters) | High (hundreds of clusters) |
| Complexity | Low | High | Medium |
| Security | Weak (many credentials) | Weak (plaintext storage) | Strong (agent local permissions) |
| Fault Isolation | Low | Medium | High |
| Drift Detection | None | Partial | Built-in |
| Recommended For | PoC, small scale | Legacy environments | Production (recommended) |
Decision Flowchart
Figure 4. Pattern selection flow by cluster count and requirements
3. Recommended Approach Architectures
Option A: GitOps (Flux / ArgoCD) — Recommended for Most Use Cases
Uses a Git repository as the Single Source of Truth, with GitOps agents in each cluster independently pulling and reconciling.
Figure 5. GitOps-based Single Source of Truth replication structure
Key Benefits:
- Drift Detection: Automatically detects and recovers when cluster state differs from Git
- Audit Trail: All change history is recorded as Git commits
- Declarative Management: Define the desired state and let agents reconcile
- Fault Isolation: An agent failure in one cluster does not affect others
Active-Active Configuration:
Both clusters independently pull from the same Git repo. DNS (Route 53) distributes traffic, and if one cluster fails, the remaining cluster immediately handles all traffic.
Active-Passive Configuration:
Only the Active cluster has its GitOps agent enabled. The Passive cluster keeps its agent in Suspended state, activating it during failover.
Option B: ArgoCD Hub-and-Spoke Model
Install ArgoCD on a Management Cluster and deploy to multiple workload clusters via ApplicationSets.
Figure 6. ArgoCD Hub-and-Spoke deployment structure
HA Strategies:
Table 3. HA strategy comparison for Hub-and-Spoke
| Strategy | Description | Suitable Scenario |
|---|---|---|
| Active-Passive Mirroring | Deploy ArgoCD in two regions; Passive keeps controllers disabled. Manual Scale-Up during failover | Environments with low DR requirements |
| Active-Active Sync Windows | Two ArgoCD instances sync during non-overlapping time windows (Sync Windows feature) | Active-Active requiring conflict prevention |
Using ArgoCD ApplicationSets' Cluster Generator, applications can be automatically deployed to all clusters registered with ArgoCD. When a new cluster is added, replication starts immediately without additional configuration.
Option C: Custom Controller (MirrorController Pattern)
When fine-grained control over object replication is needed, develop a dedicated controller to manage synchronization between source and target clusters.
Use Cases:
- Selective replication of only objects with specific Labels/Annotations
- Object transformation during replication (e.g., Namespace changes, field modifications)
- Custom conflict resolution logic
Pros and Cons:
Table 4. Pros and cons of the Custom Controller approach
| Pros | Cons |
|---|---|
| Clear separation of concerns | Additional operational overhead |
| Reduced core logic complexity | Potential synchronization delays |
| Fine-grained replication policy control | Increased debugging complexity |
| Custom conflict resolution | Requires in-house development/maintenance |
4. Active-Active vs Active-Passive Decision
Comparison Table
Table 5. Comparison of Active-Active and Active-Passive configurations by aspect
| Aspect | Active-Active | Active-Passive |
|---|---|---|
| Object Sync | Both clusters independently pull from same Git source | Only Active reconciles; Passive stands by |
| Failover Time | Near-zero (both already serving) | Minutes (Passive activation required) |
| Conflict Resolution | Write conflicts possible — prevention via Sync Windows needed | No conflicts — single writer |
| Operational Complexity | High (object IDs, DNS, state synchronization) | Low (standard failover model) |
| Cost | High (full capacity on both sides) | Low (Passive can run at reduced capacity) |
| Suitable Scenario | Multi-region HA, global load balancing | DR, cost-sensitive HA |
Recommended Mode by Workload Type
Figure 7. Recommended Active-Active/Active-Passive mode by workload type
5. Supporting Tool Stack
Object replication alone cannot achieve complete Cross-Cluster HA. Combine the following tools to build the full stack.
Table 6. Supporting tools and roles that make up the Cross-Cluster HA stack
| Tool | Role | Notes |
|---|---|---|
| Flux / ArgoCD | K8s object replication (GitOps) | Core replication mechanism |
| Route 53 | DNS-based failover/load balancing | Health Check + Failover Routing |
| Global Accelerator | Anycast IP-based global routing | For multi-region Active-Active |
| Velero | Stateful object backup/restore (PV, etcd) | Combined with S3 Cross-Region Replication |
| External Secrets Operator | Secret synchronization | AWS Secrets Manager → both clusters |
| Crossplane / ACK | AWS resource definition sync | Manage IaC as K8s objects |
Tool Combination Architecture
Figure 8. Full stack structure combining GitOps, Velero, and Route 53
6. Current Limitations and Future Outlook
There are features in the EKS multi-cluster management space that are not yet available as managed services.
Table 7. Features not yet available as managed services, and their alternatives
| Area | Current State | Alternative |
|---|---|---|
| Managed ClusterSets | Not released | RAM (Resource Access Manager) for Cross-Account grouping |
| Built-in Cross-Cluster Replication | Not released | GitOps (Flux/ArgoCD) |
| Multi-Region EKS Cluster | Not released | Independent clusters per region + GitOps sync |
| Managed ArgoCD | In development | Self-managed ArgoCD installation |
Until these features are released, the GitOps + supporting tool stack combination is the most mature and proven approach. Already about 10% of EKS customers have adopted GitOps based on Flux/ArgoCD.
7. Recommended Production Combinations
Final recommended tool combinations for eliminating single-cluster dependency.
Table 8. Final recommended tools and configurations by purpose
| Purpose | Recommended Tool | Configuration |
|---|---|---|
| K8s Object Replication | GitOps (Flux or ArgoCD) | Both clusters pull from the same Git repo |
| Stateful Data Protection | Velero + S3 Cross-Region Replication | Scheduled backup + cross-region replication |
| Secret Synchronization | External Secrets Operator | AWS Secrets Manager as shared source |
| DNS Failover | Route 53 Health Checks | Active-Active or Failover Routing |
| CRD/Custom Resources | Include in GitOps repo | Managed identically to standard K8s objects |
| AWS Resource Definitions | Crossplane or ACK | Sync IaC natively in K8s |
Implementation Priority
- P0: Deploy GitOps agents + design Git repo structure
- P1: Configure External Secrets Operator + Route 53 Health Checks
- P2: Establish Velero backup policies + S3 Cross-Region Replication
- P3: AWS resource sync with Crossplane/ACK (as needed)
8. Related Documents
- EKS High Availability Architecture Guide — Failure Domain response strategies by layer
- GitOps-based Cluster Operations — Flux/ArgoCD operations guide
9. References
- ArgoCD ApplicationSets — Multi-cluster automatic deployment
- ArgoCD Sync Windows — Active-Active conflict prevention
- Flux Multi-Tenancy — Multi-cluster repo structure
- Velero Documentation — Cluster backup/restore
- External Secrets Operator — External secret synchronization
- Crossplane — K8s native IaC
- AWS Route 53 Health Checks — DNS failover