Tools: Deploying a Highly Available Web App on AWS Using Terraform
From Hardcoded to Configurable
Building the Configurable Web Server
From Single Server to Clustered Architecture
Why This Matters
Configurable web server
Clustered web server
Documentation Matters Too
Challenges I Ran Into
Final Thoughts
Follow My Journey Today’s Terraform work took me from a single configurable EC2 web server to a clustered, load-balanced deployment on AWS. The two big ideas I focused on were: A hardcoded Terraform setup works once, but it becomes difficult to reuse. If region, instance type, and port are written directly in main.tf, every change means editing the infrastructure code itself. That’s where input variables help. With Terraform variables, I could define settings like: and then reference them in Terraform with: This made the infrastructure reusable without changing the main logic. For the first lab, I deployed a single EC2 web server using: I also used Terraform data sources to look up: The important thing here was that the infrastructure behavior came from variables instead of hardcoded values. After terraform apply, I was able to open the EC2 public DNS in the browser and confirm the page was working. The next step was to make the app more resilient. A single EC2 instance is simple, but if that instance fails, the application goes down with it. To improve that, I built a clustered version using: The request flow looked like this: Browser -> ALB -> Target Group -> EC2 instances in Auto Scaling Group In this design: I also used this Terraform data source to fetch availability zones dynamically:
data "aws_availability_zones" "all" {} That was important because the clustered setup needed to work across multiple subnets and availability zones. The difference between the two deployments became much clearer as I worked through them. Part of today’s work was also exploring the Terraform documentation for: This reminded me that learning Terraform is not just about writing code. It is also about understanding the official docs, knowing what resource arguments mean, and being able to connect Terraform blocks to real architecture decisions. Today was not easy. I had to think through: But seeing both deployments work in the browser made everything much more concrete. The biggest lesson for me today was this: By the end of the day, I had successfully deployed: That was a big step in understanding how Terraform moves from simple infrastructure to something much closer to real-world cloud architecture. This is Day 4 of my 30-Day Terraform Challenge. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse
