Skip to main content

AWS Lambda@Edge

AWS Lambda@Edge is an extension of AWS Lambda that allows you to run code closer to your application users by executing functions at AWS CloudFront edge locations. This service is commonly used to enhance the performance, security, and flexibility of content delivery by modifying requests and responses as they pass through CloudFront. Here are the key aspects of Lambda@Edge:

1. How Lambda@Edge Works​

  • Integration with CloudFront: Lambda@Edge functions are associated with an Amazon CloudFront distribution. When CloudFront processes a viewer request or response, Lambda@Edge runs your function code at the nearest edge location to the user, reducing latency.
  • Event Triggers: Lambda@Edge functions are triggered by CloudFront events, which include:
    • Viewer Request: When a viewer (e.g., browser, mobile app) makes a request to CloudFront.
    • Origin Request: When CloudFront forwards a request to your origin server (e.g., S3, EC2, or another web server).
    • Origin Response: When the origin server returns a response to CloudFront.
    • Viewer Response: When CloudFront sends the response to the viewer.
  • Low Latency: By running code at CloudFront edge locations, Lambda@Edge reduces latency and improves the user experience by processing requests and responses close to the end-users.

2. Common Use Cases​

  • Content Personalization: Customize web content based on user preferences, location, or device type. For example, you can modify HTTP headers to serve region-specific content or A/B test different versions of a webpage.
  • Security and Access Control: Implement security controls, such as IP-based access restrictions, header inspection, URL rewrites, or JWT (JSON Web Token) validation, before the request reaches your origin.
  • SEO and Redirection: Modify URLs for search engine optimization (SEO) or implement URL redirects, rewrites, or dynamic routing without making changes to the backend servers.
  • HTTP Header Manipulation: Add, remove, or modify HTTP headers for requests and responses, such as setting custom cache-control headers or modifying CORS (Cross-Origin Resource Sharing) headers.
  • Real-time Image Processing: Optimize and manipulate images in real-time, such as resizing, cropping, or format conversion, before delivering them to users.

3. Function Execution Locations​

  • Edge Locations: Lambda@Edge functions execute at CloudFront edge locations around the world. This provides the advantage of low latency since functions run as close to the users as possible.
  • Regional Failover: If an edge location becomes unavailable, CloudFront automatically routes the request to the nearest available edge location, ensuring high availability and reliability for your functions.

4. Function Deployment​

  • Global Deployment: When you associate a Lambda function with a CloudFront distribution, the function is automatically replicated across CloudFront's global network of edge locations. This global replication is managed by AWS, allowing for quick deployment and low-latency execution.
  • Versioning: Lambda@Edge functions require a versioned Lambda function. You cannot directly associate an unversioned function (the $LATEST version) with a CloudFront distribution. This ensures stability and predictable behavior across edge locations.
  • Deployment Time: Deployments may take some time to propagate to all edge locations. Changes to functions, such as updates or new versions, typically take a few minutes to become effective worldwide.

5. Programming Model​

  • Node.js and Python: Lambda@Edge supports Node.js and Python runtimes. Write your code in either language to handle events and customize the processing of CloudFront requests and responses.
  • Handler Function: The handler function receives an event object containing details about the CloudFront request or response (e.g., HTTP headers, query strings, cookies, request body). The function can then modify these details or generate custom responses.
  • Event Object: The event object varies depending on the CloudFront event type (viewer request, origin request, etc.). For example, you can access the request or response object to inspect and modify HTTP headers, URLs, query strings, or the request body.
  • Stateless: Functions should be stateless since they can be executed at any edge location. Any state (e.g., session data, counters) should be stored in an external database, like Amazon DynamoDB, or passed via HTTP headers, cookies, or query parameters.

6. Security and Access Control​

  • IAM Role: Each Lambda@Edge function requires an IAM execution role that grants permissions to perform specific actions, such as writing to logs in Amazon CloudWatch or accessing other AWS services.
  • Limited Access: Lambda@Edge runs in a restricted environment for security reasons. It has no direct access to VPCs, private subnets, or the broader AWS environment. This limitation ensures that edge code runs securely and isolates it from sensitive resources.
  • Data Privacy: Since Lambda@Edge functions can modify headers and URLs, you must be cautious when handling sensitive data (e.g., personal information, authentication tokens). Implement best practices, such as encrypting sensitive data and adhering to data protection regulations.

