Multi-Region EKS for a Global HR Platform

The problem

An AI-native HR operating system was growing its customer base across continents. A single-region AWS setup had worked during the early phase, but it could not hold. HR data is sensitive - customers in Europe, Asia, and North America had legitimate expectations that their employee data would stay in their region, and latency to a distant cluster was already becoming a friction point in sales conversations.

Beyond data residency and latency, there was an operational consistency problem. Without a deliberate multi-region design, each regional deployment becomes a one-off: different configs, different runbooks, different failure modes. The platform sat on a trusted enterprise SaaS foundation - it had to be operated with the same rigour in every region, not improvised.

What we built

The solution is a repeating regional unit - the same cluster topology, the same service stack, the same Terraform module - deployed into each AWS region where customers need to be. Adding a new region is not a project; it is applying the same pattern to a new target.

Multi-region EKS topology. Each region runs one or more Amazon EKS clusters. Each cluster lives in its own dedicated VPC with non-overlapping CIDR ranges, sized so all VPCs remain VPN-routable if the company needs centralised access in future. Clusters are independent - a failure in one region does not cascade.

Multi-region EKS topology: independent region-local clusters across AWS regions

Per-region service stack. Every region runs the same set of services:

Amazon RDS (PostgreSQL) - managed relational database, Multi-AZ for availability. HR data stays in region.
Apache Kafka - in-cluster event backbone for async workflows and HR process orchestration.
Redis - in-cluster caching layer for session data and frequently accessed HR records.
Amazon Bedrock - AI capability layer powering the AI-native features of the HR product, accessed per-region.

Per-region service stack: EKS clusters with RDS, Kafka, Redis and Amazon Bedrock inside dedicated VPCs

Networking and access. Each VPC has its own bastion host for operator access, supporting SSH, SSM Session Manager, and EC2 Instance Connect. AWS-GitHub OIDC handles CI/CD pipeline authentication - no long-lived credentials in GitHub secrets. Terraform remote state is stored in S3 per region with state locking.

Consistent deployment model. The entire regional stack is a Terraform module, parameterised by region and cluster size. Deploying to a new region is terraform apply with a new tfvars file. The same Helm charts deploy the application layer to every cluster via Argo CD with app-of-apps, so rollouts are consistent and auditable across regions.

Key outcomes

Region-local by default. Every customer's workloads and data run in the nearest AWS region. Data residency requirements are met at the topology level, not patched in after the fact.
Each cluster in its own VPC. Non-overlapping CIDRs across all VPCs keep routing clean and the fleet VPN-ready for centralised access when needed.
Consistent everywhere. The same Terraform module, Helm charts, and Argo CD app-of-apps deploy to every region. A new region is a config change, not a build.
Independent by design. Clusters are not interconnected. A regional failure stays regional - no blast radius across the fleet.
Secure access without static credentials. Every VPC bastion supports SSH, SSM Session Manager, and EC2 Instance Connect. AWS-GitHub OIDC handles CI/CD with no long-lived secrets.
AI capabilities where needed. Amazon Bedrock integrates per-region, keeping AI feature calls close to the data they operate on.