> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Edge Services for CloudFront Functions and Lambda Edge

> Overview of CloudFront Functions versus Lambda@Edge and guidance for choosing them for edge compute and request or response modifications

In this lesson we'll cover edge services for CloudFront Functions and Lambda\@Edge: what edge locations are, where these runtimes execute, their differences, and guidance for choosing the right tool for your use case.

![A blue-green gradient presentation slide with the title "Edge Services for CloudFront Functions and Lambda @ Edge" centered in white text. A small "© Copyright KodeKloud" appears in the lower-left corner.](https://mintcdn.com/kodekloud-c4ac6d9a/iUH-E6aFfTq3W6nc/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Edge-Services-for-CloudFront-Functions-and-Lambda-Edge/edge-services-cloudfront-lambda-edge-slide.jpg?fit=max\&auto=format\&n=iUH-E6aFfTq3W6nc\&q=85\&s=b2a4df5ebb3aba212b560dded9f0e70a)

What to know about edge locations

* Edge locations are globally distributed caching and compute points used by Amazon CloudFront to deliver content with minimal latency. They serve cached objects (for example, static assets and streaming media) as close to the viewer as possible.
* CloudFront Functions and Lambda\@Edge let you run custom code at these edge locations so you can inspect or modify requests and responses close to the viewer, reducing round-trips to origins and improving performance for common operations.

Where each runs

* CloudFront Functions
  * Executed on CloudFront edge servers.
  * Designed specifically for viewer-based events (requests coming from and responses going to the viewer).
  * Optimized for extremely low-latency, high-concurrency tasks with a lightweight JavaScript runtime.
* Lambda\@Edge
  * Also runs at CloudFront edge locations but supports all four CloudFront event types: `viewer-request`, `origin-request`, `origin-response`, and `viewer-response`.
  * Provides a full Lambda runtime (supported runtimes) and greater control over origin-to-viewer flows.

![A slide titled "When Do Functions Run?" comparing CloudFront and Lambda@Edge. It lists bullet points describing when each runs (CloudFront: viewer request and viewer response; Lambda@Edge: viewer request, origin request, origin response, and viewer response).](https://mintcdn.com/kodekloud-c4ac6d9a/iUH-E6aFfTq3W6nc/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Edge-Services-for-CloudFront-Functions-and-Lambda-Edge/when-functions-run-cloudfront-lambda-edge.jpg?fit=max\&auto=format\&n=iUH-E6aFfTq3W6nc\&q=85\&s=0231fa3c3f475fa093117c7718154b9f)

Key differences and practical guidance

Use the table below for a quick comparison, followed by additional implementation guidance.

| Area | CloudFront Functions | Lambda\@Edge |
| - | - | - |
| Event coverage | `viewer-request`, `viewer-response` | `viewer-request`, `origin-request`, `origin-response`, `viewer-response` |
| Runtime & capabilities | Lightweight JavaScript runtime; no full Node.js environment or built-in AWS SDK | Full Lambda runtime (supported languages); can use AWS SDKs and call external services |
| Typical use cases | Header rewrites, URL redirects, cookie/AB tests, simple validation, cache key manipulation | Complex request/response transformations, origin authentication, dynamic content generation, calls to other AWS services |
| Performance & cost | Very low latency, high concurrency, cost-effective for simple tasks | More powerful but potentially higher latency and cost |
| Deployment | Attach directly to CloudFront behaviors; rapid execution at edge | Publish and associate function versions with distributions; code is replicated to edge locations (propagation delay) |
| When to choose | High-performance, viewer-only transformations | Need origin-level control or features that require full Lambda capabilities |

Practical guidance

* Event coverage: If your logic only needs to inspect or change the request/response that the viewer sees, prefer CloudFront Functions. If you need to modify or inspect traffic that goes to or comes from your origin, use Lambda\@Edge.
* Capabilities: CloudFront Functions are ideal for deterministic, short-running JavaScript snippets (e.g., URL rewriting, header adjustments). Lambda\@Edge is for heavier processing, interacting with external APIs, or using the AWS SDK.
* Performance vs. flexibility: Start with CloudFront Functions when possible for lower latency and cost. Move to Lambda\@Edge only when CloudFront Functions cannot meet the functional requirements.
* Deployment considerations: CloudFront Functions are attached to behaviors directly and execute at edge locations without version replication concerns. Lambda\@Edge requires you to publish versions and associate them with behaviors; changes may take time to propagate to all edge locations.

Examples

* CloudFront Function: rewrite request URIs from `/old-path/*` to `/new-path/*`

```javascript theme={null}
// CloudFront Function
function handler(event) {
  var request = event.request;
  // Rewrite /old-path/* to /new-path/*
  request.uri = request.uri.replace(/^\/old-path(\/.*)?$/, '/new-path$1');
  return request;
}
```

* Lambda\@Edge: add a custom header on viewer request (Node.js Lambda)

```javascript theme={null}
// Lambda@Edge (Node.js) example
exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  // Add a custom header before forwarding to origin or returning to viewer
  request.headers['x-custom-edge'] = [{ key: 'X-Custom-Edge', value: 'true' }];
  return request;
};
```

Use CloudFront Functions for latency-sensitive viewer events and simple transformations. Choose Lambda\@Edge when you need origin-level control, complex processing, or access to the full Lambda runtime and AWS SDKs.

When to pick which (quick checklist)

* Choose CloudFront Functions when:
  * You need `viewer-request` or `viewer-response` only.
  * Tasks are small, deterministic, and require the lowest latency.
  * You want simple header rewrites, redirects, or cache-key logic.
* Choose Lambda\@Edge when:
  * You need `origin-request` or `origin-response` events.
  * You must call external services, use the AWS SDK, or perform complex transformations.
  * You require language/runtime features not available in CloudFront Functions.

Links and references

* [Amazon CloudFront Functions – Developer Guide](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html)
* [Lambda@Edge – Developer Guide](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-edge.html)
* [CloudFront distribution behaviors](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesBehaviors)

Summary

* Edge locations cache content and provide compute near users for reduced latency.
* CloudFront Functions are the preferred choice for very fast, simple request/response transformations at viewer events.
* Lambda\@Edge supports broader event coverage and more complex processing at the edge, but with added latency, cost, and operational overhead.

> **[Watch Video](https://learn.kodekloud.com/user/courses/aws-certified-devops-engineer-professional/module/614fb8a5-8397-4ea6-9d7c-fe05ebc43d18/lesson/3c526837-b5be-4b0b-a7f0-05ed119ca436)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.