CloudFront Functions vs Lambda@Edge

By the end of this lesson you will be able to

• Explain what an edge function is, why you would run code inside a CDN, and which problems it solves better than the origin.
• Name the four CloudFront event points, say exactly when each one runs, and predict which run on a cache hit, a miss, an origin error and a function-generated response.
• Compare CloudFront Functions and Lambda@Edge on runtime, scale, duration, memory, package size, network and body access, where they run and price, using today’s limits.
• Use CloudFront KeyValueStore for settings that change without a redeploy, and know the newer origin modification helpers.
• Deploy Lambda@Edge correctly (us-east-1, numbered versions, replication, logs in the Region where it ran) and diagnose 502 and 503 errors from edge functions.
• Pick the right tool for a scenario, including the cheaper answers: an origin event instead of a viewer event, or no function at all.

#Code inside the CDN

#What an edge function is

CloudFront (lesson 11.1) caches your content in hundreds of edge locations. Most of the time it just stores and serves bytes. But many modern sites need a little logic on the way: send old links to new pages, add security headers, check a login token, pick a version of a page for an experiment, shrink an image for a phone.

You could do all of that at the origin. Then every such request has to travel to the origin Region, the origin must scale for it, and a lot of it cannot be cached. An edge function is code you write and attach to a CloudFront distribution, so it runs close to the viewer, inside the CDN, before or after the cache.

The slides sum up the deal, and it is worth remembering in your own words:

• You attach code to a distribution’s cache behaviour; CloudFront runs it near your users, so the extra latency is tiny.
• There are no servers to manage and nothing to deploy per Region: CloudFront takes the code everywhere.
• It is fully serverless and you pay only for what runs.
• The purpose is to customise what the CDN delivers.

CloudFront offers two kinds: CloudFront Functions and Lambda@Edge. They look similar from far away and are completely different up close.

#What people use them for

AWS lists the jobs edge functions are typically used for. Here is each one with an everyday example from an online shop in Dhaka, Haatbazar, served at shop.example.com through d111111abcdef8.cloudfront.net:

#The four event points

Every request through CloudFront passes four points where code can be attached. This is the part the exam asks about most.

1. Viewer request

   Runs when CloudFront receives the request from the viewer, before it checks the cache. Whatever it changes (URL, headers, cookies, query string) shapes the cache key. It can also answer on its own, for example with a redirect or a 401. Runs on every request, hit or miss.

2. Origin request

   Runs only when CloudFront is about to forward the request to the origin, that is on a cache miss (or an expired object). On a hit it does not run at all. Good for choosing an origin, adding a secret header, or a lookup whose result will be cached.

3. Origin response

   Runs after CloudFront receives the origin’s response and before it caches it. It runs even when the origin returns an error, so it can replace a 404 or 503. What it changes is cached for everyone.

4. Viewer response

   Runs before CloudFront returns the response to the viewer, on hits and misses. Changes here are per viewer and not cached, for example setting a cookie.

The key difference between the two kinds starts right here:

• CloudFront Functions can run only on viewer request and viewer response.
• Lambda@Edge can run on all four.

Watch a miss, a hit, and the cases where a trigger is skipped:

#When a trigger does not run

The happy path is easy. The exceptions are where production surprises and exam distractors live:

Two consequences matter in design. First, logic in origin events runs only on misses: with a 95% hit ratio, it runs for 1 request in 20, and you pay for 1 in 20. Second, anything you need on every response, including errors, should not live only in a viewer response function; a response headers policy covers error responses too.

#One function per event, and how the two kinds combine

Each cache behaviour can have one function per event type, so at most four. You can mix the two kinds, with one rule: CloudFront Functions and Lambda@Edge cannot both be used on viewer events of the same behaviour. So “CloudFront Function on viewer request + Lambda@Edge on origin request” is allowed and common; “CloudFront Function on viewer request + Lambda@Edge on viewer response” is not.

Every function also adds its run time to the request: CloudFront waits for it to finish before it continues. That is why a viewer request function, which runs on every request, must be fast.

#CloudFront Functions: the bicycle

#What they are

CloudFront Functions are small JavaScript functions that run in the edge locations themselves, inside the request path, in a very light isolated runtime. They are a native CloudFront feature: you write, test and publish them in the CloudFront console or API, with no Lambda involved and no Region to choose.

What makes them special is the limit on everything:

