One EKS control plane, many tenants, several regions

An election management platform serves jurisdictions that each require their data to stay inside a particular geography and each expect to be unaffected by anyone else's load. The obvious answer is a cluster per jurisdiction. That answer costs a fortune and nobody can patch it.

The decision that shaped everything

One EKS cluster per region, tenants isolated by namespace. This is only defensible if the isolation is enforced by the platform rather than by convention, so three things had to be true before anything else was built:

• Network policy denies cross-namespace traffic by default, with Calico enforcing it, so a tenant cannot reach another tenant's service even by IP
• IRSA gives every workload its own IAM role, so no pod inherits node permissions and no pod can read another tenant's S3 prefix
• OPA Gatekeeper rejects anything that tries to escape: host networking, privileged containers, missing resource limits, workloads without a tenant label

Those three together are what makes namespaces sufficient. Any one of them missing and the argument collapses.

Regions

Regional placement is a legal requirement, not a latency optimisation. A tenant's workloads run in the region its jurisdiction names, and the deployment pipeline is identical across all of them. Route 53 sends each tenant's hostname to its own regional load balancer; there is no cross-region failover for data-resident tenants, because failing over would be the violation.

Deployment

A management cluster runs ArgoCD. ApplicationSets generate one application per tenant per region from a Git repository, so onboarding a jurisdiction is a pull request that adds a directory.

• Tenant configuration in Git, reviewed like code
• No kubectl access to production clusters for humans in the normal path
• Drift is corrected automatically, which means the cluster state and the repository do not diverge quietly

Nodes

Karpenter provisions nodes to fit pending pods rather than to fill a fixed node group, with Spot capacity for the workloads that tolerate interruption. Election workloads are extremely peaky. Quiet for months, then enormous for a week. Fixed capacity sized for that peak is idle most of the year.

Infrastructure code

Terraform with Terragrunt for the region and cluster layer. Terragrunt is doing real work here: the same module gets applied to every region with a small per-region input file, so a change lands everywhere or nowhere rather than in whichever region someone remembered.

Where it landed

• About 70% less operational overhead than the cluster-per-tenant design it replaced, measured in clusters to patch and control planes to pay for
• 99.99% uptime across the platform
• No cross-tenant data access in any test or audit to date
• Every deployment through GitOps, with no manual production changes

What was hard

Gatekeeper policies. Written too loose they prove nothing, written too tight they block legitimate work and teams route around them. Getting to a set that engineers accept took several iterations and a lot of conversations about specific rejected manifests.

What we still do

Cluster upgrades, policy maintenance, tenant onboarding review, and the on-call rotation across regions.