How it works : The magic, and mostly AWS, behind it
So I got AWS certified in August 2026.
I get to say that it was no easy exam and I rarely experienced that much fatigue afterwards.
But I am very happy to be a professional architect now, and as such I wanted to build something with this newly acquired knowledge.
So to demonstrate it, what's better than my very own website ?
This costed me dozens of hours (9_9)...
More seriously this website uses 4 separate services : S3, CloudFront, ACM and Route 53 (ordered by proximity to internet ascending)
I will detail how each of them are set up to produce this simple website.
S3
About every computing project I took part in are based around files. So I needed somewhere to store those files.
There are lots of options concerning file storage in AWS, but in this scenario only S3 made sense.
Indeed S3 has some fun features like static website hosting, i will talk about it later, and is reasonably priced. So it was the perfect choice.
Now even if I am supposed to be comfortable with all of this, first time is always full of surprises.
I forgot that S3 only serves http. And thus the beautiful journey of "how to secure a website" began.
Starting with bucket policies, a topic that is certainly the most engaging of all falling just behind IAM and OUs.
Policy is on the simpler side bar one detail. Originally I had a simple principal * and read, so everyone could read but not write the content.
As you might know, AWS policies are Deny-Allow-Deny. Meaning that by default permission is "denied".
The original way I used was good because it was simple, but I usually want higher security standarts and everyone and their shiba being able to access the bucket, by roughly any means available, was not enticing to me.
So I had this genius idea of using OACs, or so I thought...
As I do know from the AWS courses, and I literally had the question several times during training and also probably in the exam. You cannot use OACs for a S3 website bucket.
Why ? Because once you turn your bucket static website, it no longer signals like a S3 bucket but rather like a dumb website obviously...
So CloudFront, IAM, whatever will have a hard time using in house authentications required by the very concept of OAC.
Thus I got the infamous 403 error, because CloudFront and S3 could not understand each other.
To counter this I used another solution, less secure but the best available for website hosting : custom header
And then I had yet again another issue, because I had the genius idea of naming the header "pseudo OAC". Which in fact was a dumb choice because S3 only recognizes referal headers if they are named "Referer" (=_=).
In short a lot of self inflicted pain because I did not RTFM ! A dishonorable conduct for an Arch user.
CloudFront
CloudFront is a delivery service, so it helps to, well, deliver things.
Usually for project of this size, you do not need it. But I wanted the website to be well secured and the clients to be really comfortable knowing the website is secure.
One of the main steps for this is to serve https, as said previously S3 hosting only serves http. So I needed something to add a certificate to this connection.
So the main draw to CloudFront was the fact that I could attach certificate easily to it and then serve https, in a sense CloudFront is made for this kind of concerns so it was easy to do.
2 other small concerns originally but that were nice to have eventually, performance and cost.
I initially was not a fan of the "caching optimized" policy, because as I was in free tier TTL is static, and to be fair it was a bit long for the frequent initial updates.
But since it is cached you have faster performance accessing it, and most importantly for me you have less direct queries to S3. S3 is set to standart so query cost is not that big, but reducing it to almost zero is a great plus.
And to increase security, since I cannot use OAC, I set the origin of the distribution with a custom referer.
Architecturally speaking, CloudFront was not mandatory for a simple http serving.
But all the functionality added for a practical cost of 0, was a pretty good deal *(^o^)*.
ACM
ACM was a pretty simple part of this project. It obviously serves certificates so it's not rocket science.
I used it to secure the previous distribution so that YOU, viewer, gets a neat and secure httpS and not a boring http (*O*).
However there's a trap with that one, when you want to use CloudFront you need the certificates in us-east-1.
Again that is something you learn with the certification, but until you are challenged in real life, you tend to forget.
So I lost about 30 min wondering where my certificates got vaporized in eu-west-1, when they were tucked and warm in us-east-1.
It, itself, is nothing special. It serves two domains, the apex one and the sub "www" and is integrated to CloudFront.
The cybersecurity special if I may.
Route 53
Route 53 is a really nice service, really because it is straightforward and convenient while not overly costly.
It is the last AWS service before the great unknown of the public internet, so it has quite a charge on its shoulders ('_').
I registered the domain name through it and had some luck because it was available with .com TLD.
Setup here is pretty simple, A and AAAA alias records for constantinkeuky.com routing to CloudFront. One CNAME for the subdomain www.constantin... routing again to the same distribution and two CNAMEs for each ACM certificate. Finally the NS and SOA that are vanilla, and basically all records as simple routing.
To be fair Route 53 was one of the simplest steps, I just had to understand/remember that to bind subdomains you need a CNAME record.
So there you have it, how this website is born.
I am very proud of it for 2 reasons :
- It is the first project I did myself on AWS
- It is the first time ever I coded a website
It might seems small, but it was very fun and instructive (^o^).
So all in all a good holiday hobby !