In today’s digital world, ensuring high availability and disaster recovery (DR) is paramount for businesses running mission-critical applications. AWS provides robust tools like Amazon Elastic Kubernetes Service (EKS) and Route 53, enabling organizations to implement automatic failover strategies to enhance disaster recovery. This post will walk you through setting up EKS clusters in multiple regions and using Route 53 to manage traffic and failover between these clusters.

Introduction to AWS EKS and Route 53

Amazon Elastic Kubernetes Service (EKS) is a managed service that makes it easy to run Kubernetes on AWS without installing and operating your own Kubernetes control plane. EKS provides the scalability, security, and reliability needed for running containerized applications.

Amazon Route 53 is a scalable DNS and traffic routing service. It can route end-user traffic to application endpoints based on various routing policies, including latency-based routing, failover routing, and more. Combining EKS with Route 53 allows businesses to achieve automatic failover between clusters, ensuring minimal downtime during regional outages.

Setting Up EKS Clusters in Different Regions

To ensure disaster recovery, you must deploy your EKS clusters across two regions—one acting as the primary and the other as the disaster recovery (DR) region. Below are the general steps to establish EKS clusters in two areas:

  1. Launch the Primary EKS Cluster: Use the AWS Management Console, AWS CLI, or a tool like eksctl to create an EKS cluster in the primary region (e.g., us-east-1)—Configure node groups and set up necessary VPC and security groups.
  2. Create the DR EKS Cluster: Repeat the steps for the primary region in a secondary region (e.g., us-west-2). Ensure the same configuration for node groups, VPC, and security to maintain cluster consistency.
  3. Configure Networking and Peering: If needed, establish VPC peering between the two regions for any shared resources. Additionally, ensure that security group rules and IAM roles are consistent across clusters.

Deploying a Sample Application on EKS

Once the EKS clusters are set up, the next step is to deploy a sample application to both clusters. For simplicity, let’s deploy the 2048 game on both clusters:

  1. Clone the 2048 Game Repo: You can clone a public 2048 game repository from GitHub or create a custom Docker image for deployment.
  2. Deploy to Primary EKS Cluster: Using kubectl or Helm, deploy the 2048 game to the primary EKS cluster. Ensure the application is up and running.
    kubectl apply -f 2048-deployment.yaml
  3. Deploy to DR EKS Cluster: Repeat the deployment process in the DR EKS cluster using the same Kubernetes manifests to ensure the application runs identically in both regions.

Routing Traffic with Route 53

After successfully deploying the application in both clusters, it’s time to set up Route 53 to manage traffic routing to the primary EKS cluster:

  1. Create a Hosted Zone: In Route 53, create a hosted zone for your domain or subdomain.
  2. Configure Route 53 Record Sets: Create DNS record sets pointing to the Elastic Load Balancers (ELBs) associated with your EKS clusters. For now, the primary region’s ELB will handle the incoming traffic.
  3. Latency-Based Routing: You can optionally configure latency-based routing in Route 53 to route users to the region closest to them. However, for this disaster recovery use case, failover routing is preferred.

Enabling Failover Mechanism with Route 53

To handle failover between the primary and DR regions, follow these steps:

  1. Primary Record Configuration: Set up a Route 53 record with a failover routing policy for the primary EKS cluster. This record will handle traffic under normal operations.
  2. Secondary (Failover) Record Configuration: Create a secondary failover routing policy record pointing to the DR region’s ELB. This record should be configured as the failover target.
  3. Health Checks: Attach health checks to the primary ELB. If Route 53 detects that the primary region is down (e.g., if the ELB becomes unhealthy), traffic will automatically be redirected to the DR region.

Testing and Verifying Failover Functionality

To ensure that your failover mechanism works correctly, simulate an outage in the primary region and verify that traffic is rerouted to the DR region:

  1. Simulate Outage: Disable the ELB or stop instances in the primary EKS cluster to simulate an outage.
  2. Monitor Route 53: Route 53 will detect the failure through health checks and automatically reroute traffic to the DR region.
  3. Verify Failover: Access the application using the domain name or IP address and confirm that it is now served from the DR region. You can use the dig or nslookup command to check DNS propagation and verify that the traffic is directed to the DR region’s ELB.
  4. Restore Primary Region: Once the issue in the primary region is resolved, restore traffic routing to the primary EKS cluster by ensuring that health checks for the primary region pass.

Conclusion

Implementing automatic failover for your EKS clusters using Route 53 significantly enhances disaster recovery capabilities and ensures application uptime during outages. You can build a resilient and fault-tolerant infrastructure by setting up EKS clusters in multiple regions, deploying applications across both clusters, and configuring Route 53 for failover.

References

GitOps-driven, multi-region deployment and failover using EKS and Route 53 Application Recovery Controller

Active-active and active-passive failover