Terraform and AWS CloudFormation have been the default answer to “how do I provision cloud infrastructure with code” for most of the last decade. That default got shaken up over the past 20 months. IBM closed its $6.4 billion acquisition of HashiCorp on February 27, 2025, and by October 2026 the fallout shows up directly in monthly bills. HashiCorp’s legacy free plan for its hosted Terraform service ended March 31, 2026, replaced by a tier capped at 500 managed resources before paid pricing kicks in. CloudFormation still charges nothing to create or manage a stack. That price gap alone is driving fresh search volume for “terraform vs cloudformation,” but the real decision runs deeper than a line item on an invoice.
This comparison walks through the current versions, the licensing dispute that spawned OpenTofu, the real pricing math, state management, multi-cloud reach, migration paths, and what practitioners and 2025-2026 survey data actually say. The goal is a tool choice that fits your stack, not one picked because a sales page sounded confident. For broader context on where infrastructure-as-code tooling fits across the rest of the cloud computing stack, the category page tracks the rest of our coverage.
What Changed in the Terraform vs CloudFormation Debate for 2026
For years this comparison was simple: Terraform for multi-cloud flexibility, CloudFormation for AWS-only shops that wanted zero extra tooling. That framing still holds, but three events since 2023 changed the stakes. First, HashiCorp switched Terraform’s license from the open-source MPL 2.0 to the Business Source License 1.1 in August 2023, restricting competitors from reselling Terraform as a managed service. Second, a group of cloud vendors and contributors forked the last MPL-licensed codebase into OpenTofu, which reached general availability under the Linux Foundation in January 2024. Third, IBM bought HashiCorp outright, paying $35 per share in cash for an enterprise value of $6.4 billion according to IBM’s own newsroom announcement.
None of that touched CloudFormation’s pricing or licensing, because AWS never charged for the orchestration layer and never open-sourced it either. What changed instead is the comparison’s center of gravity: buyers now have to weigh not just HCL versus YAML, but whether they want a Terraform ecosystem now steered by IBM, a community fork in OpenTofu, or AWS’s walled-garden service that never had a licensing fight in the first place. That context matters more than any single feature row in a spec sheet, and it is why this guide treats licensing and ownership as comparison criteria right alongside syntax and state handling.
Terraform in 2026: Versions, the BSL License, and the OpenTofu Fork
The latest stable release on HashiCorp’s own GitHub releases page is Terraform v1.16.5, dated October 2, 2026. A release candidate, v1.17.0-rc1, had already surfaced by early October, carrying a general-availability version of Terraform Policy (an HCL-based policy-as-code framework) and a new -minimal-refresh planning option that limits how much state Terraform re-checks during a plan. Terraform Policy itself first appeared as a beta feature in HCP Terraform’s changelog on July 16, 2026, before graduating toward GA in the 1.17 line.
The license underneath all of this is the Business Source License 1.1, in place since August 2023. The CLI binary stays free to download and run against your own infrastructure. What BSL restricts is turning Terraform into a competing commercial product, which is exactly the clause that pushed a chunk of the community toward OpenTofu. OpenTofu’s own GitHub releases list v1.13.1 as current, published October 1, 2026, alongside a still-supported 1.12 branch at patch version 1.12.7. As HashiCorp co-founder and Terraform creator Mitchell Hashimoto put it in a conversation on the Screaming in the Cloud podcast, “Terraform definitely offers things that CloudFormation doesn’t” and that feature gap, built over a decade of provider development, is the main reason OpenTofu forked the code instead of starting fresh.
Who Actually Controls the Roadmap Now
IBM folded HashiCorp into its hybrid-cloud portfolio rather than running it as an arm’s-length subsidiary, and HCP Terraform’s 2026 changelog reads like a company integrating fast. Azure DevOps organization-scoped personal access token support landed October 2, 2026, timed to beat Microsoft’s December 1, 2026 retirement of globally scoped tokens, and SCIM-based user provisioning arrived a day earlier, on October 1. Those are enterprise-identity features, the kind IBM’s existing buyer base asks for. OpenTofu, by contrast, answers to the Linux Foundation and a steering committee drawn from Spacelift, Env0, Harness, Oracle, and other vendors who have no commercial stake in HCP Terraform’s resource-based billing.
CloudFormation in 2026: AWS’s Free Native IaC Service
CloudFormation never went through a licensing fork because there was never an open-source codebase to fork. It is a proprietary AWS service, templated in YAML or JSON, and increasingly authored through the AWS Cloud Development Kit (CDK) for teams that would rather write TypeScript or Python than raw template syntax. AWS’s pricing page confirms the core service remains free: creating, updating, and managing a stack costs nothing beyond the price of the AWS resources the stack provisions. The one documented exception is custom CloudFormation Hooks, which AWS bills per handler invocation based on call count and execution duration.
That “free unless you build custom extensions” model is a genuine structural advantage for AWS-only teams, and it is also the single biggest reason CloudFormation keeps showing up in comparison searches even though its feature pace looks conservative next to Terraform’s. As cloud engineer Eoin Shanaghy summarized on the AWS Bites podcast, “CloudFormation is an AWS service” in a way Terraform simply is not. You are not running a separate binary against an API, you are calling a first-party control plane that AWS operates, patches, and scales for you. Native drift detection is part of that same bundle. AWS’s own documentation describes drift detection as a built-in way to flag when a stack’s real-world resources have diverged from the template that created them, with no separate agent or third-party integration required.
Terraform vs CloudFormation: Full Specs Comparison
Here is how the two stack up across the categories that actually change a buying decision, current as of October 2026.
| Category | Terraform / OpenTofu | AWS CloudFormation |
|---|---|---|
| Current stable version | Terraform v1.16.5 (Oct 2, 2026); OpenTofu v1.13.1 (Oct 1, 2026) | Continuously updated AWS service, no version number |
| License | Business Source License 1.1 (Terraform); fully open-source MPL 2.0 fork (OpenTofu) | Proprietary AWS service |
| Open-source fork available | Yes, OpenTofu under the Linux Foundation since January 2024 | No |
| Owner | IBM (closed HashiCorp acquisition Feb 27, 2025, $6.4B enterprise value) | Amazon Web Services |
| Config language | HashiCorp Configuration Language (HCL), JSON also supported | YAML or JSON, plus CDK for code-first authoring |
| State tracking | Separate state file, stored locally or in a remote backend (S3, Azure Blob, GCS, HCP Terraform) | Managed internally by AWS, exposed via stack events and the API |
| Cloud provider coverage | Providers spanning AWS, Azure, GCP, Cloudflare, Kubernetes, and many SaaS platforms | AWS resources only (with some third-party CloudFormation registry extensions) |
| Drift detection | Via terraform plan/refresh; HCP Terraform can schedule automated drift runs | Native “detect stack drift” built into console, CLI, and API |
| Managed-service free tier | 500 managed resources per month (since March 31, 2026) | No orchestration fee at any volume |
| Managed-service paid pricing | $0.10 to $0.99 per managed resource per month across tiers | No per-resource orchestration fee |
| Self-hosted enterprise edition | Terraform Enterprise, quote-based pricing | Not applicable, CloudFormation has no self-hosted edition |
| Policy-as-code | Terraform Policy (HCL-based), GA in the 1.17 release line | AWS Config rules, SCPs, and CloudFormation Guard |
The pattern across that table is consistent: Terraform wins on reach and portability, CloudFormation wins on operational simplicity for teams that never plan to leave AWS. Neither row flips the comparison on its own, which is why the pricing and state-management sections below matter more than the spec sheet alone. Notice also that ownership itself is now a specs row, not just a footnote. A tool’s roadmap, support model, and pricing philosophy increasingly depend on who signs off on them, and in 2026 that means an IBM product manager on one side and an AWS service team on the other, rather than two scrappy open-source projects competing on features alone.
Pricing Breakdown: HCP Terraform’s Resource Fees vs CloudFormation’s $0 Core Cost
The Terraform CLI itself has no license fee, and OpenTofu never will, since it runs under the Linux Foundation’s open governance. What costs money is HashiCorp’s hosted collaboration layer, HCP Terraform, and that is where the 2026 pricing overhaul lands hardest. The legacy free plan closed on March 31, 2026. Its replacement caps free usage at 500 managed resources per month, a number small enough that a mid-sized VPC with a handful of subnets, security groups, and an RDS cluster can burn through it before anyone notices.
| Tier | Terraform / HCP Terraform price | CloudFormation equivalent |
|---|---|---|
| Free | 500 managed resources/month, no cost | Unlimited stacks and resources, $0 orchestration fee |
| Essentials | $0.10 per managed resource/month | Not applicable |
| Standard | $0.47 per managed resource/month | Not applicable |
| Premium | $0.99 per managed resource/month | Not applicable |
| Self-hosted enterprise | Terraform Enterprise, custom quote | Not applicable, no self-hosted CloudFormation exists |
| Custom extensions | Not applicable | CloudFormation Hooks billed per handler invocation and duration |
| Open-source alternative | OpenTofu CLI, $0, no BSL restrictions | Not applicable, CloudFormation has no open-source build |
Run the math on a realistic account: a platform team managing 3,000 resources across staging and production on the Standard tier pays roughly $1,410 a month just for HCP Terraform’s bookkeeping, before any AWS, Azure, or GCP bill arrives. The same 3,000 resources deployed through CloudFormation cost whatever the underlying EC2 instances, RDS clusters, and S3 buckets cost, full stop. That gap is why some teams are reportedly re-reading the fine print on terraform import, which a secondary analysis claims was restricted to paid tiers starting January 2026, a change HashiCorp has not detailed in an official announcement, so treat it as reported, not confirmed, until you check your own account. Teams that already run cost gates in CI, the kind we walked through in our Terraform cost gate guide using Infracost, are generally the first to notice when a per-resource fee shows up next to the AWS bill rather than inside it.
It is worth separating two different products here. You can run open-source Terraform or OpenTofu entirely for free, storing state in your own S3 bucket and never touching HCP Terraform. The fees above only apply if you want HashiCorp’s hosted remote execution, policy enforcement, and team collaboration layer. Plenty of teams skip it entirely and still get the multi-cloud benefits of Terraform’s provider ecosystem.
State Management: Who Keeps the Memory of Your Infrastructure
This is the deepest architectural split between the two tools, and it shapes almost every operational difference that follows. Terraform needs to remember what it built because it operates across providers that know nothing about each other. As technology writer John Willis explained in a summary of a HashiConf session, “CloudFormation has two parts to it, the actual templates and then the storage of system state. The AWS fabric itself keeps the state for you and you get it via API. Since Terraform is cloud agnostic the tool needs to store state itself.” That single distinction explains why Terraform users worry about state file corruption, locking conflicts, and remote backend configuration, problems that simply do not exist for a CloudFormation user.
In practice, most production Terraform setups push state into a remote backend such as an S3 bucket with DynamoDB locking, Azure Blob Storage, Google Cloud Storage, or HCP Terraform’s own managed state storage. Lose that file, or let two engineers apply changes against stale state at the same time, and you can end up with a configuration that no longer matches the state Terraform thinks it manages. CloudFormation sidesteps that entire failure class because AWS tracks every stack’s actual state inside its own control plane. The tradeoff is that you only get this guarantee within AWS. The moment a team needs to provision a Cloudflare zone, a GitHub repository, or a Datadog monitor alongside AWS resources, CloudFormation’s single-cloud state model becomes a hard wall, not a minor inconvenience.
Syntax and Learning Curve: HCL vs YAML/JSON
Terraform’s HCL was built specifically for describing infrastructure, which gives it expressions, loops, conditionals, and reusable modules that feel closer to a real programming language than a markup format. CloudFormation templates lean on plain YAML or JSON, augmented by intrinsic functions like Fn::GetAtt and Fn::Sub for the handful of dynamic behaviors AWS decided templates needed. Neither approach is objectively harder, and cloud educator Ned Bellavance made that point directly on a podcast comparing the major IaC tools: “They all have basically the same concepts behind them, the same core concepts because they’re all deploying the same thing at the end of the day and there’s only so many ways you can express that concept.”
Where the two diverge is portability of that learning investment. Bellavance also noted that prior CloudFormation experience transfers reasonably well: “So, once you learn one, say you learned CloudFormation first, then Terraform is not as big of a leap.” The practical difference shows up at scale rather than in week one. A CloudFormation author eventually hits the limits of YAML’s expressiveness and reaches for CDK, effectively trading a templating language for a full programming language layered on top of CloudFormation’s engine. A Terraform author who wants the same code-first ergonomics has options like Pulumi, which shares some of Terraform’s provider plumbing, or CDK for Terraform, HashiCorp’s own answer to AWS CDK. We cover how Pulumi and the OpenTofu fork stack up against mainline Terraform in a separate Terraform vs Pulumi vs OpenTofu breakdown, which is worth reading before picking a code-first tool on top of either engine. Both ecosystems eventually converge on “write real code, generate the template,” they just start from opposite ends.
Multi-Cloud Reach vs AWS-Native Depth
Terraform’s provider model is the reason it still dominates multi-cloud and hybrid-cloud shops. A single HCL configuration can define an AWS VPC, an Azure resource group, a GCP service account, a Cloudflare DNS zone, and a Kubernetes namespace, all tracked in one state graph with explicit dependency ordering between them, which matters even for teams comparing managed Kubernetes options like we did in our EKS vs AKS vs GKE pricing breakdown, since the cluster itself is usually just one resource in a much larger Terraform-managed graph. CloudFormation has no equivalent reach by design. It is AWS’s product, built to provision AWS resources, and third-party CloudFormation registry extensions exist but remain a thin layer compared to a dedicated provider.
That said, “AWS-only” is not a niche case. Plenty of regulated enterprises, especially in finance and healthcare, run single-cloud by policy rather than by accident, and for them CloudFormation’s depth inside AWS beats Terraform’s breadth across clouds they will never touch. CloudFormation gets first access to new AWS service features on day one, since AWS’s own service teams ship CloudFormation resource types alongside the service itself. Terraform’s AWS provider is excellent and fast-moving, maintained jointly by HashiCorp and community contributors, but it is still a second layer reacting to AWS’s API changes rather than shipping in lockstep with them. If your roadmap has zero plans to touch a second cloud provider, that lag, usually measured in days to a few weeks for brand-new services, rarely matters in practice.
Drift Detection and Day-Two Operations
Both tools can tell you when reality has drifted from your template, but they get there differently. CloudFormation’s drift detection is a first-class console and API feature: trigger it on a stack, and AWS compares live resource configuration against the template and flags every mismatch, resource by resource. Terraform achieves the same outcome through terraform plan, which refreshes state against real infrastructure and reports the delta before you apply anything. HCP Terraform can schedule these plans automatically and alert on unexpected changes, and the new -minimal-refresh option in the 1.17 release line lets teams skip re-checking resources they are confident have not changed, trading a little drift-detection coverage for faster plans on large configurations.
Day-two operations, the unglamorous work of patching, resizing, and rotating credentials on infrastructure that already exists, favor whichever tool matches how your team already thinks. CloudFormation’s change sets let you preview exactly what a stack update will do before committing, resource by resource, directly inside the AWS console. Terraform’s plan output does the same job in a terminal, with the added benefit of policy checks, via Terraform Policy or the older Sentinel framework, that can block an apply automatically if it violates a tagging rule or an instance-type restriction. Neither is strictly better here. The console-first CloudFormation workflow suits teams that live in the AWS web UI, and the plan-first Terraform workflow suits teams that already run everything through CI pipelines.
What the Adoption Surveys and Ratings Actually Say
Three independent data sources give a rough picture of where sentiment sits in late 2026. Firefly’s State of IaC 2025 report found that 89% of surveyed organizations had adopted infrastructure as code in some form, but only 6% had full coverage of their cloud estate, meaning most shops still run a mix of IaC and manual console changes. Among IaC users specifically, Terraform usage sat around 60 to 62%, still the single most-used tool despite the licensing turmoil. Future intent is murkier: depending on how the question was framed, the same broader survey data shows anywhere from just over 20% to 47% of practitioners planning to keep using Terraform going forward, and 56% described HashiCorp’s 2023 license change as disruptive to their plans. That spread is wide enough that it should be read as directional, not precise, until Firefly’s full methodology is checked against the original questionnaire.
On the review-site side, Gartner Peer Insights lists AWS CloudFormation at 4.4 out of 5 stars across 101 ratings, a solid but unspectacular score consistent with a mature, low-drama product that does one job well. HashiCorp’s own changelog, the third data point, shows a vendor still shipping fast under new ownership: SCIM provisioning and Azure DevOps token support both landed in the first two days of October 2026 alone. Put together, the numbers describe a market where Terraform still leads on raw usage, CloudFormation holds steady satisfaction among AWS-committed users, and a meaningful minority of the Terraform base is actively weighing alternatives.
| Source | Metric | Figure |
|---|---|---|
| Firefly, State of IaC Report 2025 | Organizations that have adopted IaC in any form | 89% |
| Firefly, State of IaC Report 2025 | Organizations with full IaC coverage of their cloud estate | 6% |
| Firefly, State of IaC Report 2025 | Terraform usage share among IaC users | 60-62% |
| Firefly, State of IaC Report 2025 | Respondents who found the 2023 license change disruptive | 56% |
| Gartner Peer Insights | AWS CloudFormation overall rating | 4.4 / 5 (101 ratings) |
| HCP Terraform official changelog | New enterprise-identity features shipped in first two days of October 2026 | 2 (SCIM, Azure DevOps org-scoped PATs) |
Read those six data points side by side and a pattern falls out that a single number would hide. Adoption of infrastructure as code in general is nearly universal at 89%, yet full coverage sits at just 6%, which means most of the “which tool should I use” debate is still happening inside organizations that have one foot in manual console changes and one foot in code. That gap is where a lot of CloudFormation’s staying power comes from: it is the path of least resistance for the AWS resources teams have not gotten around to automating yet, while Terraform tends to be the deliberate choice for net-new, multi-cloud work.
Real-World Scenarios: Five Teams, Five Decisions
None of these scenarios are hypothetical edge cases. They are composites of the patterns that show up repeatedly across the engineering teams, agencies, and platform groups that drive the bulk of the “terraform vs cloudformation” search volume, built from the licensing timeline, pricing tiers, and survey data covered above rather than any single named company. Match your own team’s shape against the closest one below before picking a tool.
- The three-person AWS-only startup. No Azure, no GCP, no plans to change that in the next two years. CloudFormation’s zero orchestration cost and native console integration beat Terraform’s multi-cloud flexibility they will never use, and nobody has to learn HCL on top of shipping a product.
- The 40-engineer fintech platform team running three clouds. Compliance requirements split workloads across AWS and Azure for redundancy, with a small GCP footprint for BigQuery. Terraform’s single state graph across providers is the only realistic option, and the team runs open-source Terraform with S3-backed state to avoid HCP Terraform’s per-resource fees entirely.
- The regulated healthcare company mid-way through a license review. Legal flagged the BSL 1.1 terms during a vendor risk assessment, and rather than wait for clarity, the infrastructure team migrated its existing Terraform configurations to OpenTofu, keeping the same HCL syntax and provider ecosystem while removing any BSL exposure.
- The agency managing a dozen client AWS accounts. Every client is AWS-only, and the agency standardized on CloudFormation plus CDK years ago specifically because it means zero extra tooling to install or bill for across client environments, and AWS Organizations plus StackSets handles multi-account deployment natively.
- The enterprise platform engineering group serving 200 internal developers. They need policy enforcement, self-service provisioning, and audit trails at a scale that justifies the cost, so they pay for HCP Terraform’s Premium tier specifically for Terraform Policy and SCIM-based access control, treating the per-resource fee as the price of governance rather than a tax on using Terraform at all. The same team also runs a FinOps cost-tracking layer on top of both HCP Terraform’s bill and the AWS invoice it provisions, since the two now show up as separate line items instead of one.
Which Tool Fits Your Use Case
- Pick CloudFormation if: you run exclusively on AWS, want zero extra licensing cost, and your team already lives in the AWS console or CDK.
- Pick open-source Terraform if: you manage two or more cloud providers and want to avoid any HCP Terraform billing by self-hosting state in S3, Azure Blob, or GCS.
- Pick OpenTofu if: you want Terraform’s exact feature set and HCL syntax but need to avoid Business Source License exposure for legal or procurement reasons.
- Pick HCP Terraform (paid) if: you need policy-as-code, SCIM provisioning, and centralized remote execution across a large team, and the per-resource fee is worth it for the governance it buys.
- Pick Terraform Enterprise (self-hosted) if: compliance rules require infrastructure tooling to run inside your own network boundary rather than HashiCorp’s cloud.
- Pick a CDK-first approach, either AWS CDK or CDK for Terraform, if: your engineers would rather write TypeScript or Python than a templating language, regardless of which backend ends up provisioning the resources.
Migration Guide: Moving Between Terraform and CloudFormation
Most migration traffic runs from CloudFormation toward Terraform or OpenTofu, usually driven by a new multi-cloud requirement rather than dissatisfaction with CloudFormation itself. The reverse direction, Terraform to CloudFormation, is rare and typically only happens when a team is consolidating fully onto AWS and wants to drop a third-party dependency. Here is the practical path for the common direction.
- Inventory every existing CloudFormation stack and export each template with
aws cloudformation get-templateso you have a clean source of truth before touching anything live. - Generate draft HCL from those templates using a converter rather than hand-writing resources one by one, then treat the output as a starting draft, not a final config.
- Run
terraform import(or the OpenTofu equivalent) against each existing AWS resource to bring it under Terraform state management without recreating anything. - Run
terraform planimmediately after each import and confirm it reports zero changes before moving to the next resource, catching any mismatch between the generated HCL and the real resource configuration early. - Migrate one stack at a time, starting with low-risk, non-production resources, and keep the original CloudFormation stack intact but not actively managed until the Terraform-managed version has run cleanly through at least one full deployment cycle.
- Once every resource in a stack has been imported and verified, delete the CloudFormation stack using
--retain-resourceson every resource so AWS stops tracking it without tearing anything down. - Set up remote state, S3 plus DynamoDB locking, or HCP Terraform, before any second engineer touches the migrated configuration, since local state files are not safe for team use.
terraform import aws_instance.web i-0abcd1234efgh5678
terraform plan
# Confirm "No changes." before proceeding to the next resourceBudget real time for this. A migration that looks like a weekend project on paper routinely takes several weeks for anything beyond a handful of stacks, mostly because import mapping and plan verification have to happen resource by resource, not stack by stack.
Pros, Cons, and the Verdict
Terraform and OpenTofu: Strengths and Tradeoffs
- Pro: Single workflow across every major cloud and dozens of SaaS providers.
- Pro: HCL supports modules, loops, and conditionals for real code reuse.
- Pro: OpenTofu offers the same capability with zero licensing ambiguity.
- Con: State files are an extra operational responsibility that CloudFormation users never deal with.
- Con: HCP Terraform’s new resource-based pricing can get expensive fast at scale.
- Con: AWS feature support sometimes lags a few days to weeks behind CloudFormation’s day-one coverage.
CloudFormation: Strengths and Tradeoffs
- Pro: No orchestration fee at any scale, ever.
- Pro: State managed entirely by AWS, removing an entire category of operational risk.
- Pro: Day-one support for new AWS services and native drift detection.
- Con: Zero multi-cloud support beyond thin third-party registry extensions.
- Con: YAML/JSON syntax gets verbose fast without moving to CDK.
- Con: No open governance model, no fork option, fully dependent on AWS’s roadmap.
The verdict for 2026 is a split one, and the data supports keeping it split rather than forcing a single winner. If your infrastructure lives entirely inside one AWS account or organization, CloudFormation’s $0 orchestration cost and native AWS integration outperform anything Terraform offers, and the 4.4-out-of-5 Gartner Peer Insights score reflects a tool that does its one job without drama. If you touch two or more clouds, or expect to within the next year, Terraform’s provider ecosystem remains the only tool built for that from the ground up, and the 60-62% usage share among IaC users in Firefly’s 2025 survey shows the market still agrees despite the licensing noise. The one genuinely new variable for 2026 is cost control: teams that would have defaulted to HCP Terraform without thinking now have a real reason to price out OpenTofu or self-hosted state first, given that 500-resource free tier and per-resource fees that start at $0.10 and climb to $0.99 a month.
As a rough threshold: teams under roughly a dozen engineers managing a single cloud rarely need anything beyond CloudFormation or free open-source Terraform. Past that size, once policy enforcement, SCIM provisioning, and audit trails become a real requirement rather than a nice-to-have, the HCP Terraform fee starts paying for itself, provided the team has already ruled out OpenTofu as a lower-cost path to the same governance features. Either way, the decision now has a dollar figure attached to it that it did not have three years ago, and that alone is reason enough to run the pricing math before committing.
Frequently Asked Questions
Is Terraform free to use in 2026?
The Terraform CLI is free to download and run yourself, and that has not changed. Fees only apply to HashiCorp’s hosted HCP Terraform service, where the free tier is now capped at 500 managed resources per month, with paid tiers starting at $0.10 per managed resource per month.
Why did Terraform’s license change, and what is OpenTofu?
HashiCorp switched Terraform from the open-source MPL 2.0 license to the Business Source License 1.1 in August 2023, restricting competitors from reselling Terraform as a competing managed service. A group of vendors and contributors responded by forking the last MPL-licensed version into OpenTofu, which reached general availability under the Linux Foundation in January 2024 and remains fully open source today.
Is AWS CloudFormation really free?
Yes, for the core service. AWS does not charge to create, update, or manage a CloudFormation stack. The only documented exception is custom CloudFormation Hooks, which AWS bills per handler invocation based on call count and execution duration. You still pay for whatever AWS resources the stack provisions, same as you would with any other tool.
Can I use Terraform and CloudFormation together?
Yes, and plenty of teams do, often during a gradual migration. The main risk is managing the same resource in both tools simultaneously, which can cause one tool’s state to drift from the other’s. Most teams that run both keep a clear boundary, such as CloudFormation for a legacy application and Terraform for everything new.
Which tool is better for a multi-cloud strategy?
Terraform, without much debate. Its provider model was built specifically to manage AWS, Azure, GCP, Cloudflare, Kubernetes, and SaaS platforms from one configuration and one state graph. CloudFormation is AWS-only by design and has no realistic multi-cloud path.
What is HCP Terraform and do I actually need it?
HCP Terraform is HashiCorp’s hosted service for remote state storage, remote execution, policy enforcement, and team collaboration. You do not need it to use Terraform. Plenty of teams run open-source Terraform with state stored in their own S3 bucket and never pay a cent to HashiCorp. HCP Terraform mainly earns its cost for larger teams that need centralized governance and audit trails.
Should I switch from Terraform to OpenTofu?
It depends on why you are asking. If your concern is the Business Source License’s legal terms, OpenTofu removes that concern entirely while keeping the same HCL syntax and most of the same provider ecosystem. If your concern is HCP Terraform’s pricing specifically, note that OpenTofu has its own compatible hosted offerings from third-party vendors, so switching the CLI alone does not automatically solve a hosting-cost problem.
How long does a CloudFormation-to-Terraform migration usually take?
Longer than it looks on paper. Because resources have to be imported and verified one at a time with terraform import followed by a clean terraform plan, even a modest environment with a few dozen resources across several stacks can take several weeks when done carefully, especially if production workloads are involved.