7. Resource Limits and Constraints​

  • Memory: Lambda@Edge functions can be configured with a memory allocation between 128 MB and 3008 MB. More memory also provides higher CPU power, which can help with processing-intensive tasks.
  • Execution Time: The maximum execution timeout for Lambda@Edge functions is 5 seconds. This constraint ensures that edge requests are processed quickly to maintain low latency for users.
  • Package Size: The deployment package size limit for a Lambda@Edge function is 50 MB when uploaded via an Amazon S3 bucket or 10 MB when uploaded directly through the AWS Management Console. This includes all dependencies, libraries, and function code.
  • Event Payload Size: The maximum payload size for events passed to the function is 40 KB. This includes HTTP headers, cookies, and other metadata associated with the request or response.
  • Read-Only File System: Lambda@Edge functions operate in a read-only environment. You cannot write to the file system; however, temporary storage in the /tmp directory is available, with a maximum capacity of 512 MB.

8. Logging and Monitoring​

  • CloudWatch Logs: Lambda@Edge automatically sends function logs to Amazon CloudWatch Logs in the US East (N. Virginia) region, regardless of the edge location where the function is executed. Use these logs for debugging, monitoring, and analyzing function behavior.
  • CloudFront Metrics: Use Amazon CloudFront metrics in Amazon CloudWatch to monitor request rates, error rates, and latency for your distribution, helping identify performance bottlenecks related to Lambda@Edge functions.
  • Error Handling: Lambda@Edge automatically handles function errors and returns appropriate HTTP status codes (e.g., 500 Internal Server Error) to the user. You can implement custom error handling logic within the function code.

9. Cost Considerations​

  • Pricing Model: You are charged based on the number of invocations and the execution duration (in milliseconds) of your Lambda@Edge functions. Pricing also depends on the allocated memory size for the function. Unlike standard Lambda functions, there are additional costs associated with the global replication of the function across edge locations.
  • Data Transfer: Data processed by Lambda@Edge functions (e.g., modified responses) is subject to CloudFront data transfer charges. Be mindful of the amount of data your functions process, especially when manipulating large responses.

10. Deployment and Testing​

  • Testing: Test your Lambda function code using the AWS Lambda console before associating it with a CloudFront distribution. The console provides an option to simulate CloudFront events (viewer request, origin request, etc.) to validate your logic.
  • Updates and Versioning: Use versioning to manage updates to your Lambda@Edge functions. When updating a function, create a new version and associate it with the CloudFront distribution. The changes will automatically propagate to all edge locations.

11. Best Practices​

  • Minimize Execution Time: Optimize your function code to run within the 5-second execution time limit. Use caching mechanisms (e.g., CloudFront cache headers) to reduce the need for repeated function execution.
  • Cache Responsibly: Modify cache control headers and TTL (Time to Live) values in your Lambda@Edge functions to control how CloudFront caches content. Proper caching reduces load on origin servers and speeds up content delivery.
  • Stateless Design: Design Lambda@Edge functions to be stateless and idempotent, as they may run at any edge location. Use headers, cookies, or external services (e.g., DynamoDB) to manage state if necessary.
  • Secure Headers: Use Lambda@Edge functions to add or modify security-related HTTP headers (e.g., Strict-Transport-Security, Content-Security-Policy) to enhance your application’s security posture.

12. Limitations​

  • No VPC Access: Lambda@Edge does not have direct access to VPCs, which means it cannot directly interact with private resources within a VPC. If VPC access is required, you must use regular AWS Lambda in conjunction with an API Gateway or other services.
  • Fixed Runtime Environment: Lambda@Edge supports a limited set of runtimes (Node.js and Python) and does not allow custom runtime environments. Ensure that your application logic can be implemented using the supported runtimes.
  • Limited Environment Variables: You cannot use custom environment variables with Lambda@Edge functions. Instead, pass necessary configuration data through HTTP headers, query strings, or hardcoded values.