Redirects and rewrites with Edge computing

💬 Intent

Edge Computing is an architectural pattern that lets you bring computational resources (processing, data, etc.) closer to where it's needed in order to improve response times and save bandwidth used on requests.
Within AWS, CloudFront is the Content Delivery Network (CDN) service used to speed up distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users.

😖 Problem

Imagine a scenario where you have a new website under a new domain, and you would like to forward users to that new website or even forward them to a different website according to geographical location or device.

The simplest and intuitive solution would be to create entry points for each of these different scenarios.

How laborious would that be 🥵.
There is another approach, and that's why this article was written in the first place.

😃 Solution

The solution involves using CloudFront in association with Edge Computing and setting up rewrites and redirects.

• Redirects- works at the client-side(browser), involves the process of sending a client to a different URL than the one requested, meaning that the URL you see in the browser will update. This can be used to from an old URL to a new one, to redirect based on user location or device or to implement security mechanisms by redirecting HTTP to HTTPS.

• Rewrites- works at the server-side, is the process of modifying the request made by a client (usually a browser) before it is passed to the origin server. This can be useful for a variety of reasons, such as to clean up de URL, to add or remove query parameters, or to change the request method. The changes that will be made won't be visible to the user.
  As the time of writing of this article there are two main types of edge compute features that can be leveraged by CloudFront which are CloudFront Functions and Lambda@Edge.

💡Applicability

Lambda@Edge

As can be noted in the figure above Lambda@Edge is directly facing the origin, so Lambda@Edge functions will be triggered for requests that have been evaluated at the CloudFront caching Layers hence if there is a response already cached that one will be served back to the viewer, saving function invocations. This will not only speed up the response, but it will also help with reducing costs for your redirects as the Lambda will be triggered only if there is no response cached.

• URI Redirects- Lambda@Edge is a good candidate as this type of use case can normally be cached. This is useful when trying to redirect users from an old page that for some reason the admin wouldn't want them to see or it isn't available anymore.

• Geo Location Redirects- commonly used to redirect users of a country to the proper page of their country.

• Device Redirects- commonly used to redirect the viewer to the proper page of the website, based on the user device.

• URI based rewrites- in this kind of scenario the browser won't be redirect to a brand URL, instead it will be possible to see the originally requested URI, but the content from will be pulled from a different path or backend or a different Origin.
  As an example, let's say you have a browser sent a request to the resource www.almeidadealmeida.com/best-friends.html, but you would like to get content from another backend path, without the viewer(browser) knowing about this. Lambda@Edge would be used to do a URI rewrite and actually go to the Origin to request to a URI such as www.almeidadealmeida.com/friends.html.

CloudFront Functions

The use cases handled by CloudFront functions are the ones that normally would be evaluated before they get to the CloudFront Cache thus making sure all requests are being evaluated.
CloudFront functions is a more lightweight compute version that is executed at each Edge Location provided by CloudFront.
Below are some scenarios where CloudFront functions are suitable:

• Dynamic Geo Location Redirects- using Lambda@Edge for geo location redirects is useful when the redirected response can be cached and served to subsequent requests. But if the redirected response is going to be somehow dynamic it would be better to use CloudFront Functions. If we allow our Lambda@Edge functions to triggered very often, what will be the case for dynamic responses, it will cause costs to increase, therefore using CloudFront Functions is a better suit for this scenario.

• Cookie Based Redirect - cookies are small pieces of information that are sent to our browser when we visit a website. They make it possible to a website remember information about your visit, which can both make it easier to visit the site again and make the site more useful to you.
  This redirect scenario is helpful to identify if the request coming in had cookies set which can then used to identify a user or just then redirect the user to a sign-in page.

• Bot Signatures Based Rewrite- this scenario involves a new service called Web Application Firewall (WAF) it can help you increase the security posture of your application by blocking common Web Attacks as well as allowing you to enhance its capabilities by creating your own rules. One offering is a rule that helps protecting against most common bots today some of them will be blocked by default, which are normally bots that you do not want to hit our Web site, but others will be allowed through, such a social media and search engine bots.
  So, in conjunction with CloudFront Functions it would be possible to allow the bot through their firewall, but instead of pulling the resource the bot is requesting, they would like to serve a different page/resource.

🤔Conclusions

As seen before Lambda@Edge and CloudFront Functions can be used to almost the same use cases, however knowing which to use in each scenario is crucial.
As can be seen in the diagram Lambda@Edge is directly facing the Origin and are triggered after evaluation by CloudFront caching layers, hence is it suitable for situations where the response can be cached meanwhile CloudFront Functions are suitable for lightweight computations as they are run closer to users and serve every request landing on CloudFront.