DEV Community: Victor Robin

How to Convince Your Team to Adopt Infrastructure as Code

Victor Robin — Fri, 03 Apr 2026 20:22:27 +0000

Writing Terraform code is easy.

You can master state files, modules, and providers in a weekend. But getting an entire engineering department to stop clicking around in the AWS console? That is the actual hard part.

Because writing Terraform is an engineering problem...
...but adopting Infrastructure as Code is a cultural shift.

Here is exactly how you convince your team to make the jump, build trust in automated deployments, and avoid the traps that kill most IaC initiatives.

1. Stop Pitching the Tech. Pitch the Business Case.

When you pitch IaC to leadership, do not talk about .tfstate files or the elegance of HCL. Leadership doesn't care about your tech stack. They care about risk, cost, and velocity.

Translate technical debt into business language:

The Problem: "Our environments drift, causing delayed releases." -> The Pitch: "IaC guarantees identical environments, meaning faster time-to-market and fewer rollback scenarios."
The Problem: "We don't know who changed the security group." -> The Pitch: "IaC provides a complete, Git-backed audit trail for every infrastructure change, solving our compliance nightmares."
The Problem: "Setting up a new dev environment takes three days." -> The Pitch: "Reusable modules will cut environment provisioning down to 10 minutes, freeing up engineering hours for actual product work."

2. The Incremental Strategy (How to Actually Do It)

Do not try to boil the ocean. If you ask for a 3-month feature freeze to rewrite all existing infrastructure, you will be denied. You have to prove the value incrementally.

Phase 1: Start Net-New. Pick one new piece of infrastructure. A single S3 bucket, a new IAM role, or a monitoring dashboard. Provision it entirely with Terraform. This creates an immediate success story with zero migration risk to production.
Phase 2: Import the Pain Points. Once the team sees Phase 1 work, begin importing critical existing resources. Use terraform import to bring them under state management without recreating them. Prioritize the resources that change frequently or have caused recent outages.
Phase 3: Establish the Guardrails. You can't just throw Terraform at a team and hope for the best. You must establish rules: all changes require a Pull Request, terraform plan output must be attached to the review, and state locking (via DynamoDB or Terraform Cloud) is non-negotiable.
Phase 4: Automate. Finally, connect Terraform to your CI/CD pipeline. Infrastructure changes should go through the exact same automated deployment process as application code.

3. How It Actually Fails in the Real World

The textbooks make IaC adoption sound linear. Having lived through this, here is how it actually falls apart:

The "Big Bang" Migration
Trying to migrate 100% of your legacy infrastructure at once is organizational suicide. You will spend months fighting dependency graphs while delivering zero new value to the business. Leave the stable legacy systems alone until you absolutely have to touch them.

The "Solo Hero" Trap
Underestimating the learning curve is fatal. If you write 10,000 lines of Terraform but the rest of the team doesn't know how to read it, you haven't adopted IaC... you've just built a new silo where you are the single point of failure. You must give your team the time and safety to learn without the fear of breaking production.

No Executive Buy-In
If you don't have leadership explicitly stating that "manual console changes are no longer acceptable," people will revert to their old habits the second there is an urgent bug fix.

The Bottom Line

A successful Terraform apply doesn't mean your infrastructure works; it just means the API accepted your code.

True IaC adoption means building a culture that trusts the pipeline, reviews infrastructure like software, and understands that manual provisioning is no longer an option.

Start small. Build trust. Automate the rest.

Automating Terraform Testing: From Unit Tests to End-to-End Validation

Victor Robin — Thu, 02 Apr 2026 13:16:44 +0000

Overview

Manual testing is essential when you are just starting out, but it does not scale. The moment your infrastructure grows beyond what one person can test in an afternoon, you need automated tests. Infrastructure that is tested automatically on every commit is infrastructure you can deploy with absolute confidence.

In this guide, we will break down the three layers of Terraform automated testing Unit, Integration, and End-to-End (E2E), and build a CI/CD pipeline that runs them automatically using GitHub Actions and secure AWS OIDC authentication.

Prerequisites

To follow along and run this code yourself, you will need:

An AWS Account, Terraform installed (v1.6.0 or newer for native testing)
Go installed (v1.21 or newer for Terratest)
A GitHub account to run the CI/CD pipeline

The Testing Strategy & Tradeoffs

A mature testing strategy doesn't rely on just one tool; it uses a pyramid approach balancing speed, cost, and thoroughness.

1. Unit Tests (`terraform test`)

Terraform 1.6+ ships with a native testing framework using .tftest.hcl files.

How it works: It runs a terraform plan in memory and evaluates your logic, variable validation, and configuration rules.
Tradeoffs: They are lightning-fast (seconds) and completely free because they do not deploy real infrastructure. However, they test less, they cannot catch cloud provider API errors or verify if an EC2 instance actually boots properly.

2. Integration Tests (Terratest)

Integration tests are written in Go using the Gruntwork Terratest library. They test individual, reusable modules in a sandbox.

How it works: It runs terraform apply, waits for the infrastructure to boot, makes real HTTP requests to your Load Balancers to verify the app is running, and strictly enforces a terraform destroy at the end to clean up.
Tradeoffs: Thorough, but slower (5–15 minutes) and incurs minor cloud costs since real AWS resources are provisioned.

3. End-to-End (E2E) Tests (Terratest)

E2E tests validate your final, composed architecture (VPC + DB + App) working together.

How it works: Deploys your entire production-like stack.
Tradeoffs: Highly accurate but very slow (15–30 minutes) and costly. Warning: Never run an E2E test with a destroy command against your live production state file. E2E tests should be run in isolated sandbox accounts using randomized naming to prevent collisions.

The Golden Rule: Use all three. Run Unit Tests on every Pull Request for instant feedback. Run Integration Tests when merging to your main branch. Run E2E tests in a sandbox environment before major releases.

Step-by-Step Guide: Running the Tests

Want to see this in action? Clone the repository and try it yourself.

Step 1: Clone the Repository


git clone https://github.com/Vivixell/aws-blue-green-infra/.git

cd aws-blue-green-infra

Step 2: Run the Unit Tests

Navigate to the module directory and run the native Terraform test command. This will validate our strict security group rules and Blue/Green capacity logic without deploying anything.


cd modules/webserver
terraform init
terraform test

You should see a fast, green output indicating all assertions passed.

Step 3: Run the Integration Tests

Integration tests deploy real resources. Ensure you have your AWS credentials configured locally, then execute the Go test suite.

cd ../../test
go mod tidy

# We explicitly target the Integration test to avoid running E2E tests locally
go test -v -timeout 45m -run TestWebserverClusterIntegration ./...

Grab a coffee! This will take about 10 minutes to deploy the VPC and ASG, hit the Load Balancer with HTTP requests, and tear it all back down.

Step 4: The CI/CD Pipeline

Running tests locally is great, but automation is the ultimate goal. In the .github/workflows/terraform-test.yml file, we have a pipeline that ties this all together.

Instead of hardcoding highly privileged AWS Access Keys in GitHub (a major security risk), we use OpenID Connect (OIDC). GitHub requests a temporary, short-lived token directly from AWS.

Here is a snippet of how the pipeline is structured to run Unit Tests on PRs, and Integration tests on merges:


jobs:
  unit-tests:
    name: Unit Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS Credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-east-1
      - run: terraform init
      - run: terraform test

  integration-tests:
    name: Integration Tests
    runs-on: ubuntu-latest
    if: github.event_name == 'push' # Only runs when merged to main
    needs: unit-tests
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS Credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-east-1
      - uses: hashicorp/setup-terraform@v3
      - uses: actions/setup-go@v4
      - run: |
          go mod tidy
          go test -v -timeout 45m -run TestWebserverClusterIntegration ./...

