Notes from AWS Chalk session at AWS re:Invent 2018 – Lambda@Edge optimisations

CATEGORIES

Tech

Lambda@Edge makes it possible to run Lambda code in Edge locations to modify viewer/origin requests. This can be used to modify HTTP headers, change content based on user-agent and more. We’ve written about it previously, so feel free to read this blog post if you want an introduction: https://nordcloud.com/aws-lambdaedge-running-lambda-code-in-edge-locations/

There are quite a few limitations for Lambda@Edge which depends on which request event you are responding on. For example the maximum response that is generated by the lambda function is totally different depending on if it is a viewer or origin response (40 Kb vs 1 Mb). The function in itself also has limits, such as maximum 3GB of memory allocation and 50 Mb zipped deployment package size.

This means that most use-cases have a need for optimisation. First thing first: evaluate if you really need to use Lambda@Edge. Cloudfront currently have a lot of functionality that is possible to take part of before trying to reinvent the wheel – caching depending on device, selecting headers to base caching on, regional blocks with WAF, etc. Even your origin can sometimes handle header rewrites and other header manipulation, which means that there is no need to spend the time to build it yourself. So you should only use Lambda@Edge if you know that cloudfront can’t do it and that there will be a benefit to rendering or serving your content at the edge.

Optimise before the function

If you’ve decided to use Lambda@Edge you should first look into the optimisations you can do before the function is invoked by the event. Cloudfront does a lot of optimisations for you. It groups requests so that if the response time of the object fetch is the same it will put them together and do only one get instead of sending all of them to the origin. Note that cloudfront is a multilayered CDN which will try to catch the cache from the closest location in cloudfront on miss in a specific region as well, so there is no need to build multi-region caching yourself. Another thing to look at in cloudfront is the origin paths that the event reacts upon. Perhaps the function only needs to react on a very specific HTTP path. If possible it is also always better to let the function react on origin events instead of viewer events which in turn makes the amount of events to react upon fewer and you have higher limitations for function size, response time and resource allocation.

Coding optimisations

When writing the function you should try to utilise global variables as much as possible since they are re-used between invocations and cached on the workers for a couple of hours. Small things such as keeping TCP sockets usable and perhaps using UDP instead of TCP can make a difference especially since Lambda@Edge is synchronous.

Deployment testing

When deploying the function, look at minimising the code with different tools such as browserify. Also note that Lambda@Edge can be deployed with different memory allocations so make sure that you test which size gives you the best bang for the buck – sometimes raising the memory usage from 128 Mb to 256 Mb gives you much faster responses without costing that much more.

S3 performance

If you are fetching content from S3, try using S3 Select to get just what you need from a subset of data from an object by using simple SQL expressions, and even better, try to use cached content in Cloudfront instead of trying to fetch it from S3 or other origins. This makes a lot of sense especially if the data can be cached.

Last but not least: Remove the function when not in use. Don’t use Lambda@Edge if you don’t need to anymore.

If you’d like to learn more about moving your business to the Cloud, please contact us here.

Blog

Minimizing AWS Lambda deployment package size in TypeScript

Our Senior Developer Vitalii explains how to significantly reduce the deployment package size of AWS Lambda functions written in TypeScript...

Blog

Problems with DynamoDB Single Table Design

Single Table Design is a database design pattern for DynamoDB based applications. In this article we take a look at...

Blog

Modular GraphQL server

Read about Kari's experiences with GraphQL modules!

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.








AWS Lambda@Edge: Running Lambda code in Edge locations

CATEGORIES

Tech

AWS has recently introduced Lambda@Edge which gives you the possibility to run Lambda code in Edge locations. What does it mean for CloudFront users and what can you achieve with it?

AWS Lambda is a serverless solution that allows you to run code in the Cloud without actually provisioning and managing any servers. Using Lambda, your code is executed only when needed and scales to your needs. You also only pay for the compute time you have used.

Lambda@Edge extends its capability by allowing you to run Lambda code in AWS Edge locations. This gives you the opportunity to deliver a response to your end users at the lowest latency and customise content for a better user experience. From this, your code is triggered by various CloudFront events.

Events that can trigger Lambda@Edge:

  • After CloudFront receives a request from a viewer (viewer request)
  • Before CloudFront forwards the request to the origin (origin request)
  • After CloudFront receives the response from the origin (origin response)
  • Before CloudFront forwards the response to the viewer (viewer response)

With Lambda@Edge you can:

  • Inspect cookies and rewrite URLs to perform A/B testing.
  • Send specific objects to your users based on the User-Agent header.
  • Implement access control by looking for specific headers before passing requests to the origin.
  • Add, drop, or modify headers to direct users to different cached objects.
  • Generate new HTTP responses.
  • Cleanly support legacy URLs.
  • Modify or condense headers or URLs to improve cache utilisation.
  • Make HTTP requests to other Internet resources and use the results to customise responses

You can now create custom content for your users more easily (and cheaper) than ever before. You can also, for example, identify a user’s device type and distribute the best content to them. It can also be used to identify and validate visitors at the edge and you can detect search engine bots and filter traffic from origin servers with a capture page.

Read more on Lambda@Edge optimisation on my post here.

Here are just a few Lambda@Edge use cases:

Highly Personalised Websites

URL Rewrites

Remote Network Calls

Response Generation At Viewer Request

Access Control at the Edge

A/B Testing

To start using Lambda@Edge you need to associate a function with the CloudFront distribution. The function will be automatically replicated and ready to run at every AWS Edge location.

Creating Lambda functions that integrate with CloudFront:

To view Lambda@Edge limitations, read the this AWS blog postIf you’d like to learn more about moving your business to the Cloud, please contact us here.

Blog

Minimizing AWS Lambda deployment package size in TypeScript

Our Senior Developer Vitalii explains how to significantly reduce the deployment package size of AWS Lambda functions written in TypeScript...

Blog

Problems with DynamoDB Single Table Design

Single Table Design is a database design pattern for DynamoDB based applications. In this article we take a look at...

Blog

Modular GraphQL server

Read about Kari's experiences with GraphQL modules!

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.