AWS CloudFront Functions and Lambda@Edge allow you to run serverless code at AWS edge locations worldwide, closer to your users. This post explores the differences between the two, their use cases including URL rewrites, A/B testing, and authentication, and how to choose the right tool for edge compute on CloudFront.
CloudFront functions & Lamdba@Edge
Use Cases
- Website Security and Privacy
- Dynamic web application ate the Edge
- Search Engine Optimisation (SEO)
- Intelligently Route Across Origins and Data Centres
- Bot Mitigation at the Edge
- Real-time Image Transformation
- A/B Testing
- User Authentication and Authorisation
- User Prioritization
- User Tracking and Analytics
CloudFront Functions
- Lightweight functions written in Javascript
- For high-scale, latency-sensitive CDN customisations
- Sub-ms startup times, millions of requests/second
- Used to change Viewer requests and responses:
- Viewer Request: after CloudFront receives a request from a viewer
- Viewer Response: before CloudFront forwards the response to the viewer
- Native feature of CloudFront (manage code entirely within CloudFront)
Lamda@Edge
- Lambda functions written in Nodejs or python
- Scales to 1000s of requests/scond
- Used to change CloudFront requests and responses:
- Viewer Request - after CloudFront receives a request from a viewer
- Origin request - before cloud front forwards the request to the origin
- Origin response- after CloudFront receives receives the response from the origin
- View Response - before cloud front forwards the response to the viewer
- Author your functions in one AWS Region 9us-east-I), then CloudFront replicates to its locations
CloudFront functions vs. Lambda@Edge - Use Cases
CloudFront Functions
- Cache key normalisation
- Transform request attributes (headers, cookies, query strings, URL) to create an optimal cache key
- Header manipulation
- Insert/modify/delete HTTP headers in the request or response
- URL rewrites or redirects
- Request authentication & authorisation
- Create and validate user-generated tokens(eg.JWT) to allow/deny request
Lambda@Edge
- Longer execution time(several ms)
- Adjustable CPU or memory
- Your code depends on a 3 rd libraries (eg., AWS SDK to access other AWS Services)
- Network access to user external services for processing
- File system access or access to the body of HTTP requests
Frequently Asked Questions
What is the difference between CloudFront Functions and Lambda@Edge?
CloudFront Functions are lightweight, high-performance functions for simple viewer-level manipulations with sub-millisecond execution, while Lambda@Edge supports more complex logic, longer execution times, and can run at both viewer and origin request/response stages.
When should you use Lambda@Edge?
Use Lambda@Edge for complex customizations like dynamic origin selection, authentication and authorization, generating personalized responses, or any edge logic that requires more processing power than CloudFront Functions can provide.