Conclusion

By implementing terraform test for fast syntax checking, Terratest for real-world validation, and GitHub Actions for continuous integration, you transform your infrastructure from fragile scripts into reliable, enterprise-grade software.

Happy testing!

The Importance of Manual Testing in Terraform

Victor Robin — Wed, 01 Apr 2026 16:47:58 +0000

It is incredibly tempting to write Terraform code, see the green Apply complete! text, and assume your job is done. But there is a massive difference between infrastructure that provisions successfully and infrastructure that actually works.

For Day 17 of my 30-Day Terraform Challenge, I stepped back from writing code to focus on something even more critical: breaking it. I built a structured manual testing process to verify my AWS Blue/Green architecture. Here is why manual testing is the unavoidable foundation of Infrastructure as Code.

Why Manual Testing Still Matters

With tools like Terratest available, manual testing might feel archaic. However, automated tests are only as good as the assertions you write. You cannot automate a test until you manually discover exactly what edge cases, timing issues, or cloud provider quirks need verifying. Manual testing is the exploratory phase that defines your automated test suite.

Building a Structured Test Checklist

A manual test without a checklist is just aimlessly clicking around the AWS console. To build a robust checklist, you must break your infrastructure down into four distinct verification categories:

Provisioning Verification: Do the core Terraform commands (init, validate, plan, apply) execute cleanly?
Resource Correctness: Do the tags, names, and strict Security Group rules in the AWS Console match your configuration?
Functional Verification: Does the architecture actually behave as intended? (e.g., hitting the ALB URL, checking instance health).
State Consistency: Does running a subsequent terraform plan return zero changes?

Provisioning vs. Functional Verification

A successful terraform apply only tells you one thing: AWS accepted your API calls. This is provisioning verification. It does not tell you if your Security Groups allow the right traffic, if your ALB is routing to the correct Target Group, or if your EC2 instances actually boot up your application.

To prove the code works, you need functional verification. For my Blue/Green deployment, this meant explicitly curling the ALB DNS name to ensure it returned the correct web page, and manually terminating an EC2 instance to ensure my Auto Scaling Group successfully self-healed.

The Cleanup Discipline

Perhaps the most crucial part of manual testing is cleaning up afterward. Terraform state files can become corrupted, or a destroy command can fail partway through due to an API timeout. If you don't manually verify your cleanup using the AWS CLI (aws ec2 describe-instances), you risk leaving orphaned resources running in the background. In the cloud, orphaned resources equal runaway bills.

Actual Test Results: Passes and Failures

Testing isn't about proving your code is perfect; it's about exposing the flaws. Here are two examples from my test run today:

Test 1: Functional Routing (PASS)

Command: curl -s http://prod-app-alb-123456.us-east-1.elb.amazonaws.com
Expected: "Welcome to the BLUE Environment! (prod)"
Actual: "Welcome to the BLUE Environment! (prod)"
Result: PASS - The ALB successfully routed traffic to the active Target Group.

Test 2: State Consistency (FAIL)

Command: terraform plan (Run immediately after a successful apply)
Expected: "No changes. Your infrastructure matches the configuration."
Actual: 1 resource change detected — missing tag on security group.
Result: FAIL - The aws_security_group was missing the merge(local.common_tags) block. I caught this state drift manually and fixed the module code before it scaled to hundreds of resources.

Manual testing is not optional. It is the necessary prerequisite to confidence in the cloud.

From Sandbox to Production: Building a Resilient AWS Blue/Green Infrastructure with Terraform

Victor Robin — Tue, 31 Mar 2026 19:35:23 +0000

There is a massive gap between Terraform code that simply "works" on your laptop and code that is truly production-ready. I recently tackled this exact gap as part of my 30-Day Terraform Challenge. The goal? Taking a standard AWS web server setup and transforming it into a reliable, modular, and secure system capable of handling zero-downtime Blue/Green deployments.

If you are looking to elevate your Infrastructure as Code (IaC) from basic scripts to robust, defensible architecture, this guide will walk you through the core principles of production-grade Terraform.

Prerequisites

To follow along with the concepts in this guide, you should have:

A basic understanding of AWS networking and compute (VPCs, ALBs, ASGs, EC2).
Familiarity with standard Terraform commands and syntax.
(Optional) Go installed on your machine if you wish to run the automated infrastructure tests.

Tools Used

Terraform (>= 1.6.0): Our core IaC engine.
AWS Provider (~> 6.9): To interact with AWS APIs.
Terratest (Go): For automated infrastructure validation.

Folder Structure Overview

Production code cannot live in a single, monolithic main.tf file. It needs to be modular, allowing teams to compose infrastructure safely across different environments. We separated our reusable logic into a modules directory, and called it from environment-specific root folders.

.
├── modules/
│   └── webserver/
│       ├── main.tf
│       ├── variables.tf
|       ├── provider.tf
│       ├── outputs.tf
│       └── README.md
|   
├── dev/
│   ├── main.tf
|   ├── backend.tf
│   └── outputs.tf
├── prod/
│   ├── main.tf
|   ├── backend.tf
│   └── outputs.tf
└── test/
    └── webserver_test.go

(Note: For complete usage instructions, inputs, and outputs of the module itself, you can check out the README.md in the repository's module folder!)

Github

Step-by-Step Refactoring Guide

Here is a breakdown of the specific refactoring steps required to make this infrastructure production-grade.

1. Reliability & Zero-Downtime Updates

Reliability means the system survives updates seamlessly. We implemented a Blue/Green deployment strategy using parallel Auto Scaling Groups (ASGs). To ensure updates happen without dropping traffic, we had to apply critical lifecycle rules.

Before: Modifying a launch template would immediately tear down running instances before the new ones were fully provisioned, causing an outage.

resource "aws_launch_template" "color" {
  name_prefix   = "${var.cluster_name}-lt-"
  image_id      = data.aws_ami.ubuntu.id
  instance_type = var.instance_type
}

After: We explicitly instruct Terraform to provision the replacement infrastructure before destroying the old one. This is a non-negotiable for production compute.

resource "aws_launch_template" "color" {
  name_prefix   = "${var.cluster_name}-lt-"
  image_id      = data.aws_ami.ubuntu.id
  instance_type = var.instance_type

  lifecycle {
    create_before_destroy = true 
  }
}

2. Security & Input Validation

Security isn't just about IAM roles and restricting Security Groups. It is also about protecting the deployment pipeline from human error. By adding strict input validation, we prevent invalid or highly expensive configurations from ever reaching the cloud.

Before: A developer could type any string for the environment variable.

variable "environment" {
  type = string
}

After: Terraform will immediately reject the apply if the inputs do not match our strict criteria, protecting our state and our AWS bill.

variable "environment" {
  description = "The deployment environment (e.g., dev, staging, prod)"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be explicitly set to dev, staging, or prod."
  }
}

3. Observability

You cannot fix what you cannot see. Production systems require automated monitoring and alerting out of the box. Instead of manually clicking through the AWS console later, I integrated CloudWatch alarms directly into the Terraform module.

We added a dynamic alarm that watches the CPU utilization of whichever ASG is currently active and routes alerts to an SNS topic.

resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  for_each            = local.bg_envs
  alarm_name          = "${var.cluster_name}-high-cpu-${each.key}"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 120
  statistic           = "Average"
  threshold           = 80

  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.color[each.key].name
  }
  alarm_actions = [aws_sns_topic.alerts.arn]
}

4. Automated Testing with Terratest

