You are visitor number since November 29, 2022
However, here I am, with a fully functional cloud resume page on the internet. If you thought the journey would be difficult, you underestimate the struggle that went into this. Each and every day, I was struggling to become familiar with new technology, unfamiliar terms, and abstract concepts impossible to grasp. Yet despite that, I managed to complete the cloud resume challenge, and wanted to share my struggles in this post.
The first step of this entire thing was to secure the domain, birajshah.com. I used NameCheap to register the domain, and own it myself. Once I secured the domain name, I realized that I needed the domain to point to AWS' nameservers, so it could resolve to my cloud resume once it was up. I first created a hosted zone in AWS Route 53, for my domain. It then gave me a series of AWS nameservers then I could use for my domain. I then configured the domain to point to AWS' nameservers on NameCheap. I could then move on to configuring my actual website.
I first had to create an S3 Bucket to host my site, which was relatively easy. However, I had to configure website hosting for the bucket, and then get the domain name to point to the S3 bucket as well. This required quite a lot of configuration. First, I had to enable the website hosting on the S3 bucket, and then create a public policy that allows all public access, since it is supposed to be accessed on the public internet. I set the homepage of the bucket to be index.html.
After the original birajshah.com bucket could be accessed over the internet via the HTTP protocol, I had to ensure that when people typed in www.birajshah.com, it would still resolve to birajshah.com. Making this happen required going back into Route 53 and adding CNAME records. Adding these CNAME records was easy enough, it just required going into the hosted zone and creating a new record. After this, accessing any of the three configured domain names (birajshah.com, www.birajshah.com, and resume.birajshah.com) all led to the original S3 bucket configured to birajshah.com.
It is important to note that the HTTP protocol does not encrypt data when it is transferred over the internet. As such, I needed to make the traffic secure by enabling HTTPS. To do this, I needed to get an SSL certificate from AWS' Certificate Manager. The certificate tests if I have access to the DNS information, and whether I am the one who has control over it. If this test passes, then it issues the certificate to me. I added my alternate domain names, which were www.birajshah.com, and resume.birajshah.com, the certificate issued covered all of them. Now that I had the certificate, I had to configure my sites to use HTTPS as well.
Many cloud infrastructures use Content Delivery Networks (CDN's) to cache content and create a better content delivery experience for the user. In relation to enabling HTTPS, I also wanted to employ CloudFront, AWS' CDN, for my static S3 Website. The first step to doing this was configuring my S3 buckets to use HTTPS as well as HTTP. This also meant that my alternate buckets that were supposed to redirect to my original domain needed to redirect over HTTPS instead of just HTTP. Once this was configured, I had to create a CloudFront distribution for the group of domains, and associate the distribution with the certificates that I was issued beforehand.
Creating this distribution also meant that additional CNAME records were created for the distribution's domain names. I had to create a distribution for each alternate domain, which added several records to AWS Route 53. When I accessed the CloudFront distribution URLs, it would direct me to my birajshah.com site, using the HTTPS protocol. One last step was required, however, which was editing my Route 53 A records to point to my CloudFront distribution's domain names. Once this worked, my bucket then utilized AWS CloudFront for its Content Delivery Network.
To make the visitor counter work, I required several things: a database to store the count, a function to update the database when the visitor count increases, and an API to interact with the function. Fortunately, AWS had all three available for me: DynamoDB, AWS Lambda, and AWS API Gateway. DynamoDB simply had a key value pair with an updated record with the total, and AWS Lambda was coded in Python to simply increment that count in the database by 1 each time the site is opened. In order for the website to execute the Lambda function, I created an API endpoint on AWS that was attached to my Lambda function. Every time I accessed this endpoint, the Lambda function would update the count. After all of this was working, I needed to invoke the API using JavaScript on my HTML page.
What did I learn from this? First and foremost, I realized the amount of work that goes in to creating everything on the internet. Just getting a simple task like this to run smoothly was met with so many struggles, long nights, and the finding of typos. I also saw why many of these companies cannot leave it to one developer and one team to create their services, and instead choose to lighten the load at the cost of higher expenses from the need of communication between the teams. This type of thing also requires an intense attention to detail, and without it, the project will never work as you want to. It takes time and patience to undergo such a project as this, but once done, there is a feeling of satisfaction from seeing the final product come together. This project is something that I am glad that I suffered through and is also something that I am proud of.