CloudFront supports both CloudFront Functions and Lambda@Edge. Which trigger points can each hook into, and how would you choose between them for a given piece of edge logic?

## The four trigger points A request passing through CloudFront crosses four hook points. **Viewer request** fires when CloudFront receives the request, before the cache is consulted. **Origin request** fires only when the cache misses and CloudFront is about to contact the origin. **Origin response** fires when the origin's reply arrives, before it is cached. **Viewer response** fires just before the reply is returned, whether it came from the origin or from the cache. That asymmetry is the single most useful fact here: viewer triggers run on *every* request; origin triggers run only on cache misses. A per-request cost or latency belongs on a viewer trigger only if you accept paying it on cache hits too, and expensive work that only affects what gets stored belongs on an origin trigger. ## CloudFront Functions CloudFront Functions run in a JavaScript engine built for the edge rather than a general-purpose runtime. They execute at the edge locations themselves and are designed for sub-millisecond execution — the quota is on the order of a millisecond, and exceeding it fails the request rather than slowing it. The sandbox is deliberately austere: a small maximum function size (on the order of kilobytes), a couple of megabytes of memory, **no network access, no filesystem, no access to the request or response body**, and no AWS SDK. The handler signature is `function handler(event)` and it returns either a modified request or a synthesized response. Deployment has two stages, `DEVELOPMENT` and `LIVE`, and a built-in test harness that replays a sample event. For lookup data there is CloudFront KeyValueStore, a read-only key-value store the function can consult without a network call. Typical jobs: append `index.html` to directory-style URIs, normalize or strip query strings so more requests share a cache entry, redirect on `Host` or path, inject security headers on the viewer response, do a cheap presence/format check on an authorization header before the request is allowed further. ```javascript function handler(event) { var request = event.request; var uri = request.uri; if (uri.charAt(uri.length - 1) === '/') { request.uri = uri + 'index.html'; } return request; } ``` ## Lambda@Edge Lambda@Edge is real AWS Lambda: Node.js or Python, the AWS SDK in the environment, outbound network access, and the ordinary Lambda programming model. Functions must be authored in **us-east-1** and associated as a *published numbered version* — `$LATEST` is rejected — after which CloudFront replicates them. The budgets differ by trigger: viewer-facing triggers get a small memory allowance and a few seconds of timeout, while origin-facing triggers get much more memory and tens of seconds, because they sit off the hot path of cache hits. Request and response bodies can be inspected, within size limits, when body inclusion is enabled. Things only Lambda@Edge can do: choose the origin dynamically per request, rewrite the request the origin sees, call DynamoDB or Secrets Manager for a real authorization decision, transform an origin response before it is cached, or generate a response from data fetched elsewhere. ```javascript export const handler = async (event) => { const request = event.Records[0].cf.request; const country = request.headers['cloudfront-viewer-country']; if (country && country[0].value === 'DE') { request.origin.custom.domainName = 'eu.origin.example.com'; request.headers.host = [{ key: 'host', value: 'eu.origin.example.com' }]; } return request; }; ``` ## How to choose Ask three questions in order. *Which trigger do I need?* If the answer is origin request or origin response, the choice is made — Lambda@Edge. *Do I need to call anything, or read a body?* If yes, Lambda@Edge again. *Otherwise* — a URI rewrite, a redirect, header work, a cache-key tidy-up — use a CloudFront Function, because it is dramatically cheaper per invocation, adds effectively no latency, and cannot become a source of edge timeouts. A common production shape puts a CloudFront Function on viewer request to normalize and reject junk, and a Lambda@Edge on origin request for the one decision that genuinely needs data. ## Operational gotchas A Lambda@Edge function is replicated to many Regions, so its logs land in CloudWatch Logs in the Region that served the request, not in us-east-1 — a recurring surprise during incident triage. Deleting a replicated function requires removing the association and waiting for replicas to clear. And any code on a viewer trigger is in the path of every cache hit, so a slow dependency there turns a CDN into a bottleneck.