Lambda@Edge vs CloudFront Functions

CloudFront Functions vs Lambda@Edge

CloudFront Functions vs Lambda@Edge
~ Last updated on : ~ jayendrapatil

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
  • supports two JavaScript runtimes:
    • Runtime 1.0 – ECMAScript 5.1 compliant with some ES 6-9 features
    • Runtime 2.0 – Adds async/await, Promises, ES modules, WebCrypto, Buffer module, and ES 6-12 features. Required for KeyValueStore and origin modification.
  • runs in 700+ Edge Locations (closer to viewers than Lambda@Edge)
  • 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
  • maximum function code size: 10 KB
  • maximum function memory: 2 MB
  • scales to millions of requests/second
  • pricing: $0.10 per million invocations (1/6th the cost of Lambda@Edge)
  • as they are built to be more scalable, performant, and cost-effective, they have the following limitations
    • no network access
    • no file system access
    • no access to environment variables (use KeyValueStore instead)
    • no dynamic code evaluation (eval() not supported)
    • no timers (setTimeout, setImmediate not supported)
  • cannot access the request body
  • supports Amazon CloudFront KeyValueStore for low-latency data lookups at the edge without network calls (requires Runtime 2.0)
  • supports origin modification (Nov 2024) – dynamically change or update origin servers on each request from the viewer request event, previously only possible via Lambda@Edge
  • supports access to geolocation and device data headers
  • can be built and tested entirely within CloudFront console
  • ideal use cases:
    • Cache-key manipulations and normalization
    • URL rewrites and redirects
    • HTTP header manipulation
    • Request authorization (JWT validation via hashed tokens)
    • Dynamic origin selection and modification
    • A/B testing and feature flags (using KeyValueStore)

CloudFront Functions – Origin Modification (Nov 2024)

  • allows conditionally changing or updating origin servers on each request from the viewer request event.
  • previously, origin modification was only possible using Lambda@Edge on the origin request event.
  • supports updating all existing origin capabilities such as setting custom headers, adjusting timeouts, setting Origin Shield, or changing the primary origin in origin groups.
  • uses helper methods: updateRequestOrigin(), selectRequestOriginById(), and createRequestOriginGroup().
  • VPC Origin modification support added in April 2025, enabling routing to private VPC origins.
  • requires JavaScript runtime 2.0.

CloudFront Functions – New Capabilities (Nov 2025)

  • Edge Location Metadata – Access the three-letter airport code of the serving edge location and expected Regional Edge Cache (REC). Enables geo-specific content routing or compliance requirements.
  • Raw Query String Retrieval – Access the complete, unprocessed query string as received from the viewer, preserving special characters and encoding.
  • Advanced Origin Overrides – Customize SSL/TLS handshake parameters including Server Name Indication (SNI), useful for multi-tenant setups. Parameters include hostHeader, sni, allowedCertificateNames, and originOverrides.

Lambda@Edge

  • are Lambda functions and visible on the Lambda dashboard.
  • supports Node.js and Python languages (currently supports Node.js 18, 20, 22, 24 and Python 3.9-3.13)
  • runs in Regional Edge Caches (13 locations globally)
  • 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
  • maximum memory: 128 MB for viewer triggers, 10,240 MB (10 GB) for origin triggers
  • maximum function code size: 50 MB (including libraries)
  • scales to 10,000 requests/second per Region
  • pricing: $0.60 per million invocations + duration charges (no free tier)
  • has network and file system access
  • can access the request body
  • does NOT support CloudFront KeyValueStore (use CloudFront Functions instead)
  • geolocation and device data available only on origin request/response triggers (not viewer triggers)
  • ideal 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)
    • 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
    • Complex authentication and authorization (OAuth, SAML)
    • Dynamic content generation and image transformation
  • Limitations
    • must use a numbered version of the Lambda function, not $LATEST or aliases
    • Lambda function must be in the US East (N. Virginia) Region
    • no free tier – Lambda@Edge requests are not covered by the standard Lambda free tier
    • does not support Lambda layers, VPC access, provisioned concurrency, environment variables, or X-Ray tracing

