We begin Part V: Advanced Terraform. Until now, you wrote all your infrastructure in separate files. That works for something small, but as you grow, that approach becomes repetitive and unmanageable. The solution is modules, the key piece for reusing and organizing your Terraform code like a pro. In this subchapter, you'll understand what they are and how they're structured.

Imagine you need to create the same infrastructure over and over again. For example, in your company, every new project needs a VPC with public and private subnets, just like in Chapter 12. Without modules, you would have to copy and paste all that code into each project:

This is a mess: if you find an error or want to improve the VPC, you have to change it in every place. This is exactly the problem that programming solved decades ago with functions: write something once and reuse it.

A Terraform module is a set of grouped and reusable resources, packaged as a unit with well-defined input and output. It's the equivalent of a function in programming: you define it once and "call" it as many times as you need, changing only the details.

Analogy: a module is like a reusable recipe. You write the "pizza" recipe once, indicating which ingredients it accepts (the ingredients are the parameters). Then you use it many times, changing the ingredients: a ham pizza, a mushroom pizza, a vegetarian pizza. The recipe (the module) is the same; the ingredients (the variables) change.

A module is simply a folder with .tf files. By convention, they are organized into three main files (remember the blocks from Chapter 10):

Defines what can be configured in the module from the outside. They're like the "parameters" of the recipe. For example, the VPC range or the project name:

Contains the resources the module creates, using the input variables. It's the "body" of the recipe:

Defines what information the module returns so others can use it (remember the outputs from subchapter 12.4). For example, the ID of the created VPC:

The elegance of a module is that it works like a box with a clear "contract":

Whoever uses the module doesn't need to know how it's made inside: they just provide the inputs it needs and receive the outputs they're interested in. This is abstraction: hiding complexity behind a simple interface. Just like you use a function without knowing how it's programmed inside.

Real-world example: a company's platform team creates a corporate-network module that sets up a VPC with all the company's best security and connectivity practices. Other teams just have to use that module by giving it a name and a range; they get a perfect network without being network experts. All the complexity is encapsulated in the module.

• Without modules, you end up copying and pasting the same infrastructure code, which is repetitive and unmaintainable (changing something forces you to touch it in many places).
• A module is a set of grouped and reusable resources, the equivalent of a function in programming: you define it once and use it many times. Like a reusable recipe.
• A module is a folder with .tf files, conventionally organized into three: variables.tf (inputs), main.tf (resources), and outputs.tf (outputs).
• It works like a box with a contract: you give it inputs (variables) and receive outputs, without needing to know how it's made inside. That's abstraction.

In the next subchapter, we'll dive deeper into how a module connects with the outside world: its input variables, its outputs, and how dependencies between modules are established.