Intelligent failover using AWS Lambda@Edge and Amazon DynamoDB

Modern applications increasingly require seamless user experiences and high availability, especially in scenarios where regional disruptions or outages could impact critical workloads. Businesses frequently face challenges when dynamically allocating users to specific endpoints or regions while providing persistent user-endpoint relationships and implementing robust failover mechanisms.

To address these complex scenarios, this post describes a solution that uses Amazon Web Services (AWS) Lambda@Edge and Amazon DynamoDB to offer a serverless solution for routing and managing user traffic across AWS endpoints, whether they’re cells in a cell-based architecture or different AWS Regions. The solution runs custom logic at Regional edge locations to dynamically assign users to specific Regions using session ID, or any kind of custom ID, while storing endpoint configurations in DynamoDB. This approach facilitates low-latency routing, consistent user experiences, and swift failover mechanisms to alternate endpoints during outages. This architecture is specifically designed to support business-critical workloads in industries such as e-commerce, financial services, and healthcare. Furthermore, it prioritizes resilience, scalability, and operational clarity, thus providing a robust foundation for applications that demand high availability and minimal downtime.

Protection and performance of applications at the edge

Business can use AWS compute at the edge to build highly secure, performant, and resilient applications. These require robust protection, performance, and routing capabilities to prevent source overload and enable multi-endpoint deployment.

At the forefront of the AWS edge protection strategy is Amazon CloudFront, a global content delivery network (CDN) that securely delivers data, videos, applications, and APIs to viewers worldwide. CloudFront integrates seamlessly with other AWS security services to create a robust defense mechanism against various threats.

Lambda@Edge is a feature of CloudFront and is custom-built to run lightweight Lambda functions to run at AWS Regional Edge Cache locations in response to CloudFront events. These functions can modify requests and responses, generate dynamic content, and perform various optimizations. CloudFront automatically distributes and runs these functions globally across 13 different locations, enhancing content delivery with low latency and improved user experience.

Resiliency considerations in Lambda@Edge and DynamoDB

Both Lambda@Edge and Amazon DynamoDB are designed and built to be resilient, serverless services within AWS.

Although Lambda@Edge offers serverless execution of code as any AWS Lambda function, its post-deployment set up is configured through CloudFront. Lambda@Edge functions have a timeout that matches the response and keep-alive timeouts of the CloudFront distribution. Moreover, these functions must be deployed from the US-East-1 (Northern Virginia) Region, currently only support NodeJS and Python runtimes, and have an execution soft limit of 10k simultaneous executions per Regional Edge Cache.

When a request is made to an endpoint served by CloudFront, the request is received at the nearest Point of Presence (POP) to the user’s physical location. If the requested Uniform Resource Identifier (URI) is configured for Lambda@Edge, then CloudFront forwards the request to the corresponding Regional Edge Cache for execution. In the event that the infrastructure at the initial Regional Edge Cache is impaired and unable to run the Lambda@Edge function, the request is seamlessly redirected to an alternative Regional Edge Cache that isn’t experiencing issues. This inherent resiliency is particularly well-suited for applications with stringent latency and routing requirements, providing optimal performance and reliability.

DynamoDB is a proprietary, serverless, NoSQL key-value store created and extensively adopted by AWS. DynamoDB automatically replicates each data partition across a minimum of three distinct Availability Zones (AZs) within a single Region. This inherent architecture provides high availability and fault tolerance. Furthermore, it’s also designed for single-digit millisecond data retrieval at any scale when properly partitioned.

The DynamoDB Global Tables feature enhances resilience by enabling data to be read and written across multiple AWS Regions. This makes it ideal for replicating user data or session IDs that can be accessed from Regional Edge Caches where Lambda@Edge functions execute. The integration of Lambda@Edge with DynamoDB creates a robust solution for intelligent failover and enhanced resilience in distributed applications. This combination enables real-time decision-making and traffic routing at the Regional edge closest to users, which significantly reduces latency while ensuring minimal disruption during Regional outages. When paired with the DynamoDB Global Tables storing routing configurations and state information across AWS Regions, Lambda@Edge can make informed decisions about traffic direction based on endpoint health and user data. This setup optimizes both application performance and reliability through intelligent, geographically distributed processing.

If a primary Region becomes impaired, then Lambda@Edge functions can quickly query DynamoDB to find the next best endpoint and reroute user requests accordingly. This seamless switch provides continuous availability and performance, maintaining a consistent and reliable user experience. The dynamic nature of Lambda@Edge means that these decisions can be made in milliseconds. Moreover, both the decision logic and data are distributed globally so that the system can respond instantaneously to changes in Regional health.