Lambda@Edge – Advanced Logging Controls (Apr 2025)

  • JSON Structured Logs – Function logs can now be output in structured JSON format, making it easier to search, filter, and analyze log entries without custom logging libraries.
  • Log Level Granularity – Switch log levels (ERROR, DEBUG, INFO) instantly without code changes.
  • Custom CloudWatch Log Group Selection – Choose which CloudWatch log group Lambda@Edge sends logs to, simplifying log aggregation and management at scale.

CloudFront Functions vs Lambda@Edge – Comparison

Feature CloudFront Functions Lambda@Edge
Programming Language JavaScript (ECMAScript 5.1+) Node.js and Python
Event Triggers Viewer Request, Viewer Response Viewer Request, Viewer Response, Origin Request, Origin Response
Execution Location 700+ Edge Locations 13 Regional Edge Caches
Execution Duration Sub-millisecond 5 sec (viewer) / 30 sec (origin)
Memory 2 MB 128 MB (viewer) / 10 GB (origin)
Code Size 10 KB 50 MB
Scale Millions of requests/sec 10,000 requests/sec per Region
Network Access No Yes
File System Access No Yes
Request Body Access No Yes
KeyValueStore Support Yes (Runtime 2.0) No
Origin Modification Yes (Nov 2024, viewer request) Yes (origin request)
Geolocation/Device Data Yes Origin triggers only
Build & Test in CloudFront Yes No
Pricing $0.10 per 1M invocations $0.60 per 1M invocations + duration
Isolation Model Process-based VM-based (microVM)

When to Use Which

  • Start with CloudFront Functions when:
    • Tasks are lightweight (header manipulation, URL rewrites, cache key normalization)
    • Sub-millisecond latency is required
    • High scale (millions of req/sec) is needed
    • Origin selection can be done based on headers/query strings (no body access needed)
    • Cost optimization is a priority
  • Use Lambda@Edge when:
    • You need access to the request body
    • Functions require network calls (external APIs, databases)
    • Third-party libraries or AWS SDK are needed
    • Complex logic requiring more than sub-millisecond execution
    • Origin request/response event manipulation is needed (and CloudFront Functions origin modification doesn’t suffice)

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.
  2. A company uses CloudFront to serve a multi-region application. They need to route users to the nearest origin based on the viewer’s geographic location with sub-millisecond latency impact. Which approach should they use?
    1. Use Lambda@Edge with origin request trigger
    2. Use CloudFront Functions with origin modification helper methods
    3. Use Route 53 latency-based routing
    4. Use CloudFront geographic restrictions
  3. A SaaS company wants to dynamically route tenant requests to different backend servers based on a tenant ID in the request header. The routing table changes frequently. Which solution provides the lowest latency?
    1. Use Lambda@Edge to query DynamoDB for the routing table
    2. Use CloudFront Functions with hard-coded routing logic
    3. Use CloudFront Functions with KeyValueStore to look up the tenant routing
    4. Use an Application Load Balancer with path-based routing
  4. An application requires JWT token validation at the edge and, if valid, needs to call an external authorization service to check permissions before serving content. Which combination should be used?
    1. Use CloudFront Functions for both JWT validation and the external call
    2. Use Lambda@Edge for both JWT validation and the external call
    3. Use CloudFront Functions for JWT validation on viewer request, and Lambda@Edge on origin request for the external authorization call
    4. Use API Gateway with a Lambda authorizer
  5. Which of the following is NOT a limitation of CloudFront Functions compared to Lambda@Edge? (Select TWO)
    1. Cannot access the request body
    2. Cannot modify the origin
    3. Cannot make network calls
    4. Cannot access geolocation data
    5. Cannot use KeyValueStore
    Show Answer

    Answer: B and E are NOT limitations (they are incorrect statements). CloudFront Functions CAN modify origins (since Nov 2024) and CAN use KeyValueStore –

References