Latency increase in Lambda@Edge compared to CloudFront Function

Question

I’m using CloudFront in front of my backend services. I recently tested switching from a CloudFront Function to Lambda@Edge, and I noticed a significant increase in client-side latency (approximately +30 ms p50, +40 ms p95, and +50 ms p99), even though the logic being executed is unchanged. Is this level of added latency expected? Does the overhead of invoking Lambda@Edge and using the regional edge cache typically introduce this much delay?
Currently, my CloudFront Function only performs JWT validation, but I was hoping to migrate to Lambda@Edge so I could fetch and use JWKS endpoints.

re:Post Agent · Accepted Answer

The latency increase you're experiencing when switching from CloudFront Functions to Lambda@Edge is expected and aligns with the architectural differences between these two edge computing options.

CloudFront Functions are designed specifically for lightweight, latency-sensitive use cases. They execute directly at the CloudFront edge locations, closer to your users, and are optimized for tasks like HTTP header manipulation, URL rewrites, and basic authorization checks like JWT validation.

Lambda@Edge, on the other hand, runs in regional edge caches (usually in the AWS Region closest to the CloudFront edge location that received the request), not at the edge locations themselves. This introduces additional network hops and processing overhead. Lambda@Edge functions must complete before CloudFront can continue processing the request, which directly impacts the overall latency.

The 30-50ms latency increase you're seeing is consistent with what you might expect when moving from CloudFront Functions to Lambda@Edge. This is the trade-off for gaining the additional capabilities that Lambda@Edge provides, such as the ability to make network calls (like fetching from JWKS endpoints), using more complex logic, and having access to more runtime memory and execution time.

If you need the additional capabilities of Lambda@Edge for fetching JWKS endpoints, you'll need to accept this latency trade-off. However, if latency is critical for your application, you might consider alternative approaches, such as periodically pre-fetching and caching the JWKS data elsewhere, then making it available to your CloudFront Function through configuration or other means.

Remember that Lambda@Edge is priced at approximately six times the cost of CloudFront Functions, so there are both performance and cost implications to consider in your decision.  
**Sources**  
[CloudFront events that can trigger a Lambda@Edge function - Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-cloudfront-trigger-events.html)  
[Architecture - Amazon CloudFront for Media](https://docs.aws.amazon.com/whitepapers/latest/amazon-cloudfront-media/architecture.html)

Taz · Answer

Yes, that delta is normal. CloudFront Functions run natively on the global edge locations—those are micro‑VMs executing inline with the request pipeline. Lambda@Edge runs from regional edge caches, which sit one tier deeper in the network. Each invocation involves a hop from the edge location to the regional edge and back, plus the Lambda initialization and runtime overhead. That routinely adds tens of milliseconds even for warm executions. Cold starts or larger payloads widen the gap further.
If JWT validation is the only logic you need, keep it in CloudFront Functions since they were built for sub‑millisecond header inspection and lightweight token checks.
—Taz

Latency increase in Lambda@Edge compared to CloudFront Function

Add your answer

Relevant content