Edge Services for CloudFront Functions and Lambda Edge

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.

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).

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/*

// 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)

// 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

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.

Introduction

Domain 1 - SDLC Automation

Domain 2 - Configuration Management and IaC

Domain 3 - Resilient Cloud Solutions

Domain 4 - Monitoring and Logging

Domain 5 - Incident and Event Response

Domain 6 - Security and Compliance

Edge Services for CloudFront Functions and Lambda Edge

Watch Video