Manual testing is slow, expensive, and prone to oversight. To truly trust our infrastructure, we need automated tests. Using Terratest (a Go library developed by Gruntwork), we wrote a script that actively deploys the infrastructure to a sandbox, runs real-world HTTP checks against the Load Balancer, and then tears it all down.


package test

import (
    "testing"
    "time"
    "github.com/gruntwork-io/terratest/modules/http-helper"
    "github.com/gruntwork-io/terratest/modules/terraform"
)

func TestWebserverCluster(t *testing.T) {
    t.Parallel()

    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../dev",
        Vars: map[string]interface{}{
            "cluster_name":       "terratest-app",
            "environment":        "dev",
            "active_environment": "blue",
            "vpc_cidr":           "10.0.0.0/16",
            "instance_type":      "t3.micro",
            "asg_capacity": map[string]interface{}{
                "min": 1, "max": 1, "desired": 1,
            },
        },
    })

    // Crucial: Ensures the infrastructure is destroyed even if the test fails
    defer terraform.Destroy(t, terraformOptions)

    terraform.InitAndApply(t, terraformOptions)

    albDnsName := terraform.Output(t, terraformOptions, "alb_dns_name")
    url := "http://" + albDnsName

    // Asserts that the ALB is up and routing to the Blue environment
    http_helper.HttpGetWithRetry(t, url, nil, 200, "Welcome to the BLUE Environment!", 30, 10*time.Second)
}

Why this matters: Notice the defer terraform.Destroy(t, terraformOptions) line. Automated tests cost real money because they spin up real AWS resources. If an assertion fails halfway through, the Go test panics and stops. By deferring the destroy command, we guarantee that no matter what happens during the test run, the environment is cleanly destroyed at the end. No orphan resources, no surprise AWS bills.

Final Thoughts

Terraform is incredibly powerful, but how you write it dictates whether your infrastructure is a liability or an asset. Moving from "it works" to "it's production-ready" requires a massive shift in mindset toward defensible code, strict boundaries, and automated safety nets.

Have you implemented automated testing for your IaC yet? Let me know your preferred workflow in the comments!

Deploying Multi-Cloud Infrastructure with Terraform Modules

Victor Robin — Mon, 30 Mar 2026 20:27:10 +0000

Repo

The Monolith Problem

Most engineers start writing Terraform by dropping a single AWS provider block at the top of their main.tf and dumping all their resources underneath it. That works for a weekend project. It completely falls apart in production.

When you need to deploy a globally distributed application, or provision underlying infrastructure and deploy application workloads on top of it simultaneously, you need to master advanced provider orchestration.

Today, I am sharing the blueprints for three advanced Terraform provider patterns:

Passing Aliased Providers into Modules.
Local Container Orchestration (Docker).
Provider Chaining (AWS EKS + Kubernetes).

Pattern 1: The Multi-Provider Module

The golden rule of writing reusable Terraform modules is this: A module must never declare its own provider block.

If a module hardcodes a region or an account, it becomes rigid. Instead, a module must demand that the calling configuration passes the providers down to it. We do this using configuration_aliases.

The Module Definition (`modules/app/main.tf`)

Notice how the module explicitly requires two distinct AWS connections to function:

terraform {
  required_providers {
    aws = {
      source                = "hashicorp/aws"
      version               = "~> 5.0"
      configuration_aliases = [aws.primary, aws.replica] 
    }
  }
}

resource "aws_s3_bucket" "primary" {
  provider      = aws.primary
  bucket_prefix = "primary-data-"
}

The Root Caller (`live/main.tf`)

In the root directory, we define the actual API connections and "wire" them into the module using the providers map:

provider "aws" {
  alias  = "east"
  region = "us-east-1"
}

provider "aws" {
  alias  = "west"
  region = "us-west-2"
}

module "global_app" {
  source = "../modules/app"

  providers = {
    aws.primary = aws.east
    aws.replica = aws.west
  }
}

Pattern 2: Local Container Orchestration

Terraform is not just for cloud APIs. It can orchestrate anything with an accessible API—including your local Docker daemon. Before dealing with the complexity of cloud-managed Kubernetes, you can test container deployments locally using the kreuzwerker/docker provider.

provider "docker" {}

resource "docker_image" "nginx" {
  name         = "nginx:latest"
  keep_locally = false 
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.image_id
  name  = "terraform-nginx"
  ports {
    internal = 80
    external = 8080
  }
}

Run terraform apply, and Terraform will pull the image and spin up the container on port 8080 locally. No docker run commands required.

Pattern 3: Provider Chaining (AWS EKS + Kubernetes)

This is where Terraform flexes its true enterprise capability.

What if you want to provision an AWS EKS cluster, and then immediately deploy an Nginx pod into that cluster, all within a single terraform apply?

To do this, we use Provider Chaining. We use the AWS provider to build the cluster, extract the cluster's endpoint and certificate authority data on the fly, and pass that data directly into the configuration of the Kubernetes provider.

The Dynamic Authentication Block

Instead of hardcoding static kubeconfig files, we use an exec block. This forces the Kubernetes provider to execute an AWS CLI command in the background to fetch a short-lived authentication token for the cluster we just built.

# 1. Provision the Cluster (AWS Provider)
module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "~> 20.0"
  cluster_name    = "production-cluster"
  # ... vpc and subnet configuration ...
}

# 2. Authenticate dynamically to the new cluster
provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)

  exec {
    api_version = "client.authentication.k8s.io/v1beta1"
    command     = "aws"
    args        = ["eks", "get-token", "--cluster-name", module.eks.cluster_name]
  }
}

# 3. Deploy the workload (Kubernetes Provider)
resource "kubernetes_deployment" "nginx" {
  depends_on = [module.eks] 

  metadata {
    name = "nginx-deployment"
  }
  spec {
    replicas = 2
    # ... container spec ...
  }
}

Note: The depends_on = [module.eks] is critical. It prevents the Kubernetes provider from trying to deploy pods before the AWS provider has finished standing up the control plane.

Conclusion

When you decouple providers from modules and learn to chain them together, Terraform transitions from a simple provisioning tool into a complete, end-to-end platform orchestrator.

Getting Started with Multiple Providers in Terraform

Victor Robin — Mon, 30 Mar 2026 16:51:58 +0000

Overview

Every real-world cloud infrastructure eventually outgrows a single region. Whether you are building a multi-region Active-Passive disaster recovery architecture, deploying global CloudFront endpoints, or managing resources across different AWS accounts, a single default Terraform provider won't cut it.

For Day 14 of my 30-Day Terraform Challenge, I dove deep into Terraform's provider system. In this guide, I will break down how providers actually work under the hood, how to lock their versions, and walk you through a step-by-step implementation of cross-region S3 replication using the Provider Alias pattern.

What is a Provider, Really?

Terraform Core is essentially just a parsing engine. It reads your HCL code and builds a dependency graph. It doesn't actually know how to talk to AWS, Azure, or Kubernetes.

That is where Providers come in. A provider is an executable plugin (a Go binary) that Terraform downloads. It acts as the translation layer between your declarative HCL code and the target platform's REST APIs. When you write an aws_s3_bucket block, the AWS provider is what actually makes the PUT request to the AWS API.

Installation, Versioning, and The Lock File

When you run terraform init, Terraform reads the required_providers block, reaches out to the Terraform Registry, and downloads the exact provider binaries you need.

Because cloud APIs change constantly, you must always pin your provider versions.

The Constraint Syntax

Here is a practical look at how we define version constraints:

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0" 
    }
  }
}

= 6.0.0: Exact version matching (Too rigid for most use cases).
>= 6.0.0: Any version greater than or equal to 6.0.0 (Too risky, might pull a breaking 7.0 update).
~> 6.9: The pessimistic constraint operator. This translates to "Use the highest available version in the 6.x.x range, but do NOT upgrade to 7.0". This is the industry standard for balancing security patches with stability.

