Who Am I?
Hello, my name is Maurice Murphy and I’m a self-taught full-stack developer. With nearly a decade of experience building React, React Native and Node applications. I'm transitioning into Cloud Engineering and targeting AWS roles by Q3 2026. This is the first project in that journey. While I’ve worked with Amazon Web Services in the past (S3), this is by far the most extensive experience I’ve had with the platform thus far. While this is a portfolio project, my intentions are to create an end-to-end ecosystem all via AWS. The overarching goal cost efficiency, as well as, pure efficiency. This means only using services that are necessary for completing the task at hand. As someone who is studying for the SAA-C03, it is easy to get overwhelmed by the sheer amount of services provided by AWS. This is what I chose to build.
What Did I Make?
I built a serverless URL shortener, how it works is actually quite simple. The user copies a url, paste it the input field, they then get a short code back in return. From there, the user clicks the links and gets redirected to the desired destination. The services used were Lambda, API Gateway, DynamoDB, S3, and CloudFront. Honestly, the goal was not to reinvent the wheel, but to become more comfortable with creating systems and understanding infrastructure. Through my full-stack experience, I would unintentionally create somewhat complex systems. However, this project was my attempt at intentionally doing so.
What’s the purpose?
I chose Lambda for the API layer instead of running a server on EC2. This app doesn't need a server running 24/7, it only needs compute when someone shortens a URL or hits a short code. Lambda runs the Python function on demand, scales automatically, and costs essentially nothing at this traffic level. Although I'm somewhat new to Python, it was a welcomed experience to expand the coding knowledge.
For the database I chose DynamoDB over RDS. The access pattern here is simple, look up one short code, get one URL back. That's a single key lookup. NoSQL was the right decision for this app. I'm also very comfortable with NoSQL through my experiences with MongoDB/Mongoose, so I felt right at home with it.
As for the API Gateway, it was the only way to give Lambda a public HTTP endpoint. Lambda is simply a function with nothing else. The API Gateway connects my Lambda function to the internet. Without it, Lambda has no public address — nobody on the internet can reach it.
My react app is actually sitting in a S3 bucket. It is just four files total: an index.html, a CSS/JS assets folder, and two SVG images. The database interaction happens on the backend through API Gateway and Lambda, not in these static files. However, similar to Lambda, S3 needs to be connected to something for it to work properly. CloudFront provides security via HTTPS and OAC. OAC is particularly useful because it allows my S3 bucket to be entirely private. Everything was not smooth sailing and CloudFront (by far) was the one service that gave me the most headaches. That being said, it was not the only service that required tinkering.
Finally, I used IAM to give my account least privilege. This was my mindset when I scoped down IAM for Lambda to PutItem and GetItem on one specific DynamoDB table. Even if something went wrong with my Lambda function, the issue is contained to exactly those two operations on that one table. Nothing else in my AWS account is accessible.
Here’s Everything That Went Wrong
The first came before I wrote a single line of code. My IAM user, which I created specifically for this project, didn't have permission to create roles. The problem is, Lambda automatically creates an execution role when you create a function. My user did not have the required permission, iam:CreateRole. So the easy fix was to add the right permission via my Admin Account. The lesson there was to ensure that I check what permission my IAM user has before provisioning resources.
The second error was a simple region mismatch. I created my Lambda function in us-east-2, but my DynamoDB table was set in us-east-1. Since everything else was set in us-east-1, I just changed the Lambda region to that. That was not the only issue I faced with Lambda though. In fact, I was actually still having an issue writing to DynamoDB.
My third error was that the execution role only had CloudWatch logging permissions by default. I was forced to temporarily add full DynamoDB access, AmazonDynamoDBFullAccess. Once I was able to confirm everything worked, I replaced that permission with a custom policy scoped to exactly two actions: dynamodb:GetItem and dynamodb:PutItem. This is the concept of least privilege in action.
There’s also the boto3, the AWS SDK for Python, being set to the wrong region because I failed to explicitly define one. The fix was just passing region_name='us-east-1’ to boto3.resource(). Again, the fix was simple enough and honestly I should get into the practice of always hardcoding the region.
CORS was the most frustrating error to deal with by far. My React frontend on localhost was blocked from calling the API Gateway endpoint because the browser sends an OPTIONS preflight request before every cross-origin POST. API Gateway was returning 404 on OPTIONS because that route didn't exist. The fix required four separate steps. First, I added OPTIONS routes in API Gateway. Second, was adding CORS headers to every Lambda response. The third fix was adding an explicit OPTIONS handler in Lambda. Finally, it came down to scrapping and recreating the entire API Gateway when the deployment changes failed to take effect. CORS requires headers in both API Gateway AND Lambda. The preflight route must exist and Lambda must handle it explicitly.
Ultimately, CloudFront was the final hurdle. 403 errors kept coming up even after checking the bucket policy, which was correct. The problem was that I was using the S3 website endpoint opposed to the REST endpoint. The S3 website endpoint is not compatible with OAC. Upon switching to the REST endpoint, attaching the OAC correctly, and setting the Default root object to index.html, everything finally worked. The S3 bucket is now fully private. Only CloudFront can serve the files.
Each of these errors taught me far more than a tutorial or course could.
Here's What's Next
This is the first of three projects I'm building as part of my Cloud Engineering portfolio. The next one rebuilds this entire infrastructure using Terraform. Thus, no console clicking, everything defined as code.
Live demo: https://d1ft8ojjt95ptr.cloudfront.net/
GitHub: https://github.com/murphym757/serverless-url-shortener
I'm targeting Cloud/DevOps Engineering roles by Q3 2026 and currently studying for the AWS Solutions Architect Associate certification. If you're hiring or know someone who is, I'd love to connect.
Top comments (0)