Terraform can make infrastructure changes easier to review and reproduce across AWS, Google Cloud and Azure. It does not automatically choose the cheapest architecture, make applications highly available, or make one cloud’s resources portable to another.
Reviewed 16 October 2026: corrected the licence description, separated Terraform CLI from paid cost-estimation features, and removed automatic savings and vendor lock-in claims.
What Terraform does
Terraform is an infrastructure as code tool. You describe desired resources in configuration, review a plan of proposed changes, then apply approved operations through provider APIs. Configuration can be version controlled and reused in modules. HashiCorp documents this write, plan and apply workflow.
Current Terraform releases are source available under the Business Source License, rather than the open-source licence described in the original article. HashiCorp announced the change in August 2023. Check the actual release and licence terms for your intended use.
Where the operational benefits come from
| Capability | Useful result | What still needs attention |
|---|---|---|
| Versioned configuration | Reviewable history of intended changes | Review quality, permissions and changes made outside Terraform |
| Plans | A preview of creates, changes and destroys | Unknown values, application impact and resource replacement |
| Reusable modules | A shared starting point for environments | Safe defaults, maintenance and environment-specific requirements |
| State | Mapping between configuration and managed resources | Access control, backup, locking where supported and recovery |
| Automation | A repeatable execution process | Approvals, credentials, concurrency and failure handling |
These are tools for controlling changes. They do not prove that a particular change is safe. Ask what happens if an apply fails part way through, an external change appears, or a plan replaces a database.
AWS, Google Cloud and Azure use different resources
Terraform communicates through separately versioned provider plugins. AWS, Google Cloud and Azure each have their own resource types, API behavior and permissions. Pin and review provider versions, and verify support for the services and fields you need.
A common workflow is not a common cloud architecture. Moving an application from one provider to another can still require networking changes, identity redesign, database migration and application changes. Terraform configuration for one provider is not a drop-in configuration for another. Multi-cloud also adds operating responsibilities, so use it when the requirements justify that work.
Cost optimization requires a separate check
Terraform can provision unnecessary or oversized resources just as consistently as correctly sized ones. Savings come from a justified change to usage or architecture, followed by verification against billing data.
A normal Terraform plan describes resource changes rather than providing a complete cloud bill. HCP Terraform’s plan comparison lists cost estimation as a plan-dependent feature. Its estimates depend on supported resources and assumptions and should not replace invoices or a full workload model.
Use the cloud-cost review method to record the baseline, proposed change, continuing charges and implementation cost. Include Terraform platform charges, engineering time, storage, requests, networking, licences and support where applicable.
Illustrative example, not a measured result: suppose an environment uses an assumed €0.10 per instance-hour. Reducing ten identical instances to eight for an assumed 720-hour period reduces the compute line by 2 × 720 × €0.10 = €144. That calculation excludes disks, network charges, discounts, tax and implementation time. Terraform may execute the change, but load testing must establish whether eight instances meet the workload’s requirements.
Treat state and deployment identity as sensitive
Terraform state and plan files can contain secrets. Marking a value sensitive affects its display but does not generally prevent it being stored. HashiCorp’s sensitive-data guidance explains the available controls and the conditions for ephemeral values and write-only arguments.
Restrict access, use an appropriate protected backend, keep recovery procedures and avoid committing state or credentials to a public repository. Review the deployment identity with the AWS IAM permissions guide before granting broad provisioning access.
A rollout you can review
- Inventory the resources Terraform will manage and identify existing owners.
- Start with a bounded non-production scope and account for existing resources rather than recreating them accidentally.
- Review configuration, provider versions, credentials and state protection.
- Save and review a plan, especially deletions, replacements and permission changes.
- Apply through an authorized process and verify application behavior afterwards.
- Record manual changes, drift and failed operations. Rehearse recovery rather than assuming an automatic rollback exists.
For the wider design questions that configuration cannot answer, use the cloud architecture planning guide.
