Skip to main content


CloudFront is not just a CDN. It's also an SSL offloader, Host: header rewriter, path prepender, geolocator, georestrictor, secure content gateway, http to https redirector, error page customizer, root page substituter, web application firewall, origin header injector, dynamic content gzipper, path-based multi-origin http request router, viewer platform identifier, DDoS mitigator, zone apex alias target... so don't get too hung up on "CDN" or on the fact that you're stacking one service in front of another -- CloudFront was designed, in large part, to complement S3. They each specialize in certain facets of storage and delivery. source

7 things wrong with CloudFront -


CLI Reference:

Invalidate the edge caches:

aws cloudfront create-invalidation --distribution-id <distribution-id> --paths '/*' [--profile <profile>]

Lambda@Edge vs CloudFront Functions


CloudFront Functions

  • Launched 2021
  • 2018+ Edge Locations

simple HTTP(s) request/response manipulations that can be executed by very short-lived functions. For these use cases, you need a flexible programming experience with the performance, scale, and cost-effectiveness that enable you to execute them on every request.

a new serverless scripting platform that allows you to run lightweight JavaScript code at the 218+ CloudFront edge locations at approximately 1/6th the price of Lambda@Edge.


  • Launched 2017
  • 13 Regional Edge Caches

complex, compute-heavy operations that are executed when objects are not in the cache. We launched Lambda@Edge in 2017 to offer a fully programmable, serverless edge computing environment for implementing a wide variety of complex customizations. Lambda@Edge functions are executed in a regional edge cache (usually in the AWS region closest to the CloudFront edge location reached by the client). For example, when you’re streaming video or audio, you can use Lambda@Edge to create and serve the right segments on-the-fly reducing the need for origin scalability. Another common use case is to use Lambda@Edge and Amazon DynamoDB to translate shortened, user-friendly URLs to full URL landing pages.


(Developer Guide) Customizing at the edge with Lambda@Edge -

Announcement (Dec 2016):

inspection and alteration of HTTP headers, access control (requiring certain cookies to be present), device detection, A/B testing, expedited or special handling for crawlers or ‘bots, and rewriting user-friendly URLs to accommodate legacy systems. Many of these use cases require more processing and decision-making than can be expressed by simple pattern matching and rules.


CloudFront Functions

(Developer Guide) Customizing at the edge with CloudFront Functions -

Announcement (May 2021): Introducing CloudFront Functions – Run Your Code at the Edge with Low Latency at Any Scale -

Announcement (May 2021): Amazon CloudFront announces CloudFront Functions, a lightweight edge compute capability -




List functions: aws cloudfront list-functions

Describe function: aws cloudfront describe-function --name redirect-www-to-apex [--stage LIVE]

Event types

  • viewer request: triggered after CloudFront receives a request from a viewer
  • viewer response: before CloudFront forwards the response to the viewer

event example

"version": "1.0",
"context": {
"distributionDomainName": "",
"distributionId": "E123",
"eventType": "viewer-request",
"requestId": "4TyzHTaYWb1sHhEqV6GX1qTfHUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
"viewer": {
"ip": ""
"request": {
"method": "GET",
"uri": "/index.html",
"querystring": {},
"headers": {},
"cookies": {}

Redirect www to non-www

With two S3 buckets

With Lambda@Edge

With CloudFront Functions

* Redirects to
* This function is for a 'viewer request' event trigger.
* Inspired by:
* -
* -
* -
function handler(event) {
var request = event.request
if (! {
return request
var host =
if (host.startsWith('www.')) {
var apexHost = host.slice(4) // '' → ''
var newUrl = `https://${apexHost}${request.uri}`
var response = {
statusCode: 301,
statusDescription: 'Moved Permanently',
headers: {
location: { value: newUrl },
return response
return request


  • Go to the CloudFront console → Functions. Click 'Create function'.
  • Set Name to redirect-www-to-apex and Description to "Redirect to". Click 'Create function'.
  • Paste the function code at the 'Build' tab.
  • You can optionally test the function at the console or with the command aws cloudfront test-function --if-match <ETag> --name redirect-www-to-apex --event-object fileb://<path>/with-www.json. To get the ETag, use aws cloudfront describe-function --name redirect-www-to-apex [--stage DEVELOPMENT/LIVE].
  • At the 'Publish' tab, click 'Publish function'.
  • At the 'Publish' tab, section 'Associated distributions', click 'Add association'. Select the Distribution from the dropdown. Set 'Event type' to 'Viewer Request' and 'Cache behavior' to 'Default (*)'. Click 'Add association'. The distribution will appear at the list of 'Associated distributions'.

Add Headers

Use the Mozilla Observatory to check if the headers are correct.

Adding HTTP headers to CloudFront responses -

With Lambda@Edge

With CloudFront Functions