CloudFront Functions Vs Lambda@Edge (Real World Use Cases) | Overview.

CloudFront Functions Vs Lambda@Edge (Real World Use Cases) - Overview.

Scope:

• Intro,
• CloudFront Functions,
• Lambda@Edge,
• Key traits,
• Mental model,
• Table of real-world use cases for each (Quick Differences),
• Best Use Cases,
• Decision Cheat Sheet.

Intro:

• Unpacking CloudFront Functions and Lambda@Edge.
• They’re both ways to run custom code within the AWS CloudFront content delivery network.
• However, they have different:
• Capabilities, 
• Execution locations, 
• Performance profiles, 
• Costs.

1. CloudFront Functions

• Purpose: Ultra-lightweight JavaScript code that runs at CloudFront’s edge locations to manipulate requests/responses at the viewer level.
• Think fast, simple, and cheap for things like headers, redirects, and URL rewrites.

Key traits:

• Language: JavaScript (ECMAScript 5.1)
• Execution time limit: <1 ms (very strict)
• Memory: ~2 MB
• Event types supported:
• viewer-request (before CloudFront fetches content)
• viewer-response (before returning to the viewer)
• No network access (can’t call external APIs)
• Use cases:
• Simple header manipulation (e.g., add/remove security headers)
• Redirect based on country, device type, or URL pattern
• URL rewrites for static file versioning
• A/B testing at the edge without complex logic
• Pricing: Much cheaper than Lambda@Edge (microseconds of compute time per invocation)

Mental model: A tiny, lightning-fast filter for incoming and outgoing requests at the edge.

2. Lambda@Edge

Purpose: Run more powerful Node.js or Python functions at AWS edge locations, but with full AWS Lambda capabilities.
Think heavier processing, flexible logic, and integration with other AWS services.

Key traits:

• Languages: Node.js, Python (full Lambda runtimes, multiple versions)
• Execution time limit:
• Viewer events: up to 5 seconds
• Origin events: up to 30 seconds
• Memory: 128 MB – 10 GB
• Event types supported:
• viewer-request
• viewer-response
• origin-request (before request is sent to origin)
• origin-response (before returning to viewer)
• Can call external services (HTTP calls, DynamoDB, S3, etc.)
• Use cases:
• Authentication/authorization at the edge
• Dynamic content generation
• Image transformation on the fly
• Custom caching logic
• Language/locale negotiation
• Pricing: More expensive due to Lambda execution pricing + data transfer

Mental model: A full Lambda function, deployed globally at edge locations.

 Table of real-world use cases for each.

1. Quick Differences

Feature	CloudFront Functions	Lambda@Edge
Execution Location.	Runs at all edge locations in microsecond-scale	Runs at edge locations (Viewer) and regional edge caches (Origin)
Runtime.	JavaScript (lightweight, V8-based)	Node.js, Python
Max Execution Time.	≤ 1 ms	5 sec (Viewer), 30 sec (Origin)
Memory.	≤ 2 MB	128 MB – 3,008 MB
Package Size Limit.	≤ 10 KB	≤ 50 MB
Cost.	Cheaper	More expensive
Cold Starts.	None (always warm)	Possible
Capabilities.	Very fast header/cookie/URL manipulation	Heavy computation, API calls, content modification

2. Best Use Cases

CloudFront Functions  (Ultra-light, sub-ms)

Run before/after cache at Viewer level, with extreme speed.

• URL Rewrites & Redirects
• Change /old-path → /new-path
• Append query params (?lang=en)
• HTTP Header Manipulation
• Add/remove headers for security (e.g., CSP, HSTS)
• Set cache-control dynamically
• Simple A/B Testing
• Route 50% of users to /beta
• Geo-based Routing
• Redirect by country or region using CloudFront-Viewer-Country
• Lightweight Auth
• Validate JWT from cookies or headers (simple checks only)

Lambda@Edge  (Full-powered, ms–seconds)

Run before/after cache at both Viewer & Origin levels.

• Complex Authentication
• OAuth flows, signed cookies, Cognito integration
• Dynamic Origin Selection
• Choose backend based on request path, country, or user segment
• Content Personalization
• Inject user-specific HTML, JSON, or API results
• Heavy Response Transformations
• Modify HTML body, compress files, watermark images
• Integration with External APIs
• Call backend services before responding
• Custom Logging & Analytics
• Send request/response data to external logging services

3. Decision Cheat Sheet

• Need <1 ms response time, simple changes, lowest cost? → CloudFront Functions
• Need heavy logic, API calls, or origin manipulation? → Lambda@Edge
• Need both? → Yes, Chain them:
• CloudFront Function for fast routing.
• Lambda@Edge for deeper processing.