• Language: JavaScript only, in a restricted runtime (version 5.1 of the language standard with selected newer features; runtime 2.0 adds const, let, async/await, a crypto module and KeyValueStore).
• Duration: sub-millisecond. CloudFront measures it as compute utilization, 0–100% of the allowed time; a function that goes over is stopped and the viewer gets an error.
• Memory: 2 MB. Code size: 10 KB, including any data you paste in.
• No network access, no file system, no request body, no timers, no eval. Everything the function knows comes from the request (method, URI, query string, headers, cookies, viewer IP) and from its KeyValueStore.
• Geolocation and device headers such as CloudFront-Viewer-Country are available (when you add them through a cache or origin request policy).
• Scale: millions of requests per second, instantly.
• Events: viewer request and viewer response only.
• Price: $0.10 per million invocations, nothing for duration, and the first 2 million a month are free. That is the “about 6 times cheaper” in the notes: Lambda@Edge charges $0.60 per million requests before duration.

#The jobs they are made for

AWS names four, and they match the notes exactly:

1. Cache key normalisation. Turn /Product/42?utm_source=fb&fbclid=x9 and a hundred similar URLs into /product/42, so they share one cached copy. The hit ratio goes up and the origin load goes down.
2. Header manipulation. Insert, change or delete request or response headers: add True-Client-IP for the origin, add security headers, remove headers that leak information.
3. URL redirects and rewrites. Send oldsite.example to newsite.example with the path kept, or rewrite /about to /about/index.html for an S3 origin.
4. Request authorisation. Validate a hashed token such as a JWT (signature and expiry) and answer 401 at the edge, without calling anyone.

A complete redirect function is a handful of lines:

function handler(event) {
  var req = event.request;
  if (req.headers.host && req.headers.host.value === 'oldsite.example') {
    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: { location: { value: 'https://newsite.example' + req.uri } },
    };
  }
  return req; // not the old host: carry on to the cache
}

Returning the request lets it continue; returning a response object answers the viewer immediately. A viewer response function receives the response (and the request) and returns the response, changed.

#KeyValueStore: settings without a redeploy

A 10 KB function cannot hold a list of 5,000 old URLs, and editing code to change an experiment from 10% to 50% is slow and risky. CloudFront KeyValueStore solves both: a global, low-latency key-value datastore that a CloudFront Function can read at the edge.

• You create a store, add keys through the console, CLI or API, and associate it with the function (one store per function; a store can serve up to 100 functions).
• The function reads values with await kvs.get(key) (runtime 2.0). The read is local to the edge, not a network call.
• Updates spread to all edge locations within seconds, with no function redeploy.
• Limits: keys up to 512 bytes, values up to 1 KB, 5 MB per store. Reads cost $0.03 per million (2 million free a month); other API calls $1 per 1,000.
• It is read-only from the function, and only CloudFront Functions can use it, not Lambda@Edge.

Typical contents: a redirect map, A/B percentages and feature flags, an allow list of partner IDs, the secret used to check JWT signatures.

#Choosing the origin from a CloudFront Function

Since late 2024, a viewer request CloudFront Function (runtime 2.0) can also change the origin of a request with helper methods: cf.updateRequestOrigin() (change or set the origin’s domain, timeouts, headers, OAC…), cf.selectRequestOriginById() (switch to another origin already in the distribution) and cf.createRequestOriginGroup() (build a failover pair on the fly). Before, only Lambda@Edge on the origin request could do that.

There is a cost trade-off AWS itself points out: a viewer request function runs on every request, while a Lambda@Edge origin request function runs only on misses. For highly cacheable content, Lambda@Edge can be the cheaper way to route between origins. For the exam, “dynamic origin selection” with network lookups still points to Lambda@Edge; the CloudFront Functions helpers are a good side note.

Watch the typical jobs, and the limits that send a job elsewhere:

#Lambda@Edge: the sports car

#What it is

Lambda@Edge is an extension of AWS Lambda (taught in depth in chapter 15, Lambda basics). For this lesson you only need this much: a Lambda function is code that AWS runs when an event arrives, billed per request and per millisecond of run time, with an IAM execution role that gives it permissions. Lambda@Edge takes such a function and lets CloudFront events trigger it.

• Languages: Node.js and Python, with any libraries you bundle, including the AWS SDK.
• Events: all four: viewer request, viewer response, origin request, origin response.
• Duration: up to 5 seconds on viewer events and 30 seconds on origin events.
• Memory: 128 MB on viewer events; on origin events up to 10,240 MB (10 GB), with CPU growing with memory.
• Package size: up to 50 MB compressed, for both event types today (it used to be 1 MB for viewer events).
• Network access: yes. It can call DynamoDB, S3, any AWS service or any API on the internet.
• File system (/tmp) and request body access: yes. The body is offered only if you tick include body; it arrives base64-encoded and is cut at 40 KB on a viewer request and 1 MB on an origin request.
• Geolocation and device headers: only on origin events (CloudFront adds them after the viewer request).
• Scale: up to about 10,000 requests per second per Region, and it shares the Region’s Lambda concurrency quota (1,000 by default) with your other Lambda functions.
• Price: $0.60 per million requests plus $0.00005001 per GB-second of run time, metered per millisecond. No free tier.

