First of all, what is Lambda@Edge? The best description comes from Amazon themselves:
With Lambda@Edge, you can easily run your code across AWS locations globally, allowing you to respond to your end users at the lowest latency. Your code can be triggered by Amazon CloudFront events such as requests for content to or from origin servers and viewers. Upload your Node.js code to AWS Lambda and Lambda takes care of everything required to replicate, route and scale your code with high availability at an AWS location close to your end user. You only pay for the compute time you consume - there is no charge when your code is not running.
In my last post, I talked about how we automated the build and deployment of our team site with Jekyll, GitHub, Travis, S3 and CloudFront.
One of the important elements of hosting any site nowadays are HTTP security headers. There are a number of resources available about these and the importance of them so I’m not going to go in to much detail but I will provide some links to a few of the more useful tools and articles I’ve read.
- Everything you need to know about HTTP security headers
- Hardening your HTTP response headers - Scott Helme
- Hardening Your HTTP Security Headers - MaxCDN
- securityheaders.io - a tool to check headers
With an S3 website, you can control cache headers by adding information to the object metadata but controlling HTTP headers
isn’t possible. If you were hosting your site with something like nginx, it’d be easy to simply edit your
server block and set some headers. Something like this:
Last year (2016), Jeff Barr announced a preview of Lambda@Edge to deal with this and in July 2017 that became generally available and Jeff posted how it’s now possible to have intelligent processing of HTTP requests at the edge.
I’d seen an article previously about how to use the preview to add headers, but, as the author notes this is no longer valid because the format of functions within Lambda@Edge changed. After some searching I found this article from nvisium.com which had an excellent overview and guide on how to set it all up.
Once I’d created the Lambda function, added the headers I wanted and saved the version I could then reference it in our
CloudFront distributions. Note that I chose to add the function editing the CloudFront distribution rather than letting
Lambda do it for me. You’ll also always need to include the version after the ARN, so, something like
If you curl our team site URL you’ll see the custom headers (note, some removed from this snippet):
Conclusion and notes
Lambda@Edge is only currently available in us-east-1 (console/GUI) although it can be used in other regions.
I’d like to note that Lambda and Lambda@Edge are both still young services and as such are developing rapidly. One issue I noticed which has been discussed online a lot is that replicated Lambda functions cannot be deleted. What this means is your console can get filled rapidly with old or testing versions. Hopefully this will be fixed in the future.