Context & Pain Points
Election management workloads carry a jurisdiction boundary that is legal, not just architectural: a tenant's data has to stay in its own region, and one tenant must never be able to read another's records even by accident. The obvious answer, a dedicated EKS cluster per tenant, multiplies control planes, upgrade windows, node groups and monitoring stacks by the tenant count, and every one of those becomes a thing an operator can configure differently under time pressure. The second constraint pulls the opposite way. Jurisdictions run their own schedules, so capacity has to follow a workload profile that changes per tenant, and a platform sized for the busiest tenant sits idle most of the year.
What We Had To Solve
- Achieving hard multi-tenant isolation for different jurisdictions within shared EKS clusters without creating per-tenant cluster sprawl.
- Designing cross-region EKS architectures with consistent GitOps workflows and unified policy enforcement, so a region is a parameter rather than a second codebase.
- Dynamically provisioning and right-sizing node groups per tenant using cost-efficient Spot capacity, on workloads whose busy periods do not line up.
- Managing per-tenant networking, ingress routing, and RBAC controls at scale without manual configuration drift.
- Keeping each jurisdiction's data resident in its own region while still offering a documented cross-region recovery path.
How We Built It
- Implemented native Kubernetes Namespace isolation per tenant within shared EKS clusters, eliminating sprawl while enforcing strict security boundaries with Calico network policy and OPA Gatekeeper admission rules.
- Provisioned multi-region EKS infrastructure using Terraform and Terragrunt with region-parameterized, DRY module hierarchies, so a new region is a set of inputs rather than a fork of the modules.
- Deployed ArgoCD at the management cluster level with ApplicationSets to declaratively sync per-tenant workloads across all regions, which makes the Git history the record of what is running.
- Configured Karpenter with tenant-aware NodePools and Spot interruption handling to dynamically right-size compute per workload profile, so an idle jurisdiction stops paying for a busy one's headroom.
- Ran Aurora Global Database with asynchronous cross-region replication behind each region's isolated data subnet, keeping reads local to the jurisdiction and the recovery path documented.
- Kept observability regional, with Prometheus, Grafana and Loki deployed alongside the workloads in each region rather than shipping every metric and log to one place.
Outcomes That Mattered
70% Operational Reduction
Eliminated per-tenant cluster sprawl by managing all tenants through a single EKS control plane per region, so upgrades and node maintenance happen once instead of per tenant.
Zero Tenant Leakage
Achieved strict network-enforced tenant isolation using native Kubernetes Namespaces and IAM Roles for Service Accounts (IRSA), so a pod's AWS permissions stop at its own namespace.
99.99% Uptime
Maintained continuous availability across all tenant workloads via multi-region load distribution behind Route 53 and CloudFront.
100% GitOps
All tenant workload deployments fully automated through ArgoCD ApplicationSets, with zero manual interventions and no cluster change that is not in Git.
Outcome
The platform runs full stacks in two AWS regions, us-east-1 on VPC 10.0.0.0/16 and ca-central-1 on 10.1.0.0/16, each with its own public, private and isolated subnet tiers rather than a shared data or security layer. Tenants are Kubernetes Namespaces inside a shared EKS cluster per region, with Calico network policy and OPA Gatekeeper enforcing the boundary and IRSA scoping AWS permissions per service account. Aurora Global Database replicates asynchronously between regions, so a jurisdiction reads locally while a regional failure still has somewhere to go. ArgoCD ApplicationSets sync every tenant workload, Karpenter provisions Spot-backed nodes per tenant NodePool, and Prometheus, Grafana and Loki run in each region alongside the workloads they watch. Operational overhead dropped 70% and tenant workloads held 99.99% uptime.