Serverless URL redirect with path preservation through HTTPS

In my previous article, we discussed the updates made in setting up a static website with Hugo on AWS through Terraform, including the one hosting this site. I specifically talked about the domain name change from blog.mehdilaruelle.ninja to mehdilaruelle.com, which posed several challenges:

• Changing the configuration in Hugo’s config.toml (relatively straightforward)
• Managing the SSL certificate (made easier through automation via Terraform)
• Redirecting blog.mehdilaruelle.ninja to mehdilaruelle.com, considering that the domain hosting is on the OVH side.

In this article, we will discuss domain redirection using Amazon API Gateway and AWS Certificate Manager for HTTPS on the source URL. The advantage of this solution is that it is:

• Serverless
• Allows URL rewriting while preserving the path
• Almost free (potentially completely free depending on the number of redirects)
• Does not require AWS Lambda
• Deployable with Terraform

TL;TR: For those interested in deploying a serverless redirect URL, here is the GitHub repository.

Prerequisites

To understand this article, you should:

• Have some knowledge about AWS

To reproduce the example in this blog, you need to:

• Have an AWS account and credentials.
• Have a domain name
• Deploy the infrastructure on AWS using Terraform

What is a Path?

Before delving further into the tutorial, it’s important to have a clear understanding of the concept of a path, domain name, etc. An image is worth a thousand words: Source: https://velog.io/@jch9537/URI-URL

By path preservation, we mean the domain name + the path. However, the solution also allows for preserving the query string along with the path. For simplicity in our explanations and examples, we will focus solely on the path.

The Challenge of Redirection with OVH

First and foremost, it’s important to note that the domain name mehdilaruelle.ninja was hosted on OVH when I wanted to set up a redirection from blog.mehdilaruelle.ninja to mehdilaruelle.ninja while preserving the path in HTTPS.

To implement such redirection on OVH, the only way was to go through an OVH Apache server. Fortunately, it was possible to obtain one for free with the 100M hosting. Once done, you need to enable SSL and modify the configuration in the .htaccess file for URL rewriting.

The following example illustrates the setup when the server is ready and configured:

However, as in my case, if you have a subdomain, it’s not possible to use the free 100M hosting for multisite, and you will encounter the following error:

To accomplish this, I had to subscribe to a higher plan to set up redirection. This seemed like an excessive constraint for such a simple operation, prompting me to explore an alternative.

The Solution with Amazon API Gateway

To implement serverless URL redirection, I used Amazon API Gateway, which provides the ability to perform URL rewriting (specifically, transformation) using its MOCK features and the Apache Velocity Template Language (VTL), all without using AWS Lambda.

The redirection works as follows:

1. The user enters the URL (e.g., https://blog.mehdilaruelle.ninja/post). Here, we refer to it as the source URL.
2. The DNS server hosting the source domain name (in my case, OVH) redirects to our API Gateway. Configuration is needed, and for those curious about the details, I encourage you to check the steps in the GitHub repository.
3. The API Gateway processes the user’s request with the source domain name. AWS Certificate Manager is used to set up our API Gateway with HTTPS (this is free, and the verification process is relatively straightforward). For those interested in learning more about this, the AWS official documentation explains the various steps.
4. The API Gateway rewrites the URL and returns the destination URL to the user.

This leads to the following representation:

You can deploy the solution with Terraform via the GitHub repository.

Zoom on Amazon API Gateway, MOCK, and VTL

Here is an overview of our API Gateway and its different methods:

First, we will look at the Amazon API Gateway methods that will allow us to handle user requests, and then we will briefly touch on VTL.

Amazon API Gateway Methods

We have 2 methods:

• A GET on the root path /: If the user accesses to our site without a path via the source URL (e.g., https://blog.mehdilaruelle.ninja/), we will return the destination URL (e.g., https://mehdilaruelle.com/). No rewrite is done here; instead, we return a static value.
• Any method (ANY) with the path starting with / and any value that follows, represented here as {proxy+}: The PROXY allows us to manipulate the value passed in the URL path. This method will be used for the rewrite from the source URL to the destination URL while preserving the path. To learn more about the proxy resource, I invite you to check AWS documentation on the topic.

Amazon API Gateway Request and Response

Firstly, we need to separate the requests sent by our user to Amazon API Gateway and, on the other hand, the responses sent by Amazon API Gateway to our user.

For those unfamiliar with API Gateway, let’s explain the different steps:

1. Method request: Allows us to set up authorizations on our Amazon API Gateway, check the model, etc. Here, we won’t use the Method request.
2. Integration request: Allows us to indicate the type of service called (e.g., AWS Lambda, AWS Service, etc.) and how the service is called. Here, we use a MOCK, so the Integration request will serve as a passthrough (transmitting the request as is).
3. MOCK: Does nothing special because no backend/service is called.
4. Integration response: This is where the magic happens. We will use the Apache Velocity Template Language (VTL) in the case of the path /{proxy+} to retrieve the value of the path from the request and return the destination URL with a HTTP 301. It looks like this:
5. Method response: Here, the method will add in the Response Header Location with the destination URL.

A brief note on VTL

Some people might be interested in exploring the Apache Velocity Template Language (VTL) within API Gateway, especially for its transformation options (without using AWS Lambda).

The code we use in our solution is as follows:

#set($Path = $input.params().get('path').get('proxy') )
#set($context.responseOverride.header.Location = "https://mehdilaruelle.com/$Path")

In our case, in line 1, we retrieve the path passed by the /{proxy+} method. In the second line, we override the Location header with the destination URL (here: https://mehdilaruelle.com/) along with the path retrieved in line 1.

For the more curious, I invite you to learn more about the multitude of possible transformations in AWS’s official documentation.

Conclusion

The solution we’ve implemented enables serverless redirections while preserving the path, and it’s practically free. To achieve this, we leverage the power of Amazon API Gateway and the Apache Velocity Template Language (VTL), allowing us to avoid using AWS Lambda functions in our case. It’s essential to note that the goal here is not to perform computational operations, for which the use of AWS Lambda would be necessary, but rather to transform the request/response.

For those interested in deploying the serverless redirect URL, the corresponding GitHub repository is available here. Finally, as always, if you have other improvement ideas, topics to explore, or feedback to share, feel free to reach out.