AWS Case Study 3 - Serverless URL shortener service
What is URL shortener?
URL shortener is a service on the World Wide Web that generates short URLs from long URLs.
When such short URL is open in internet browser, user is automatically redirected to the original long URL.?
Why people use URL shorteners?
There are several reasons for URL shortening.?
Oftentimes regular unshortened links are aesthetically unpleasing.?
Web developers may pass descriptive attributes in the URL to represent data hierarchies, transaction paths or session information.?
This can result in hundreds of characters long URLs containing complex character patterns.?
Such URLs are difficult to memorize, type out or distribute.?
Thus, short URLs may be more convenient for hard copy publications, social media posts and in text messages which have limit on the max. number of allowed characters (e.g. SMS or Twitter).??
Which basic requirements URL shortener service should fulfill?
URL shortener should be able to:
- generate short URLs from long URLs that users provide
- redirect user's web browser to the original long URL upon accessing the short URL
Can URL shortener service be designed to run on 100% AWS serverless architecture?
Definitely yes.?
We just need to register a short domain name, develop a Lambda function that does the URL shortening magic and integrate it with the following 6 Amazon Webservices:??
- Amazon API Gateway,
- Amazon CloudFront,
- Amazon DynamoDB,
- Amazon Route 53,
- AWS Certificate Manager,
- AWS Identity and Access Management.
How such URL shortener serverless architecture can look like??
Let's take a look under the hood of the Lambda function?
The core of our AWS URL shortener service is residing in the following Lambda function:
Note: this is just a screenshot - an excerpt of the URL shortener Lambda function, if you want to download the full source code including static website content (html+img files), please click here.
This Lambda function handles these 3 types of requests:
- requests to render 'URL shortener' web page, i.e. fetch static web content from the Lambda storage and output it (green lines in the architecture scheme above),
- requests to shorten long URLs, i.e. use algorithm to convert long URL into short one, store in DB and include in the web page content (yellow lines in the architecture scheme above),
- requests to redirect users accessing short URL to the original longer URL (orange lines in the architecture scheme above).
With regards to 1)?
领英推è
If you are interested in more details about how this works, you can read the article that I have already written on this topic
With regards to 2)?
- we allow user to shorten only those URLs which are using https:// or https:// protocols,
- algorithm that generates the path part of the short URL (https://odkaz.link/%%%%) is the following: we take the current number of "milliseconds that elapsed since 1st January 1970 till this moment of Lambda function execution" and convert it into a radix-36 representation. In other words, we convert the timestamp containing just Arabic numerals 0-9 into the text string containing both Arabic numerals and Latin letters. This results in?having only 8 characters in the path instead of 13.
- if exactly the same long URL was shortened in the past, we won't generate a brand new short URL representation of it, but rather provide the user with the already existing short URL,
- as Lambda doesn't provide us with the persistent storage option, we store both long and short URLs in the Amazon DynamoDB table.
With regards to 3)
- in case there is a match between the short URL user requested to visit and the short URL located in the Amazon DynamoDB table, Lambda function issues HTTP status code 301 (Moved permanently) and by using the Location field in the HTTP response header redirects user to the target (long) URL,
- in case there is no match, HTTP status code 404 (Not Found) is issued.??
What else do we need to do to make URL shortener work?
Lambda function is of course not enough for entire URL shortener solution to work.?
You are going to need also these AWS services:
- Amazon DynamoDB - to have persistent storage to hold the URL pairs (long URL, short URL),
- AWS Identity and Access Management - to be able to attach DynamoDB access policy to your Lambda function so that Lambda can do "reads/writes" to your DynamoDB table,?
- Amazon API Gateway - to setup a REST API endpoint which internet browser could reach and through which URL shortener and its features can be accessed,
- Amazon Route 53 - to register a short domain name for your URL shortener service,
- AWS Certificate Manager - to generate SSL certificates for your CloudFront distribution,?
- Amazon CloudFront - to configure static content caching and HTTP to HTTPS redirection as REST API endpoints can be reached only using https protocol,?
Frequently asked questions
1) Let's talk about our favourite topic - the costs. How much does the URL shortener cost to setup and operate?
Setup costs:?few hours of your time + initial fee of $5 for the first year of .link domain name registration.
Operating costs:?
- $0.50 monthly - Route 53's charge for 1 hosted domain zone,
- a recurring yearly domain renewal fee of $5 payable after every 12 months,
- other costs are depending on your traffic, but unless your URL shortener is not used by several hundred thousand times per month, the Amazon Cloudfront costs will be within additional $1/month (if Cloudfront's 12-month Free tier is applicable to you then you won't be charged for 50GB of DATA TRANSFER OUT and 2 million HTTP/HTTPS requests you and your users do each month).
2) I stored image files in Lambda storage as you recommended but when these files are being fetched by Lambda and provided through the REST API to the internet browser, my images are rendered as broken. What am I doing wrong?
Most often this is the case when you forget to configure REST API endpoint properly to handle binary data. Go to the Settings> of your REST API endpoint, scroll down to the Binary Media Types, click on the Add Binary Media Type, into the input field enter: */* and Save the settings.
3) I changed the contents of the index.html file stored in the Lambda function, redeployed the function but still when I visit the URL shortener I see the old index.html content (both old HTML and images). Why?
It is because of Amazon CloudFront caching policy and your Cache-Control header setting which you configured in your Lambda function that sets your static content to expire after 1 year:?var cacheControl = "max-age=31536000";
This value is setup intentionally to help you save potential costs arising from unnecessarily made REST API calls and Lambda function invocations to render your static homepage.
You may override this value and make CloudFront reload your static content if you create an invalidation request.
Navigate to the CloudFront and your distribution and under the Invalidations tab click on the button Create Invalidation, when asked to provide Object Paths enter the following:?
/
/img/*
Invalidating objects removes them from CloudFront edge caches.
4) Can I reach you if I have questions regarding this article and related AWS services that are part of this architecture?
Yes, feel free to get in touch with me via my LinkedIn profile and I will gladly try to help you with any questions you may have or with setting up this entire URL shortening solution.
Work for my mind
2 å¹´try this and send me your feedback pls https://shorturls.link/
5X Snowflake Advanced Data Engineer, Advanced Architect, Advanced Administrator ,Advanced Data Analyst, Data Superhero, SnowPro Core, SnowPro Certification SME, Oracle , SIEBEL EIM; https:/medium.com/@sachin.mittal04;
4 å¹´Really great stuff, was not aware about shorter URL service, thanks for sharing. Could relate to this as I followed your pandemic architectute case study which was again best in terms of integration