A Simple Way to Create a URL Shortener With AWS

As a software company for digital solutions, we also wanted to design our business cards with digital means. So we added QR codes to our business cards. However, during the design process, we noticed that our URLs were so long that they generated very detailed QR codes. For small business cards, this was not an acceptable solution. So the URLs had to become shorter. Solutions for this already exist via various external providers, but it was important for us to provide the redirects ourselves, since data usage by trackers of external parties are not always transparent and we wanted to ensure data protection.

Manual solution via AWS

Without any programming, this can already be solved using AWS:

1. An S3 bucket is created for static web hosting.

2. A cloudfront distribution is created that is linked to the desired domain and points to the S3 bucket.

3. For each shortened URL, an empty object is created in the S3 bucket. In the process, the metadata ("x-amz-website-redirect-location") is adjusted to include the long URL as the redirect URL. If required, the lifecycle policy can be added to have the object automatically deleted after the desired time. This can be relevant in some use cases, for example when a work-in-progress is shared with a customer.

A prepared setup

Doing it manually is too easy for us, so we solved the setup via code. In our public project, only the domain has to be adjusted to be able to use the setup in our own infrastructure. After that, the redirect objects are created via the CLI:

1$ export AWS_PROFILE=newcubator-newcubator
2$ touch empty
3$ aws s3 cp empty s3://ncub.de/[[NAME]] --website-redirect "[[URL]]"

Since the created objects are empty and created only for metadata, they do not cost any storage space. This makes this serverless architecture very cheap. If caching is enabled, even more cost can be saved: When the URL is called, Cloudfront reads the Redirect URL from the cache, if there is a CacheHit. This makes the response much faster for end users. Furthermore, the cache is stored in EdgeLocations, which, unlike the S3 buckets, are not located in the large data centers such as Frankfurt, Paris and London. The Route 53 network uses significantly more data centers, which are located in Düsseldorf, Amsterdam and Hamburg, among other places. The application thus gains further in performance due to the physical proximity to users. Only if there is no CacheHit, it has to be checked in the S3 bucket in the larger data center.

Integrating familiar communication tools

An important tool for our team is Slack. Slack is used by every department in our company and has already been extended with our own apps with great satisfaction so that the tool supports us efficiently, especially in recurring tasks. It was therefore obvious that we also wanted to support the use of the URL Shortener via Slack. The plan was to create a slash command that would replace the CLI commands: The slash command triggers a lambda function via an API call, which then creates the empty redirect object in the S3 bucket. The fact that you only have to enter a slash command in the usual communication tool means that employees without any prior technical knowledge can now also start the background process.

The following input in a Slack channel

1/short-link https://newcubator.com/team irma

listens for the slash command "/short-link", takes as first parameter the long URL to redirect to and as second optional parameter "irma", which should be the abbreviation for the shortened URL. If there is no desired abbreviation, an automatic abbreviation is generated without the second specified parameter. The corresponding answer you get is

1ncub.de/irma

And so we have the shortened URL, which fits wonderfully on our business cards!

No tracking by third parties

Another advantage of our implementation is that you have full control over the data. Since no external URL shortener is used, tracking data collected by third parties can be avoided. The requests to the generated URLs are logged via Cloudfront in its own S3 bucket, from which tracking data is then read and processed in your company's individual way. In our infrastructure, this is solved via a lambda function. The generation of a request log triggers this lambda function, which filters all relevant data from the new log file and sends the data to the analysis tool of choice, in our case Matomo. As a result, our marketing department always has access to the most up-to-date data in the familiar analysis tool.

More accessibility for technical solutions

Ultimately, it is a technically simple solution. The implementation steps, be it the manual steps or the implementation via our finished project, are easy to understand and therefore accessible to more employees. Individual software can be complex, but it can also be simple. Above all, it should integrate smoothly into the daily work routine. Therefore, easy accessibility of new functions or simplified digitalized processes is essential. For our business card problem, we have found an optimal solution with this requirement in mind. Different departments can use the new function without any hassle and it was even looked beyond the initial need, so that not only the graphics department has a simplified way to work, but also the need of the marketing department was met.

Our project is publicly available on GitHub! We hope to be able to support other teams in their process optimizations. So if you find any application for it, feel free to write us and share your experience!