Infrastructure as Code (IaC): Definition, Tools, Examples

What is Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) is the practice of managing infrastructure (servers, networks, databases, load balancers, DNS, IAM policies) through code instead of manual console clicks or one-off scripts. The code lives in version control, gets reviewed in pull requests, and is applied via CI/CD — exactly like application code.

IaC has become foundational for any non-trivial cloud deployment. AWS, Azure, GCP, and Kubernetes are all configurable via APIs; IaC tools wrap those APIs in higher-level languages and provide idempotency, drift detection, and rollback.

Why IaC?

• Reproducibility. Spin up identical environments (dev, staging, prod) from the same code.
• Version control. Every infrastructure change is git-tracked, diffable, reviewable.
• Disaster recovery. Lost a region? Re-deploy infrastructure from code in minutes.
• Documentation by default. The code IS the documentation.
• Auditability. Who changed what, when — visible in git history.
• Testing. Plan/preview changes before applying.
• Collaboration. Pull requests + reviews on infrastructure changes.
• Modularity. Reusable modules across teams/projects.

IaC tools comparison

Declarative vs imperative IaC

Most teams now prefer declarative for predictability; imperative (Pulumi/CDK) wins for complex multi-cloud logic.

Terraform example

# main.tf
provider "aws" {
  region = "eu-west-1"
}

resource "aws_s3_bucket" "website" {
  bucket = "my-marketing-site"
  tags = {
    Environment = "production"
  }
}

resource "aws_cloudfront_distribution" "cdn" {
  origin {
    domain_name = aws_s3_bucket.website.bucket_regional_domain_name
    origin_id   = "s3-website"
  }
  enabled = true
  default_cache_behavior {
    target_origin_id       = "s3-website"
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
  }
  # ... viewer cert, restrictions, etc.
}

terraform init
terraform plan   # Preview changes
terraform apply  # Apply changes

IaC workflow

1. Write infrastructure code in a repo
2. Open a pull request with the change
3. CI runs terraform plan + posts diff to PR
4. Reviewer checks the plan
5. Merge → CI runs terraform apply
6. State + outputs stored in remote backend (S3 + DynamoDB lock)

IaC best practices

• Remote state with locking. S3 + DynamoDB (Terraform), AWS-managed (CFN). Prevents concurrent applies.
• Modularize. VPC module, RDS module, etc. Reusable across environments.
• Separate environments. Different state files per dev/staging/prod.
• Plan before apply. Always review the plan; never blindly apply.
• Pin tool + provider versions. Avoid surprises from upstream changes.
• Don't commit secrets. Use AWS Secrets Manager / Vault / SOPS.
• Use workspaces / aliasing for multi-region.
• Drift detection. Run plans regularly; investigate any drift.
• Policy-as-code. Sentinel, OPA, Checkov — enforce rules in CI.
• Tag everything. Cost allocation + ownership.

Common IaC pitfalls

• Manual changes drift the state. Someone clicks in console; terraform plan wants to revert.
• State file in git. Contains secrets. Use remote backend.
• No state locking. Two engineers run apply simultaneously; corrupt state.
• Mega-monolith state. One state file for everything; blast radius huge. Split.
• Hardcoded values. Use variables + locals; parametrize for environments.
• Insufficient testing. Apply to staging first; never straight to prod.
• Ignored deprecation warnings. Provider/CFN deprecations bite later.
• Forgetting the destroy plan. When tearing down, plan + review carefully — destroy is irreversible.

FAQ: Infrastructure as Code

Terraform or CloudFormation?

Terraform if multi-cloud or you prefer HCL. CloudFormation if AWS-only and want native + free state management.

What's the difference between IaC and configuration management?

IaC provisions infrastructure (cloud resources). Config management (Ansible, Chef) configures the OS/apps inside provisioned hosts. Increasingly blurred — Ansible can do both.

Should I use modules?

Yes for anything reusable. Don't over-modularize prematurely; start simple, refactor when you have ≥3 use cases.

Where do I store Terraform state?

Remote backend with locking: S3 + DynamoDB on AWS, GCS on GCP, Azure Storage on Azure, Terraform Cloud, Spacelift, etc.

How do I handle secrets in IaC?

Reference secrets from external stores (AWS Secrets Manager, Vault). Never commit secrets to git. Use SOPS or git-crypt for encrypted-at-rest values.

What's drift?

When real infrastructure differs from what the code declares. Caused by manual changes. Run terraform plan regularly; reconcile or block manual changes.

Can I use IaC for Kubernetes?

Yes — Terraform, Pulumi, Crossplane, or Helm/Kustomize for K8s manifests. K8s is itself declarative.

Test IaC-deployed apps with LoadFocus

After IaC provisions your infrastructure, LoadFocus verifies it handles real traffic — running JMeter and k6 scripts from 25+ regions. Sign up free at loadfocus.com/signup.