AWS CloudFront Support
Lambda@Edge vs CloudFront Functions: picking the right one.
Both run your code at the edge, but they are very different tools. CloudFront Functions are lightweight JavaScript for viewer-side tweaks. Lambda@Edge is full Lambda with network access and more event types. We match each requirement to the right one.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You need redirects, URL rewrites or header changes at the edge
- You want JWT checks or custom authentication before the origin
- A Lambda@Edge function adds cost or latency for a simple task
- You need to call an external API or read a body from the edge
- You are debugging a function that returns 502 or does not seem to run
What you get
- A decision table mapping each requirement to a function type
- Function code with tests
- Associations and roles in infrastructure as code
- Monitoring across the regions where logs appear
How we do it
A clear, safe process you can follow along with.
1. List what the logic must do
We write down the event (viewer request, viewer response, origin request, origin response), whether it needs network or request-body access, and how much compute it needs.
2. Apply the decision rule
Header manipulation, URL rewrites, simple redirects, cache key normalization and token signature checks fit CloudFront Functions. Calling other services, using the request body, longer processing or origin-side events need Lambda@Edge.
3. Check runtime limits
We confirm current limits for code size, execution time and memory for each option in AWS documentation, because they differ sharply and change over time, and design to stay well under them.
4. Build and test
CloudFront Functions have a test console that runs against sample events. For Lambda@Edge we test the Lambda in us-east-1 with sample CloudFront events before publishing a numbered version.
5. Associate and deploy
Lambda@Edge needs a published version, not $LATEST, with a role trusted by both lambda.amazonaws.com and edgelambda.amazonaws.com. We attach the function to the correct behavior and event type.
6. Monitor and debug
Lambda@Edge logs appear in CloudWatch Logs in the region closest to the edge location that ran it, so we search several regions. CloudFront Function metrics and logs show errors and compute utilization.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Using Lambda@Edge for a simple redirect
A CloudFront Function does the same job with less setup and lower cost.
Expecting logs in one region
Lambda@Edge logs land in the regions where the function ran, which is why people think nothing is logged.
Heavy logic on viewer request
Viewer events run on every request, even cache hits. Put heavy work on origin events so it runs only on a cache miss.
Invalid response shapes
Lambda@Edge responses must follow the CloudFront event structure, or CloudFront returns a 502.
Frequently Asked Questions
When should I use CloudFront Functions instead of Lambda@Edge?
Use CloudFront Functions for short, CPU-light viewer-side tasks such as redirects, rewrites and header edits. Use Lambda@Edge when you need network calls, body access or origin events.
Why can't I find my Lambda@Edge logs?
They are written to CloudWatch Logs in the region nearest the edge location that handled the request, not necessarily your home region. We search the likely regions.
Can both run on the same behavior?
Yes, on different event types in some combinations, for example a CloudFront Function on viewer request and Lambda@Edge on origin request. We check the supported combinations before designing.
Want Help With Lambda@Edge vs CloudFront Functions: picking the right one?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required