#Where it runs, and how it gets there

You create a Lambda@Edge function only in US East (N. Virginia), us-east-1. You publish a numbered version (never $LATEST or an alias) and associate that version’s ARN with a cache behaviour and an event. CloudFront then replicates the function to AWS Regions around the world, which takes a few minutes.

When an event fires, the function runs in the AWS Region nearest to the edge location that received the request, the same tier as the Regional Edge Caches (lesson 11.1), not in the edge location itself. That is a little further from the viewer than a CloudFront Function, which is one reason a viewer-event Lambda@Edge adds more latency.

Two practical consequences:

• Logs land where the function ran. CloudWatch Logs gets a log group named /aws/lambda/us-east-1.<function-name> in each Region where it executed. A viewer in Dhaka produces logs in ap-south-1 (Mumbai), not in us-east-1.
• Deleting takes patience. You cannot delete the function while replicas exist: remove it from every distribution, wait for CloudFront to delete the replicas (it can take a few hours), then delete it.

Some Lambda features are not supported at the edge: environment variables, VPC access, layers, the arm64 architecture, container images, dead-letter queues, X-Ray, provisioned concurrency and more than 512 MB of ephemeral storage. The execution role must trust both lambda.amazonaws.com and edgelambda.amazonaws.com.

#The jobs it is made for

AWS’s list for Lambda@Edge is the mirror image of the CloudFront Functions limits:

• functions that take several milliseconds or more;
• functions that need adjustable CPU or memory;
• code that depends on third-party libraries, including the AWS SDK for other AWS services;
• functions that need network access to external services;
• functions that need file system access or the body of the HTTP request.

In the notes’ words, that means:

• Dynamic content generation: build a page or fragment per request, for example a personalised offer from the customer’s segment.
• External API and database calls: look up a session in a third-party service or a user’s tier in DynamoDB (exam trick 2).
• Image optimisation: resize an image on the fly for the device’s screen, on an origin response for a missing size, and store the result.

Watch the jobs, a hit that skips the function entirely, and what slowness does:

#Side by side

This table uses today’s AWS limits; the notes’ and slides’ older values are corrected in the last column.

Try the trade-offs yourself. Tick what a job needs, or start from an example:

#What it costs, and why the event matters

Where the code runs decides how often you pay. Take Haatbazar’s 100 million requests a month with a 90% hit ratio and a function that runs 5 ms at 128 MB:

• CloudFront Function on viewer request: 100 M invocations, minus 2 M free = 98 M × $0.10 per million = $9.80.
• Lambda@Edge on viewer request: 100 M × $0.60 per million = $60, plus 100 M × 0.005 s × 0.125 GB = 62,500 GB-s × $0.00005001 ≈ $3.13, total ≈ $63.
• Lambda@Edge on origin request: only the 10 M misses: $6 + $0.31 ≈ $6.31.

So the bicycle is cheapest per run, but the sports car parked at the origin event can be cheaper still, because it runs ten times less often. Change the numbers:

#What goes wrong

#Edge functions in system design

• The serverless front door. Static site in S3 behind CloudFront with OAC (lessons 10.3 and 11.1), a CloudFront Function for redirects, clean URLs and security, and the real API on API Gateway and Lambda (chapter 15). No servers anywhere.
• Protect the origin. Reject bad tokens, oversized requests and junk paths at the edge, so the origin only sees work worth doing. For attack patterns (SQL injection, XSS, rate limits, bots) use AWS WAF on the distribution (lesson 11.2) instead of hand-written rules.
• Raise the hit ratio. Normalise the cache key with a CloudFront Function; often the cheapest performance win in the whole stack.
• Personalise without losing the cache. Put the segment (country, device, A/B group, shop tier) into the cache key, so each segment is cached once, instead of building every page at the origin.
• Route across origins and Regions. Choose an origin by country, by user tier from DynamoDB, or by a weight in KeyValueStore. For plain availability failover, origin groups (lesson 11.1) need no code; for TCP/UDP acceleration and static IPs, see Global Accelerator (lesson 11.4).
• Know when not to use one. Fixed headers → response headers policy. Country blocking → geo restriction (lesson 11.2). Private content → signed URLs or cookies (lesson 11.2). Heavy business logic → the origin. An edge function is the right tool when the logic must run near the viewer and no built-in setting does it.

