You know how to create and connect modules (subchapters 18.1 and 18.2). Now a practical question: do you have to write all your modules from scratch? The answer is no. There are modules that you create (local) and public, ready-made modules that you can use directly from the Terraform Registry. Knowing when to use each will save you a lot of work.

Remember that when calling a module you specify its source (where it comes from, subchapter 18.2). That source can be of several types:

Let's look at each one.

A local module is one you write yourself, stored in your own project or in a company repository. You reference it with a folder path:

When to use local modules:

• When you encapsulate logic specific to your company or project (your security conventions, your naming style, your specific requirements).
• When you want total control over the code.
• For internal modules you share between your organization's projects (often stored in a common Git repository, which we'll see in subchapter 18.4).

The Terraform Registry is a public catalog of modules already built, maintained by HashiCorp, AWS, and the community. These are modules for common tasks (creating a VPC, a cluster, a database...) made by experts, tested by thousands of people, and ready to use. You reference them by their name in the registry:

The module terraform-aws-modules/vpc/aws is one of the most used in the world: it creates a complete VPC with all best practices, and is maintained by a huge community. Instead of writing hundreds of lines, you use it with just a few.

When to use Registry modules:

• For common and standard infrastructure (VPCs, clusters, databases) where you don't need anything special.
• To save time and leverage the work of experts.
• To benefit from modules tested by thousands of users, covering edge cases you might not have foreseen.

Analogy: local modules are like cooking your own recipe (total control, tailored to your taste); Registry modules are like using a quality ready-made product from a trusted brand (fast, reliable, made by experts). Sometimes you cook, sometimes you buy ready-made; the key is knowing when each is best.

When using public modules, remember security: you are incorporating third-party code into your infrastructure. Best practices:

• Use modules from reliable and verified sources (the "verified" ones in the Registry, or the official AWS/HashiCorp ones).
• Always pin the version (version = "5.0.0"), as in the example. This prevents an unexpected module update from changing your infrastructure without notice (we'll see this in subchapter 18.4).
• Review what the module does before using it in production. Don't blindly add unknown code.

⚠️ Beware of trust injection: a malicious module could create unwanted resources or expose data. So, just like with software dependencies, use only trusted sources and pin versions.

In reality, teams combine both approaches:

For example, you create a local module company-network that internally uses the Registry VPC module, but adds your security rules and conventions. This way you get the best of both: the robustness of the public module and the customization of your logic.

• You don't have to write all modules from scratch: there are local modules (you create them) and Terraform Registry modules (public, ready-made).
• Local modules (source = "./path"): for your company's/project's specific logic, with total control.
• Registry modules (source = "terraform-aws-modules/..."): for common and standard infrastructure, made by experts and tested by thousands; they save a lot of time.
• Security: use only trusted sources, always pin the version, and review the code before using it in production (it's third-party code in your infrastructure).
• In practice, they are combined: Registry modules for common stuff, local modules for your own, sometimes one inside the other.

In the next subchapter we'll see something crucial for using modules safely as a team: versioning modules with Git tags.