For a recent personal project of mine, I needed to quickly and easily redirect and track user traffic to a serverless website I hosted in AWS.
For a recent personal project of mine, I needed to quickly and easily redirect and track user traffic to a serverless website I hosted in AWS. Nothing groundbreaking — just inspect the URL the user had supplied, record a unique identifier in the URL, and then redirect the user to the site.
In my search for good documentation, I often found things that were out-of-date, contradictory, or hard to find. Not a lot of Terraform code either. I wanted to write up this demo to (hopefully) help you avoid some of the same mistakes I made along the way, and arrive at a quick and easy solution for serverless HTTP redirects using AWS.
Architecture & User Flow
Diagram is also available here for direct viewing.
Deployment and Usage
You’ll need the code in my demo repo to deploy this infrastructure.
Check out the README file for deployment instructions. It’s a pretty straightforward Terraform deployment, but there are some important disclaimers and notes in there as well.
After our simple redirect app has been deployed, open up the API Gateway dashboard in the AWS console. Click on the newly created “example-redirect-api” resource.
From here, click the blue hyperlink below “Invoke URL”
This will open a new page in your browser with an error message. This is to be expected, since the route set up in the Terraform code expects
At the end of the URL in your browser, enter
/redirect/youtube-- if all goes well, this should redirect you to the YouTube homepage. Our API+Lambda serverless service is successfully redirecting traffic!
You can test this with other sites by picking another site name at the end of the URL instead of youtube. Try google, reuters, amazon, or whatever other site you’d like!
All the Python code is contained within the
terraform/lambda_code directory, and will execute in AWS as a, you guessed it, Lambda function. The actual code is pretty short, which is what we want for this demo.
Lines 7, 12, and 20 are simply logging for our function.
In line 10, you can see we set the “redirect_site” variable to the value of the “proxy” key of the “pathParameters” parent key of the event that invoked our Lambda (
redirect_site = event -> pathParameters -> proxy). This event is delivered from API Gateway, and is triggered whenever a user visits our API Gateway URL. You can review an example event in my demo repo. The
parse.quote() method is to escape non-URL friendly characters from our user-supplied redirect, in case they’ve somehow slipped into the event.
Down on line 15, we begin to create the response object by creating an empty dictionary. On line 16, we then create a new entry in this dictionary with key “statusCode” and a value of 302 (the HTTP status code we want to deliver to the user). Line 17 just creates an empty body, since we’re going to be redirecting the user anyway.
Line 18 is where the redirect URL is actually set. We create a “headers” key in our response dictionary, and populate it with another dictionary with key “Location” and value “https://www.<redirect_site>.com”. This is what the user’s browser will redirect to once they get our HTTP 302 response.
Finally, on line 22, we return the response object to API Gateway so it can be delivered to the user.
Check out the Terraform files themselves for comments explaining what each resource declaration is and what it does. Let me know if anything is inadequately described or still confusing.
Reviewing Logs in CloudWatch
I mentioned earlier that logging is set up in our Python Lambda function. You can review these logs in the AWS console by going to the CloudWatch dashboard, clicking on “Log Groups” under “Logs” in the left toolbar, and then finding the
/aws/lambda/redirect-lambda-example log group.
From there, just click on the most recent log stream from the list and review the Lambda function’s logs.