CloudFront Functions | Overview.

CloudFront Functions - Overview.

Scope:

• Intro,
• Architecture,
• Where CloudFront Functions Run,
• Trigger Points,
• Deployment & Versioning,
• Execution Environment,
• Request/Response Flow Sample,
• Advantages of This Model,
• Limitations.

Intro:

• CloudFront Functions are a lightweight, low-latency edge computing feature within Amazon CloudFront.
•  CloudFront Functions allow twtech to run JavaScript code at AWS Edge locations in response to viewer requests (viewer request and viewer response events). 
• They are designed for simple, highly-scalable manipulations of HTTP requests and responses.

Architecture

1. Where CloudFront Functions Run

• CloudFront has over 400+ edge locations worldwide (Points of Presence, or PoPs).
• A CloudFront Function is deployed to every single PoP, so it runs as close as possible to the viewer (the client/browser).
• This is why it can execute in sub-milliseconds — no long network hops to a central server.

2. Trigger Points

CloudFront Functions only run at two event stages in the request/response lifecycle:

1. Viewer Request – right after the viewer (browser, app) sends a request to CloudFront, before CloudFront decides where to fetch the content from.
2. Viewer Response – right before CloudFront sends a response back to the viewer.

NB:

•  CloudFront Functions never see “origin request” or “origin response” events — that’s Lambda@Edge territory.

3. Deployment & Versioning

• twtech writes the function in JavaScript (ECMAScript 5.1).
• When twtech publishes it, CloudFront replicates it to all PoPs globally in seconds.
• Functions are versioned — twtech associates a specific version with a CloudFront distribution behavior.
• Since they are tied to behaviors, twtech can apply different functions to different paths or cache behaviors.

4. Execution Environment

• Sandboxed JavaScript runtime (isolated, no network or filesystem access).
• Memory: ~2 MB
• Execution limit: < 1 ms per invocation (measured at the edge).
• Deterministic: No async calls, no external libraries, only built-in JavaScript features.
• Output must be a modified HTTP request or response object (immutable input → twtech clone/modify → return).

5. Request/Response Flow Sample

• Let’s say twtech has a viewer-request CloudFront Function that redirects all twtechapp.com traffic to https://www.twtechapp.com.

Flow:

1. User request:

# vbnet

 

GET /index.html

Host: twtechapp.com

2. CloudFront edge location receives request.
3. Viewer-request function runs:

# javascript

 

function handler(event) {

  var request = event.request;

  if (request.headers.host.value === 'twtechapp.com') {

    return {

      statusCode: 301,

      statusDescription: 'Moved Permanently',

      headers: {

        'location': { value: 'https://www.twtechapp.com' }

      }

    };

  }

  return request;

}

4. If redirect condition is met → sends redirect immediately from the edge.
5. If not → passes request on to normal CloudFront caching/origin logic.

6. Advantages of This Model

• Speed – Runs in microseconds, no origin round trip.
• Cost-efficiency – Pricing is per request with microsecond granularity.
• Scalability – Runs at every PoP automatically, no provisioning.
• Security – No external network calls possible, minimizing attack surface.

7. Limitations

• Can’t fetch data from APIs, S3, or databases.
• No async/await or timers.
• No origin-level logic (use Lambda@Edge for that).
• Only lightweight transformations — heavy parsing or computation will hit limits.