SysPad › Lessons › networking lessons › Edge Functions (CloudFront)

How Edge Functions (CloudFront) works

Code at the CDN edge. CloudFront Functions: sub-ms JS for header rewrites/redirects at $0.10/1M. Lambda@Edge: full runtimes with network access at $0.60/1M + duration. If the edge code calls a service, question the design.

Some code is too impatient to travel. A redirect, an auth-token check, an A/B bucket assignment: making the user cross an ocean to your origin for a one-line decision wastes 100ms. CloudFront lets you run code at the edge, and gives you two very different tools for it whose price differs by 6x per invocation.

What you will learn

What kind of work belongs at the edge at all?
CloudFront Functions vs Lambda@Edge: how do you pick?
Why does a slow edge function hurt more than a slow origin handler?
What does the 100x cost mistake look like?

Code that runs before the cache

Edge functions attach to CloudFront events and run at the PoP closest to the user, BEFORE your cache and origin. Classic jobs: redirects, header rewrites, signed-cookie checks, geo-routing, A/B assignment.

Two runtimes, one decision

CloudFront Functions: a tiny JavaScript runtime, sub-millisecond budget, viewer request/response only, NO network calls, ~$0.10 per million. Built for header surgery at millions of RPS. Lambda@Edge: real Node/Python, seconds of budget, can call other services, also hooks origin events, ~$0.60 per million plus duration.

The multiplier nobody prices in

Edge code runs on every request, including cache hits (viewer events). A 5ms edge function in front of a 10ms cached response has raised your latency 50% and billed itself millions of times a day. Slow or chatty work belongs at the origin, where the cache shields it.

⚓ In SysPad, flip the runtime enum on an Edge Functions node between the two options at the same RPS: the ~6x invocation price gap and the duration charge are the whole comparison, live.

Why does Lambda@Edge deploy take so long and run "somewhere regional"?

Lambda@Edge replicates your function to regional edge caches worldwide, so updates propagate globally (minutes, not seconds) and logs land in the region that served each user, which makes debugging famously scattered. CF Functions, being tiny, propagate fast and stay simple. One more reason to default small.

Flashcards

Design review: JWT signature validation on every request (pure crypto on the token, no lookups) at 80k RPS. Which edge tool, and why does the answer save ~$100/day?: CF Functions: no network needed, sub-ms crypto fits its budget, and at 80k RPS the $0.10 vs $0.60 per million gap plus zero duration charge is roughly $100+/day. Lambda@Edge here is the classic 6x overpay.
A teammate wants the edge function to check a DynamoDB deny-list per request. What are the two problems?: CF Functions cannot make network calls at all, and on Lambda@Edge a cross-region DynamoDB lookup per request adds real latency on EVERY request pre-cache. Deny-lists usually belong in a periodically-pushed CloudFront KeyValueStore or at the origin.
After adding an 8ms Lambda@Edge viewer function, the site's cached responses went from 12ms to 20ms globally. Why did the cache not protect you?: Viewer-event functions run before the cache, on every request including hits. The cache shields the ORIGIN, not the edge code in front of it.

Sources

Open the SysPad canvas · Official Edge Functions (CloudFront) documentation