CloudFront Functions vs Lambda@Edge

CloudFront Functions vs Lambda@Edge

CloudFront Functions vs Lambda@Edge

CloudFront Functions vs Lambda@Edge

CloudFront Functions

  • is a CloudFront native feature (code is managed entirely within CloudFront) and visible only on the CloudFront dashboard.
  • supports lightweight functions written only in JavaScript language
  • runs in Edge Locations
  • has process-based isolation
  • supports Viewer Request, Viewer Response trigger events only
    • Viewer Request: after CloudFront receives the request from the Viewer
    • Viewer Response: before CloudFront forwards the response to the Viewer
  • supports sub-millisecond execution time
  • scales to millions of requests/second
  • as they are built to be more scalable, performant, and cost-effective, they have the following limitations
    • no network access
    • no file system access
  • cannot access the request body

Lambda@Edge

  • are Lambda functions and visible on the Lambda dashboard.
  • supports Node.js and Python languages, currently
  • runs in Regional Edge Caches
  • has VM-based isolation
  • supports Viewer Request, Viewer Response, Origin Request, and Origin Response trigger events.
    • Viewer Request: after CloudFront receives the request from the Viewer
    • Viewer Response: before CloudFront forwards the response to the Viewer
    • Origin Request: before CloudFront forwards the request to the Origin
    • Origin Response: after CloudFront receives the response from the Origin
  • supports longer execution time, 5 seconds for viewer triggers and 30 seconds for origin triggers
  • scales to 1000s of requests/second
  • has network and file system access
  • can access the request body

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You’ve been given the requirement to customize the content which is distributed to users via a CloudFront Distribution. The content origin is an S3 bucket and the customization attribute exists in the request body. How could you achieve this?
    1. Add an event to the S3 bucket. Make the event invoke a Lambda function to customize the content before rendering
    2. Use CloudFront Functions
    3. Use Lambda@Edge
    4. Use a separate application on an EC2 Instance for this purpose.

References

AWS_CloudFront_Functions_Lambda@Edge_Comparison

AWS CloudFront Edge Functions

AWS CloudFront Edge Functions

  • AWS CloudFront helps write your own code to customize how the CloudFront distributions process HTTP requests and responses.
  • The code runs close to the viewers (users) to minimize latency, and without having to manage servers or other infrastructure.
  • Custom code can manipulate the requests and responses that flow through CloudFront, perform basic authentication and authorization, generate HTTP responses at the edge, and more.
  • CloudFront Edge Functions currently supports two types
    • CloudFront Functions
    • Lambda@Edge

 

Architectural diagram.

CloudFront Functions

  • is a CloudFront native feature (code is managed entirely within CloudFront) and visible only on the CloudFront dashboard.
  • supports lightweight functions written only in JavaScript language
  • runs in Edge Locations
  • has process-based isolation
  • supports Viewer Request, Viewer Response trigger events only
    • Viewer Request: after CloudFront receives the request from the Viewer
    • Viewer Response: before CloudFront forwards the response to the Viewer
  • supports sub-millisecond execution time
  • scales to millions of requests/second
  • as they are built to be more scalable, performant, and cost-effective, they have the following limitations
    • no network access
    • no file system access
  • cannot access the request body
  • use-cases ideal for lightweight processing of web requests like
    • Cache-key manipulations and normalization
    • URL rewrites and redirects
    • HTTP header manipulation
    • Access authorization

Lambda@Edge

  • are Lambda functions and visible on the Lambda dashboard.
  • supports Node.js and Python languages, currently
  • runs in Regional Edge Caches
  • has VM-based isolation
  • supports Viewer Request, Viewer Response, Origin Request, and Origin Response trigger events.
    • Viewer Request: after CloudFront receives the request from the Viewer
    • Viewer Response: before CloudFront forwards the response to the Viewer
    • Origin Request: before CloudFront forwards the request to the Origin
    • Origin Response: after CloudFront receives the response from the Origin
  • supports longer execution time, 5 seconds for viewer triggers and 30 seconds for origin triggers
  • scales to 1000s of requests/second
  • has network and file system access
  • can access the request body
  • use-cases
    • Functions that take several milliseconds or more to complete.
    • Functions that require adjustable CPU or memory.
    • Functions that depend on third-party libraries (including the AWS SDK, for integration with other AWS services).
    • Functions that require network access to use external services for processing.
    • Functions that require file system access or access to the body of HTTP requests.
  • Limitations
    • Numbered version of the Lambda function should be used, not $LATEST or aliases.
    • Lambda function must be in the US East (N. Virginia) Region.

CloudFront Functions vs Lambda@Edge

CloudFront Functions vs Lambda@Edge

CloudFront Edge Functions Restrictions

  • Each event type (viewer request, origin request, origin response, and viewer response) can have only one edge function association.
  • CloudFront Functions and Lambda@Edge in viewer events (viewer request and viewer response) cannot be combined.
  • CloudFront does not invoke edge functions for viewer response events when the origin returns an HTTP status code 400 or higher.
  • Edge functions for viewer response events cannot modify the HTTP status code of the response, regardless of whether the response came from the origin or the CloudFront cache.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You’ve been given the requirement to customize the content which is distributed to users via a CloudFront Distribution. The content origin is an S3 bucket. How could you achieve this?
    1. Add an event to the S3 bucket. Make the event invoke a Lambda function to customize the content before rendering
    2. Add a Step Function. Add a step with a Lambda function just before the content gets delivered to the users.
    3. Use Lambda@Edge
    4. Use a separate application on an EC2 Instance for this purpose.
  2. A company’s packaged application dynamically creates and returns single-use text files in response to user requests. The company is using Amazon CloudFront for distribution but wants to further reduce data transfer costs. The company cannot modify the application’s source code. What should a solutions architect do to reduce costs?
    1. Use Lambda@Edge to compress the files as they are sent to users.
    2. Enable Amazon S3 Transfer Acceleration to reduce the response times.
    3. Enable caching on the CloudFront distribution to store generated files at the edge.
    4. Use Amazon S3 multipart uploads to move the files to Amazon S3 before returning them to users.

References