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 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)
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.
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.
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?
Add an event to the S3 bucket. Make the event invoke a Lambda function to customize the content before rendering
Add a Step Function. Add a step with a Lambda function just before the content gets delivered to the users.
Use Lambda@Edge
Use a separate application on an EC2 Instance for this purpose.
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?
Use Lambda@Edge to compress the files as they are sent to users.
Enable Amazon S3 Transfer Acceleration to reduce the response times.
Enable caching on the CloudFront distribution to store generated files at the edge.
Use Amazon S3 multipart uploads to move the files to Amazon S3 before returning them to users.
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?
Use Lambda@Edge with a DynamoDB table for routing rules
Use CloudFront Functions with KeyValueStore for routing configuration
Use multiple CloudFront distributions with Route 53 geolocation routing
Use CloudFront cache behaviors with path-based routing
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?
Use Lambda@Edge to query a database for redirect mappings
Configure CloudFront cache behaviors for each redirect
Use CloudFront Functions with KeyValueStore to store redirect mappings
Use an Application Load Balancer with listener rules for redirects
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?
Lambda@Edge on origin request event
Lambda@Edge on viewer request event
CloudFront Functions with origin modification on viewer request event
CloudFront Functions on viewer response event
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?
Use Lambda@Edge to validate certificates on viewer request
Use CloudFront Connection Functions with KeyValueStore for the revocation list
Use CloudFront Functions to check certificate headers
