Terraform Networking Patterns#

Networking is the first thing you build and the last thing you want to change. CIDR ranges, subnet allocation, and connectivity topology are difficult to modify after resources depend on them. Getting the network right in Terraform saves months of migration work later.

This article covers the networking patterns across AWS, Azure, and GCP — from basic VPC design to multi-region hub-spoke topologies.

CIDR Planning#

Plan CIDR ranges before writing any Terraform. Once a VPC is created with a CIDR block, changing it requires recreating the VPC and everything in it.

Terraform Provider Configuration Patterns#

Providers are Terraform’s interface to cloud APIs. Misconfiguring them causes resources to be created in the wrong region, with the wrong credentials, or with an incompatible provider version. These failures are often silent — Terraform succeeds, but the resource is in the wrong place.

Version Constraints#

The Required Providers Block#

Every configuration should declare its providers with version constraints:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.25"
    }
    helm = {
      source  = "hashicorp/helm"
      version = "~> 2.12"
    }
  }
}

Version Constraint Syntax#

Recommended patterns:

Terraform Safety for Agents#

Terraform is the most dangerous tool most agents have access to. A single terraform apply can create, modify, or destroy real infrastructure — databases with production data, networking that carries live traffic, security groups that protect running services. There is no undo button. terraform destroy is not an undo — it is a different destructive action.

This article defines the safety protocols agents must follow when working with Terraform: what to check before every plan, how to read plan output for danger, how to present plans to humans, when to apply vs when to stop, and how to handle state conflicts.

Terraform Secrets and Sensitive Data#

Every Terraform configuration eventually needs a password, API key, or certificate. How you handle that secret determines whether it ends up in your state file (readable by anyone with state access), in plan output (visible in CI logs), in version control (permanent history), or properly managed through a secrets provider.

This article covers the patterns for handling secrets at every stage of the Terraform lifecycle — from variable declaration through state storage.

Terraform Workspaces vs Directories#

You have dev, staging, and production. Same infrastructure, different sizes and settings. How do you organize Terraform? Two competing approaches:

• Workspaces: One set of .tf files, multiple state files selected by terraform workspace select
• Directories: Separate directories per environment, each with their own .tf files and state

Both work. Both have tradeoffs. The right choice depends on how similar your environments are, who manages them, and how much isolation you need.

Testing Infrastructure Code#

Infrastructure code has a unique testing challenge: the thing you are testing is expensive to instantiate. You cannot spin up a VPC, an RDS instance, and an EKS cluster for every pull request and tear it down 5 minutes later without significant cost and time. But you also cannot ship untested infrastructure changes to production without risk.

The solution is the same as in software engineering: a testing pyramid. Fast, cheap tests at the bottom catch most errors. Slower, expensive tests at the top catch the rest. The key is knowing what to test at which level.

Testing Strategies in CI Pipelines#

Every CI pipeline faces the same tension: run enough tests to catch bugs before they merge, but not so many that developers wait twenty minutes for feedback on a one-line change. The answer is not running everything everywhere. It is running the right tests at the right time.

The Three Test Tiers#

Tests divide into three tiers based on execution speed, failure signal quality, and infrastructure requirements.

Testing Strategy Selection#

Choosing the right mix of tests determines whether your test suite catches real bugs or just consumes CI minutes. There is no single correct answer – the right strategy depends on your system architecture, team size, deployment cadence, and the cost of production failures.

The Testing Pyramid#

The classic testing pyramid, introduced by Mike Cohn, prescribes many unit tests at the base, fewer integration tests in the middle, and a small number of end-to-end tests at the top.

The ROI of Agent Infrastructure#

Most people skip agent infrastructure setup because the first task feels urgent. The second task is also urgent. By the tenth task, they have spent more time re-explaining context, correcting assumptions, and watching the agent re-derive decisions than the infrastructure would have cost to set up.

This article quantifies the return on agent infrastructure investment — not in abstract terms, but in minutes per session, tokens per project, and errors per workflow.

Threat Modeling for Developers#

Threat modeling is the practice of systematically identifying what can go wrong in a system before it goes wrong. It is not a security team activity that happens once. It is a design activity that happens every time the architecture changes.

The output of threat modeling is not a report that sits in a wiki. It is a prioritized list of threats that becomes security requirements in the backlog.