The .terraform.lock.hcl File
When terraform init resolves your version constraints, it generates a .terraform.lock.hcl file. This file records:

Version: The exact version it selected (e.g., 6.9.37).
Constraints: The rule you set that led to this selection.
Hashes: Cryptographic checksums of the provider binary for multiple operating systems.

Best Practice: You must commit this file to Git! It guarantees that your CI/CD pipeline and every engineer on your team downloads the exact same provider version, preventing the classic "It works on my machine" deployment failure.

Prerequisites for the Lab

If you want to pull down the repository and run this architecture yourself, you will need:

Terraform installed (>= 1.6.0)
AWS CLI installed and configured with Admin or PowerUser credentials.
Basic understanding of AWS IAM and S3.

Step-by-Step Guide: Multi-Region S3 Replication

By default, an AWS provider block connects to a single region. To deploy to a second region in the same codebase, we use Provider Aliases.

Here is how to run my Multi-Region S3 Disaster Recovery architecture.

Step 1: Clone the Repository

Clone the project and navigate to the directory:

git clone https://github.com/Vivixell/terraform-aws-s3-replication
cd terraform-aws-s3-replication

Step 2: Understand the Providers (`providers.tf`)

Open providers.tf. You will see the default provider (routing to Virginia) and an aliased provider (routing to Oregon)

# Default Provider (Primary Region)
provider "aws" {
  region = "us-east-1"
}

# Aliased Provider (Secondary Region)
provider "aws" {
  alias  = "west"
  region = "us-west-2"
}

Step 3: Review the Infrastructure (`main.tf`)

Open main.tf. Notice how we dictate which region a resource belongs to.

The Primary Bucket:

Because there is no explicit provider argument, this bucket automatically deploys to us-east-1 using the default provider.

resource "aws_s3_bucket" "primary" {
  bucket_prefix = "ovr-primary-data-"
}

The Replica Bucket:

Here is the alias pattern in action. By passing provider = aws.west, Terraform routes this specific API call to the us-west-2 endpoint.

resource "aws_s3_bucket" "replica" {
  provider      = aws.west 
  bucket_prefix = "ovr-replica-backup-"
}

The rest of main.tf provisions the necessary IAM roles and the replication rule that binds the two buckets together.

Step 4: Deploy the Architecture

Initialize your backend and lock file, check the plan, and apply:

terraform init
terraform plan
terraform apply -auto-approve

The terminal will output the dynamically generated names of your primary and replica buckets.

Step 5: Test the Replication
Open your AWS Console and navigate to S3.

Upload a test file (an image or a .txt file) to your primary bucket in us-east-1.

Wait about 30–60 seconds, then check your replica bucket in us-west-2. The file will have been automatically duplicated across the country!

Step 6: Clean Up

Because the force_destroy = true flag is enabled on both buckets in the codebase, tearing down the environment is a single command. (Note: Terraform will delete all replicated files inside the buckets during this process).

terraform destroy -auto-approve

Understanding how to manipulate the provider meta-argument unlocks the ability to build true enterprise-grade, highly available architectures.

How to Handle Sensitive Data Securely in Terraform

Victor Robin — Sun, 29 Mar 2026 17:55:37 +0000

Every real-world infrastructure deployment involves secrets—database passwords, API keys, and TLS certificates. The number one security mistake engineers make is letting those secrets leak into their codebase or terminal outputs.

For todays Terraform Challenge, I built an impenetrable wall around my infrastructure's sensitive data using AWS Secrets Manager.

Here is the definitive guide to the three ways secrets leak in Terraform, and exactly how to close every single path.

Leak Path 1: Hardcoded in `.tf` Files

The Mistake: Writing a secret directly into a resource argument. The moment you run git add, that password is permanently stored in your version control history for anyone in your organization (or the public) to see.

❌ Vulnerable Pattern:


resource "aws_db_instance" "app_database" {
  username = "admin"
  password = "SuperSecretPassword123!" # Never do this!
}

✅ Secure Alternative (AWS Secrets Manager):

Instead of typing the password, create it manually in AWS Secrets Manager. Then, use Terraform data blocks to fetch it dynamically at runtime.

# 1. Fetch the secret from AWS

data "aws_secretsmanager_secret" "db_credentials" {
  name = "prod/db/credentials"
}

data "aws_secretsmanager_secret_version" "db_credentials" {
  secret_id = data.aws_secretsmanager_secret.db_credentials.id
}

# 2. Decode the JSON string
locals {
  db_creds = jsondecode(data.aws_secretsmanager_secret_version.db_credentials.secret_string)
}

# 3. Inject it at runtime
resource "aws_db_instance" "app_database" {
  username = local.db_creds["username"]
  password = local.db_creds["password"]
}

Result: The secret never exists in your configuration files.

Leak Path 2: Passed as a Variable with a Default

The Mistake: Moving the secret to variables.tf, but giving it a default value. Default values are still committed to source control, meaning the leak still happens.

❌ Vulnerable Pattern:


variable "db_password" {
  type    = string
  default = "SuperSecretPassword123!" # Still committed to Git!
}

✅ Secure Alternative (sensitive = true):

Remove the default value completely. Furthermore, add the sensitive = true flag. This prevents Terraform from accidentally printing the secret to the terminal screen when you run terraform plan or terraform apply.


variable "db_password" {
  description = "Database administrator password"
  type        = string
  sensitive   = true 
  # Terraform will now require this to be passed securely via TF_VAR_ environment variables or a secure CI/CD pipeline.
}

output "db_connection_string" {
  value     = "mysql://${local.db_creds["username"]}:${local.db_creds["password"]}@${aws_db_instance.app_database.endpoint}"
  sensitive = true # Outputs <sensitive> instead of the raw string in the CLI
}

Leak Path 3: Stored in Plaintext in the State File

The Mistake: Even if you use AWS Secrets Manager and the sensitive = true flag perfectly, Terraform still stores the final evaluated values of your resources in terraform.tfstate in plaintext. If an attacker gains access to your state file, they have the keys to your kingdom. sensitive = true only hides it from the terminal; it does not encrypt the state file.

✅ Secure Alternative (The State File Security Audit):
Because secrets inevitably end up in state, the state file itself must be locked down using a remote backend (like AWS S3) with strict security boundaries.

My Production S3 Backend Security Checklist:

Server-Side Encryption: Enabled (encrypt = true and AES256 default encryption rules on the bucket).
Versioning: Enabled (to recover from accidental state corruption).
Public Access Blocked: block_public_acls and block_public_policy strictly enforced.
State Locking: DynamoDB table attached to prevent concurrent write corruption, or use S3 nataive lockfile settings use_lockfile = true
Least Privilege IAM: Only specific CI/CD roles are allowed s3:GetObject on the state bucket.

Finally, to ensure no local state files or variable files are ever accidentally committed to GitHub, your .gitignore must always include:

# Terraform Security Gitignore
.terraform/
*.tfstate
*.tfstate.backup
*.tfvars
override.tf

Security is not optional in production infrastructure. Master your secrets management before you deploy, not after a breach.

How Conditionals Make Terraform Infrastructure Dynamic and Efficient

Victor Robin — Thu, 26 Mar 2026 20:45:09 +0000

If you are maintaining separate Terraform codebases for your Development, Staging, and Production environments, you are doing twice the work for half the reliability.

The gold standard of Infrastructure as Code is the Environment-Aware Module: a single, unified codebase that intelligently adapts its sizing, features, and resources based on the environment it is deployed into.

Today on my Terraform Challenge, I'll be diving deep into Terraform's conditional logic. Here is how Platform Teams use conditionals to eliminate code duplication and build smarter deployments.

