There are several tools for Infrastructure as Code. The most well-known are Terraform, CloudFormation, Pulumi, and CDK. In this subchapter, we compare them so you understand their differences and, above all, why this book chooses Terraform. It’s not about which one is “the best” in the abstract, but about which fits best for learning and for most cases.

• What it is: the most popular IaC tool and the main focus of this book.
• Language: HCL (HashiCorp Configuration Language), a declarative language created specifically to describe infrastructure. It’s easy to read (we’ll see it in Chapter 10).
• Multi-cloud: works with AWS, Azure, GCP, and hundreds of other providers, all with the same language. This is its big advantage.
• Declarative: yes (as we saw in subchapter 9.2).

• What it is: the native AWS IaC tool.
• Language: YAML or JSON files.
• AWS only: exclusive to AWS. Not for Azure or GCP.
• Advantage: fully integrated into AWS and supports new AWS services very quickly. You don’t need to install anything extra.
• Drawback: files can become long and verbose, and it locks you into AWS (vendor lock-in, remember Chapter 2).

• What it is: IaC using real programming languages (Python, TypeScript, Go, C#…).
• Idea: instead of learning a specific language, you use the language you already know, with normal loops, conditions, and functions.
• Multi-cloud: yes.
• For whom: attractive for developers who prefer “normal” code. In exchange, it can be more complex and requires programming knowledge.

• What it is: like Pulumi but from AWS: you define infrastructure with programming languages (TypeScript, Python, Java…) and, underneath, it generates CloudFormation.
• AWS only (mainly).
• For whom: developers in the AWS ecosystem who want to use code instead of YAML. There is also CDK for Terraform (CDKTF), which combines CDK with Terraform.

We choose Terraform for very specific reasons, similar to why we chose AWS in Chapter 2:

Terraform is by far the most used and in-demand IaC tool in job offers. Learning it maximizes your professional opportunities.

With Terraform, what you learn works for AWS, Azure, GCP, and hundreds of other services, all with the same language. If you switch clouds tomorrow, you can reuse your knowledge. CloudFormation and CDK lock you into AWS.

The HCL language was designed to be readable and clear, even for those who don’t program. It’s friendlier to start with than writing long YAML or using a full programming language.

There are thousands of examples, reusable modules (Chapter 18), and answers to any question. The Terraform community is gigantic.

As we saw in Chapter 2, the AWS provider for Terraform is the most mature and complete. AWS + Terraform is one of the most in-demand combinations.

Choosing Terraform doesn’t mean the others are bad:

• CloudFormation is excellent if you work only with AWS and want total native integration.
• CDK / Pulumi are great for developers who prefer to use their favorite programming language.

The good thing is that, once you understand the concepts of IaC (declarative, state, idempotence…), switching from one tool to another is relatively easy. The concepts are universal, as we saw with clouds in Chapter 2.

In 2023, HashiCorp changed Terraform’s license to a more restrictive one. In response, the community created OpenTofu, an open-source version compatible with Terraform (it’s a fork). For learning and for most uses, both are practically identical and what you learn here applies to both. It’s good to know that OpenTofu exists as a free alternative.

• The four main IaC tools are Terraform, CloudFormation, Pulumi, and CDK.
• CloudFormation and CDK are AWS-only; Terraform and Pulumi are multi-cloud.
• Pulumi and CDK use programming languages; Terraform uses HCL (declarative and easy to read); CloudFormation uses YAML/JSON.
• We choose Terraform because it’s the market standard, multi-cloud (doesn’t lock you in), with readable HCL, and a huge community.
• OpenTofu is a free and compatible alternative to Terraform, created after the 2023 license change.

In the last subchapter of this chapter, we’ll see the fundamental Terraform workflow: the plan → apply → destroy cycle.