Static Web Content and AWS

Blunt Jackson
Dec 24, 2019 · 8 min read

Cloud9 + S3 - Route 53 = Rapid Static Web Site

AWS Nomads #2: The scrappy internet app developer will always need a quick way to get static content flowing. Everything here can be done with a mobile web browser.

The Cloud is Here to Serve You

Ingredients for this recipe:

  • 1 web browser, mobile or otherwise.
  • 1 S3 bucket
  • 1 Cloud9 instance (which creates 1 EC2 instance)


  • 1 Internet domain

Not Recommended:

  • AWS Route53

What are we building?

You could call it a static web site, but for many we developers, what we are really talking about are the static assets that back a dynamic website. Either way, this recipe is for you.

But for this example we are going to set up a full static web site on a new domain.

Step 1: (Optional) Use your developer AWS account.

If you haven’t read “Securing Your AWS Development Experience” you can review that to understand why using the root AWS account is not such a fantastic idea. So, either set up a rights-restricted developer account and use that for the remainder of this exercise, or proceed at your own risk using your root account.

Step 2: Create your Dev Box

First of all, you do not need a developer box in order to create a static web site. If you have a setup with a good code editor and local storage (e.g., a laptop), you can do everything from your laptop or other local computer and skip the Amazon developer box.

However, for the nomadic developer it makes sense to keep a developer box within AWS; and it becomes a convenience for all developers. This ends up costing 5–6 bucks a month, but it will be your monthly expense with the highest utility and value. Just a few quick benefits:

  • Easy access from mobile devices;
  • Good code editor from any web browser;
  • Convenient integration with other AWS services, including command line AWS access;
  • All the usual cloud benefits in case your local device is lost or damaged.

That’s the why, here’s the how:

1 — In your AWS management console, select Cloud9 from “Developer Tools” section. (Optional: read through all the documentation.)

2 — Create Environment. Give it a name and, if you want, a description. Neither of these have any inherent significance, but a name like “DevBox” is handy if you have other EC2 instances in your life.

3 — Configure Environment. The default settings are your best and most affordable options:

4 — Review your settings & create the environment. It will take a minute or two to spin up the EC2 instance and get you running:

5 — When it is done, it drops you into the Cloud9 editor, with a ReadMe as the file you are looking at:

Note the bottom panel: that’s your command line on the EC2 instance, running bash. The left panel is your standard file tree. You can use command line tools or the interface to manipulate files, folders, set up anything you want about your dev environment, and so forth. You are now ready to develop your website.

Step 3: Create your Website!

I’m going to create a folder for it, and add my index.html.

Step 4: Create your S3 Bucket

The key to all of this is serving the static assets from an S3 bucket, and this is important — the S3 bucket needs to have the name of the domain you are going to be serving, including a subdomain. If you are going to be serving “” then you want your s3 bucket to be “” — and you will configure your DNS to forward “” to the www subdomain. (The subdomain does not matter, but www is traditional.)


1 — From the management console, select S3.

2 — Hit the Create Bucket button.

3 — Name your bucket. Very Important: As noted above, the bucket name should be the full domain of your website.

4 — Configure options & Set permissions. The default configuration is fine for now, but when setting permissions, uncheck the “Block all public access” option. This is going to be a static web site, so we need the public to have access. (Note we will need to do this in two more ways before it works; the static website requires all three steps!)

The default has the top check box checked; I unchecked it for this exercise.

5 — Turn on static hosting. Now that your bucket is created, you need two more permissions steps, and the first is static hosting:

  • Click on your bucket from the S3 default page.
  • Choose the “Properties” tab.
  • Click on the “Static Website Hosting” box.
  • Select the option: “Use this bucket to host a website”
  • Note the endpoint, you will need this later. You can always come back to this window, or cut and paste that endpoint to a more convenient location.
  • Also note the default pages.
  • In the following screen I am setting up a new website, “”

6 — Set permissions for the bucket. You might have thought the previous two steps were enough information for Amazon to consider this a public website, but not so. There is one more step, and that is to make the bucket world-readable. This step requires a JSON object defining permissions, sample to follow.

  • Select the “Permission” tab
  • Click the “Bucket Policy” button
  • Enter your JSON, which might be like so:
"Version": "2012-10-17",
"Statement": [
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "*"

This declares that everyone (Principal: “*”) can execute the Action GetObject on the resource “”.

Obviously, that latter string should map to the domain you are setting up. If you have any doubt, the Bucket Policy Editor does remind you what resource you are setting permissions for in the above the editor panel.

Step 5: Upload your Website

If all of this has gone according to plan, you should be able to very easily upload your index.html file from your Cloud9 editor. First, make sure you can see your new bucket:

dev:~/environment/mysite $ aws s3 ls
2019-12-23 20:11:49
2019-12-23 19:22:07
2019-11-21 09:13:12 elasticbeanstalk-us-west-2-92736412987234

There it is! Along with your other S3 buckets.

So, let’s upload your index.html file:

dev:~/environment/mysite $ aws s3 cp index.html s3://
upload: ./index.html to s3://
dev:~/environment/bioculus $

Yay! It worked! Or did it?! A downside of the aws s3 command-line tools: they tend to fail silently. Go back to your S3 window and have the web browser confirm that your file actually uploaded. And give it 20–30 seconds to propagate.

Step 6: Validate the Hosting

We have not yet hooked up the domain to this bucket, however, the bucket should be serving.

Let’s say the bucket uri that you copied from Step 4.5 above was: ‘’ — simply load that in your browser or click the link in the configuration panel and verify that your file is being served correctly. If anything is wrong, it is probably a permissions error, so you may want to double check your work in steps 4.4–4.6.

Step 7: Configure DNS

Now, you can use Route 53 for this, but it requires using Amazon’s nameservers, and using Amazon’s nameservers is going to add an incremental dollar or two. I am partial to Google for my DNS needs: it’s simple, reliable, and (once you’ve got the domains) free.

So if you want to use Route 53, you are on your own at this point. But using Google or any other DNS server is quite simple.

1 — Set up an CNAME for your subdomain. In this case, the CNAME record should point ‘www’ to ‘’ — this is the destination that you have validated in step 6. Note that a CNAME is not a redirect, and AWS will honor it if the name matches everything left of s3-website in your bucket name.

Setting up a CNAME takes a while to propagate, depending on your TTL settings, and general DNS flim-flam. But before you take that break, you may also want to set up domain forwarding. If you want your root-node domain ( to redirect to your configured subdomain (, your DNS providor can probably do that for you. Google can.

2 — (Optional) Forward your root domain to your subdomain. This will be DNS provider specific, so I’ll leave you to it.

And with those two steps, you should be good. Now you can take that break, give it all an hour or two, and you should be the proud developer of a Hello World site.

Step 8: Initiate Rapid Development

Now that you have all the working pieces in place, using Cloud9 for to build out your website or static components of your website and uploading it to S3 is tremendously easy.


1 — How much is this going to cost?

The optional EC2 instance costs about $6.00 per month if you keep it running; and is money well spent. The S3 bucket charges based on storage, access, and transfer throughput. For this test, it is effectively free; if you have a low volume website, costs are negligible. (It is all free under Amazon’s free tier, but both EC2 and S3 convert to paid after your first 12 months.)

I don’t recommend Route53, because it is unnecessary. But for convenience you can add that for an additional $1–2 per month.

2 — Can I set up my EC2 instance to automatically sync to S3 when I change a file?

There are two techniques: first is to mount the S3 bucket as a drive on your EC2 instance, and the second is to set up a script utilizing inotifywait or similar to monitor the filesystem for changes and execute a sync when things change. Here is a gist for a sync script using inotifywait.

3 — What about images?

The easiest thing to do is to use the browser view of the S3 bucket to upload images directly from whatever local machine you are using.

4 — How do I use this to add dynamic content?

I am so glad you asked, because will be the next article in this series!

This NeXT cube is thought to be the first webserver. And it’s not too far off the way I hosted websites in 1997 or so, although I used home-built webservers with overclocked motherboards running out of my basement.

Blunt Jackson

Written by

Building web applications since 1992. Crikey, that’s a long time.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade