Gabe Bidot

After a good deal of trial, error, and back-and-forth problem solving, my website is finally live on Amazon Web Services (AWS). Getting to this point wasn't as simple as uploading files and calling it a day. It took multiple services working together, several troubleshooting sessions, and even collaboration with AI coding assistants to push past sticking points.

This experience taught me a lot about the complexity of cloud hosting, the benefits of having complete control over infrastructure, and why there will always be a case for using third-party platforms.

⸻

The Complexity of Hosting on AWS

What most people expect when they hear "host a website" is something quick and straightforward. AWS doesn't work that way. It gives you the building blocks, but it's up to you to assemble them properly. In practice, hosting a simple static site required working with:

Amazon Simple Storage Service (Amazon S3) for file storage and static website hosting
Amazon CloudFront as the content delivery network that distributes content worldwide
Amazon Route 53 for DNS, handling the domain and pointing traffic to CloudFront
AWS Certificate Manager (ACM) for SSL/TLS certificates so the site runs securely over HTTPS
AWS Identity and Access Management (IAM) for permissions, access policies, and bucket control

Each of these services has its own purpose, and each comes with details that can derail progress if you miss a step. My first attempt failed when a bucket policy returned an AccessDenied error. CloudFront refused to connect properly until I set up the origin access control. Even once everything was technically in place, Route 53 took time to propagate DNS changes, which meant hours of waiting before I could even test if it worked.

The challenges went deeper than configuration alone. My Next.js site had to be set up for static export since S3 only serves static files. I ran into 403 errors from CloudFront when the Origin Access Control wasn't configured properly. Even after deployment worked, smaller problems showed up, like every blog post displaying the wrong date because of timezone formatting. And when I tried to fix blog styling with Tailwind's typography plugin, it broke other pages due to compatibility issues with Tailwind v4.

What felt like overcomplication eventually made sense. AWS isn't designed to hide the details. It is designed to give you control over them.

⸻

The Benefits of Building It Yourself

Despite the frustration, there were clear benefits to doing this work myself.

First, I now fully understand how my website is delivered. From S3 storing the files, to CloudFront caching them worldwide, to Route 53 making sure my domain points to the right place, I know what's happening behind the scenes. That visibility is something I wouldn't get from a one-click setup elsewhere.

Second, the infrastructure is enterprise-grade. The exact services I used are the same ones that power large-scale businesses. That means my personal website is benefitting from the same reliability and global reach as companies that serve millions of users.

Third, the costs are minimal. Once configured, hosting a static site through S3 and CloudFront costs almost nothing. What you pay for is knowledge up front. The monthly bill ends up being pennies compared to traditional hosting services. My actual AWS costs come out to less than a dollar per month for storage and CDN requests.

The biggest benefit though is learning. Building this myself gave me more than a website. It gave me hands-on experience with the mechanics of cloud hosting, which deepened my understanding in a way that certifications or documentation never could.

Once the infrastructure was in place, I even automated the deployment process. What started as manual steps through the AWS console became a simple bash script. Now a single command handles everything: building the Next.js site, syncing files to S3, and invalidating the CloudFront cache. Every deployment that once took multiple browser tabs and console commands now runs with npm run build && ./scripts/deploy.sh.

⸻

The Case for Third-Party Hosting

Even after successfully standing up the site, I came away with a renewed appreciation for third-party platforms. Services like Vercel, Netlify, or managed WordPress hosting make this process far easier.

Their value is simplicity. They abstract away the details that caused me trouble: bucket policies, origin access control, DNS propagation, and certificate validation. With a third-party service, you point to your code, click deploy, and your site is online. Vercel would have handled my Next.js deployment automatically, with no static export configuration required. Ironically, my CyberLab project is hosted on Vercel for exactly this reason.

That simplicity comes at a cost. You give up control, accept some level of vendor lock-in, and lose the ability to fine-tune your infrastructure. For many projects, that trade-off is worth it. For me, I wanted to feel the weight of configuring every piece, even if it meant longer nights and error messages along the way.

⸻

The Takeaway

The process of hosting on AWS reinforced that the platform is not difficult for the sake of being difficult. It is designed for control and flexibility. That comes at the cost of complexity, but it also brings the benefit of scalability and security.

If your priority is speed and ease of use, a third-party service will deliver exactly what you need. If your priority is control, ownership, and the opportunity to learn how the internet is delivered in the modern cloud, AWS is worth the effort.

For me, the journey mattered as much as the outcome. The end result is a functioning website. The real value is the understanding I gained along the way.

⸻

Disclaimer: The views and opinions expressed in this post are my own and do not necessarily reflect the views of Amazon Web Services (AWS) or its affiliates.