Functions at Edge

Limitations of Lambda@Edge

Lambda@Edge functions are designed to operate within the CloudFront edge network, allowing for real-time processing of viewer and origin requests and responses. However, it’s essential to note that these functions have some restrictions compared to standard Lambda functions:

• Supported runtimes: Lambda@Edge supports only Node.js and Python runtimes, limiting the programming languages available for function development.

• No VPC access: Lambda@Edge functions execute within the AWS Public Zone, so they lack access to Virtual Private Cloud (VPC)-based resources, which might restrict certain use cases requiring VPC connectivity.

• No Lambda layers: Lambda@Edge does not support Lambda layers, limiting the ability to reuse common code across multiple functions.

• Execution limits: Lambda@Edge functions have distinct size and execution time limits compared to standard Lambda functions, imposing constraints on memory allocation and function timeout.

CloudFront Functions

CloudFront Functions are lightweight serverless functions that run at the edge of the AWS CloudFront global network. They enable developers to customize and manipulate content delivery at the edge locations, allowing for real-time processing of requests as they are received and responses as they are generated. This helps optimize content delivery, implement security measures, and personalize content without provisioning or managing additional infrastructure.

CloudFront Functions seamlessly integrate with CloudFront distributions and are executed at the edge of the CloudFront network, ensuring low-latency processing closer to end-users. They can handle millions of requests per second, scale automatically, and perform consistently. CloudFront Functions follow a pay-as-you-go pricing model, ensuring cost-effectiveness by charging users only for the compute resources consumed, suitable for applications of all scales. The cost for CloudFront Functions is $0.10 per 1 million invocations.

Limitations of CloudFront Functions

CloudFront Functions have the following limitations:

• Limited language support: Currently, CloudFront Functions support only JavaScript (Node.js) as the programming language, limiting language choice for developers.

• Execution time limit: Functions have a maximum execution time limit of 5 seconds, which may restrict the complexity of operations that can be performed within a single function.

• Limited libraries and dependencies: CloudFront Functions have limited access to external libraries and dependencies compared to traditional serverless platforms like AWS Lambda, which may impact the ability to reuse existing code or libraries.

• Limited debugging tools: Debugging CloudFront Functions can be challenging, as limited debugging tools and logging capabilities are available compared to other serverless platforms.

• Statelessness: Functions are stateless by design, meaning they do not maintain state between invocations, which may require developers to implement additional mechanisms for state management if needed.

Execution workflow

Functions at Edge integrate seamlessly with the traditional CloudFront architecture, consisting of customers, edge locations, and origins. The communication flow between these components involves four stages:

• Viewer request: The function executes after the CloudFront edge location receives a viewer request. This allows for preprocessing viewer requests before they are forwarded to the origin.

• Origin request: Before CloudFront forwards a request to the origin, the origin request function can modify or augment the request as necessary, providing dynamic behavior based on the request parameters.

• Origin response: Upon receiving a response from the origin, CloudFront triggers the origin response function, enabling post-processing of origin responses before they are delivered to viewers.

• Viewer response: The viewer response function executes just before CloudFront sends the response to the viewer, allowing for final adjustments or customizations to the response content.

Functions can be invoked at each stage to manipulate the traffic flow. The architecture with Lambda at each stage is shown in the illustration below:

Execution limits on Lambda@Edge

Lambda@Edge functions have specific limits depending on their execution context within the CloudFront architecture:

• Viewer side limits: Functions invoked on the viewer side have a memory allocation limit of 128MB and a function timeout of five seconds, ensuring efficient processing of viewer requests.

• Origin side limits: Functions executed on the origin side share similar constraints with standard Lambda functions, including memory allocation limits and a function timeout of 30 seconds, enabling comprehensive processing capabilities closer to the origin.

Execution limits on CloudFront Functions

CloudFront Functions have specific limits depending on their execution context within the CloudFront architecture:

• Viewer side limits: Functions invoked on the viewer side within CloudFront have a memory allocation limit, which dictates the amount of memory available for execution. The exact limit may vary but is typically lower than Lambda@Edge, often around 64MB or 128MB. CloudFront Functions have a maximum execution time limit of around 5 seconds, ensuring efficient processing of viewer requests and timely responses.

• Origin side limits: Functions executed on the origin side have higher memory allocation limits than the viewer side, around 256MB or 512MB. CloudFront Functions executed on the origin side have a maximum execution time limit of around 30 seconds, enabling more comprehensive processing closer to the origin.

Use case scenarios for functions at edge

Some of the use cases for functions at the edge are listed below:

• A/B testing: Functions at the edge can be used to cater to A/B testing scenarios. For example, an e-commerce company, ABC Corp, uses functions at the edgee for A/B testing of product images on its website’s homepage. Using a viewer request Lambda function, the company dynamically modifies image URLs based on predefined logic to serve viewers two distinct versions (Version A and Version B) without altering the URL structure. The Lambda function incorporates logic algorithms such as percentage-based allocation or user segmentation to determine which version to display to each viewer. By seamlessly delivering image variations and collecting data on user engagement, click-through rates, and conversion metrics, ABC Corp gains insights to optimize website performance and enhance user experience iteratively.

• Distribution based on region: Functions at the edge can be utilized to distribute traffic based on user region. For instance, an origin request function can inspect the incoming request headers to determine the user’s geographical region. Based on this information, the function can route the request to different origin servers or serve different content variations tailored to specific regions. This allows for optimized content delivery and improved user experience by ensuring users are directed to the nearest or most appropriate servers based on their geographic location.

• Distribution based on devices: Functions at the edge can distribute traffic based on the user’s device type. For example, an origin request function can examine the user-agent header in the incoming request to determine the type of device accessing the content, such as desktop, mobile, or tablet. Depending on the device type detected, the function can dynamically modify the content being served, optimizing it for the specific device’s screen size, resolution, or capabilities. This enables personalized content delivery tailored to the device, ensuring an optimal viewing experience for users across various devices.

CloudFront functions vs. Lambda@Edge

Lambda@Edge and CloudFront Functions are both serverless compute services offered by AWS to customize and extend the functionality of CloudFront. Lambda@Edge excels in executing complex logic or accessing AWS services at edge locations, making it suitable for use cases requiring access to additional AWS services like DynamoDB, S3, or AWS Lambda, or scenarios demanding fine-grained control over request/response processing, user authentication, or content personalization.

On the other hand, CloudFront Functions are ideal for lightweight content transformations, header manipulations, or URL-based routing without relying on external dependencies or AWS services. They are best suited for scenarios prioritizing simplicity and agility over advanced functionality or integration with other AWS services or where JavaScript-based logic suffices and the overhead of managing Lambda@Edge functions is unnecessary.

Use cases for Lambda@Edge

• Dynamic content manipulation: Lambda@Edge allows us to execute serverless functions at AWS edge locations, enabling dynamic content manipulation closer to the end user.

• Content personalization: We can use Lambda@Edge to customize content based on user requests or device characteristics, such as geolocation or user-agent.

• Access control and authentication: Implement access control policies, authentication mechanisms, or authorization logic at the edge to restrict access to resources or content.

• A/B testing and experimentation: Conduct A/B testing or experimentation by routing requests to different origins or serving different versions of content based on predefined criteria.

Use cases for CloudFront functions

• Lightweight content transformation: CloudFront Functions are lightweight JavaScript functions that execute at the edge locations, primarily for simple content transformations or modifications.

• Header manipulation: Modify request or response headers, such as adding custom headers, removing sensitive headers, or altering caching directives.

• URL rewriting and redirection: Implement URL rewriting rules, URL redirections, or URL-based routing logic to customize the behavior of content delivery.

• Content security policies: Enforce security policies, such as cross-origin resource sharing (CORS), content security policies (CSP), or cookie attributes, to enhance security and mitigate common web vulnerabilities.