Lambda@Edge vs CloudFront Functions

CloudFront Functions and Lambda@Edge are both edge compute services that allow you to run code in response to CloudFront events, processing requests and responses at AWS edge locations before they reach the origin or the viewer. However, they are built on fundamentally different architectures and are intended for different use cases.

CloudFront Functions is a lightweight, low-latency option that runs JavaScript code (ECMAScript 5.1 compliant) at CloudFront edge locations. It is designed for high-scale, submillisecond operations such as URL rewrites, HTTP header manipulation, cache key normalization, and simple authentication or authorization checks. CloudFront Functions execute in a dedicated, isolated environment with no network access and no access to the file system. They are ideal for operations that must happen quickly and at massive scale, with thousands of requests per second per distribution.

Lambda@Edge, on the other hand, is an extension of AWS Lambda that runs functions at CloudFront edge locations. It supports multiple runtimes (Node.js, Python, Java, Go, .NET, Ruby) and provides full access to the Lambda execution environment, including network access, environment variables, and up to 10 GB of ephemeral storage. Lambda@Edge is designed for more complex operations that require significant compute, such as user authentication, database lookups, dynamic content generation, or integration with other AWS services. However, this flexibility comes with higher latency, longer execution timeouts, and higher cost.

CloudFront Functions are executed in a V8-based JavaScript engine that is tightly integrated with CloudFront's request processing pipeline. When a viewer request arrives at an edge location, CloudFront evaluates any associated function based on the event type (viewer request or viewer response). The function runs synchronously, blocking the request/response flow until it completes. The execution must finish within 1 millisecond for viewer events and 5 milliseconds for viewer response events (hard limit). The function has no access to the network, file system, or environment variables; it can only manipulate the request/response object (e.g., headers, cookies, query strings, URI) and return it. Because the runtime is minimal, CloudFront Functions can handle millions of requests per second with very low latency (submillisecond).

Lambda@Edge functions are triggered by CloudFront events and run in a standard Lambda execution environment. When a CloudFront event occurs (e.g., viewer request, origin request, origin response, viewer response), CloudFront sends the event data to the Lambda function, which runs asynchronously (but the CloudFront processing waits for the response). The function can make network calls to external services, read from S3, query DynamoDB, or invoke other Lambda functions. The maximum execution time is 5 seconds for viewer events and 30 seconds for origin events. Lambda@Edge functions have access to up to 10 GB of memory and 512 MB of ephemeral storage. However, because they are standard Lambda functions, they have cold start latency, especially when using larger runtimes or VPC configurations. CloudFront caches the function's response for the same event type and distribution, but the first invocation can be slow.

CloudFront Functions: - Runtime: JavaScript (ECMAScript 5.1) - Event types: Viewer request, viewer response - Maximum execution time: 1 ms (viewer request), 5 ms (viewer response) - Memory: 128 MB (fixed, cannot be changed) - Network access: None - File system access: None - Environment variables: None - Maximum function size: 10 KB (code only, no dependencies) - Pricing: $0.10 per million invocations (first 2 million free per month) - Concurrency: No limit beyond CloudFront distribution capacity

Lambda@Edge: - Runtimes: Node.js 18, Python 3.11, Java 11, Go 1.x, .NET 8, Ruby 3.2 - Event types: Viewer request, viewer response, origin request, origin response - Maximum execution time: 5 seconds (viewer events), 30 seconds (origin events) - Memory: 128 MB to 10 GB (in 1 MB increments) - Network access: Yes (can access VPC resources if configured) - File system access: Yes (ephemeral storage up to 512 MB) - Environment variables: Yes (up to 4 KB) - Maximum function size: 1 MB (console editor), 50 MB (zipped, including layers) - Pricing: $0.60 per million invocations (first 1 million free per month) plus compute time - Concurrency: Limited by Lambda account limits (default 1000 concurrent executions per region)

To create a CloudFront Function, you use the AWS Management Console, CLI, or SDK. In the console, navigate to CloudFront > Functions > Create function. Write your JavaScript code directly in the editor (max 10 KB). After testing with sample events, publish a version and associate it with a CloudFront distribution behavior for a specific event type (viewer request or viewer response). You can also use the AWS CLI:

aws cloudfront create-function --name MyFunction --function-config Comment="My function",Runtime=cloudfront-js-1.0 --function-code "function handler(event) { var request = event.request; request.headers['x-custom'] = {value: 'test'}; return request; }"

To create a Lambda@Edge function, you first create a Lambda function in the Lambda console (same region as your distribution, typically us-east-1) with the appropriate IAM role (must include a trust policy for lambda.amazonaws.com and edgelambda.amazonaws.com). After creating the function, you publish a version and add a CloudFront trigger from the Lambda console or CloudFront console. The trigger specifies the CloudFront distribution, behavior, and event type. Verification can be done by checking CloudFront logs or using curl with custom headers.

Both services integrate with CloudFront's cache behavior. CloudFront Functions can modify the cache key (by altering headers, cookies, or query strings) to influence caching behavior. Lambda@Edge can also modify the cache key and can perform more complex logic like checking authentication tokens before allowing cached content to be served. Additionally, Lambda@Edge can interact with other AWS services like DynamoDB, S3, or even external APIs to dynamically generate responses or redirect users. CloudFront Functions cannot make any external calls, so they rely solely on the request/response object.

CloudFront Functions: - URL redirects (e.g., redirecting from HTTP to HTTPS) - Adding security headers (e.g., HSTS, CSP) - Normalizing query strings for cache optimization - A/B testing by setting cookies - Simple authentication using pre-shared keys in headers

Lambda@Edge: - User authentication against a database (e.g., DynamoDB) - Image resizing on-the-fly using the origin response - Generating dynamic content based on user location or device - Integrating with third-party APIs for personalization - Complex URL rewrites that require external data

CloudFront Functions are extremely fast and cheap. They are ideal for high-volume, low-latency operations. Lambda@Edge is slower (due to cold starts and network I/O) and more expensive, but it offers far greater flexibility. For the SAA-C03 exam, the key differentiator is latency: if the operation must complete in under 1 ms, use CloudFront Functions. If you need network access or longer execution times, use Lambda@Edge.

A global e-commerce company wants to run A/B tests on their product pages by showing different variants to users based on a cookie. They need to add a cookie to a subset of users (e.g., 10% of traffic) and then use that cookie to serve different content from the origin. The operation must not add significant latency because even 100 ms delay can reduce conversion rates. They choose CloudFront Functions for the viewer request event to set the cookie if it doesn't exist, using a simple random number generator. The function runs in under 1 ms and scales to millions of requests per second. Misconfiguration: if they used Lambda@Edge, the cold start would add 200-500 ms latency to every request, degrading user experience. Additionally, the cost would be significantly higher. The correct approach is CloudFront Functions for cookie injection, combined with origin-side logic to read the cookie and serve the appropriate variant.

A media streaming service needs to authenticate users before allowing them to access video content. The authentication involves checking a JWT token against a DynamoDB table to verify the user's subscription status. This requires network access to DynamoDB and potentially complex token validation logic. They choose Lambda@Edge for the viewer request event. The Lambda function extracts the JWT from the Authorization header, decodes it, queries DynamoDB, and either allows the request (by passing it through) or returns a 401 response. The function has a 5-second timeout, which is sufficient for the database query. If they used CloudFront Functions, they could not access DynamoDB, so authentication would be impossible. However, they must consider cold start latency: for a global audience, they should keep the Lambda function warm by invoking it periodically (e.g., using CloudWatch Events). Misconfiguration: not setting the correct IAM role for Lambda@Edge (must include edgelambda.amazonaws.com in the trust policy) will cause the function to fail with a 502 error.

A news website serves millions of images daily at various resolutions (thumbnails, mobile, desktop). They want to resize images on-the-fly when a new resolution is requested, rather than storing all variants. They use Lambda@Edge for the origin response event: when an image is fetched from the origin (S3), the Lambda function checks the requested dimensions from the query string, resizes the image using a library like Sharp, and returns the resized image. The function runs in under 5 seconds (within the origin response timeout). This avoids storing multiple copies and reduces S3 storage costs. CloudFront Functions cannot perform image processing because they lack network access and compute power. Misconfiguration: if the Lambda function takes too long (e.g., >30 seconds for very large images), CloudFront will time out and return a 504 error. In production, they would set a maximum execution time and use CloudFront's error handling to fall back to a default image.