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, 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 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:


Locally on my MacBook pro:

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


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:

  1. Visit the s3 dashboard.
  2. Click on Create bucket
  3. Give the bucket a name. I named it In our tutorial let’s call it, If the name is already taken AWS will flash validation errors letting you know. I suppose the name must be unique for AWS.
  4. Do not Block public access. We want to make all the contents of our bucket publicly available.
  5. Eventually you will get to “create the bucket” -- when you get there, just create the bucket.
  6. Visit the permissions of your recently created bucket and click on the Bucket Policy tab.
  7. 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": "*"
  8. Click on the properties tab -- should be next to the overview tab -- and then click on the Static website hosting card.

  9. Select Use this bucket to host a website and enter index.html under Index document.

  10. Click save.

  11. Click back into the Static website hosting card and see that AWS s3 has provided you with a link

  12. 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>.

  13. When you visit the above link,, 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.


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

  1. Visit the ACM dashboard
  2. click Request a certificate
  3. select Request a public certificate and then click on Request a certificate.
  4. enter * as the Domain name.
  5. click Add another name to this certificate and enter and
  6. select DNS validation as your validation method and click on Review.
  7. You should see * as your domain name and as additional names: and
  8. Click Next.
  9. Click on DNS validation to verify that you are the owner of and then click Review
  10. Click Confirm and request
  11. 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.
  12. Click Continue
  13. 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.


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, , is not good enough for you. You want something like

  1. Click on Create Hosted Zone at Route53’s dashboard.
  2. Enter
  3. Click Create.
  4. Notice the row NS and the four values to its right. Because I bought my domain from 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 the first hop takes them to namecheap’s DNS which will then direct the computer looking up to AWS , provided that name cheap has the correct NS records.
  5. Open up the file you downloaded from ACM called, DNS_Configuration and copy the value under Record Name on the * row.
  6. Click Create Record Set in Route53 console page.
  7. in Name: paste the value that you copied from the DNS_Configration file minus
  8. for Type: choose CNAME
  9. Return to the file you downloaded from ACM called, DNS_Configuration and copy the value under Record Value on the * row.
  10. Enter the copied value into Value: and click Create.
  11. Repeat the above steps from 5-10 but use the Record Name and Record Value data from the row -- noting that you will need the www. part of the record name.
  12. It will take some time but eventually if you return to the ACM dashboard under your certificate for * you will see an Issued value under the Status column, which verifies that you are indeed the owner of I think it took approximately an hour for me.


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:

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:

  1. Visit cloudfront’s dashboard.
  2. Click Create Distribution.
  3. Select Get Started under Web.
  4. Under Origin Domain Name enter the url that your s3 bucket provided back in step 11 under the s3 section:
  5. Under Viewer Protocol Policy select Redirect HTTP to HTTPS.
  6. Under Alternate Domain Names enter
  7. Under SSL Certificate select Custom SSL Certificate. Within the form field you should be able to select the ACM certificate * (111111111111)
  8. Click Create Distribution
  9. 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

  1. Now let’s return to Route53’s dashboard and lick on your hosted zone
  2. Click on Create Record Set
  3. Enter www for Name:
  4. Type: needs to be set to A - IPv4 address
  5. Set Alias: to, yes.
  6. 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.
  7. Click Save Record Set.

Visit -- you should now be seeing the same page My Site except the url will be and not the insecure and kinda ugly

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

s3 Redirects

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

Cloudfront for redirect

  1. visit the Cloudfront dashboard to create another distribution.
  2. Repeat steps all the steps from the cloud front section above (steps 1-9) However instead of entering under Alternate Domain Names enter Also under Origin Domain Name enter the redirect url from your bucket

Route53 To Give Your Redirect An A-Record

  1. Visit the hosted zone in the route53 dashboard.
  2. 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 to

Now will resolve to

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.