Why I Chose Terraform #

If you are comfortable enough with the way your stack operates, then it is better to preserve it in the form of infrastructure as code (IaC). IaC can tremendously help us in managing our infrastructure stack with ease, especially if you plan to grow your infrastructure.

There are lots of IaC tools out there, and CloudFormation seems like a no-brainer choice because of its seamless integration with other AWS services. For now, I use AWS as the only vendor in my tech stack. But, I cannot simply rule out any possibilities of using other cloud providers in the future, especially after Azure starts to chip away at AWS’s domination in the cloud computing market share.

Therefore, I decided to pick Terraform as the IaC tool of choice mainly because of its platform-agnostic characteristics and its declarative configuration language. As I dug deeper into Terraform, I also found that their supporting systems (documentation and registry) are quite impressive.

Despite my minuscule infrastructure, I still think it’s harmless to get used to the best practices in managing it properly like big organizations do. Principally, IaC can help me enhance every aspect of my infrastructure, including cost, security, and scalability. But, one thing that I really like about using IaC is how convenient it is for me to document and inspect my infrastructure through lines of code rather than endlessly wrestling with the ever-changing AWS console UI.

Terraform Project #

This is a simple Terraform project that leverages existing public modules from the Terraform Registry to build a practical S3-hosted personal website suitable for personal usage like a blog.

I chose to use public modules from the Terraform Registry because they ticked all the boxes for a personal project. These modules are well-maintained by the community, comprehensive, and easy to apply. However, if you want to manage distinctive infrastructure for business or professional use, I strongly recommend using private modules. You can also share your private modules with limited groups for better change management.

As Terraform has become a household name in the cloud community, there are many emerging “denominations” on how to properly organize modules. There’s no absolute right or wrong approach, but I prefer using simplest approach available because it’s easier to maintain and understand, especially when involving non-technical people.

I believe that edge cases, though always possible, remain rare occurrences. The best thing we can do is create simpler projects, as it’s almost impossible to please everyone by covering all possible edge cases. Instead of trying to bring every solution to the table, creating overly complex modules or projects could backfire on us.

In a simple personal blog settings, we have to build several core infrastructures using AWS to make it work. Some of them are:

• S3 bucket to store our contents and enables them to be accessed publicly
• SSL certificate to ensure the safety of our blog using HTTPS protocol
• Lambda functions to automate the creation of several key features such as Cross Origin Resource Sharing (CORS) and execution role
• CloudFront to enable secure and faster content delivery

We can create and manage above infrastructures using Terraform through our IDE of choice without having to touch our AWS account’s dashboard.

Preparing for the Project #

After we have figured out the list of AWS infrastructures that we want to use, we need to do some key preparations first:

• Setting up AWS CLI credentials on our local machine. This can be done after we installed AWS CLI on our local machine.
• Make sure that we don’t put our AWS credentials (Key ID and secret access key) into our Terraform file.
• Install or upgrade the latest version of Terraform.