Application Performance - Edge functions
Edge functions are powerful developer tools to add custom logic at the edge with CloudFront.
Achraf Souk
Amazon Employee
Published Apr 29, 2025
Edge functions are powerful developer tools to add custom logic at the edge with CloudFront. Edge functions allow developers to enrich web applications while reducing latency, and build fully distributed applications. Edge functions can be used for:
- Implementing advanced HTTP logic. CloudFront provides you with native rules such as redirection from HTTP to HTTPs, routing to different origins based the request path, etc... Edge functions allow you to go beyond the native in CloudFront to implement advanced HTTP logic such as normalizing cache keys, rewriting URLS, HTTP CRUD operations, etc...
- Reducing application latency. Some application logic can be offloaded from the origin to the edge to benefit from caching (e.g. A/B testing) or to execute closer to users (e.g. HTTP redirections, URL shortening, HTML rendering). In a micro-services or micro-front architectures, you can use edge functions to implement common logic (e.g Authorization & Authentication) once at the entry point of the application instead of implementing it in each component separately.
- Protecting the application perimeter. Edge functions can be used to enforce security controls such as access control, and advanced geoblocking at the edge. This allows you to reduce the attack surface of your origin and remove unnecessary scaling costs.
- Request routing. You can use edge functions to route each HTTP request to a specific origin based on application logic. This can be useful for scenarios such as advanced failover, origin load balancing, multi-region architectures, migrations, application routing, etc...
CloudFront provides you with two flavors of edge functions: CloudFront Functions and Lambda@Edge. CloudFront Functions offer sub-millisecond startup times and scales immediately to handle millions of requests per second, which makes it ideal for lightweight logic (cache normalization, URL rewrite, request manipulation, authorization, etc...). Lambda@Edge is an extension of AWS Lambda, executed in a distributed way across Regional Edge Caches. Lambda@Edge offers more computing power, and advanced functionalities such as external network calls, albeit for a higher cost and latency overhead. This documentation provides in-depth details about the differences between both runtimes.
Edge functions can be either used to manipulate inflight HTTP requests and responses, or simply to terminate requests and generate responses instead of flowing upstream in CloudFront. Edge functions can be configured to be executed at different events during the lifecycle of a request on CloudFront:
Image not found
- Viewer events: Executed for every request, before checking CloudFront cache. It's ideal for cache normalization, authorization or placing unique cookies. CloudFront Functions are only allowed on viewer events.
- Origin events: Executed on cache misses, before going to the origin to fetch files. It's ideal to generate content or manipulate responses before caching it.
Consider the following best practices:
- Associate an Edge function to the most specific cache behavior, to avoid unnecessary functions execution cost.
- Use the most optimal edge function runtime for your case. For example, if your logic can be implemented either using CloudFront Functions or Lambda@Edge on viewer events, use CloudFront Functions. If your logic can be implemented with CloudFront Functions on viewer events, or with Lambda@Edge on origin events, use CloudFront Functions, unless the cache hit ratio is very high.
- Learn about restrictions on edge functions when you design your application. Note that, on viewer events, you can either use Lambda@Edge or CloudFront Functions, but not both (e.g. Lambda@Edge on viewer request event and CloudFront Functions on viewer response event).
Practical applications of edge compute in Amazon CloudFront
CloudFront functions are written in JavaScript, can be built and tested entirely in the CloudFront Console and APIs, and can log to CloudWatch logs in us-east-1 region. As a developer, you need to write functions with compute utilization less than 80%. Executions that exceed compute utilization quotas will be throttled by CloudFront, which can be monitored using CloudWatch metrics.
This programming model guide helps you write CloudFront functions. Below is an example function to redirect users coming from Germany to localized German content:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
function handler(event) {
var request = event.request;
var headers = request.headers;
var host = request.headers.host.value;
var country = 'DE';
var newurl = `https://${host}/de/index.html`;
if (headers['cloudfront-viewer-country']) {
var countryCode = headers['cloudfront-viewer-country'].value;
if (countryCode === country) {
var response = {
statusCode: 302,
statusDescription: 'Found',
headers: { location: { value: newurl } },
};
return response;
}
}
return request;
}CloudFront Functions also provides the ability to decouple and store persistent data seperately from your code via CloudFront KeyValueStore. The KeyValueStore is especially ideal in situations where embeded data, such as bulk redirect mappings, would take you over the function's size quota. It also has the benefit of enabling you to update your persistent data without having to modify your function.
Lambda@Edge functions can be written in NodeJs or Python. They allow you to benefit of the power of a Lambda container with configurable memory (up to 10GB). Since it's based on AWS Lambda, a Lambda@Edge function is authored in the Lambda console, and exclusively in us-east-1. When you finish authoring it, and deploy to your CloudFront distribution, CloudFront replicates globally to its Regional Edge Caches. To associate a Lambda@Edge function with a CloudFront cache behavior, you first need to publish a new version of it, then deploy it to your target cache behavior. Every Lambda@edge function update triggers a new CloudFront deployment (in contrast to CloudFront Functions, where only the initial association triggers a CloudFront deployment). Consider the following when developing Lambda@Edge functions:
- Learn about best practices for using Lambda@Edge, especially around managing execution concurrency. Concurrency measures the number of concurrently running Lambda containers per Regional Edge Cache region. In each region, Lambd@Edge concurrency has quotas in terms of bursting speed and absolute limit.
- Learn about best practices for fetching external data from your Lambda@Edge function.
- Lambda@Edge logs are shipped to CloudWatch logs in the region where they were executed with a log group name prefixed by us-east-1. If you need to centralize Lambda@Edge logs in a single region, consider the following Lambda@Edge log aggregator solution. Note that every function execution generates logs to CloudWatch Logs (in contrast to CloudFront Functions, where logs are generated only when explicitly written in the function code). You can disable Lambda@Edge logs by removing permissions to send logs to CloudWatch from its associated IAM role, .
This programming model guide helps you write Lambda@Edge functions. Below is an example function that redirects requests based on a redirections stored in an S3 bucket:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
const aws = require('aws-sdk');
const s3 = new aws.S3({ region: 'us-east-1' });
const s3Params = {
Bucket: 'redirections-configuration',
Key: 'redirects.json',
};
const TTL = 5000; // TTL of 5 seconds
async function fetchRedirectionsFromS3() {
const response = await s3.getObject(s3Params).promise();
return JSON.parse(response.Body.toString('utf-8')).map(
({ source, destination }) => ({
source: new RegExp(source),
destination,
})
);
}
let redirections;
function fetchRedirections() {
if (!redirections) {
redirections = fetchRedirectionsFromS3();
setTimeout(() => {
redirections = undefined;
}, TTL);
}
return redirections;
}
exports.handler = async event => {
const request = event.Records[0].cf.request;
try {
const redirects = await fetchRedirections();
for (const { source, destination } of redirects) {
if (source.test(request.uri)) {
return {
status: '302',
statusDescription: 'Found',
headers: {
location: [{ value: destination }],
},
};
}
}
return request;
} catch (_error) {
return request;
}
};How to Set up a Lambda@Edge Function
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.
Comments
Log in to comment