CloudFront Functions for Edge Logic

CloudFront Functions is a feature of Amazon CloudFront that lets you write lightweight JavaScript functions to manipulate HTTP requests and responses at the edge. These functions execute at CloudFront edge locations, which are the points of presence (PoPs) closest to your viewers. The primary purpose is to perform simple, high-frequency operations such as URL rewrites, header manipulation, cache key normalization, and authentication redirects with extremely low latency.

Before CloudFront Functions, the only way to run custom logic at the edge was Lambda@Edge, which is a full Lambda function triggered by CloudFront events. However, Lambda@Edge has higher latency (on the order of milliseconds) due to function cold starts and execution overhead. For use cases that require submillisecond processing, such as modifying every request to a high-traffic website, Lambda@Edge can be too slow. CloudFront Functions fills this gap by providing a lightweight runtime optimized for speed.

CloudFront Functions are written in JavaScript (ECMAScript 5.1 compliant) and use a custom runtime that is heavily optimized for low latency. The runtime does not support Node.js APIs; instead, it provides a minimal set of built-in objects and methods. Functions are triggered by two CloudFront events: viewer request and viewer response. They execute before CloudFront checks its cache for viewer request events and after CloudFront receives the response from the origin for viewer response events.

At a high level, the flow is: 1. A viewer sends an HTTP request to a CloudFront distribution. 2. CloudFront receives the request at an edge location. 3. If a viewer request function is associated, CloudFront invokes it with the request object. 4. The function runs and returns a modified request object or generates a response (e.g., redirect or 401). 5. CloudFront then checks its cache using the (possibly modified) request. 6. If a cache miss occurs, CloudFront forwards the request to the origin. 7. When the origin responds, if a viewer response function is associated, CloudFront invokes it with the response object. 8. The function modifies the response (e.g., adding headers) and returns it. 9. CloudFront caches the response (if appropriate) and sends it to the viewer.

Key implementation details:

To create a CloudFront Function, you can use the AWS Management Console, AWS CLI, or AWS SDK. The steps are:

Example CLI command to create a function:

aws cloudfront create-function --name my-function --function-config Comment="My function",Runtime=cloudfront-js-1.0 --function-code file://function.js

Example function code (URL rewrite):

function handler(event) {
    var request = event.request;
    var uri = request.uri;
    
    // Rewrite /old-path/* to /new-path/*
    if (uri.startsWith('/old-path/')) {
        request.uri = uri.replace('/old-path/', '/new-path/');
    }
    
    return request;
}

To test a function, you can use the CloudFront console's test tab, which simulates a request and shows the function's output.

CloudFront Functions complement Lambda@Edge. For more complex processing (e.g., database access, external API calls, image manipulation, or functions requiring Node.js modules), you must use Lambda@Edge. Lambda@Edge supports longer execution times (up to 30 seconds), larger function size (50 MB compressed), and a full Node.js or Python runtime. However, Lambda@Edge incurs higher latency (cold starts) and higher cost per invocation.

CloudFront Functions also interact with CloudFront's caching behavior. Since viewer request functions execute before cache lookup, they can modify the cache key (e.g., by normalizing query strings or rewriting URLs). This can improve cache hit ratios. Viewer response functions can modify responses before caching, but changes to the response body are not supported (only headers, status code, and cookies).

CloudFront Functions are designed for submillisecond execution. In benchmarks, typical functions execute in 0.5-2 ms. This is orders of magnitude faster than Lambda@Edge, which often takes 5-50 ms due to cold starts and runtime overhead. For high-traffic sites with millions of requests per minute, this latency difference is critical.

A large e-commerce company serves millions of users worldwide. They need to redirect users to localized content based on their country. Using CloudFront Functions, they write a viewer request function that reads the CloudFront-Viewer-Country header, maps it to a country code, and rewrites the URL prefix (e.g., /us/ to /de/ for German users). This function executes in under 1 ms, ensuring no noticeable delay. Previously, they used Lambda@Edge, which added 20-50 ms latency per request, impacting conversion rates. The function is associated with the default cache behavior. They also normalize query strings by removing tracking parameters (e.g., utm_source) to improve cache hit ratios. The function code is under 2 KB and handles 50,000 requests per second during peak. They monitor FunctionExecutionTime and keep it below 0.8 ms. A common misconfiguration is forgetting to handle missing headers, causing errors; they added a default country fallback.

A video streaming service uses CloudFront to deliver content. They need to add security headers like X-Content-Type-Options and Strict-Transport-Security to all responses. They use a viewer response function to add these headers. The function also sets a Set-Cookie header for a session token if the request includes a valid token in the query string. The function runs at the edge, reducing origin load. They handle 100,000 requests per minute. The function is tested with the console tool and deployed across multiple distributions. A pitfall is that viewer response functions cannot modify the response body; they attempted to add a watermark but had to use Lambda@Edge instead.

A SaaS company hosts customer-specific applications behind CloudFront. They use a viewer request function to extract a tenant ID from the hostname or URL path and rewrite the request to the correct origin path. They also add a custom header X-Tenant-ID for the origin to identify the tenant. The function is lightweight and processes 10,000 requests per second. They use CloudFront Functions because Lambda@Edge would introduce unacceptable latency for their real-time application. They encountered an issue where the function code exceeded 10 KB after adding complex tenant mapping; they had to simplify the logic and use a lookup table with a smaller size. They also learned that functions cannot access external databases, so they preload mappings in the code.