1. The Ternary Operator & Environment-Aware Locals

The Problem: You want t3.micro instances in Dev to save money, but t3.small instances in Production to handle traffic. Scattering if/else logic directly inside your resource blocks makes your code incredibly difficult to read and update.

The Solution: Centralize your logic using the ternary operator (condition ? true_value : false_value) inside a locals block. This creates a single source of truth for your module's environment awareness.

[Image of Environment-aware Terraform module architecture]

Before (Hardcoded & Rigid):

resource "aws_instance" "web" {
  instance_type = var.instance_type # Requires passing this manually every time
}

After (Dynamic & Centralized):


variable "environment" {
  description = "The deployment environment"
  type        = string
}


locals {
  # The boolean flag
  is_production = var.environment == "production"

  # Centralized environment sizing
  instance_type = local.is_production ? "t3.small" : "t3.micro"
  min_size      = local.is_production ? 3 : 1
}


resource "aws_instance" "web" {
  instance_type = local.instance_type # Clean, readable, and dynamic!
}

2. The Optional Resource Pattern (`count = condition ? 1 : 0`)

The Problem: You need strict CloudWatch Alarms and Auto Scaling policies in Production, but deploying them in Dev is a waste of AWS budget. You cannot dynamically "comment out" a resource block.

The Solution: Use the count meta-argument as an On/Off switch. If the condition is true, Terraform sets the count to 1 (creates it). If false, it sets the count to 0 (skips it entirely).


variable "enable_scaling_policy" {
  type    = bool
  default = false
}

resource "aws_autoscaling_policy" "scale_up" {
  # The On/Off Switch
  count = var.enable_scaling_policy ? 1 : 0

  name                   = "production-scale-up"
  autoscaling_group_name = aws_autoscaling_group.asg.name
  adjustment_type        = "ChangeInCapacity"
  scaling_adjustment     = 1
}

3. Safely Referencing Conditionally Created Resources

The Problem: If you use the count = 0 trick above to skip creating a scaling policy, but your outputs.tf file still tries to export that policy's ARN, your terraform plan will crash. Terraform cannot output the ID of a resource that doesn't exist.

The Solution: You must reference conditionally created resources using the index [0] (since count treats them as a list), and use a ternary operator to output null if the resource was skipped.

Before (Will crash if count is 0):

output "scaling_policy_arn" {
  value = aws_autoscaling_policy.scale_up.arn
}

After (Safe and robust):

output "scaling_policy_arn" {
  # If enabled, output the ARN of the first (and only) item. Otherwise, output null.
  value = var.enable_scaling_policy ? aws_autoscaling_policy.scale_up[0].arn : null
}

4. Input Validation Blocks

The Problem: Your entire environment-aware module relies on the environment variable being exactly "dev", "staging", or "production". If a junior developer accidentally passes environment = "prod", your ternary conditionals will evaluate to false, deploying Dev-sized infrastructure into your Production AWS account.

The Solution: Use variable validation blocks. This forces Terraform to evaluate the input during the plan phase and immediately throw a custom error if the string isn't an exact match.

variable "environment" {
  description = "Deployment environment"
  type        = string

  validation {
    # The condition must evaluate to true, or the plan fails.
    condition     = contains(["dev", "staging", "production"], var.environment)
    error_message = "Fatal: Environment must be exactly 'dev', 'staging', or 'production'."
  }
}

Final Thoughts

Mastering conditionals transforms you from someone who writes Terraform scripts into someone who architects resilient cloud systems. By centralizing logic in locals, making resources toggleable, and validating inputs strictly, your modules become virtually bulletproof.

Are you using validation blocks in your Terraform modules yet? Let me know in the comments.

30DayTerraformChallenge #Terraform #IaC #DevOps #AWSUserGroupKenya #EveOps #CloudEngineering

Mastering Loops and Conditionals in Terraform

Victor Robin — Wed, 25 Mar 2026 20:31:40 +0000

When you first start writing Terraform, you declare every resource manually. If you need three private subnets, you write three aws_subnet blocks. If you need five IAM users, you write five aws_iam_user blocks.

This works for simple tutorials, but in a true enterprise environment, hardcoding infrastructure is a massive anti-pattern. Real infrastructure needs to be dynamic, scaling up or down based on variable inputs without requiring massive code rewrites.

To write professional-grade Terraform, you must master its four primary dynamic tools: count, for_each, for expressions, and conditionals. Here is the definitive guide to how they work, when to use them, and the one dangerous trap that catches almost every junior engineer.

1. `count`: The Simple Loop

The count meta-argument is the simplest way to create multiple identical copies of a resource. You pass it an integer, and Terraform creates that many instances, tracking them with an index number (count.index) starting at 0.

resource "aws_instance" "web" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server-${count.index}" # Results in web-server-0, web-server-1, etc.
  }
}

When to use it: Use count when the resources are truly identical and interchangeable, and you simply need N number of them.

2. The `count` Index Problem (The Danger Zone)

It is tempting to use count with the length() function to iterate over a list of strings, like a list of usernames. Do not do this.

The Broken Architecture
Imagine you have a list of developers who need IAM users:

variable "devs" {
  default = ["alice", "bob", "charlie"]
}

resource "aws_iam_user" "team" {
  count = length(var.devs)
  name  = var.devs[count.index]
}

Terraform maps these internally by their index:

aws_iam_user.team[0] = alice
aws_iam_user.team[1] = bob
aws_iam_user.team[2] = charlie

What breaks: Suppose "alice" leaves the company, so you remove her from the list. The list is now ["bob", "charlie"].

Instead of just deleting Alice, Terraform looks at the new indexes:

Index 0 is now bob. Terraform renames Alice's user to Bob.
Index 1 is now charlie. Terraform renames Bob's user to Charlie.
Index 2 no longer exists. Terraform deletes Charlie's original user.

You just caused massive destructive churn across your entire team's access because a list shifted.

3. `for_each`: The Safe Loop

To solve the list-shifting problem, Terraform introduced for_each. Instead of using a fragile numerical index, for_each iterates over a map or a set of strings, using the actual string values as the unique identifier.

The Correct Architecture
If we refactor the IAM user example using a set:

variable "devs" {
  type    = set(string)
  default = ["alice", "bob", "charlie"]
}

resource "aws_iam_user" "team" {
  for_each = var.devs
  name     = each.value
}

Now, Terraform tracks them like this:

aws_iam_user.team["alice"]
aws_iam_user.team["bob"]

If you remove "alice" from the variable, Terraform only deletes aws_iam_user.team["alice"]. Bob and Charlie are completely untouched because their identifiers never changed.

When to use it: Use for_each whenever you are creating multiple resources that have unique identities (like subnets with different CIDR blocks, or users with different names).

4. Conditionals: The Ternary Operator

Sometimes you don't need a loop; you just need an ON/OFF switch. Terraform handles conditional logic using the ternary operator: condition ? true_value : false_value.

The most powerful way to use this is by combining it with count to make an entire resource optional based on an environment variable.

For example, you might want an Auto Scaling Policy in Production, but not in Dev to save costs:


variable "enable_scaling_policy" {
  description = "If true, creates an Auto Scaling policy"
  type        = bool
  default     = false
}

resource "aws_autoscaling_policy" "scale_up" {
  # If true, count = 1 (resource is created). If false, count = 0 (resource is skipped).
  count                  = var.enable_scaling_policy ? 1 : 0

  name                   = "production-scale-up"
  autoscaling_group_name = aws_autoscaling_group.asg.name
  adjustment_type        = "ChangeInCapacity"
  scaling_adjustment     = 1
}

5. `for` Expressions: Reshaping Data

Do not confuse for_each with for expressions.

for_each creates resources.
for expressions reshape data.

Often, you need to output data from your module, but the raw Terraform state object is too messy. A for expression lets you loop through a complex object and extract exactly what you want, usually formatting it into a clean list or map.

Here is how you extract a clean dictionary mapping your private subnet names directly to their generated AWS Subnet IDs:

output "private_subnet_map" {
  description = "A clean map of private subnet keys to their actual AWS Subnet IDs"

  # Loops through the aws_subnet.private resources, grabbing the key (k) and the ID
  value = { for k, subnet in aws_subnet.private : k => subnet.id }
}

Output result:

private_subnet_map = {
  "private_app_1" = "subnet-0a1b2c3d4e5f6g7h8"
  "private_app_2" = "subnet-0z9y8x7w6v5u4t3s2"
}

Final Thoughts

Mastering these four tools transitions you from writing static Terraform scripts to engineering highly reusable, scalable infrastructure modules.

Stop copy-pasting resource blocks. Start looping.

Advanced Terraform Module Usage: Versioning, Gotchas, and Reuse Across Environments

Victor Robin — Tue, 24 Mar 2026 19:06:30 +0000

If you followed my Day 8 breakdown, you know that moving from a monolithic main.tf to a reusable Terraform module is a massive architectural leap. But building a module is only half the battle.

If you don't understand how Terraform resolves paths, handles state logic, or pins versions, your beautiful module will quickly become a nightmare for other engineers to use.

For Day 9 of the 30-Day Terraform Challenge, I am diving deep into enterprise module management. We are going to cover the three most common module "gotchas" that break deployments, how to properly version your code using Git, and the exact multi-environment pattern Platform Teams use to test new infrastructure safely.

Part 1: The 3 Terraform Module Gotchas

When you transition from writing root environments to writing child modules, Terraform's behavior changes in subtle ways. Here are three mistakes that are incredibly easy to make and deeply frustrating to debug.

Gotcha 1: The File Path Trap

Imagine you have a user-data.sh script sitting in your module folder. You might be tempted to reference it like this:

# ❌ THE WRONG WAY

resource "aws_launch_template"  "app" {

  # ...

  user_data = filebase64("./user-data.sh") 
}

Why it fails: Terraform resolves the ./ relative to the directory where you run terraform apply (the root environment), not where the module lives. When your Prod environment calls this module, Terraform will look for prod/user-data.sh and crash.

The Fix: Always use the path.module expression. This tells Terraform to dynamically locate the script based on the module's actual location.

✅ THE RIGHT WAY


resource "aws_launch_template" "app" {

  user_data = filebase64("${path.module}/user-data.sh") 
}

Other possible values are:

Gotcha 2: The Inline Block "Perpetual Diff"

Some AWS resources, like Security Groups, allow you to define rules inline or as separate resources. When writing modules, inline blocks are dangerous.

❌ THE WRONG WAY (Inline)

resource "aws_security_group" "web" {
  ingress {
    from_port = 80
    to_port   = 80
    protocol  = "tcp"
  }
}

Why it fails: If a developer calls your module and later decides they need to attach a custom VPN rule to that same Security Group using an external aws_security_group_rule, Terraform will panic. The module claims strict ownership of the inline block and will constantly try to delete the developer's new rule, resulting in an endless loop of infrastructure changes.

The Fix: Always use standalone resources inside modules to allow external extensibility.

✅ THE RIGHT WAY (Standalone)


resource "aws_security_group" "web" {
  name = "web-sg"
}

resource "aws_security_group_rule" "http" {
  type              = "ingress"
  security_group_id = aws_security_group.web.id
  from_port         = 80
  to_port           = 80
  protocol          = "tcp"
}

Gotcha 3: The Blunt depends_on

Sometimes, a developer calling your module will try to force an execution order using depends_on.

❌ THE WRONG WAY


module "webserver" {
  source     = "../modules/webserver"
  depends_on = [aws_database_instance.main]
}

Why it fails: This forces Terraform to treat your entire webserver cluster as a single, opaque block. If anything changes in the database (even just updating a tag), Terraform might mistakenly taint the entire module and attempt to destroy and recreate your Auto Scaling Group and Load Balancer.

The Fix: Let Terraform's native dependency graph do the work. Pass explicit resource outputs into the module as variables.

✅ THE RIGHT WAY



module "webserver" {
  source     = "../modules/webserver"
  db_address = aws_database_instance.main.address # Implicit dependency created safely!
}

Part 2: Module Versioning & Source Syntax

In a production environment, you never point your infrastructure at a local folder. You point it at a version-controlled registry. This guarantees that a change to the module code doesn't instantly break every environment using it.

To version a module, you simply use Git tags.

# Tagging a stable release in your module repository
git tag -a "v0.0.1" -m "Initial stable release"
git push origin v0.0.1

Once tagged, how you format the source URL determines exactly what Terraform pulls down. Here is what the syntax looks like across different ecosystems:

1. The Local Source (Good for initial drafting, bad for teams):

module "webserver" {
  source = "../modules/webserver"
}

2. The Git Repository Source (The Enterprise Standard):

Notice the double slash //. This tells Terraform where the repository ends and the specific subfolder begins, while ?ref= targets the exact Git tag.

module "webserver" {
  source = github.com/Vivixell/Reusable-Infrastructure//modules/webserver?ref=v0.0.1"
}

3. The Terraform Public Registry Source:

When pulling from HashiCorp's official registry, the syntax simplifies. The version gets its own explicit argument.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
}

Part 3: The Multi-Environment Deployment Pattern

Now that our module is versioned remotely, we can implement the true Platform Engineering lifecycle: Dev tests the new features, Prod stays pinned to stability.

I released v0.0.1 of my webserver module, and then added a new custom_tags feature and released v0.0.2. Here is how my root environments consume them simultaneously without conflict:

The Production Environment (Pinned to Stable)

Production code should never use the master branch or the "latest" tag. It is strictly pinned to the battle-tested v0.0.1 release.

# prod/main.tf
module "webserver_cluster" {
  source = github.com/Vivixell/Reusable-Infrastructure//modules/webserver?ref=v0.0.1"

  cluster_name  = "prod-app"
  instance_type = "t3.small"
  # ... standard inputs ( check the repo for the complete code)
}

check the repo for the complete code

The Development Environment (Testing Bleeding Edge)

The Dev team is actively testing the new tagging feature. Their environment points to v0.0.2.

# dev/main.tf
module "webserver_cluster" {
  source = "[github.com/Vivixell/Reusable-Infrastructure//modules/webserver?ref=v0.0.2](https://github.com/Vivixell/Reusable-Infrastructure//modules/webserver?ref=v0.0.2)"

  cluster_name  = "dev-app"
  instance_type = "t3.micro"

  # Testing the new feature introduced in v0.0.2!
  custom_tags = {
    Environment = "Development"
    Owner       = "OVR"
  }
}

When you run terraform init in these separate folders, Terraform downloads the exact, isolated versions of the code. If v0.0.2 has a catastrophic bug, Production remains completely safe.

Final Thoughts

Understanding file paths, inline blocks, and versioning is what separates writing Terraform scripts from building actual Infrastructure as Code architecture.

Are you pinning your module versions, or are you living dangerously on the main branch? Let me know in the comments.

Building Reusable Infrastructure: The Art of Terraform Modules

Victor Robin — Mon, 23 Mar 2026 20:31:19 +0000

If you are writing Terraform by putting all your resources into a single main.tf file, you aren't building infrastructure; you are just writing a very long deployment script.

