![\"Lambda](\"https:\/\/static.gosquared.com\/images\/liquidicity\/17_10_09_lambda_01@2x.jpg\")
<\/p>\n<\/p>\n
Lambda@Edge was first announced in preview by AWS back in December<\/a>; it hit public release in July<\/a>. We\u2019ve been using it since the preview – here\u2019s some of the things we\u2019ve learned along the way.<\/p>\n Lambda is AWS\u2019s \u201cserverless\u201d platform for running code as functions – instead of booting EC2 Instances (i.e. \u201cservers\u201d) and worrying about operating systems, supervisors, logging, deployment, scaling, or any of the other factors required to actually run your code, you can simply write the code for a function in your favourite programming language (JavaScript, Python, Java or C#), and AWS will take care of the undifferentiated heavy lifting of actually getting that code to run somewhere.<\/p>\n CloudFront is AWS\u2019s content delivery network (CDN), which acts as a layer on top of your web site or assets, for distributing your content globally, so that assets (typically JavaScript, CSS or images) can be cached and served from a point of presence (or \u201cedge location\u201d) geographically close to your users. You can put CloudFront in front of any web origin you like, most commonly either web servers of your own or hooked directly into an S3 bucket.<\/p>\n Typically with a CDN like CloudFront, web content falls into two categories: static and dynamic. Static content includes assets like JavaScript or images which are the same no matter who is requesting them or how; dynamic content includes parts of your web site or app that vary based on application logic – whether or not the user is logged in etc.<\/p>\n In most cases you\u2019ll set up your CDN to cache static content so it\u2019s always readily-available at the edge closest to your user and doesn\u2019t need re-fetching. Dynamic content, since by definition it\u2019s not constant, can\u2019t be cached, and the CDN has to hit your origin server for those requests. This extra request back to the origin adds extra latency, and effectively negates the benefit of having a CDN in the first place.<\/p>\n What Lambda@Edge allows you to do is to push some of the dynamic logic from your origin onto CloudFront\u2019s edge servers. You can write some code, deploy it to Lambda@Edge, and have it interact with requests from your visitors at the edge location, geographically close to your users, potentially enabling you to serve some of your dynamic content requirements without incurring the full round-trip latency to your origin server.<\/p>\n There are some restrictions to exactly what you can implement with Lambda@Edge – you get a very limited amount of resources, so reimplementing your entire application\u2019s logic at the edge probably isn\u2019t feasible – but there is a wide variety of simple cases in which Lambda@Edge can help you move logic closer to your users, reducing latency and creating a faster experience.<\/p>\n Lambda@Edge effectively allows you to hook into requests as they pass through the CloudFront edge servers, and modify data in flight. There are four different stages in the request lifecycle that you can hook into: viewer request, which comes immediately after the request is received by the edge server, before hitting the cache layer; origin request which come when the edge server has decided it needs to fetch data from the origin server, but before it sends the request; origin response after the origin has sent its response, but before the response gets cached; and viewer response which is called on every request just before the response is sent to your user\u2019s browser. <\/p>\n At each of these stages the request\/response body and headers can be modified. Your Lambda function can also call out to external sources of data to inject directly into the content. Additionally, either of the request hooks can be used to directly generate a response rather than letting the request continue to the cache or origin server.<\/p>\n There\u2019s an important distinction between the viewer and the origin handlers described above: the viewer handlers will be called for every single request received by the CloudFront distribution, before any caching behaviour. This is useful if, for example, you want to perform an A\/B test based on a cookie value by modifying the requested URL, but it\u2019s important to bear in mind that these functions come with a (small) overhead that will add to the overall latency of the request. The origin handlers, on the other hand, are only called when the CloudFront edge does not have the requested content in the cache, or decides that the content needs to be refreshed. So if the modifications you are making to requests or responses can be cached and reused, the origin handlers may be more appropriate.<\/p>\n There are an endless number of possible things that can be achieved with Lambda@Edge, and here at GoSquared we\u2019ve barely scratched the surface. But here are our favourite two use-cases:<\/p>\n One of the best things about CloudFront since its inception is its support for plugging directly into S3 for serving static assets. You can simply put CloudFront in front of an S3 bucket and have it serve all the objects within it, without having to worry about setting up any web servers of your own.<\/p>\n The downside that comes with S3 origins is that S3 doesn\u2019t give you a huge amount of control over exactly how those objects are served – most notably the HTTP headers sent along with the response data.<\/p>\n Many browser security features are controlled by HTTP headers such as We\u2019ve also found the fine-grained programmatic control allowed by Lambda@Edge to be useful purely for neatness as well as security. The deploy process we use for some of our S3 assets leaves useful metadata attached to these assets, which are served up as Here\u2019s an example of a Lambda@Edge origin response handler we might have for this sort of header-modification.<\/p>\n Previously we would use a tier of web servers in between the S3 origin and CloudFront to perform all this header-modification logic. Now we can offload everything to Lambda@Edge and completely remove a whole moving part from the flow. Woo serverless!<\/p>\n In the original days of CloudFront, it did not support any kind of modification to your response data at all. This included modifications such as using gzip Content-Encoding to reduce bandwidth. This was fine if you were using an origin server which supported dynamically serving compressed or uncompressed content based on the What is Lambda@Edge?<\/h2>\n
How does it work?<\/h2>\n
![\"Lambda](\"https:\/\/static.gosquared.com\/images\/liquidicity\/17_10_09_lambda_02@2x.jpg\")
<\/p>\nViewer vs. Origin handlers<\/h3>\n
What can I do with this?<\/h2>\n
Adding security headers on S3 origins<\/h3>\n
Access-Control-Allow-Origin<\/code>, Content-Security-Policy<\/code> and Strict-Transport-Security<\/code>, so being able to set these headers on all your resources and assets is essential nowadays. With Lambda@Edge it\u2019s now a simple matter of adding an origin response handler to add or modify these headers before the response gets stored in the cache.<\/p>\nX-Amz-Meta-*<\/code> headers. This metadata is useful for us and our deployments, but serves no value to the end-user, so we take advantage of Lambda@Edge to clean up these headers from being sent out.<\/p>\nexports.handler = (event, context, callback) => {\n const headers = event.Records[0].cf.response.headers;\n\n \/\/ Strip out unnecessary metadata headers\n Object.keys(headers).forEach(k => {\n if (\/^x-amz-meta\/i.test(k)) {\n delete headers[k];\n }\n });\n\n function setHeader(k, v) {\n headers[k.toLowerCase()] = [ { key: k, value: v } ];\n }\n\n setHeader('Access-Control-Allow-Credentials', 'true');\n setHeader('Access-Control-Allow-Origin', '*');\n setHeader('Access-Control-Allow-Methods', 'OPTIONS, GET');\n setHeader('Access-Control-Allow-Headers', 'Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control, Cookie');\n setHeader('Strict-Transport-Security', 'max-age=31536000');\n setHeader('X-XSS-Protection', '1; mode=block');\n setHeader('Cache-Control', 'public, max-age=86400');\n\n callback(null, event.Records[0].cf.response);\n};\n<\/code><\/pre>\nServing pre-compressed versions of files<\/h3>\n
Accept-Encoding<\/code> request header. The one small problem with this was that S3 didn\u2019t support dynamic compression like this.<\/p>\n