Key takeaways

  • Infrastructure as code (IaC) means defining your cloud resources in files instead of clicking in a console. Terraform is the most widely used tool for it.
  • With Terraform, every change is reviewed, repeatable and recorded in Git, and you can rebuild an environment from scratch.
  • The setup that matters most: remote state with locking, separate state per environment, small reusable modules and a CI/CD pipeline that runs plan and apply.
  • Most teams can move an existing AWS setup into Terraform step by step, without downtime.

What is infrastructure as code?

Infrastructure as code means you describe your servers, databases, networks and permissions in text files, store them in Git and let a tool create or change the real resources to match.

Without IaC, infrastructure is built by hand in the AWS console. It works until someone needs to rebuild it, copy it to a new region or understand why production differs from staging. Nobody remembers every click.

With IaC, your infrastructure gets the same benefits as application code. (If you want help setting this up, see our CI/CD and Terraform consulting.)

  • Reviews. Every change goes through a pull request.
  • History. Git shows who changed what and why.
  • Repeatability. Staging and production come from the same code.
  • Recovery. If an environment is lost, you can recreate it.
Console (by hand) Infrastructure as code (Terraform)
How changes happen Clicks, often undocumented Pull request, reviewed and recorded in Git
Staging vs production Drift apart over time Built from the same code
Rebuild after an incident Days, from memory Minutes to hours, from code
Who can make changes Whoever has console access Through the pipeline, with approvals
Audit trail for SOC 2 Hard to prove Git history and CI logs

Why Terraform for infrastructure as code

Terraform, from HashiCorp, is the most common IaC tool for teams on AWS. You write configuration in HCL, a readable language, and Terraform works out which resources to create, change or delete.

Why teams choose it:

  • Works across providers. AWS, Google Cloud, Cloudflare, GitHub, Datadog and hundreds more, in one workflow.
  • Plan before apply. terraform plan shows exactly what will change before anything happens.
  • Large ecosystem. Well-maintained community modules exist for most AWS services.
  • Hiring. Most DevOps engineers already know it.

A note on licensing: Terraform moved to the Business Source License in 2023. For almost all companies using it to manage their own infrastructure, nothing changes. OpenTofu is an open-source fork that is largely compatible if you prefer an open license.

Terraform vs CloudFormation. CloudFormation is AWS-only and managed by AWS. Terraform is better if you use more than one provider or want one tool for everything. Both are valid; what matters is using one consistently.

How a Terraform project should be structured

A simple, scalable layout for a SaaS team:

infra/ modules/ network/ database/ service/ envs/ staging/ main.tf backend.tf production/ main.tf backend.tf
  • Modules hold reusable building blocks, such as a VPC or a service with its load balancer.
  • Environments call those modules with their own settings.
  • Each environment has its own state. A mistake in staging can never touch production.

Keep modules small and focused. One giant module that builds everything becomes impossible to change safely.

Terraform state: the part teams get wrong

Terraform keeps a state file that records which real resources it manages. Handle it carefully:

  • Store it remotely. Use an S3 bucket with versioning and encryption, never a laptop.
  • Lock it. Two people running apply at the same time can corrupt state. Newer Terraform versions support locking directly in S3 with use_lockfile = true. Older setups use a DynamoDB table.
  • Separate it. One state per environment, and often per major component, so each plan stays small and fast.
  • Protect it. State can contain secrets. Restrict access to the bucket and keep secrets in AWS Secrets Manager or SSM Parameter Store.

Running Terraform in CI/CD

Running Terraform from laptops does not scale. A typical pipeline in GitHub Actions:

  1. On a pull request: run terraform fmt, validate, a security scan and plan, and post the plan as a comment.
  2. Review: a teammate reads the plan, not just the code.
  3. On merge: run apply for that environment, with production protected by an approval step.

Use OIDC to let GitHub Actions assume an IAM role in AWS, instead of storing long-lived access keys as secrets.

Useful checks to add:

  • tflint for mistakes and bad practices.
  • Checkov or Trivy for security issues such as public buckets or open security groups.
  • Infracost to show how much a change will cost before it ships.

Moving an existing AWS setup into Terraform

Most teams already have infrastructure built by hand. You do not need to rebuild it:

  1. Start with what changes most often, for example your application services, not the VPC.
  2. Import existing resources. Terraform import blocks bring real resources under management without recreating them, and terraform plan -generate-config-out can draft the configuration for you.
  3. Run plan until it shows no changes. That means your code matches reality.
  4. Lock down console access so changes go through Terraform from now on.
  5. Repeat for the next component.

A typical SaaS team can move its core AWS setup in 2 to 6 weeks, depending on size and how much was built by hand.

Common Terraform mistakes

  • One state for everything. Plans become slow and every change is risky.
  • Hardcoded values everywhere. Use variables and module inputs.
  • Secrets in code or state without protection.
  • Changes made in the console after Terraform. This creates drift. Run a scheduled plan to catch it.
  • No version pinning. Pin Terraform and provider versions so builds do not break unexpectedly.
  • Giant modules. Keep them small enough to understand in one sitting.

FAQ

Is Terraform free to use?

Yes, for managing your own infrastructure. HashiCorp also sells paid platforms such as HCP Terraform, but most teams run the free CLI in their own CI/CD.

Should we use Terraform or OpenTofu?

Either works. Terraform has the larger ecosystem and commercial support. OpenTofu is open source under the Linux Foundation and is largely compatible. Pick one and stay consistent.

How long does it take to adopt infrastructure as code?

A new project can use Terraform from day one. Moving an existing AWS setup usually takes 2 to 6 weeks for a typical SaaS team.

Do we need Terraform if we only use AWS?

Not strictly. CloudFormation or AWS CDK are fine. Terraform is the better choice if you also manage Cloudflare, GitHub, monitoring tools or another cloud.

Next step

If your infrastructure still lives in the AWS console, or your Terraform has grown messy, we can help. See our CI/CD and Terraform consulting, or read what DevOps consulting services include and cost.

Originally published at kestronai.com.