On Day 6 of my Terraform journey, I built a highly available web cluster. It worked perfectly. But if my team suddenly asked for a Staging environment, my only option would have been to copy and paste 200 lines of code. That is a maintenance nightmare.

Today, for Day 8 of the 30-Day Terraform Challenge, I ripped that monolithic architecture apart and converted it into a reusable Terraform Module. Here is a breakdown of how module architecture actually works, the calling patterns, and the difference between a module your team will love and one they will hate.

The Anatomy of a Module Directory

A module is simply a container for multiple resources that are used together. The moment you start using modules, your mental model must split into two concepts: the Child Module (the blueprint) and the Root Module (the execution environment).

Here is the directory structure I built to manage this:

terraform-project/
├── modules/
│   └── webserver/       # The Child Module (The Blueprint)
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       ├── versions.tf
│       └── README.md
├── dev/                 # The Root Module (The Execution)
│   ├── main.tf          
│   ├── backend.tf       
│   └── .terraform.lock.hcl
└── prod/                # The Root Module (The Execution)
    ├── main.tf          
    ├── backend.tf       
    └── .terraform.lock.hcl

The Golden Rules of the Child Module

Notice what is missing from the modules/webserver folder: there is no provider "aws" block, and no backend "s3" block. A good module is completely agnostic. It should not know if it is being deployed to us-east-1 or eu-west-2, and it shouldn't care where its state file is stored. The Root environments (dev/ and prod/) handle the authentication and pass it down.

Inputs, Outputs, and the Calling Pattern

To make the blueprint reusable, you have to strip out every hardcoded value.

1. The Inputs (`variables.tf`)

Instead of naming my VPC "my-vpc", I introduced a cluster_name variable. I also removed the default values for my network CIDR blocks so the Root module is forced to provide them.

# modules/webserver/variables.tf

variable "cluster_name" {
  description = "The prefix for all resources (e.g., dev-app, prod-app)"
  type        = string
}


variable "vpc_cidr" {
  description = "The CIDR block for the VPC"
  type        = string
}

Inside the module's main.tf, every resource tag now dynamically references that input:

# modules/webserver/main.tf

resource "aws_vpc" "this" {
  cidr_block = var.vpc_cidr
  tags = { Name = "${var.cluster_name}-vpc" }
}

2. The Calling Pattern

With the blueprint ready, spinning up an entire production-grade environment in prod/main.tf requires just a few lines of code. The Root module "calls" the Child module using the source argument.


# prod/main.tf

provider "aws" {
  region = "us-east-1"
}

module "webserver" {
  source = "../modules/webserver" 

  cluster_name  = "prod-app"
  vpc_cidr      = "10.1.0.0/16" 
  instance_type = "t3.small"

  # ... subnet maps go here ...
}

3. The Outputs (`outputs.tf`)

When resources are buried inside a module, the Root environment cannot automatically see them. If I want to know the DNS name of my Load Balancer after I deploy, the module must explicitly export it.


# modules/webserver/outputs.tf

output "alb_dns_name" {
  value = aws_lb.alb.dns_name
}

The Root module then catches that output and displays it to the console:


# prod/main.tf

output "production_url" {
  value = module.webserver.alb_dns_name
}

Easy vs. Painful Modules: Best Practices

Writing a module is easy. Writing a good module requires architectural foresight.

1. Avoid Hardcoding with "Sensible Defaults"

A painful module hardcodes configurations. If my module hardcoded the Load Balancer to port 80, and the Dev team needed to test a Node.js app on port 8080, they would be blocked.

An easy-to-use module provides a sensible default. In my variables.tf, I set the HTTP port to 80 by default. If the user doesn't specify a port, it works out of the box. If they need something custom, they can easily override it in their Root module.

2. Module Scope: When to Split

Right now, my webserver module deploys the network (VPC, Subnets, NAT) and the compute layer (ALB, ASG, EC2). For my personal lab, this is fine.

In the real world, this is an anti-pattern. Networking lifecycles are very different from application lifecycles. Best practice dictates splitting this into two modules: a vpc-network module and an app-compute module. This prevents a bad application deployment from accidentally tearing down the company's core routing tables.

3. Write a Useful README

A Terraform module without a README.md is practically useless to another engineer. Your README must act as the API documentation for your infrastructure. It should include:

An architecture diagram or summary.
An exact copy-paste example of how to call the module (module { source = ... }).
A markdown table detailing every required input variable, its type, and its purpose.

Final Thoughts

Moving from flat files to modules is the threshold where you stop writing scripts and start acting as a true Platform Engineer. You are building guardrails, standardizing deployments, and making it fundamentally easier for your team to safely consume cloud resources.

You can check out the full refactored code and directory structure on my GitHub.

Deploying a Highly Available Web App on AWS Using Terraform

Victor Robin — Thu, 19 Mar 2026 21:45:16 +0000

Welcome to Day 4 of my 30 Days of Terraform challenge. If you followed along with my first article you remember we deployed a single server into a VPC using terraform. That was a great starting point but it had a massive flaw because a single server is a single point of failure. If that availability zone goes down or the server crashes your application goes offline with it.

Today we are evolving our infrastructure from a simple hardcoded server into a fully configurable and highly available clustered deployment. We are going to build a custom Virtual Private Cloud block with public and private subnets and place our application servers in the private subnets for security while an Application Load Balancer routes internet traffic to them.

Let us dive right into the architecture and the code.

Overview

In this setup we are building a robust network foundation. We will create a VPC spanning two Availability Zones to ensure redundancy. Our architecture includes an Application Load Balancer residing in the public subnets to receive web traffic and an Auto Scaling Group managing our EC2 instances in the private subnets.

This means our actual application servers are completely hidden from the direct internet and can only be accessed through the load balancer. We are also utilizing variables and data sources extensively so the code is dynamic and reusable instead of being rigidly hardcoded.

Prerequisites

Before you start deploying this architecture you need to make sure your environment is ready.

Terraform installed on your local machine
AWS CLI installed and configured with your credentials
Appropriate IAM permissions configured for your AWS user account

You must ensure your IAM user or role has the permissions to create VPC resources like subnets and route tables as well as EC2 instances and Load Balancing components. A lack of these permissions will cause the deployment to fail immediately.

Step by Step Guide

1. Cloning the Repository

You can grab the complete source code for this deployment directly from my GitHub repository to follow along.

git clone https://github.com/Vivixell/Highly-Available-Web-App-on-AWS-Using-Terraform.git

cd Highly-Available-Web-App-on-AWS-Using-Terraform

2. Running the Code

Once you have the code on your local machine the deployment process follows the standard Terraform workflow.

Initialize the working directory to download the AWS provider plugins:

terraform init

Review the execution plan to see exactly what Terraform will create in your AWS account:

terraform plan

Apply the configuration to build the infrastructure:

terraform apply -auto-approve

Once the deployment finishes Terraform will output the DNS name of your new Load Balancer so you can paste it into your browser and see the live application.

3. Understanding the Code

Let us break down the most critical parts of this configuration to understand how it all pieces together.

The Power of Variables

Hardcoding values is a bad practice because it forces you to rewrite your core logic whenever a requirement changes. We moved our configurations into variables.tf using maps and objects to keep things organized.

Here is how we handle our application ports and Auto Scaling capacities dynamically.

variable "server_ports" {
  description = "A dictionary mapping application layers to their ports"
  type = map(object({
    port        = number
    description = string
  }))
  default = {
    "http" = { 
      port        = 80
      description = "Standard web traffic" 
    }
  }
}

variable "asg_capacity" {
  description = "Capacity settings for the Auto Scaling Group"
  type = object({
    min     = number
    max     = number
    desired = number
  })
  default = {
    min     = 2
    max     = 4
    desired = 2
  }
}

The Security Groups

We operate on a zero trust model here. The load balancer security group allows public traffic on port 80 but our instance security group explicitly rejects all internet traffic and only accepts connections coming directly from the load balancer security group.

resource "aws_security_group" "instance_sg" {
  name        = "instance-sg"
  description = "Allow traffic from ALB only"
  vpc_id      = aws_vpc.my_vpc.id
}

resource "aws_vpc_security_group_ingress_rule" "instance_http" {
  security_group_id            = aws_security_group.instance_sg.id
  referenced_security_group_id = aws_security_group.alb_sg.id
  from_port                    = var.server_ports["http"].port
  to_port                      = var.server_ports["http"].port
  ip_protocol                  = "tcp"
}

The Launch Template and Auto Scaling Group

Instead of creating standalone EC2 instances we define a blueprint using a Launch Template. We dynamically fetch the latest Ubuntu AMI and pass a startup script that installs Apache and displays the specific private IP of the server so we can visually confirm the load balancer is working across different instances.

The Auto Scaling Group then takes this template and ensures we always have our desired number of servers running across our private subnets.

resource "aws_launch_template" "my_app" {
  name_prefix   = "my-app-lt-"
  image_id      = data.aws_ami.ubuntu.id
  instance_type = var.instance_type

  vpc_security_group_ids = [aws_security_group.instance_sg.id] 

  user_data = base64encode(<<-EOF
    #!/bin/bash
    apt-get update -y
    apt-get install -y apache2
    systemctl start apache2
    systemctl enable apache2
    echo "<h1>Hello from OVR Private Subnet! My IP is: $(hostname -I)</h1>" > /var/www/html/index.html
  EOF
  )
}

resource "aws_autoscaling_group" "my_asg" {
  name             = "my-app-asg"
  desired_capacity = var.asg_capacity.desired
  max_size         = var.asg_capacity.max
  min_size         = var.asg_capacity.min

  vpc_zone_identifier = [for subnet in aws_subnet.my_private_subnet : subnet.id]
  target_group_arns   = [aws_lb_target_group.my_tg.arn]

  launch_template {
    id      = aws_launch_template.my_app.id
    version = "$Latest"
  }

  tag {
    key                 = "Name"
    value               = "my-asg-instance"
    propagate_at_launch = true
  }
}

Challenges I Faced

Honestly the actual code writing and deployment went completely smoothly without any logic roadblocks on my end. The modular approach of mapping out the variables and understanding the flow of traffic made the process straightforward and highly predictable.

Possible Challenges You Might Have

While the code is solid you might run into environmental issues depending on your local setup.

Network Connectivity Drops: You might see an error like lookup sts.us-east-1.amazonaws.com: no such host when running the apply command. This simply means your local machine temporarily lost its connection to the AWS authentication servers usually due to a VPN drop or a local DNS issue.
IAM Permission Errors: If you are not using an Administrator account you will need to ensure your user has explicit permissions to create VPCs subnets load balancers and auto scaling groups otherwise AWS will reject the API calls.

Possible Improvements

This architecture is robust but there is always room to grow in cloud engineering. A great next step would be implementing HTTPS by requesting an SSL certificate from AWS Certificate Manager and attaching it to a secure listener on the load balancer. We could also break this monolithic file structure down further by separating the networking resources into a dedicated Terraform module to increase reusability across multiple environments.

Final Thoughts

Moving from a single instance to a load balanced auto scaling environment is one of the most important leaps you make as a cloud engineer. You are no longer just launching servers but rather designing resilient systems that can survive failures and scale with demand.

Stay tuned for the next phase of the challenge where we will dive even deeper into infrastructure automation.

DEV Community: Victor Robin

How to Convince Your Team to Adopt Infrastructure as Code

1. Stop Pitching the Tech. Pitch the Business Case.

2. The Incremental Strategy (How to Actually Do It)

3. How It Actually Fails in the Real World

The Bottom Line

Automating Terraform Testing: From Unit Tests to End-to-End Validation

Overview

Prerequisites

The Testing Strategy & Tradeoffs

1. Unit Tests (terraform test)

2. Integration Tests (Terratest)

3. End-to-End (E2E) Tests (Terratest)

Step-by-Step Guide: Running the Tests

Step 1: Clone the Repository

Step 2: Run the Unit Tests

Step 3: Run the Integration Tests

Step 4: The CI/CD Pipeline

Conclusion

The Importance of Manual Testing in Terraform

Why Manual Testing Still Matters

Building a Structured Test Checklist

Provisioning vs. Functional Verification

The Cleanup Discipline

Actual Test Results: Passes and Failures

From Sandbox to Production: Building a Resilient AWS Blue/Green Infrastructure with Terraform

Prerequisites

Tools Used

Folder Structure Overview

Step-by-Step Refactoring Guide

1. Reliability & Zero-Downtime Updates

2. Security & Input Validation

3. Observability

4. Automated Testing with Terratest

Final Thoughts

Deploying Multi-Cloud Infrastructure with Terraform Modules

The Monolith Problem

Pattern 1: The Multi-Provider Module

The Module Definition (modules/app/main.tf)

The Root Caller (live/main.tf)

Pattern 2: Local Container Orchestration

Pattern 3: Provider Chaining (AWS EKS + Kubernetes)

The Dynamic Authentication Block

Conclusion

Getting Started with Multiple Providers in Terraform

Overview

What is a Provider, Really?

Installation, Versioning, and The Lock File

The Constraint Syntax

Best Practice: You must commit this file to Git! It guarantees that your CI/CD pipeline and every engineer on your team downloads the exact same provider version, preventing the classic "It works on my machine" deployment failure.

Prerequisites for the Lab

Step-by-Step Guide: Multi-Region S3 Replication

Step 1: Clone the Repository

Step 2: Understand the Providers (providers.tf)

Step 3: Review the Infrastructure (main.tf)

The Primary Bucket:

The Replica Bucket:

Step 4: Deploy the Architecture

Step 6: Clean Up

How to Handle Sensitive Data Securely in Terraform

Leak Path 1: Hardcoded in .tf Files

Leak Path 2: Passed as a Variable with a Default

Leak Path 3: Stored in Plaintext in the State File

How Conditionals Make Terraform Infrastructure Dynamic and Efficient

1. The Ternary Operator & Environment-Aware Locals

2. The Optional Resource Pattern (count = condition ? 1 : 0)

3. Safely Referencing Conditionally Created Resources

4. Input Validation Blocks

Final Thoughts

30DayTerraformChallenge #Terraform #IaC #DevOps #AWSUserGroupKenya #EveOps #CloudEngineering

Mastering Loops and Conditionals in Terraform

1. count: The Simple Loop

2. The count Index Problem (The Danger Zone)

3. for_each: The Safe Loop

4. Conditionals: The Ternary Operator

5. for Expressions: Reshaping Data

Final Thoughts

Advanced Terraform Module Usage: Versioning, Gotchas, and Reuse Across Environments

Part 1: The 3 Terraform Module Gotchas

Gotcha 1: The File Path Trap

1. Unit Tests (`terraform test`)

The Module Definition (`modules/app/main.tf`)

The Root Caller (`live/main.tf`)

Step 2: Understand the Providers (`providers.tf`)

Step 3: Review the Infrastructure (`main.tf`)

Leak Path 1: Hardcoded in `.tf` Files

2. The Optional Resource Pattern (`count = condition ? 1 : 0`)

1. `count`: The Simple Loop

2. The `count` Index Problem (The Danger Zone)

3. `for_each`: The Safe Loop

5. `for` Expressions: Reshaping Data

1. The Inputs (`variables.tf`)

3. The Outputs (`outputs.tf`)