The Ops Community ⚙️

Tony Morris
Tony Morris

Posted on • Originally published at on

Static Website Playground: Terraform on AWS

Static Website Playground: Terraform on AWS

I need a side project, so here I am.

I make a lot of strong statements about my opinions of public cloud providers and infrastructure-as-code tooling. I figure I may as well back them up with real actual projects.

This is the first post in a series that I'm calling Static Website Playground. Each post will have the same premise: build a static website and deploy it to a specific public cloud, utilizing some type of infrastructure-as-code tooling.

This post is about using Terraform to deploy to AWS.

The important piece first:

I was going to draw a diagram to represent the architectural layout here, but... it's super simple. So I'll just discuss the interest bits below.



Each of these static websites is stored in the same repository and organized by IaC provider and then by cloud provider.


Every post in this series will be using Cloudflare as the public DNS provider. I've got a Zone that I created previously (, so this part is super simple. I look up the Zone using a data resource, then I create a new CNAME Record in the Zone that points to the S3 bucket's website endpoint. More on that part later.

Note that I recently had to update this to use the new S3 resources in the Terraform AWS provider, so I'm now using aws_s3_bucket_website_configuration.this.website_endpoint as the CNAME target, rather than the previous aws_s3_bucket.this.website_endpoint.


This deployment is as bare-bones as possible in AWS. It creates an S3 bucket, uploads an HTML file index.html, and sets some properties on the bucket to enable it to be viewed as a public website. There's a small bucket policy that's also attached to the bucket, allowing GetObject access to the objects in the specified bucket from anywhere in the world.

Terraform Cloud

To deploy the resources, I use the free version of Terraform Cloud. I connect a workspace to my GitHub repository, then I use the working directory to point to the correct subdirectory in the repository.

Using this project as an example, I have a workspace named static-website-playground-aws-terraform, pointed to the GitHub repository linked above, and then set to terraform/aws as its working directory.

Using Terraform Cloud gives me a nice hook directly into Pull Requests (if you enable it), plus I can see the changes that I'm making in a feature branch easily.

It's important to note that my favorite feature of using Terraform Cloud is the ability to run terraform plan from my local console pointed to the remote workspace. This runs the plan in a Terraform Cloud runner with all the variables defined there, rather than somewhere on my laptop that I could accidentally commit to source.

What's Next?

Next up will be using Pulumi to deploy to AWS. Obviously it won't have Terraform Cloud, but I imagine most of the rest of it will be exactly the same. Stay tuned!

Top comments (0)