AWS Lambda@Edge
Learn AWS Lambda and Serverless
AWS Lambda Architecture
What is Distributed Tracing?
What are the AWS Lambda Supported Languages?
AWS Lambda Python
AWS Lambda NodeJS: Building Functions
What causes an AWS Lambda cold start?
AWS Lambda Cost Guide
AWS Lambda Kotlin: Building Serverless Web Apps
AWS Lambda boto3
AWS Lambda Edge
AWS Lambda Java

What is AWS Lambda@Edge? A Primer

Since its introduction in 2014, AWS Lambda has not only defined the serverless world, but with regular updates and enhancements, AWS Lambda continues to set the competition bar higher than any of the competing solutions from Microsoft, Google, and others. One of the key innovations is Lambda@Edge, which evolved from AWS Lambda to provide low-latency dynamic functionality for responsive web applications.  In this article we’ll explore Lambda@Edge, seeing what this latest offering in the serverless world has to bring to web development.

AWS-Lambda-at-Edge_How-It-Works

Defining the problem space

A key metric in the success and proper operation of a web application is the time needed to display a page. Load time for a web application encapsulates two sets of application behavior – the amount of processing time needed to respond to the most recent action taken by the user, and the amount of time it takes to display the results to the user. Both of these efforts, added together, produce the wait time that a user experiences between sending the request to the browser and seeing the result.

Time and time again, research has repeatedly shown that load time in a web application has a direct correlation with user conversion. Websites with 30 seconds of load time tend to see better conversion rates than those with 60 seconds of load time, and sites with 15 seconds of load time see better conversion rates than those with 30. Optimizing for load time, due to this general pattern, can bring quick wins in conversion rates relative to the amount of effort required. Thus, once your application reaches a steady state of feature delivery, you’ll want to make sure your content delivery is lightning fast.

CDNs get close

CDNs, or Content Delivery Networks, are a first step towards solving the load time problem. CDNs consist of networks of servers spread across the globe that are tasked with delivering content to the users of the CDN, specifically the browsers of your application’s users. CDNs are great for serving static content from a server as geographically close to the user as possible, reducing the time needed to fetch static assets from the web. This geographic nearness is built based on the CDN’s network topology, which could store assets in any number of different ways based upon the type of content being delivered. What this ultimately means is that all the images, fonts, CSS, and other elements of a web application are stored within a CDN, and the CDN handles request routing such that the server returning the assets in question is the server that is geographically closest to the user.

While this gets us a good way towards solving the loading half of the load time problem, it cannot speak to the sheer amount of time needed to produce custom output that varies based on user input. This is generally achieved by sending commands to application servers running custom functionality, and due to the nature of this functionality, it does not often lend itself well to the static delivery patterns that CDNs are intended to support.

Learn more about AWS Lambda in our guide: Complete Guide to AWS Lambda Cost

True flexibility with Lambda@Edge

Lambda@Edge closes this critical hole in run-time optimization. Lambda@Edge is a new way to approach serverless development for applications driven by CDNs. Lambda@Edge allows developers to run custom code from AWS CloudFront, reducing the round trip time needed to obtain calculation results to display to the user. Instead of building a custom server and configuring it to run your custom code, you simply upload your code to Lambda@Edge, set the initiation events, and your code will automatically be run on the CloudFront CDN exit point closest to your users, reducing overall latency.

Where standard AWS Lambda functions can respond to triggers from many different AWS services, Lambda@Edge is focused on CDN-driven events that can be used as triggers, tying your content delivery with your application functionality. This can allow you to easily scale your application, as the AWS CloudFront CDN is already built for low latency and high availability.

Learn more about AWS Lambda in our guide: AWS Lambda NodeJS: Building Functions

Conclusion

The continued evolution of serverless technology brings new revolutionary offerings on a frequent basis, and Lambda@Edge is the latest in this string. Lambda@Edge runs your custom Lambda functions on the AWS CloudFront CDN, allowing your application’s serverless code to execute as close to the user as possible. By reducing the load time required to deliver content to the user, Lambda@Edge can help you drive adoption for your serverless application by reducing load time, reducing the complexity of the deployed architecture, and removing the need to contact application servers for a response. With a globally-deployed serverless app, Lambda@Edge is critical in ensuring a quality experience for all of your users, regardless of locale.

Learn how easy AWS Lambda monitoring can be with Lumigo