Skip to main content
In this lesson we compare CloudFront Functions and Lambda@Edge — two ways to run code at Amazon CloudFront edge locations. Both let you execute logic close to end users to reduce latency, modify traffic, and offload work from origin servers.
A turquoise presentation slide titled "Service Section — The Power of Edge Networking" highlighting "CloudFront Functions and Lambda@Edge." The slide has a gradient background and a small "© Copyright KodeKloud" note in the corner.
Why run code at the edge?
  • Reduce origin load by handling simple responses, redirects, or authentication at edge locations.
  • Lower latency by executing logic in the same region/network as end users.
  • Modify requests and responses (headers, URLs, cache keys) before they reach your origin or before they return to clients.
A diagram titled "CloudFront Functions and Lambda@Edge" showing Amazon CloudFront in the center connecting backend origins (Lambda, S3, other service) on the left to multiple edge locations on the right. Arrows indicate request/response flows between the user, edge locations, and CloudFront.
How each service integrates with CloudFront events
  • CloudFront Functions run at viewer-facing events:
    • viewer-request — when CloudFront receives a request from a viewer
    • viewer-response — when CloudFront prepares to return a response to the viewer
      They are built for extremely short, stateless operations with minimal cold start time.
  • Lambda@Edge supports additional CloudFront event hooks:
    • viewer-request
    • origin-request — before forwarding to the origin
    • origin-response — after receiving the origin response
    • viewer-response
      Lambda@Edge enables more complex processing both before and after origin communication, including use of libraries and network access.
CloudFront Functions are optimized for viewer-request and viewer-response events and are ideal for very short, latency-sensitive tasks. Lambda@Edge can run at viewer-* and origin-* events, enabling more complex workflows that require additional compute, libraries, or external calls.
When to choose CloudFront Functions CloudFront Functions are the best fit when you need tiny, high-throughput, low-latency logic executed directly at the viewer edge. Typical use cases:
  • Cache key normalization — rewrite or normalize request attributes to improve cache hit rates.
  • Header manipulation — insert, modify, or delete HTTP headers (for example, add true-client-ip).
  • URL redirects and rewrites — implement redirects or rewrite URIs at the edge.
  • Simple request validation or authorization — basic token/header checks that do not require network access.
A presentation slide titled "CloudFront Functions Use Cases" showing four numbered cards with icons: 01 Cache key normalization, 02 Header manipulation, 03 URL redirects or rewrites, and 04 Request authorization.
When to choose Lambda@Edge Choose Lambda@Edge when your edge logic needs more runtime capabilities than CloudFront Functions can provide:
  • Longer-running operations (tens to hundreds of milliseconds or more).
  • Custom CPU/memory requirements or other Lambda configuration options.
  • Use of third-party libraries or the AWS SDK to call other AWS services.
  • Network access to external systems or downstream services.
  • File system access (for example, limited /tmp usage) or handling of request bodies for supported events.
A presentation slide titled "Lambda@Edge Use Cases" showing four numbered cards that list: long-running functions, configurable CPU and memory functions, dependencies on third-party libraries, and network-dependent functions.
Feature comparison Best practices and considerations
  • Prefer CloudFront Functions for tiny, stateless tasks executed at viewer events to minimize cost and latency.
  • Use Lambda@Edge when you need runtime flexibility, libraries, or origin-side processing (origin-request/origin-response).
  • Carefully consider cold-start and concurrency characteristics for Lambda@Edge functions — test under realistic traffic patterns.
  • Keep edge logic minimal and maintainable to avoid complexity spread across many edge functions.
Remember: CloudFront Functions cannot make outbound network calls and have a restricted, small runtime environment. If your logic requires external API calls or third-party libraries, use Lambda@Edge.
Summary
  • Both CloudFront Functions and Lambda@Edge let you execute code at CloudFront edge locations to manipulate requests/responses and reduce origin traffic.
  • Use CloudFront Functions for ultra-low-latency, short-lived tasks (header manipulation, cache-key normalization, redirects, simple validation).
  • Use Lambda@Edge for longer-running, dependency-rich, or networked tasks and when you need processing at origin request/response events.
Links and references

Watch Video