CDN
Intermediate 14 min read CDN

Edge Computing & Functions

Computation where the eyeballs are

Edge functions move small bits of logic — rewriting, signing, A/B gating, geolocation — next to users instead of round-tripping to the origin. CloudFront Functions, Lambda@Edge, Cloudflare Workers and Google edge runtimes trade limits for sub-ms subnets.

Lambda@EdgeCloudFront FunctionsedgeruntimerewriteA/BGeolocation
Prerequisites: CDN Security & Access Control
Before we start

What you will learn

  • Handle view request events vs origin/origin-response events
  • Pick edge function vs origin logic by latency, size and state needs
  • Implement URL normalization, header signing and A/B gating at the edge
In 60 seconds

Edge runtimes intercept requests before/after the cache and origin: view request (normalize, route, block), origin request (add auth headers, sign), origin response (transform/cache-tag). CloudFront Functions in JS-with-restrictions for low latency; Lambda@Edge for more power; Workers/Front Door similar with their own constraints.

Introduction

What is this?

Trigger points: viewer-request, origin-request, origin-response, viewer-response. Mutations allowed: headers, URI, query params, body (CloudFront Functions: body blocked vs Lambda@Edge: streamed). Limits: per-trigger size/time (Functions: ~10KB code, ~1ms CPU, 25ms limit; Lambda@Edge: 1-5s, 128MB-10GB memory depending on runtime; no VPC/EAL by default). Use cases: geolocation headers, normalize trailing slash, add auth header for origin, set-signed-cookie, cache key shaping, gzip-ish edge transforms. Billing: per-request invocation × duration.

Motivation

Why do you need it?

  • Edge logic cuts an entire origin round trip for cheap-but-smart decisions (headers, rewrites).
  • Signing requests at the edge hides credential material from the client entirely.
  • A/B or header-grease variants become an edge concern; origin stays single-purpose.
  • Routing per geography at the edge honors licensing without a per-region deployment.
Think about it

Mental model

Imagine

A quick-thinking concierge who re-addresses mail before it leaves the lobby

Think of

Edge functions on viewer-request

Malformed packages are fixed, extra postage stamps added, and only the truly new letters proceed to the post office (origin).

Mechanics

How it works

  • A distribution behavior associates the function to one of the four trigger events.
  • Viewer-request event fires before cache; a rewrite/normalize decision either serves or forwards.
  • Origin-request fires only on miss; it injects auth/signing headers toward the origin.
  • Origin-response/ viewer-response post-process the reply (set cache headers, shrink body).
  • The function mutates the minimal request/response context and returns it for the next hop.

Edge function trigger points.

Viewer request
Cache lookup
Origin request
Origin response
Viewer response
Hands-on

Examples

Rewrite semantics in a CloudFront Function

Rewrite semantics in a CloudFront Function
function handler(event) {
  var req = event.request;
  if (req.uri === '/products') { req.uri = '/products/index.html'; }
  if (!req.headers.host) {
    return { statusCode: 400, statusDescription: 'Bad Request' };
  }
  return req;
}

A pure, side-effect-free request mutator — no disk, no network, no timers — which is exactly what edge runtimes are built to run cheaply.

Real world

In production

  • Country gate: viewer-request geolocation header → 410 for restricted markets before cache.
  • Signed requests: origin-request injects the cloud signing key so the origin rejects anonymous calls.
  • Cache shaping: alphabetize query params + drop utm_* in a viewer-request to raise hit ratio.
  • A/B smoke test: cookie check assigns variant header at edge, resetting cache key via headers.
Guidelines

Best practices

  • Put only logic that must run on every request at the edge; leave heavy compute at origin.
  • Keep functions pure and idempotent — the edge may retry them.
  • Test event fixtures locally before propagating to a distribution.
  • Measure edge adds: if a viewer-request delta routinely exceeds origin response time, reconsider.
  • Validate the function's own failure: return a 5xx fallback rather than silently dropping requests.
Watch out

Common mistakes

  • Baking secrets into edge functions — credentials still need proper key storage/rotation.
  • Doing domain logic (auth, validation) that belongs at the origin server-side.
  • Relying on viewer-request body access where the runtime explicitly disallows bodies.
  • Ignoring per-function time/memory limits until a busy burst pushes latency past SLA.
When things break

Debugging tips

  • Test with explicit event JSON: curl -X POST localhost:9000 -d @event.json against a local runner.
  • Compare request flow with and without the function to isolate whose mutation broke things.
  • Monitor function error rate + invocation latency; a 4xx/5xx at the edge hides the origin state.
  • Log a minimal identifier; correlation between edge logs and origin logs reveals causality.
Interviews

Interview checkpoint

Practice

Hands-on lab

Normalize Caching with an Edge Function
45 min · intermediate
In progress
Objectives
  • Write a viewer-request edge function that normalizes trailing slashes and query params
  • Associate it with a distribution behavior
  • Prove hit ratio improves by comparing cache behavior before/after

Normalize Caching with an Edge Function

45 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which trigger fires only when there is a cache miss?

2

The primary reason edge functions exist is:

Go deeper

Official documentation

CloudFront Functions overview
docs
Lambda@Edge events
docs