Infrastructure as Code — Terraform, Pulumi, and Why You Should Never Click in a Console Again

If it's not in code, it doesn't exist#

You spent an hour configuring a load balancer in the AWS console. It works perfectly. Three months later, you need to recreate it in a new region.

Can you? Probably not. You don't remember the settings. Nobody documented them. The console doesn't have version history.

Infrastructure as Code solves this: define your infrastructure in files, version them in git, and apply them automatically.

What IaC actually gives you#

Reproducibility. Run the same code, get the same infrastructure. Every time. In any region.

Version control. Infrastructure changes go through pull requests. Review before deploy. Rollback by reverting a commit.

Automation. CI/CD pipelines apply infrastructure changes. No human clicking buttons.

Documentation. The code IS the documentation. Want to know how your network is configured? Read the code.

The tools#

Terraform (HCL)#

The industry standard. Declarative configuration language.

resource "aws_instance" "api" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"

  tags = {
    Name = "api-server"
  }
}

Strengths: Multi-cloud, massive provider ecosystem, mature state management. Weaknesses: HCL is a new language to learn. State management can be tricky.

Pulumi (TypeScript/Python/Go)#

Write infrastructure in real programming languages.

const server = new aws.ec2.Instance("api", {
  ami: "ami-0c55b159cbfafe1f0",
  instanceType: "t3.medium",
  tags: { Name: "api-server" },
});

Strengths: Use your existing language. Loops, conditionals, and functions work naturally. Strong typing catches errors early. Weaknesses: Smaller ecosystem than Terraform. Learning curve if you're new to cloud APIs.

AWS CDK#

AWS-specific, generates CloudFormation under the hood.

Best for: AWS-only shops that want to stay in the AWS ecosystem. Limitation: Locked to AWS. Can't manage GCP, Azure, or third-party services.

The workflow#

1. Write code → terraform plan (preview changes)
2. Review diff → "Adding 1 load balancer, modifying 2 security groups"
3. Approve → terraform apply (make changes)
4. Commit → git push (version the change)

Every infrastructure change is:

• Previewed before applying
• Reviewed by a teammate
• Tracked in git history
• Reproducible

State management#

Terraform tracks the current state of your infrastructure in a state file. This maps your code to real resources.

Remote state (required for teams): Store state in S3, GCS, or Terraform Cloud. Lock it so two people can't apply simultaneously.

State drift: Someone changes something in the console. Now the state file doesn't match reality. terraform plan will show the drift. Either fix it in code or import the change.

Common patterns#

Modules. Reusable infrastructure components. A "VPC module" creates the same networking setup everywhere.

Environments. Same code, different variables. dev.tfvars, staging.tfvars, prod.tfvars.

Workspaces. Terraform workspaces for managing multiple instances of the same infrastructure.

From architecture to infrastructure#

On Codelit, you can generate any system architecture and export it directly as Terraform code. The architecture becomes real infrastructure — databases, load balancers, queues, and CDNs defined as code, ready to deploy.

---

Turn architectures into code: generate a system on Codelit.io and click Export → Terraform to get deployable infrastructure.