This architecture not only boosts application uptime but also streamlines the complexity typically associated with multi-Regional failover strategies. Developers can manage their routing logic centrally within the Lambda@Edge functions and rely on the DynamoDB built-in replication to handle data synchronization across AWS Regions. This setup eliminates the need for custom synchronization scripts or complex failover mechanisms, reducing operational overhead and increasing the reliability of the system.

Solution

Efficiently managing web/API traffic across multiple Regions or endpoints, while maintaining session affinity, is crucial for global businesses and critical applications. This solution represents a serverless approach that addresses this challenge while offering flexibility and capability in handling traffic routing and balancing. Moreover, this solution uses 13 different Regional Edge Caches across 13 AWS Regions to run code exclusively on origin requests and responses. This only occurs when CloudFront must fetch content from the original application endpoint rather than serving already-cached assets such as CSS, HTML, or images.

The process begins when a user’s request is routed to CloudFront. CloudFront has 600+ POPs and can serve static or dynamic content from any of those locations. The configurations to route requests to Lambda@Edge should only be made for specific URI paths and/or only for requests that require user data specific to the user making the request. Static content such as images, CSS or JavaScript files or dynamic requests that don’t require user authentication or session information don’t need to flow through this custom solution.

The following steps show the request flow:

1. A request comes in and the URI is configured for Lambda@Edge
2. Check for session ID and AWS Region/endpoint selection cookies—Lambda@Edge Origin Request Function
   • If present, then forward the request to the correct Region/endpoint.
   • If not present, then send user to a random Region/endpoint (routing strategy can be customized).
3. Get the response from the origin and check cookies—Lambda@Edge Origin Response function
   • If present, then do nothing.
   • If not present, then create a session ID or get the session ID assigned by source and save the Region/endpoint that the user was forwarded to originally in cookies for fast routing and in DynamoDB for reference later if users need to be redirected.

Figure 1: Multi-region failover architecture using CloudFront, Lambda@Edge, & DynamoDB Global Tables across AWS regions.

Not every request will/must flow through this route. Static requests or dynamic requests that don’t require user-specific data can still flow through normal channels through CloudFront routing rules.

One of the key advantages of this approach is how it can handle Regional or service impairments gracefully. We’ve built in mechanisms to evacuate users from affected Regions and redistribute them to healthy ones. When the impaired Region recovers, we can rehydrate it, and seamlessly reintegrate it into our traffic distribution. This level of flexibility is what differentiates this solution from standard routing mechanisms

Moreover, this solution operates entirely on the data plane after setup, which avoids the pitfalls and potential bottlenecks associated with control plane operations. This design choice results in faster performance and improved reliability. Lambda functions use /tmp to locally cache available Regions and fetch from DynamoDB only, when necessary, which further optimizes response times.

The versatility of this solution extends to various use cases. It’s perfect for serving applications where data sharing between users isn’t required, such as personal email, financial data, or medical records. It also excels in A/B testing scenarios, so that we can route a subset of users to a test Region or node for feature testing. Furthermore, it can function as a router for cell-based architectures, providing fine-grained control over traffic distribution within a single Region or across multiple Regions and endpoints.

Security and performance are at the forefront of this design. The Origin Request Lambda@Edge function can be used to authenticate users, block bots, and check other request headers, all within a mere 2–3 ms. Although it doesn’t support layers, ARM, or AWS X-Ray, these limitations are far outweighed by the benefits of its strategic positioning at the edge.

Cost-effectiveness is another significant advantage of this serverless solution. Although Lambda@Edge executions are more expensive than standard Lambda functions, the pay-per-use model means that you’re only paying for what you need. For high-traffic applications, the improved performance and flexibility more than justify the cost.

Setup and deployment

This solution is open source and includes an AWS Cloud Development Kit (AWS CDK) to publish the solution in your own account. Go to the AWS-Sample GitHub repository for more information.

Conclusion

Managing user traffic across endpoints with resilience, efficiency, and while providing session affinity is a critical challenge for modern applications, especially those with high availability requirements. This solution uses AWS Lambda@Edge and Amazon DynamoDB to offer a powerful and scalable way to dynamically route users, ensure persistent endpoint/Region associations, and enable seamless failover during outages. Furthermore, all of this is done while minimizing latency and operational complexity. This approach uses a serverless architecture to eliminate the burden of managing infrastructure, making it ideal for mission-critical workloads in industries such as e-commerce, finance, and healthcare.

Whether you’re looking to enhance user experience, implement endpoint sharding, or strengthen application resiliency, this architecture provides a robust foundation to achieve your goals. Follow the best practices and insights shared in this post to design a resilient, scalable, and cost-effective solution that meets the needs of even the most demanding applications. You can use Lambda@Edge to focus on delivering value to your users while AWS handles the heavy lifting of traffic management and resiliency.

About the authors