How I Made This Site - Hosting At 53 Cents A Month - Part 1

Intro: Watch out! This is a long post and most likely will be updated over time as I go through the motions of setting up a site as I describe below with a friend. If any of the below information is inaccurate or unclear please email me at the information provided under about / contact.

As an application developer, I am very comfortable with local development. Once I have an app or a technology installed and set up -- the set up on my computer or the configuration harness for the technology is usually the hardest part for me -- I am good to go. Once I have what I need running on my machine, I am ready and excited to start developing. However, when it comes to managing software in “the cloud”, I can get a little nervous because managing infrastructure is not my strongest suit.

The fact is sad but true -- unlike applications, their processes, libraries, design patterns and language specifications, I do not understand sufficiently enough in my opinion the systems and infrastructure upon which these applications rely. These systems -- such as, IP/TCP, firewalls, security groups, servers, DNS, TLS, Operating Systems, Virtual Machines and Containerized Environments, just to name a short list of very important systems that many applications rely upon -- make applications available to users for consumption. Without these systems, the applications that we developers create will just stay on our machines, and there will be neither users nor customers to enjoy our creations.

Sure -- I could use the wide gamut of options like squarespace, contently, wordpress.com etc… to host a site and just focus on what I think I’m good at: HTML, CSS, JavaScript. If I had a robust application, I could even use something like heroku where I would be able to have my cake and eat it to: a backend that’s fully customizable with little to no maintenance of its infrastructure. Lately I’ve also been looking into serverless services like Zeit. In any event, I fully embrace the point made here, Embracing NoOps.

By conflating the role of an application developer with the role of an operations engineer, organizations are spending more time managing their infrastructure than the real challenge: delivering features their users will value.

I personally could not agree more, and that is why for robust applications whose infrastructure I am responsible for maintaining I go with Heroku. The dollar amount spent on heroku is significantly more valuable from the perspective of a dev team's effectiveness than the days, weeks -- if not months -- of time and effort it would take to design, maintain and scale infrastructure for which the team is responsible.

However, having said that, learning about systems and infrastructure has given me a less myopic view of technology and of what I do as an application developer. Getting “my hands dirty” with infrastructure has appropriately in my opinion broadened my knowledge as a developer to my benefit. I also now better understand what the hardworking system administrators have to deal with on a day to day basis. With growing understanding of systems and infrastructure, I feel more cross functional as a team member and can better emphasize folks in DevOps and system administration.

As is always the challenge when it comes to learning something, I must say to myself, “How must I learn this?”. While video tutorials, blog posts and books are great, more often than not there is nothing like an appropriately measured side project that targets the skill set and knowledge that I want to learn. To learn more about infrastructure and systems, I decided to set up robskrob.com on an s3 bucket in AWS.

Why not set up the project on either ec2, elastic beanstalk or leverage docker to containerize the app process powering my site?

Originally I planned on using elastic beanstalk as my choice for infrastructure, supporting my site. I even got the site up and running on elastic beanstalk, using Rails and Wordpress. Eventually, I got hit up by AWS billing and learned that just having two elastic beanstalk apps -- one for production and one for staging -- would cost me roughly $20 to $30 a month. For my personal site, that was way too much money for me. For affordability reasons I decided to host my site with s3.

Now, let’s get to what I used and how I did it to make my current site.

Here’s a list:

Remotely:

s3, for hosting
s3 redirects non www traffic, robskrob.com to www.robskrob.com so my site has one uniform address.
cloud front to allow for TLS and to act as a CDN
ACM to provide my domain name with a certificate
route53 for DNS

Locally on my MacBook pro:

a deploy script leveraging AWS’s aws cli to upload html, CSS and JS files to the s3 bucket
of course an app process (I use Rails and Wordpress -- more on that later) that relies on mysql and redis
three dot files that let me leverage environment variable data per QA, Production and local environment

Let’s tackle the first group of remote technologies that allow me to make this site, robskrob.com, publicly available on what we commonly refer to as, the internet.

s3

s3 hosts my site. Meaning, s3 stores my HTML, JS and CSS files. Here’s a step by step guide to how I set up a bucket that works for my site:

Visit the s3 dashboard.
Click on Create bucket
Give the bucket a name. I named it www.robskrob.com. In our tutorial let’s call it, www.extremedogwalking.club. If the name is already taken AWS will flash validation errors letting you know. I suppose the name must be unique for AWS.
Do not Block public access. We want to make all the contents of our bucket publicly available.
Eventually you will get to “create the bucket” -- when you get there, just create the bucket.
Visit the permissions of your recently created bucket and click on the Bucket Policy tab.

Enter the following permissions -- as of 07/21/2019 these permissions provided public access to a s3 bucket:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::www.extremedogwalking.club/*"
    }
]
}

Click on the properties tab -- should be next to the overview tab -- and then click on the Static website hosting card.
Select Use this bucket to host a website and enter index.html under Index document.
Click save.
Click back into the Static website hosting card and see that AWS s3 has provided you with a link http://www.extremedogwalking.club.s3-website-us-east-1.amazonaws.com.
Click on your bucket and upload a file called, index.html. Add some HTML boiler and just for fun in the body place <h1> My Site </h1>.
When you visit the above link, http://www.extremedogwalking.club.s3-website-us-east-1.amazonaws.com, the browser takes you to the above url and receives the index.html file. You should see the text My Site in the page of the browser.

For a potentially more thorough tutorial, here’s a tutorial on hosting a static site with s3.

ACM

AWS Certificate manager let's you create a verified certificate which enables you to enable https -- SSL/TLS -- for your hosted site so network communication can be secure. TLS is a topic that deserves it's own post but for now, I will just guide you through the steps I took to create a TLS certificate so I could enable a secure network protocol for clients exchanging data with robskrob.com:

Visit the ACM dashboard
click Request a certificate
select Request a public certificate and then click on Request a certificate.
enter *.extremedogwalking.club as the Domain name.
click Add another name to this certificate and enter www.extremedogwalking.club and extremedogwalking.club
select DNS validation as your validation method and click on Review.
You should see *.extremedogwalking.club as your domain name and as additional names: extremedogwalking.club and www.extremedogwalking.club.
Click Next.
Click on DNS validation to verify that you are the owner of www.extremedogwalking.club and then click Review
Click Confirm and request
Click on Export DNS configuration to a file to get access to the record values that you will need to confirm that you own this domain.
Click Continue
Head over to Route53 to set up DNS and finish up the verification process so you can own a certificate that will allow you to host your site using https.

Route53

DNS is a topic deserving of its own post -- most likely multiple ones. I’ll just take you through the somewhat rudimentary steps in setting up DNS for your domain name because chances are, http://www.extremedogwalking.club.s3-website-us-east-1.amazonaws.com , is not good enough for you. You want something like https://www.extremedogwalking.club.

Click on Create Hosted Zone at Route53’s dashboard.
Enter extremedogwalking.club.
Click Create.
Notice the row NS and the four values to its right. Because I bought my domain from namecheap.com I had to insert those NS records into namecheap’s dashboard under the domain’s management area. If you purchased your domain from somewhere that was not AWS Route53 then you will most likely will need to do the same thing I did -- copy the four NS records and paste them into whatever console is provided by the company you purchased your domain. Effectively what this does is, when a computer looks up the domain extremedogwalking.club the first hop takes them to namecheap’s DNS which will then direct the computer looking up extremedogwalking.club to AWS , provided that name cheap has the correct NS records.
Open up the file you downloaded from ACM called, DNS_Configuration and copy the value under Record Name on the *.extremedogwalking.club row.
Click Create Record Set in Route53 console page.
in Name: paste the value that you copied from the DNS_Configration file minus .extremedogwalking.club.
for Type: choose CNAME
Return to the file you downloaded from ACM called, DNS_Configuration and copy the value under Record Value on the *.extremedogwalking.club row.
Enter the copied value into Value: and click Create.
Repeat the above steps from 5-10 but use the Record Name and Record Value data from the www.extremedogwalking.club row -- noting that you will need the www. part of the record name.
It will take some time but eventually if you return to the ACM dashboard under your certificate for *.extremedogwalking.club you will see an Issued value under the Status column, which verifies that you are indeed the owner of extremedogwalking.club. I think it took approximately an hour for me.

Cloudfront

Is a CDN that allows for anyone around the world equal and quick access to the hosted assets in your s3 bucket -- HTML, CSS and JS. Without Cloudfront we would have two problems:

Computers accessing your site from Virginia will have a faster time doing so than folks in the Philippines -- or anywhere else in the world.
Your site will never allow for https, which allows for encrypted data to pass from the computer with the browser requesting access to your site using HTTP to the s3 bucket hosting your assets. This is a big problem because without https the data passing between the client’s browser and your bucket will be in human readable format and subject to one of the many forms of hacking a person’s private information, like, a credit card number, provided that you site allows for users to enter sensitive information like that into a form for example.

Given the above two problems, we definitely want to enable https for communication between our s3 bucket and another’s computer acting as a client with a browser. To do this, we need to take the following steps:

Visit cloudfront’s dashboard.
Click Create Distribution.
Select Get Started under Web.
Under Origin Domain Name enter the url that your s3 bucket provided back in step 11 under the s3 section: http://www.extremedogwalking.club.s3-website-us-east-1.amazonaws.com
Under Viewer Protocol Policy select Redirect HTTP to HTTPS.
Under Alternate Domain Names enter www.extremedogwalking.club.
Under SSL Certificate select Custom SSL Certificate. Within the form field you should be able to select the ACM certificate *.extremedogwalking.club (111111111111)
Click Create Distribution
Return to the dashboard and notice the Pending state. For this state to change from Pending to Enabled cloud front may take a few hours. The Status column will also say In Progress, and we will have to wait until it changes to Deployed. For better or for worse, a lot of System Administration work involves sitting around and waiting for things to happen so be sure to work on tasks asynchronously in order to not be blocked constantly and indefinitely.

Cloudront and Route53 to associate the CDN with its DNS

Now let’s return to Route53’s dashboard and lick on your hosted zone extremedogwalking.club.
Click on Create Record Set
Enter www for Name:
Type: needs to be set to A - IPv4 address
Set Alias: to, yes.
Set Alias Target: to the Cloudfront Domain Name value — visit the dashboard of cloud front and you should see a row Domain Name with a corresponding value in the row. For this to work of course your cloud front distribution has to have successfully been Enabled under the its State column and Deployed under the Status column. Moreover, cloud front also must reference your Issued ACM credentials.
Click Save Record Set.

Visit www.extremedogwalking.club -- you should now be seeing the same page My Site except the url will be https://www.bucket.com and not the insecure and kinda ugly http://www.extremedogwalking.club.s3-website-us-east-1.amazonaws.com.

At this point we may be happy enough but other’s may notice a critical problem: https://extremedogwalking.club does not exist. Moreover, even if it did exist, how can I rewrite https://extremedogwalking.club to https://www.extremedogwalking.club? Thankfully, s3 has another awesome feature, redirects.

s3 Redirects

repeat steps 1-8 in the above s3 section but instead of naming your bucket www.extremedogwalking.club name the bucket extremedogwalking.club.
Click on the Properties tab of your bucket and then click on the Static website hosting card.
Select Redirect requests and in the Target bucket or domain section enter www.extremedogwalking.club and make sure protocol is set to https.
Click save

Cloudfront for redirect

visit the Cloudfront dashboard to create another distribution.
Repeat steps all the steps from the cloud front section above (steps 1-9) However instead of entering www.extremedogwalking.club under Alternate Domain Names enter extremedogwalking.club. Also under Origin Domain Name enter the redirect url from your bucket http://extremedogwalking.club.s3-website-us-east-1.amazonaws.com

Route53 To Give Your Redirect An A-Record

Visit the hosted zone extremedogwalking.club in the route53 dashboard.
Repeat all the steps from Cloudront and Route53 to associate the CDN with its DNS in creating an A-Record. However, next to Name: leave it blank and for the Alias Target enter the cloud front distribution that points to your bucket, serving as a redirect for extremedogwalking.club to www.extremedogwalking.club

Now https://extremedogwalking.club will resolve to https://www.extremedogwalking.club

Also observe how any http urls resolve to their correct and corresponding https urls.

Admittedly this was a very lengthy post and will probably be subject to edits as I should go through all of the above steps again just to make 100 percent sure I did not miss anything. If you made it at the end of this post, congratulations! That was a lot to take in. If any of this is unclear please visit the contact me part of this site and shoot me an email. Eventually I will have comments on this post but until then feel free to send me a message via email.

The next part to cover is my local set up where I develop my site and then upload all the web assets to my s3 bucket. Right now, my site is just a h1 tag of My Site, which is fairly useless. In my next post I will show how I bind the above cloud systems nicely to an application development that is not only fast and flexible but also dirt cheap, costing this developer only 53 cents a month to run a custom and fully operational website.