Terraform

Terraform is HashiCorp’s infrastructure as code tool: you describe the servers, networks, and databases you need in a text file, and Terraform creates them for you. Instead of clicking through a cloud console or running one-off scripts, you write a configuration once, and Terraform figures out the order of operations, tracks what already exists, and updates only what changed. It works across AWS, Azure, Google Cloud, Kubernetes, and thousands of other providers through a single, consistent workflow. For AI teams standing up GPU clusters, vector databases, and inference endpoints across multiple providers, Terraform turns infrastructure into version-controlled code instead of tribal knowledge locked in someone’s head.

How Terraform works

Terraform runs on a simple loop: you write what you want, Terraform shows you what it will do, and you approve before anything changes. It talks to cloud providers through their APIs, so it can create a virtual machine on AWS the same way it creates one on Azure, just through a different provider plugin.

Here is how the core workflow breaks down:

• Write: You define resources in HCL (HashiCorp Configuration Language), a declarative syntax that describes the end state you want rather than the steps to get there.
• Providers: Plugins that translate your HCL into API calls for a specific platform. The Terraform Registry hosts thousands of them, covering AWS, Kubernetes, Datadog, GitHub, and more.
• Plan: Terraform compares your configuration against its state file and real infrastructure, then prints exactly what it will add, change, or destroy.
• Apply: Once you approve the plan, Terraform executes the changes in the correct order, building a resource graph so independent resources deploy in parallel.
• State: A file that records every resource Terraform manages and its current attributes. It is the source of truth Terraform uses to detect drift and plan future changes.

What you can build with Terraform

• Multi-cloud AI infrastructure: Provision GPU instances on AWS, storage on GCP, and DNS on Cloudflare from one configuration, so your ML pipeline is not locked into a single vendor’s console.
• Self-service developer platforms: Package a standardized module for spinning up a database, load balancer, and web server, so product teams request infrastructure without filing a ticket to the platform team.
• Disaster recovery environments: Keep a full copy of your production configuration ready to apply in a second region, cutting recovery time from hours of manual clicking to a single terraform apply.
• Kubernetes cluster provisioning: Stand up an EKS, GKE, or AKS cluster and configure its networking, node pools, and IAM roles in the same configuration that deploys your application workloads.
• Ephemeral QA and staging environments: Spin up a full copy of production for a pull request, run tests against it, then tear it down automatically to avoid paying for idle infrastructure.
• Policy-enforced infrastructure pipelines: Combine Terraform with Sentinel or Open Policy Agent so every proposed change is checked against cost limits and security rules before it reaches production.