DEV Community: Farouq Mousa

Production-Ready Terraform - Part 3: The Finale — Automating Terraform with CI/CD

Farouq Mousa — Tue, 16 Dec 2025 09:32:30 +0000

Hello again,
In [Part 2], we moved our state to the cloud using S3 and secured it with locking (via DynamoDB or S3 Native). But we still have a problem: we are running Terraform from our laptops.

Running terraform apply locally is risky. It relies on local credentials, lacks audit trails, and "works on my machine" doesn't cut it for production. In this final chapter, we will build a fully automated CI/CD Pipeline that moves Terraform execution to a controlled environment.

We will cover:

Automating the Plan: Running terraform plan automatically on every Pull Request.
The "Human in the Loop": using GitHub Environments or Atlantis to approve changes safely.
The "PR-to-Prod" Workflow: A complete end-to-end lifecycle for your infrastructure.

1. Automating the Plan (GitHub Actions)

The first rule of CI/CD for infrastructure is visibility. When a developer opens a Pull Request (PR), we want to immediately see what would happen if we merged that code.

We will use GitHub Actions to automatically run terraform plan and post the results as a comment on the PR.

Prerequisites: OIDC (Stop using Keys!)

Security Note: Do not store long-lived AWS Access Keys in your GitHub Secrets. Instead, use OpenID Connect (OIDC). It allows GitHub Actions to assume an IAM Role in your AWS account temporarily.

Create an IAM Role in AWS with a trust policy allowing your GitHub repo.
Grant this role permissions to manage your infrastructure and access the S3 backend.

The "Plan" Workflow

Create a file at .github/workflows/terraform-plan.yml:

name: "Terraform Plan"

on:
  pull_request:
    branches: [ main ]

permissions:
  id-token: write # Required for OIDC
  contents: read
  pull-requests: write # Required to post comments

jobs:
  plan:
    name: "Terraform Plan"
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsTerraformRole
          aws-region: us-east-1

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        id: plan
        run: terraform plan -no-color -out=tfplan
        continue-on-error: true # Don't fail the job yet, we want to see the error in the comment

      - name: Post Plan to PR
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const plan = `${{ steps.plan.outputs.stdout }}`;
            const outcome = `${{ steps.plan.outcome }}`;

            const output = `#### Terraform Plan 📖 \`${outcome}\`
            <details><summary>Show Plan</summary>

            \`\`\`hcl
            ${plan}
            \`\`\`

            </details>`;

            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })

What this does:

Triggers whenever a PR is opened against main.
Authenticates to AWS securely via OIDC.
Runs terraform plan.
Critically: It uses a script to post the plan output directly into the PR conversation. Now, your team can review infrastructure changes just like they review code.

2. The "Human in the Loop": Approving the Apply

We never want to automatically apply changes to production without a human sanity check. Infrastructure mistakes can be catastrophic (e.g., accidentally deleting a database).

We have two main strategies for this:

Option A: The "GitHub Native" Way (Environments)

GitHub has a feature called Environments. You can create an environment called production and add a protection rule: "Required Reviewers".

When you set this up, the "Apply" workflow (triggered after merge) will pause and wait for a designated person to click "Approve" in the GitHub UI before running terraform apply.

Pros: Native to GitHub, easy to set up, free for public repos (and paid plans).
Cons: Requires maintaining two separate workflows (Plan on PR, Apply on Merge).

Option B: The "ChatOps" Way (Atlantis)

Atlantis is a popular open-source tool dedicated to Terraform automation. It runs as a service (e.g., in Fargate or K8s) and listens to webhooks from your repo.

Instead of clicking buttons, you interact via comments:

You comment atlantis plan on the PR. Atlantis runs the plan and replies with the output.
You comment atlantis apply. Atlantis locks the state, runs the apply, and automatically merges the PR if successful.

Pros: Incredible locking mechanism (locks the PR so no one else can edit), keeps the "Plan" and "Apply" strictly coupled (you apply exactly what you planned).
Cons: Requires hosting and maintaining a server/container.

3. The Full "PR-to-Prod" Automated Workflow

Let's assume we are using Option A (GitHub Native) for simplicity. Here is what the full lifecycle looks like:

1. The Trigger

A developer creates a new branch, changes an EC2 instance type in main.tf, and opens a Pull Request.

2. The Automated Plan

GitHub Actions triggers the Plan Workflow. It runs terraform plan, sees that an instance needs to change from t2.micro to t3.medium, and comments this diff on the PR.

3. The Human Review

The Tech Lead reviews the PR code and the Plan comment. They see that the change is intentional and safe. They approve the PR.

4. The Merge & Apply

The developer merges the PR into main. This triggers the Apply Workflow:

name: "Terraform Apply"

on:
  push:
    branches: [ main ]

jobs:
  apply:
    name: "Terraform Apply"
    runs-on: ubuntu-latest
    environment: production # <--- This enforces the "Human Approval" rule!

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsTerraformRole
          aws-region: us-east-1

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Init
        run: terraform init

      - name: Terraform Apply
        run: terraform apply -auto-approve

Because we added environment: production, this job will enter a "Waiting" state. GitHub notifies the required reviewers. Once approved, the job resumes, runs terraform apply -auto-approve, and your infrastructure is updated.

Conclusion & Series Takeaways 🎓

We have come a long way. We started with a fragile terraform.tfstate file on a laptop and ended with a robust, automated, team-ready CI/CD pipeline.

Key Takeaways from the Series:

Remote State is Non-Negotiable: Never keep state local. Use S3 (or compatible storage) to share state and prevent data loss.
Locking Saves Lives: Always implement locking (DynamoDB or S3 Native) to prevent two people from corrupting state by applying at the same time.
Don't Apply Blindly: Use CI/CD to visualize terraform plan on every Pull Request. Treat infrastructure changes with the same rigor as application code.
Least Privilege: Use OIDC for your pipelines. Don't scatter long-lived AWS Access Keys across developer laptops or CI systems.

By following this pattern, you transform Terraform from a "dangerous tool only the Ops lead can touch" into a safe, collaborative platform for the entire engineering team.

Happy Terraforming! Feel free to leave your questions in the comments, and I will be glad to connect on LinkedIn.

Disclaimer: Parts of this article were drafted with the help of an AI assistant. The technical concepts, code examples, and overall structure were directed, curated, and verified by the author to ensure technical accuracy and reflect real-world experience.

A Better Way to Write Production-Ready Terraform - Part 2 - Remote State Management

Farouq Mousa — Wed, 12 Nov 2025 13:41:09 +0000

Hey everyone, and welcome back! In Part 1 of this series, we tackled the first major challenge in writing professional IaC: modularity. We took a complex EKS cluster, broke it down into a reusable module, and learned how to use .tfvars and locals to create clean, declarative environment configurations.

Our dev environment's main.tf looked great. But we left off with a critical, unanswered question:

What happens when you actually run terraform apply?

If you followed along, you now have a terraform.tfstate file sitting in your environments/dev directory. This single file is the "source of truth" that maps your code to your real-world AWS resources.

And right now, it's a real Production-Killer!

The Danger of Local State Files

If you're working alone, on a single project, a local state file is fine. The second you add a teammate or a CI/CD pipeline, that local terraform.tfstate file becomes your biggest liability.

Here are the scenarios that keep me up at night:

The "Who Has the Latest?" Problem: You run apply, then your co-worker (who doesn't have your state file) also runs apply. They just created a second EKS cluster, or worse, their operation failed, thinking the first one didn't exist.
The "It's on My Laptop" Problem: You go on vacation. A production-down incident happens. The only copy of the production state file is on your encrypted laptop, which is 10,000 miles away. The team is completely blocked.
The "Race Condition" Problem: You and a colleague apply at the exact same time. You both read the same state file, and you both try to modify the same resource. This corrupts your state file, and now Terraform has no idea what's real and what's not.
The "Leaked Secrets" Problem: State files often contain sensitive data in plain text. If you accidentally git commit your state file, you've just pushed secrets to your repository.

The solution to all of this is Remote State.

Solution: Remote State with S3 and DynamoDB

A remote state backend moves the state file off your laptop and into a shared, centralized, and secured location. For our AWS stack, the standard pattern is a combination of two services:

Amazon S3: Used to store the state file itself.
Amazon DynamoDB: Used for state locking.

Wait, locking? What's that?

When you run terraform apply, Terraform will first place a "lock" in the DynamoDB table. If your co-worker tries to run apply at the same time, their command will fail, stating that the state is already locked by you. This simple mechanism completely prevents race conditions and state corruption.

How to Implement It

First, you need to create the S3 bucket and DynamoDB table. (You only do this once).

Pro Tip: Since these resources are the foundation for all your Terraform projects, I recommend creating them manually or with a simple, separate Terraform setup that you run and then "forget" about.

S3 Bucket: Create an S3 bucket. Let's call it my-awesome-app-tfstate. Enable bucket versioning (so you can roll back a bad state) and block all public access.
DynamoDB Table: Create a DynamoDB table. Let's call it terraform-state-lock. It only needs one attribute: a Partition key named LockID (with a type of String).

Configuring Your Environment

Now, in each of your environment directories (environments/dev, environments/prod), you add a new file. Let's call it backend.tf.

environments/dev/backend.tf

terraform {
  backend "s3" {
    bucket         = "my-awesome-app-tfstate"
    key            = "eks-cluster/dev/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

environments/prod/backend.tf

terraform {
  backend "s3" {
    bucket         = "my-awesome-app-tfstate"
    key            = "eks-cluster/prod/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Look closely at the key property. This is the magic.

We are storing both environment state files in the same bucket, but we're giving them unique paths (or "keys"). This provides perfect isolation. Your dev apply will read/write to the dev state file, and your prod apply will only touch the prod state file.

Now, when you cd environments/dev and run terraform init, Terraform will detect the backend block. It will ask if you want to copy your existing local state to the new S3 backend. Say "yes," and you're officially running on remote state!

This is a highly valuable update for your article series! The deprecation of DynamoDB-based locking in favor of the S3 native mechanism is a major shift that simplifies production workflows.

I will integrate this information into a new section in Part 2, aligning with your previous structure and tone. Note that the S3 native locking was generally available (GA) starting in Terraform v1.11.0, after being introduced as an experimental feature in v1.10.

Introducing S3 Native State Locking (Terraform v1.11+)

The core of our Part 2 solution—using a dedicated DynamoDB table for state locking—is the battle-tested, standard pattern. However, the world of Terraform is constantly evolving, and a major simplification has arrived that we must address: S3 Native State Locking.

While effective, relying on a DynamoDB table added cost and complexity. It forced us to manage an extra resource and grant additional IAM permissions for every environment, violating our goal of minimal overhead.

With Terraform v1.11.0 (and later), the S3 backend now includes a built-in locking mechanism that works without DynamoDB, leveraging S3's conditional write capabilities to ensure safety.

Why Switch from DynamoDB?

The motivation is simple: simplification and cost reduction.

Fewer Resources: You eliminate the need to provision and maintain a dedicated DynamoDB table.
Reduced Overhead: Less IAM policy management and fewer resources to monitor.
Lower Cost: Eliminates the small but constant cost associated with DynamoDB table usage.

While DynamoDB locking is robust, Terraform's long-term roadmap signals a shift towards this simplified, native locking model, with DynamoDB support slated for future deprecation.

How to Enable S3 Native Locking

The process is incredibly straightforward, requiring only the addition of the use_lockfile argument to your backend configuration.

Before: Using DynamoDB for Locking (The Classic Pattern)

terraform {  
  backend "s3" {  
    bucket         = "your-terraform-state-bucket"  
    key            = "path/to/your/statefile.tfstate"  
    region         = "us-east-1"  
    dynamodb_table = "terraform-state-lock"  # 👋 Goodbye, complexity!
    encrypt        = true  
  }  
}

After: Switching to S3 Native Locking

Ensure you are on Terraform v1.11.0 or newer. Simply remove the dynamodb_table line and add the lockfile flag:

terraform {  
  backend "s3" {  
    bucket       = "your-terraform-state-bucket"  
    key          = "path/to/your/statefile.tfstate"  
    region       = "us-east-1"  
    encrypt      = true  
    use_lockfile = true  # 🎉 S3 native locking enabled
  }  
}

With S3 locking enabled, Terraform creates a temporary .tflock file in the same location as the state file during any operation. You may need to update your S3 bucket policies and IAM permissions to accommodate the new lock file. You can also temporarily use both dynamodb_table and use_lockfile = true during your migration for maximum safety.

The New Problem: We're Not DRY

This is a huge improvement. Our state is secure, locked, and versioned. But as a senior engineer, something about this should bother you...

We're repeating ourselves.

That backend.tf block is identical in dev and prod, except for one line: the key. And what about our provider.tf? We're probably copying that into every environment too.

If we have 50 microservices, that's 50 (or 100, or 150) copies of the same backend.tf and provider.tf files. What happens when we need to update our provider version? We have to find and replace it in 150 places.

This is a violation of the DRY (Don't Repeat Yourself) principle.

The "Next Level" Solution: Terragrunt

This is where a tool like Terragrunt comes in. Terragrunt is a thin wrapper for Terraform that provides extra tools to manage multiple environments.

Its main superpower is keeping your environment configurations DRY.

With Terragrunt, your file structure changes. You get rid of backend.tf, provider.tf, etc., in your environment directories. Instead, you create a terragrunt.hcl file.

New Project Structure:

terraform-project/
├── modules/
│   └── aws-eks-cluster/
│       ├── main.tf
│       └── ...
├── environments/
│   ├── dev/
│   │   ├── terragrunt.hcl
│   │   └── dev.tfvars
│   ├── prod/
│   │   ├── terragrunt.hcl
│   │   └── prod.tfvars
│   └── terragrunt.hcl  # <--- A NEW ROOT FILE

1. The Root terragrunt.hcl
This file defines the configuration you want to share across all environments.

# environments/terragrunt.hcl

# Configure the remote state backend ONCE
remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "override"
  }
  config = {
    bucket         = "my-awesome-app-tfstate"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

# Define the inputs we want to pass to our Terraform modules
inputs = {
  # We can automatically load .tfvars files
  # This finds dev.tfvars in dev, prod.tfvars in prod, etc.
}

That key = "${path_relative_to_include()}/terraform.tfstate" is the magic. Terragrunt will automatically generate a unique key for each environment based on its directory path (e.g., dev/terraform.tfstate).

2. The Environment terragrunt.hcl
Now, your environment-specific files become incredibly simple.

environments/dev/terragrunt.hcl

include "root" {
  path = find_in_parent_folders()
}

# Tell Terragrunt where our actual Terraform module is
terraform {
  source = "../../modules/aws-eks-cluster"
}

# All inputs are automatically loaded from dev.tfvars!

That's it. This file tells Terragrunt to:

Go find the root terragrunt.hcl and inherit all its settings (like the S3 backend).
Use the aws-eks-cluster module as its source code.
Automatically find and use all the variables defined in dev.tfvars.

Now, to deploy dev, you cd environments/dev and run:
terragrunt apply

Terragrunt will, in the background, generate the backend.tf file for you, pull down the module, and run terraform apply with all your variables from dev.tfvars.

We have achieved the ultimate goal:

Modules are DRY (Part 1).
State Management is robust and safe (Part 2).
Environment Configuration is DRY (Part 2).

What's Next in Part 3?

We've come a long way. We've defined our infrastructure as reusable modules, and we've built a scalable, DRY structure to manage state and configuration for multiple environments.

But how do we run this? So far, we've been running terragrunt apply from our laptops. That's not a real-world workflow.

In Part 3, we'll tie this all together in a CI/CD Pipeline. We'll explore:

How to set up GitHub Actions (or your tool of choice) to run plan on every pull request.
The "human in the loop": Using tools like Atlantis or GitHub Actions approval steps to safely run apply.
A full, "PR-to-Prod" automated workflow.

Stay tuned, and happy building! Feel free to leave your questions in the comments, and I will be glad to connect on LinkedIn.

A Better Way to Write Production-Ready Terraform - Part 1 - Modularity

Farouq Mousa — Sat, 27 Sep 2025 14:43:55 +0000

Hey everyone! If you've been in the DevOps or Cloud Engineering space for a while, you've probably seen it all. From a single, monstrous main.tf file that tries to define an entire universe, to copy-pasting code across projects until you can't tell which Kubernetes cluster belongs to dev and which one is the prod money-maker.

We've all been there. You start with a simple project, and it works. Then business asks you to spin up a staging environment. Then a UAT environment. Soon, you're drowning in duplicated code, and a simple change (like a Kubernetes version upgrade) requires updating five different places. That's not just messy; it's a recipe for disaster.

Over the years, I've learned that writing good Infrastructure as Code (IaC) is a lot like writing good application code. It's all about patterns, reusability, and modularity. In this multi-part series, I'll walk you through the design patterns I use to build robust, scalable, and easy-to-manage Terraform projects for AWS.

Today, we're starting with the absolute foundation for taming complexity: The Module Pattern.

What's Wrong With a Giant `main.tf`?

Imagine you're building a car engine. You could try to assemble every single piston, wire, and bolt in one go, right on the factory floor. It might work, but what happens when you want to build a slightly different engine for a different car model? You'd have to start from scratch or painstakingly copy your first creation.

A monolithic main.tf file for an EKS cluster is that chaotic assembly. It mixes the what (an EKS control plane, IAM roles, node groups, security groups) with the where and why (this is for the dev environment with t3.medium nodes, this is for the prod app with m5.large nodes).

This approach has several major flaws:

It's not DRY (Don't Repeat Yourself): Creating a new environment means copying hundreds of lines of complex IAM and networking code.
High cognitive load: Understanding the cluster setup requires deciphering a huge, interconnected block of code.
High blast radius: A small typo in an IAM policy could cripple your entire cluster, and if you've copy-pasted, that vulnerability exists in every environment.

We can do better. Instead of assembling the engine piece by piece every time, let's build pre-fabricated components, like a complete fuel injection system or a pre-wired ignition module. In Terraform, we call these modules.

The Module Pattern: Your IaC Building Blocks

A Terraform module is a self-contained package of Terraform configurations that are managed as a group. Think of it as a function in a programming language. It takes some inputs (variables), performs some actions (creates resources), and provides some outputs.

For something like an EKS cluster, a module is a lifesaver. It can encapsulate all the boilerplate resources needed to get a cluster up and running:

The EKS cluster control plane itself.
The complex IAM roles and policies for the cluster and its nodes.
The managed node groups, including their launch templates and auto-scaling configurations.

You then call this single module from your environment-specific code, passing in values like the cluster name, version, and instance types.

A Practical Example: A Reusable EKS Cluster Module

Let's build a simplified version. A common best practice is to have a modules directory in your repository where you store your custom, reusable modules. Our initial project structure looks like this:

terraform-project/
├── modules/
│   └── aws-eks-cluster/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
└── environments/
    └── dev/
        └── main.tf

Inside modules/aws-eks-cluster/, we define the module's API (variables.tf), its logic (main.tf), and its return values (outputs.tf).

(For brevity, the full code for the EKS module is omitted here but is the same as in our previous discussion. It defines resources like aws_eks_cluster, aws_eks_node_group, and their associated IAM roles.)

Patterns for Environment Variables

Okay, we have our reusable EKS module. Now for the most important part: How do we feed it the right configuration for each environment (dev, prod, etc.) in a way that is clean, scalable, and easy to manage?

Let's look at the evolution of passing variables, from the basic approach to the recommended best practice.

Method 1: In-line Arguments

The most straightforward way is to hardcode the values directly in the module block inside your environment's main.tf.

# environments/dev/main.tf

module "eks_cluster" {
  source = "../../modules/aws-eks-cluster"

  # --- In-line arguments ---
  cluster_name                = "my-app-dev-cluster"
  node_group_instance_types   = ["t3.medium"]
  node_group_desired_size     = 2
  # ... other variables
}

This is fine for a quick test, but it doesn't scale. It mixes configuration with logic, making the file hard to read and forcing you to hunt for values when you need to make a change.

Method 2: Using `.tfvars` Files (The Standard Way)

A much better pattern is to separate your configuration values from your resource logic. A .tfvars file is a simple text file for variable assignments. You create one for each environment.

1. Define Root Variables: First, in your environment directory (environments/dev/), create a variables.tf file to declare the variables this environment will accept.

# environments/dev/variables.tf

variable "node_group_instance_types" {
  description = "Instance types for the EKS node group."
  type        = list(string)
}
# ... other variable definitions

2. Create an Environment .tfvars File: Now, create a dev.tfvars file in the same directory to provide the values.

# environments/dev/dev.tfvars

node_group_instance_types   = ["t3.medium"]
node_group_desired_size     = 2

Your prod environment would have its own prod.tfvars with different values, like ["m5.large"].

3. Update main.tf and Apply: Your main.tf now uses these variables, becoming generic.

# environments/dev/main.tf
module "eks_cluster" {
  source = "../../modules/aws-eks-cluster"

  # Pass variables from the root module to the child module
  node_group_instance_types = var.node_group_instance_types
  # ...
}

You then apply the specific configuration from the command line: terraform apply -var-file="dev.tfvars". This cleanly separates the "what" from the "how."

Method 3: Using `locals` for Derived Values

What if you want to enforce a consistent naming convention? Instead of defining cluster_name in every .tfvars file, you can derive it using locals. Locals are like named constants within your configuration.

Create a locals.tf file in your environment directory.

# environments/dev/locals.tf

locals {
  # Base variables
  environment = "dev"
  project     = "my-app"

  # Derived value to enforce naming conventions
  cluster_name = "${local.project}-${local.environment}-cluster"

  # Centralized map of tags
  common_tags = {
    Environment = title(local.environment)
    Project     = local.project
  }
}

Now, your main.tf can use this local value, ensuring consistency: cluster_name = local.cluster_name.

Putting It All Together: The Recommended Structure

For a truly robust and readable project, you should combine Methods 2 and 3.

Use .tfvars files for the raw inputs that change between environments (instance sizes, counts).
Use locals to enforce conventions and derive values (names, tags).

Here is the complete, recommended file structure and workflow for your dev environment:

Project Structure:

terraform-project/
├── modules/
│   └── aws-eks-cluster/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
└── environments/
    └── dev/
        ├── main.tf           # Orchestrates the modules
        ├── variables.tf      # Defines input variables for the environment
        ├── locals.tf         # Defines naming conventions and common tags
        └── dev.tfvars        # Sets the actual values for dev

dev.tfvars (The Raw Config):

# environments/dev/dev.tfvars
instance_types = ["t3.medium"]
node_count     = 2

locals.tf (The Conventions):

# environments/dev/locals.tf
locals {
  environment = "dev"
  project     = "my-app"
  cluster_name = "${local.project}-${local.environment}-cluster"
  common_tags = {
    Environment = title(local.environment)
    Project     = local.project
    ManagedBy   = "Terraform"
  }
}

main.tf (The Orchestrator):

# environments/dev/main.tf
module "eks_cluster" {
  source = "../../modules/aws-eks-cluster"

  # Values from locals
  cluster_name = local.cluster_name
  tags         = local.common_tags

  # Values from .tfvars file
  node_group_instance_types = var.instance_types
  node_group_desired_size   = var.node_count

  # Other values like VPC and subnets
  vpc_id     = data.aws_vpc.selected.id
  subnet_ids = data.aws_subnets.private.ids
}

This pattern gives you the best of all worlds: a clean separation of concerns, enforced consistency, and environment configurations that are simple and easy to audit.

What's Next in Part 2?

We've now built a reusable module and established a robust pattern for configuring it across multiple environments. This is a massive step towards professional-grade IaC.

But there's still a critical piece of the puzzle missing: State Management. Where does Terraform store the state file for each environment? How do we prevent developers from accidentally running dev changes against the prod state?

In Part 2, we'll explore patterns for remote state backends (using S3, of course!) and introduce tools like Terragrunt to keep our environment configurations even more DRY.