November 2021: Note there is a new way to do this natively within CloudFront, and it wont cost you a Lambda@Edge invocation.
For a long time, I’ve been using Lambda@Edge to inject various HTTP security-related headers to help browsers improve the security model of the content that they fetch and render.
I’ve been doing this as I have been using S3 as the origin (accessed via a CloudFront Origin Access Identity). S3 itself cannot add/inject many of the common security headers when it passes
These Functions execute when the origin returns the content to the CloudFront regional edge; the returned content then gets cached with the injected headers included.
The end result is getting a good rating on securityheaders.com, hardenize.com, and other public security evaluation services.
An alternate in the Lanbda@Edge execution lifecycle is to trigger on Viewer Response; in which case the cached version doesn’t have the headers injected, and every viewer request triggers the code execution. Clearly, if every viewer has the same set of headers, there’s no need to execute each view response and pay for the additional Lambda@Edge executions.
Now there’s a new option – CloudFront Functions (AWS blog post). Written entirely in JavaScript, it executes only at Viewer Request, or Viewer Response. There is no Origin Request or Origin Response option. It also executes at the CloudFront Edge, not the Regional Edge.
Thie example injects a number of headers, and would need only minor potential customisation on the Content Security Policy (and possibly Permissions Policy) to work for most sites:
function handler(event) {
var request = event.request;
var response = event.response;
response.headers['strict-transport-security']= { value: 'max-age=31536000' };
response.headers['x-xss-protection']= { value: '1'};
response.headers['x-content-type-options']= { value: 'nosniff'};
response.headers['x-frame-options']= { value: 'DENY'};
response.headers['referrer-policy']= { value: 'strict-origin-when-cross-origin'};
response.headers['expect-ct']= { value: 'enforce, max-age=86400'};
response.headers['permissions-policy']= { value: 'geolocation=(self), midi=(), sync-xhr=(self), microphone=(), camera=(), magnetometer=(), gyroscope=(), fullscreen=(), payment=(), autoplay=(self)'};
response.headers['content-security-policy'] = { value: "default-src: 'self'; img-src 'self' data: ; style-src 'self' 'unsafe-inline' ; frame-ancestors 'none'; form-action 'none'; base-uri 'self'; "};
return response;
}You may want to evaluate the cost of both Lambda@Edge and CloudFront Functions. After the first year, Functions is charged at US$0.10 per million functions. As an equivalent, Lambda@Edge for a similar Node.JS function that executes in one millisecond with 128 MB of memory would be US$0.2021 per million requests.
However, given a busy website, you may want to look at the efficiency differences between Viewer Response execution for CloudFront Functions, and Origin Response and the caching for Lambda@Edge (multiplied by the number of Edge Cache locations (13), and the cache retention rate).
If you have only a few unique URLs, and content that can be cached for a long period, and large volumes of requests, then Lambda@Edge may result in near free execution.
| Lambda@Edge | CloudFront Functions | |
| Unique URLs | 100 | 100 |
| HTTP viewer Requests | 10M/month | 10M/month |
| Execution time | 1ms | N/A |
| Number of Regional Edges | 13 | N/A |
| Memory/execution | 128MB | N/A |
| Execution time | Origin Response | Viewer Response |
| Number of code invocations | 1300 (once per Regional Edge, Per Unique URL, and possibly cached for a month – depending on Edge cache expiry) | 10M |
| Possible Costs (as at 28/Aug/2021) | Duration: US$0.0000000021 * 1300 = Requests: US$0.2 * 0.0013 Total: US $0.00026273 | US$0.1 * 10 Total: US$1 |
| CloudFront Functions cost uplift compared to Lambda@Edge | 3,806 times more expensive |
If we were using Lambda@Edge on ViewerResponse, and not caching the object with headers injected, then CloudFront Functions would be cheaper; or if the content being sent was dynamic from the origin and not suitable to be cached, in which case we wouldn’t get the efficiency savings of fewer executions.
Even if we are using Origin Response with Lambda@Edge, we can’t determine the cache expiry of the Lambda@Edge cached responses (we can influence it); the cached objects could expire and re-execute every day, so the Lambda@Edge costs could go up 30x (which would only make CloudFront functions 126 times more expensive). YMMV. TIMTOWTDI.