Functions at the edge

When building services on AWS, Amazon CloudFront acts as a high-performance content delivery network (CDN) for your core services/origin. They achieve this by having a widespread network of edge locations globally to handle requests, which significantly reduces latency by caching content closer to the users.

To add logical functionality to the edges, AWS gives you two serverless options: CloudFront functions and Lambda@Edge. Both these services intercept requests from clients and allow for processing, such as modifying headers or checking JWT tokens, before the request reaches your core services.

What is Lambda?

Say you wanted to run a small program without the hassle of worrying about Linux servers, how to run and maintain them. Remembering all those Linux commands that are confusing or easy to forget, well, with Lambda, you can run code on the cloud without having to run a server of any sort. You press run, and it runs, and you have different ways of hitting that run button, so it can do pretty much anything you can code. It's similar to hitting the play button in VS Code to run your program, but in the cloud instead.

Say you wanted something to happen every week, with EventBridge + Lambda, that is totally possible and quite easy. Say you wanted to make an API Gateway without worrying about REST API frameworks. Look no further with API Gateway + Lambda integration. You write the code and don't need to worry much about infrastructure provisioning; it's FAAS( Function as a service ).

FAAS is an industry term for saying; you provide the code and we will run it for you

With AWS Lambda, you get a generous free tier, which includes 1 million requests and 400,000 GB-seconds of compute time every month. This essentially means that if you have a program that will have low traffic, Lambda is a cost-effective way of running it compared to running an EC2 instance 24/7. This also means that if your Lambda function doesn't run, you pay nothing.

Lambda is considered Stateless, where the function won't remember what it previously did; however, that can be solved by saving the data to DynamoDB, which is itself a serverless NoSQL DB.

Cloudfront?

AWS CloudFront is what the industry calls a CDN (Content Delivery Network). Let's go over this with a simple analogy, say you went to your favourite clothing store and found a jumper that you really liked. You wanted to do the click and collect option, but that store doesn't actually have it in stock. They will let you order it, but in the background, the store has actually put in an order to either their main warehouse or another of their stores for that item. That item then gets shipped to your store of choice, where you can collect the item.

This is the same thing CloudFront is doing; it's essentially an entry point into your AWS-based application that is physically close to you. If that entry point has the thing you want, you get it straight away; if not, it has to request it from the central location of the app, wherever it is. Once that has been sent back to the entry point, it's then cached, so if you ask for the same thing again, it will have it ready for you.

With Cloudfront, you are able to run functions at the edge locations before the request even hits your main app, and this is useful for filtering bad requests from unauthorised requests or for simply checking JWT tokens, but there are two ways to do this.

Cloudfront Functions

Cloudfront functions are the first way we can run a small program to intercept and deal with requests at the edge locations. A couple of restrictions include no network access or not being run for longer than 1ms. You're also restricted to just JavaScript as your language of choice; however, if you can overcome all these restrictions, it's the cheapest way to run functions at edge locations.

Lambda@edge

The alternative to running CloudFront functions is to use Lambda@edge instead. It costs more to run but has way more features, so it's a bit more useful. Firstly, you're not constrained to 1ms but instead to 30 seconds. It also supports all the lambda native languages like Python, Go and Java. Most importantly, it also supports network access, so it can talk to other services like DynamoDB for authentication at the edge if you want to.

A downside to lambda@edge is that it adds latency to every request since it is generally slower than CloudFront functions. Lambda@edge is also restricted to x86_64 only and not ARM.