This Website is Running Serverless

When you open yazdan.cloud, you are not hitting a server that I own. There is no virtual machine running somewhere on my behalf, no web server to patch, and nothing I have to keep alive at three in the morning. This entire website is serverless, and in this post I want to walk you through exactly how it works and why I chose to build it this way.

So what does "serverless" really mean?

"Serverless" is one of those words that makes it sound like no servers are involved at all. There are, of course, plenty of servers behind the scenes. The difference is that I do not manage a single one of them. AWS does. I do not provision capacity, I do not scale machines up and down, and I do not pay for idle time. I simply upload my files, and the platform takes care of delivering them to anyone in the world who asks for them.

For a static website like this one, built from plain HTML, CSS, and JavaScript, that is a perfect fit. There is no database to query and no backend code that has to run on every request. Each page is already built and ready to be served exactly as it is.

The architecture

The whole thing is assembled from a handful of managed AWS services, each doing one job and doing it well:

• Amazon S3 stores every file and acts as the origin. I enabled static website hosting on the bucket, so my HTML, stylesheets, scripts, and images all live there as plain objects.
• Amazon CloudFront is the content delivery network that sits in front of S3. It caches the site at edge locations around the globe, so a visitor in Singapore and a visitor in London both get a copy served from somewhere close to them.
• AWS Certificate Manager issues and automatically renews a free SSL/TLS certificate, so the site is always served over HTTPS without me ever touching a renewal.
• Amazon Route 53 handles DNS and points the yazdan.cloud domain at the CloudFront distribution.

Put together, a single request travels a very short and very boring path, which is exactly what you want:

Visitor → Route 53 (DNS) → CloudFront (CDN + HTTPS) → S3 (origin files)

How I deploy an update

Because the site is just files in a bucket, deploying a change is a single command. I sync my local folder up to S3 and let the --delete flag clean up anything I have removed:

aws s3 sync ./ s3://yazdan.cloud/ --delete

Then I tell CloudFront to drop its cached copies so visitors see the new version straight away:

aws cloudfront create-invalidation --distribution-id E35EN0QH5TLQ7O --paths "/*"

That is the entire release process. No SSH, no restarts, no downtime.

Why I keep coming back to this setup

• It costs almost nothing. With static files and generous free tiers, hosting a personal site this way runs to a few cents a month, sometimes nothing at all.
• It scales on its own. Whether ten people or ten thousand show up on the same day, CloudFront and S3 absorb the traffic. There is nothing for me to resize.
• There is nothing to maintain. No operating system to update, no web server to harden, no dependencies quietly going out of date.
• It is secure by default. There is no server to log into and no application layer to exploit, just static content served over HTTPS.
• It is fast everywhere. Serving from edge locations means low latency no matter where my visitors are.

The takeaway

You do not need a big, always-on server to put something on the internet. For a personal site, a blog, a portfolio, or documentation, going serverless on AWS gives you a fast, secure, and almost free home for your work, and it frees you to spend your time on the content instead of the plumbing.

This is exactly the kind of practical, hands-on cloud topic I love sharing on my journey towards the cloud. If you would like me to write a step-by-step guide on setting this up from scratch, let me know, and I will put one together. Stay tuned.