#Try it yourself

CloudFront Functions, end to end with the AWS CLI. redirect.js holds the redirect function shown above:

# 1. Create the function (it starts in the DEVELOPMENT stage)
aws cloudfront create-function --name haat-redirect \
  --function-config Comment="old host to new",Runtime=cloudfront-js-2.0 \
  --function-code fileb://redirect.js

# 2. Test it with a sample viewer request event; look at FunctionOutput and ComputeUtilization
aws cloudfront describe-function --name haat-redirect          # note the ETag
aws cloudfront test-function --name haat-redirect --if-match <ETag> \
  --event-object fileb://event-old-host.json --stage DEVELOPMENT

# 3. Publish to LIVE, then attach it to a cache behaviour (FunctionAssociations, EventType viewer-request)
aws cloudfront publish-function --name haat-redirect --if-match <ETag>
aws cloudfront get-distribution-config --id E1A2B3C4D5E6F7 > dist.json   # edit, then update-distribution

# 4. KeyValueStore for settings
aws cloudfront create-key-value-store --name haat-settings
aws cloudfront-keyvaluestore put-key --kvs-arn <store ARN> --key checkout_b_percent --value 10 --if-match <ETag>

Lambda@Edge (it must be us-east-1):

aws lambda create-function --region us-east-1 --function-name haat-resize \
  --runtime nodejs22.x --handler index.handler --role arn:aws:iam::111122223333:role/edge-role \
  --zip-file fileb://resize.zip --timeout 30 --memory-size 1024
aws lambda publish-version --region us-east-1 --function-name haat-resize    # returns version 1
# associate arn:aws:lambda:us-east-1:111122223333:function:haat-resize:1 with EventType origin-response

# Where did it run? Logs are in the Region near the viewers:
aws logs describe-log-groups --region ap-south-1 --log-group-name-prefix /aws/lambda/us-east-1.haat-resize

Then watch the edge from outside:

curl -sI https://oldsite.example/eid-sale | grep -i -E '^(HTTP|location|x-cache|x-amz-cf-pop)'
# HTTP/2 301, location: https://newsite.example/eid-sale, x-cache: FunctionGeneratedResponse from cloudfront

curl -sI "https://shop.example.com/Product/42?utm_source=fb" | grep -i -E '^(x-cache|age|x-amz-cf-pop)'
curl -sI "https://shop.example.com/product/42?utm_source=x" | grep -i -E '^(x-cache|age|x-amz-cf-pop)'
# the second one should say Hit from cloudfront: both normalised to the same cache key

x-cache shows Hit, Miss, RefreshHit or FunctionGeneratedResponse; age shows how long the object has been cached; x-amz-cf-pop names the edge location (an airport-style code, for example one starting with BOM for Mumbai or SIN for Singapore).

#Summary

Key takeaways

• An edge function is code attached to a CloudFront cache behaviour that runs near viewers; serverless, deployed globally by CloudFront, pay per use. Two kinds: CloudFront Functions (bicycle) and Lambda@Edge (sports car).
• Four events: viewer request (before the cache, every request), origin request (misses only), origin response (before caching, even on errors), viewer response (every response below 400). CloudFront Functions: viewer events only. Lambda@Edge: all four.
• One function per event type per behaviour; the two kinds cannot share viewer events of one behaviour, but CloudFront Function on viewer + Lambda@Edge on origin is fine.
• CloudFront Functions: JavaScript, sub-millisecond, 2 MB memory, 10 KB code, no network, no body, no file system, millions of requests per second, edge locations, $0.10 per million (2 million free). Jobs: cache key normalisation, headers, redirects/rewrites, JWT checks. KeyValueStore gives them editable settings (5 MB per store).
• Lambda@Edge: Node.js or Python, created in us-east-1, numbered version, replicated, runs in the nearest Region; 5 s / 128 MB on viewer events, 30 s / up to 10 GB on origin events, 50 MB package; network, body and file system access; about 10,000 requests per second per Region; $0.60 per million + duration, no free tier. Jobs: DynamoDB or API calls, image resizing, dynamic content, body inspection.
• Exam tricks: sub-ms / header / highest scale / lowest latency / cheapest redirect → CloudFront Functions; database or network call / heavy compute / origin request → Lambda@Edge; fixed headers only → response headers policy.
• Errors: 503 = the function failed, timed out or was throttled; 502 = it returned something invalid. Lambda@Edge logs are in the Region where it ran.

Self-check: CloudFront Functions vs Lambda@Edge30 questions