Scaling the Architecture
Day 5 of my Terraform challenge felt different.
It wasn’t just about deploying infrastructure anymore it was about understanding how everything actually works together.
I extended my previous setup by introducing an AWS Application Load Balancer (ALB) in front of my Auto Scaling Group.
Instead of sending traffic directly to one EC2 instance, the flow now looks like this:
- User → ALB
- ALB → Target Group
- Target Group → EC2 instances (ASG)
This setup improves:
- High availability
- Fault tolerance
- Traffic distribution
If one instance fails, the application continues running because traffic is redirected automatically.
Security Improvements
I improved the architecture security by ensuring:
- The ALB is public
- The EC2 instances are private
- Instances only accept traffic from the ALB
This prevents direct access to instances and follows best practices.
Understanding Terraform State
The most important concept today was Terraform state.
Terraform stores infrastructure details in:
terraform.tfstate
This file contains:
- Resource IDs
- Configuration details
- Relationships between resources
It acts as the source of truth.
Every time Terraform runs:
terraform plan
It compares:
- Your code
- The state file
- The actual infrastructure
Experiments I Ran
1. State Tampering
I manually edited the state file and then ran:
terraform plan
Terraform detected inconsistencies immediately.
2. Infrastructure Drift
I changed a resource directly in AWS.
Then ran:
terraform plan
Terraform detected the drift and attempted to bring everything back in sync.
Key Takeaways
- Never manually edit the state file
- Never commit it to Git
- Use remote state storage in real projects
- Use state locking in team environments
Final Thoughts
This day changed how I see Terraform.
It’s not just about creating infrastructure it’s about maintaining it correctly over time.
Understanding Terraform state is what separates beginners from engineers who can manage real production systems.
Top comments (0)