HashiConf 2025 Don't miss the live stream of HashiConf Day 2 happening now View live stream
Well-Architected Framework

Use infrastructure as code

Before you can automate your infrastructure processes, you need to clearly define what infrastructure systems and tools you need. Infrastructure as code (IaC) provides a declarative approach to defining your infrastructure that creates version-controlled specifications you can review, test, and automate. This document explains what infrastructure as code is, why you should use it, and how to implement it with Terraform.

What is infrastructure as code

Infrastructure as code lets you define your infrastructure using declarative configuration files instead of manual processes. Rather than clicking through cloud provider consoles or running manual commands, you write code that describes your desired infrastructure state, and infrastructure as code tools then create, modify, and manage your infrastructure to match that state. This approach makes your infrastructure configurations readable, shareable, and versionable—you can understand your complete infrastructure topology by reading configuration files and apply the same engineering practices to infrastructure that you use for application development, including code review, automated testing, CI/CD deployment, and phased rollouts.

Why use infrastructure as code

Infrastructure as code addresses the following operational challenges:

  • Eliminate manual configuration errors: Manual infrastructure provisioning through cloud consoles leads to inconsistent configurations, missed steps, and deployment failures. Infrastructure as code defines infrastructure declaratively, reducing human error from the provisioning process.

  • Enable team collaboration: Traditional infrastructure management creates knowledge silos where only specific team members understand production systems. Infrastructure as code stores configurations in version control, enabling code review, collaboration, and knowledge sharing across your entire team through pull requests and documentation.

  • Provide auditability and compliance: Manual changes through cloud consoles leave incomplete audit trails that fail compliance requirements. Infrastructure as code captures every infrastructure modification in version control with commit messages explaining who made changes, when, and why, creating comprehensive audit trails for security and compliance teams.

Infrastructure as code provides the following benefits:

  • Version control: Track every infrastructure change over time through version control history, enabling you to understand how your infrastructure evolved and why specific decisions were made.

  • Consistency: Deploy identical infrastructure across all environments, eliminating configuration drift between development, staging, and production that causes environment-specific bugs.

  • Testing: Validate infrastructure changes before deployment through automated testing, catching errors and policy violations before they reach production systems.

  • Automation: Integrate infrastructure deployments into CI/CD pipelines, enabling continuous delivery of infrastructure changes alongside application deployments.

  • Documentation as code: Infrastructure definitions serve as living documentation that stays synchronized with actual deployed resources, unlike separate documentation that quickly becomes outdated.

How to implement infrastructure as code

You implement infrastructure as code using tools that let you define infrastructure declaratively and apply those definitions to create actual resources. Terraform is an infrastructure as code tool that works with any cloud provider or service in its provider ecosystem, or any system with an API.

Terraform uses providers to interact with cloud resources and services. Terraform creates and manages these resources by storing the state of your infrastructure. You define the desired state of your infrastructure using HashiCorp Configuration Language (HCL), and Terraform deploys and configures the resources to match your configuration.

Define basic infrastructure

The following Terraform configuration defines basic infrastructure including networking, compute, and storage resources:

main.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

# Look up Ubuntu AMI
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical's AWS account ID

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-plucky-25.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

# Define virtual network
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = {
    Name        = "main-vpc"
    Environment = "production"
  }
}

# Define subnet within the network
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  map_public_ip_on_launch = true

  tags = {
    Name = "public-subnet"
  }
}

# Define compute instance
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.public.id

  tags = {
    Name = "web-server"
    Role = "webserver"
  }
}

# Define storage
resource "aws_s3_bucket" "app_data" {
  tags = {
    Name        = "Application Data"
    Environment = "production"
  }
}

# Output important values
output "instance_public_ip" {
  value       = aws_instance.web.public_ip
  description = "Public IP address of the web server"
}

output "bucket_name" {
  value       = aws_s3_bucket.app_data.id
  description = "Name of the S3 bucket"
}

The Terraform configuration defines a VPC with a subnet, launches an EC2 instance in that subnet, and creates an S3 bucket for application data. When you run terraform apply, Terraform creates these resources in AWS. The configuration shows resource dependencies—the subnet references the VPC ID, and the instance references the subnet ID. Terraform automatically determines the correct creation order based on these dependencies.

Terraform maturity progression

The following Terraform maturity model provides a roadmap to help you create consistent infrastructure, application configurations, and images:

  1. Adopt: Compose infrastructure as code in Terraform files using HCL to provision resources from any infrastructure provider. Start by defining simple resources like virtual machines, networks, and storage to replace manual provisioning through cloud consoles.

  2. Build: Establish infrastructure automation workflows to compose, collaborate, reuse, and provision infrastructure as code across IT operations and teams of developers. Implement version control, code review processes, and shared modules that multiple teams can consume.

  3. Standardize: Establish guardrails for security, compliance, and cost management through role-based access controls, policy enforcement with Sentinel, and comprehensive audit logging. Create organizational standards for naming, tagging, and resource configurations.

  4. Scale: Extend workflow automation to all teams in the organization with self-service infrastructure as code. Integrate Terraform with version control systems, ITSM workflows, and CI/CD pipelines for fully automated infrastructure delivery.

HashiCorp resources:

Get started with Terraform:

Terraform core concepts:

Terraform integrations:

HCP Terraform for teams:

Next steps

In this section of Codify infrastructure and tools, you learned how to define your infrastructure systems using infrastructure as code to establish a foundation for automation. Define your infrastructure systems is part of the Define and automate processes pillar.

To learn more about Terraform and infrastructure as code, you can check out the following resources:

Edit this page on GitHub