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 three types
  • CloudFront Functions
  • Lambda@Edge
  • CloudFront Connection Functions (for mTLS validation)

 

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 (import/export), WebCrypto, Buffer module, Symbol, DataView, and ES 6-12 features
• 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
• 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
  • 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
• use-cases ideal for lightweight processing of web requests like
  • Cache-key manipulations and normalization
  • URL rewrites and redirects
  • HTTP header manipulation
  • Access authorization
  • Dynamic origin selection and modification (added Nov 2024)
  • A/B testing and feature flags (using KeyValueStore)

CloudFront Functions – Origin Modification (Nov 2024)

• CloudFront Functions now supports origin modification, allowing you to conditionally change or update 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 from the cloudfront module: updateRequestOrigin(), selectRequestOriginById(), and createRequestOriginGroup().
• Requires JavaScript runtime 2.0.
• In April 2025, VPC Origin modification was also added, enabling routing to private VPC origins from CloudFront Functions.
• Available at no additional charge.

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 (e.g., directing European users to GDPR-compliant origins).
• Raw Query String Retrieval – Access the complete, unprocessed query string as received from the viewer, preserving special characters and encoding that may be altered during standard parsing.
• Advanced Origin Overrides – Customize SSL/TLS handshake parameters including Server Name Indication (SNI). Useful for multi-tenant setups where CloudFront connects through CNAME chains resolving to servers with different certificate domains. Parameters include hostHeader, sni, allowedCertificateNames, and originOverrides.
• Available at no additional charge in all CloudFront edge locations.

Amazon CloudFront KeyValueStore

• is a low-latency, globally distributed datastore for CloudFront Functions (launched Nov 2023).
• allows storing key-value pairs that can be read by CloudFront Functions at the edge without making a network call.
• enables dynamic updates to configuration data without deploying code changes.
• requires CloudFront Functions using JavaScript runtime 2.0.
• eliminates the need for environment variables (which are not supported in CloudFront Functions).
• use cases:
  • URL redirects and rewrites based on dynamic mappings
  • A/B testing configuration
  • Feature flags
  • Access control lists
  • SaaS tenant routing at the edge
  • Geo-based routing configuration
• supports operations via CloudFront API using Signature Version 4A (SigV4A):
  • GetKey – retrieve a single key
  • PutKey – add or update a key
  • DeleteKey – remove a key
  • ListKeys – list all keys
• data is eventually consistent across all edge locations.

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
• 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.
  • Complex authentication and authorization (JWT validation, OAuth).
• 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.
  • No free tier – Lambda@Edge requests are not covered by the standard Lambda free tier.

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 large volumes of log entries without custom logging libraries.
• Log Level Granularity – Switch log levels (ERROR, DEBUG, INFO) instantly without code changes, useful for real-time issue investigation.
• Custom CloudWatch Log Group Selection – Choose which CloudWatch log group Lambda@Edge sends logs to, simplifying log aggregation and management at scale.
• Configurable via Lambda APIs, Lambda console, AWS CLI, AWS SAM, and AWS CloudFormation.

CloudFront Connection Functions

• is a newer type of edge function specifically designed for mutual TLS (mTLS) validation at the edge (launched 2025).
• executes during the TLS handshake, before HTTP request processing begins.
• allows custom certificate validation logic: device-specific authentication, certificate revocation, allow/deny decisions for TLS connections.
• uses JavaScript runtime 2.0 (cloudfront-js-2.0).
• can integrate with CloudFront KeyValueStore for real-time data lookups (e.g., certificate revocation lists).
• use cases:
  • Custom certificate revocation checking
  • Device allowlist validation
  • Additional certificate attribute validation beyond standard mTLS
  • Logging connection-level metadata
• runs at CloudFront edge locations worldwide.

CloudFront Functions vs Lambda@Edge

Feature	CloudFront Functions	Lambda@Edge
Runtime	JavaScript (runtime 1.0 or 2.0)	Node.js, Python
Execution Location	700+ Edge Locations	13 Regional Edge Caches
Event Triggers	Viewer Request, Viewer Response	Viewer Request, Viewer Response, Origin Request, Origin Response
Execution Time	Sub-millisecond	5 sec (viewer), 30 sec (origin)
Scale	Millions of requests/sec	Thousands of requests/sec
Network Access	No	Yes
File System Access	No	Yes
Request Body Access	No	Yes
Origin Modification	Yes (via viewer request, Nov 2024)	Yes (via origin request)
KeyValueStore	Yes (runtime 2.0 required)	No (use DynamoDB or external calls)
Pricing	~1/6th the price of Lambda@Edge	Higher (no free tier for 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 on the same cache behavior.
• 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.
• Lambda@Edge functions must be created in US East (N. Virginia) region and must use a numbered version (not $LATEST or aliases).
• CloudFront Functions cannot access the request body, make network calls, or use timers.
• Origin modification in CloudFront Functions runs on every request (viewer request event), whereas Lambda@Edge origin modification only runs on cache misses (origin request event).

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.
3. A company needs to dynamically route CloudFront requests to different origin servers based on the viewer’s geographic location with sub-millisecond latency. The routing configuration changes frequently. Which solution meets these requirements with the LEAST operational overhead?
   1. Use Lambda@Edge with a DynamoDB table for routing rules
   2. Use CloudFront Functions with KeyValueStore for routing configuration
   3. Use multiple CloudFront distributions with Route 53 geolocation routing
   4. Use CloudFront cache behaviors with path-based routing
4. A development team needs to implement URL redirects for a website served through CloudFront. The redirect mappings change weekly and currently contain 500 entries. They need sub-millisecond performance. Which approach is MOST efficient?
   1. Use Lambda@Edge to query a database for redirect mappings
   2. Configure CloudFront cache behaviors for each redirect
   3. Use CloudFront Functions with KeyValueStore to store redirect mappings
   4. Use an Application Load Balancer with listener rules for redirects
5. A company wants to dynamically route requests to different backend origins based on customer subscription tier. Requests include the tier as a header. The company wants this logic executed on every request with the lowest possible latency. Which edge function approach should they use?
   1. Lambda@Edge on origin request event
   2. Lambda@Edge on viewer request event
   3. CloudFront Functions with origin modification on viewer request event
   4. CloudFront Functions on viewer response event
6. A solutions architect needs to implement custom mutual TLS certificate validation that checks client certificates against a revocation list at CloudFront edge locations. The revocation list is updated hourly. Which solution is MOST appropriate?
   1. Use Lambda@Edge to validate certificates on viewer request
   2. Use CloudFront Connection Functions with KeyValueStore for the revocation list
   3. Use CloudFront Functions to check certificate headers
   4. Configure CloudFront’s built-in certificate revocation checking

References

• AWS CloudFront Edge Functions
• Introducing CloudFront Functions
• CloudFront Functions JavaScript Runtime 2.0
• Amazon CloudFront KeyValueStore
• CloudFront Functions Origin Modifications
• CloudFront Functions – 3 New Capabilities (Nov 2025)
• Lambda@Edge Advanced Logging Controls
• CloudFront Connection Functions
• Helper Methods for Origin Modification