My portfolio was already running well on Vercel. Deployments were simple, HTTPS was handled automatically, and I did not have to manage the infrastructure underneath it. The site worked, but I could not clearly explain what was happening behind the deployment.

I wanted to understand how a static website is stored, secured, cached, and delivered, so I rebuilt the hosting layer on AWS. The goal was not to prove that AWS was better than Vercel. It was to build a secure alternative, troubleshoot it when something went wrong, and decide which platform made the most sense for the project.

The Architecture

I exported the Next.js application as static files and uploaded them to a private Amazon S3 bucket. Public access was blocked, which meant visitors could not reach the files directly through S3.

CloudFront became the public entry point for the site. It used Origin Access Control to securely retrieve files from the private bucket. Route 53 handled DNS, while CloudFront delivered the site over HTTPS and cached the static files at edge locations.

The main security requirement was simple. The S3 bucket had to remain private, and all public traffic had to pass through CloudFront.

This setup gave me direct experience with storage, permissions, DNS, HTTPS, caching, and request routing instead of relying on a platform to manage those parts for me.

The 403 Error

My first deployment returned a 403 Access Denied error. At first, it looked like a permissions problem.

Instead of repeatedly changing policies and hoping something worked, I checked each part of the request path. I reviewed the S3 bucket policy, the CloudFront origin, the Origin Access Control configuration, the uploaded files, and the CloudFront cache.

I found a JSON error in the bucket policy and corrected it, but the 403 remained.

The response headers included:

server: AmazonS3

That detail showed me that CloudFront was successfully reaching S3. The connection between the two services was working, so the problem was likely related to the object CloudFront was requesting.

I returned to the CloudFront configuration and found that the Default Root Object field was blank. When a visitor requested /, CloudFront was not automatically requesting index.html.

The requested object did not exist. Because CloudFront had permission to retrieve objects but not list the bucket, S3 returned a 403 response instead of a clearer missing-file response.

I set the Default Root Object to index.html, invalidated the CloudFront cache, and the portfolio loaded successfully. The full issue was diagnosed and fixed in about 45 minutes.

What I Learned

The most valuable part of the project was learning how to narrow down a vague error across multiple services.

Reading the response headers helped me identify where the error came from. Checking the uploaded files prevented me from making unnecessary permission changes. Invalidating the CloudFront cache also made sure I was testing the latest configuration instead of an older cached response.

The biggest lesson was that an access error does not always mean the permissions are wrong. Sometimes the requested file or path is the real problem.

The project also showed me why troubleshooting cloud systems requires looking at the full request path. A browser may display one simple error, but the actual cause can be hidden several services behind it.

Why I Chose Vercel

The AWS proof of concept worked. The portfolio was delivered through CloudFront over HTTPS, the static files were cached, and the S3 bucket remained private.

However, a working solution is not automatically the best production choice.

Keeping the AWS version active would introduce usage-based costs and additional maintenance. For a small personal portfolio with limited traffic, that extra cost and work would not provide enough value.

Vercel already provides managed deployments, HTTPS, CDN delivery, and preview environments without requiring me to keep separate AWS resources running. AWS gave me more control and helped me understand the infrastructure, but Vercel remained the simpler and more practical choice for the current size of the project.

Because of that, I treated the AWS deployment as a tested alternative architecture rather than the permanent production platform. The live portfolio continues to run on Vercel.

The Business Decision

Cloud engineering is not about using as many cloud services as possible. It is about choosing a solution that fits the problem, budget, expected traffic, and maintenance needs.

The AWS version proved that I could design, secure, deploy, and troubleshoot the hosting infrastructure myself. Choosing Vercel for production showed that I could also evaluate cost and operational effort instead of keeping infrastructure running only to make the project look more impressive.

If the portfolio later needs deeper AWS integrations, infrastructure as code, custom security controls, or more detailed logging, the AWS architecture may become the better option. For now, Vercel provides the value the project needs without unnecessary cost or maintenance.

Final Lesson

This project taught me how CloudFront and S3 communicate, how a private origin is protected, and how a missing file can appear to be a permissions problem.

Building the AWS solution proved that I understood the infrastructure. Choosing not to keep it running proved that I understood the tradeoffs.

Powered by Synscribe