Sabes crear y conectar módulos (subcapítulos 18.1 y 18.2). Ahora una pregunta práctica: ¿tienes que escribir todos tus módulos desde cero? La respuesta es no. Existen módulos que tú creas (locales) y módulos públicos ya hechos que puedes usar directamente desde el Terraform Registry. Saber cuándo usar cada uno te ahorrará muchísimo trabajo.

Recuerda que al llamar a un módulo indicas su source (de dónde sale, subcapítulo 18.2). Ese origen puede ser de varios tipos:

Veamos cada uno.

Un módulo local es uno que escribes tú, guardado en tu propio proyecto o en un repositorio de tu empresa. Lo referencias con una ruta de carpeta:

Cuándo usar módulos locales:

• Cuando encapsulas lógica específica de tu empresa o proyecto (tus convenciones de seguridad, tu forma de nombrar, tus requisitos concretos).
• Cuando quieres control total sobre el código.
• Para módulos internos que compartes entre los proyectos de tu organización (a menudo guardados en un repositorio Git común, que veremos en el subcapítulo 18.4).

El Terraform Registry es un catálogo público de módulos ya construidos, mantenidos por HashiCorp, AWS y la comunidad. Son módulos para tareas comunes (crear una VPC, un cluster, una base de datos...) hechos por expertos, probados por miles de personas y listos para usar. Los referencias por su nombre en el registro:

El módulo terraform-aws-modules/vpc/aws es uno de los más usados del mundo: crea una VPC completa con todas las buenas prácticas, y lo mantiene una comunidad enorme. En vez de escribir cientos de líneas, lo usas con unas pocas.

Cuándo usar módulos del Registry:

• Para infraestructura común y estándar (VPCs, clusters, bases de datos) donde no necesitas nada especial.
• Para ahorrar tiempo y aprovechar el trabajo de expertos.
• Para beneficiarte de módulos probados por miles de usuarios, que cubren casos límite que tú quizá no habrías previsto.

Analogía: los módulos locales son como cocinar tu propia receta (control total, adaptada a tu gusto); los del Registry son como usar un producto de calidad ya preparado de una marca de confianza (rápido, fiable, hecho por expertos). A veces cocinas, a veces compras hecho; lo bueno es saber cuándo conviene cada cosa.

Al usar módulos públicos, recuerda la seguridad: estás incorporando código de terceros a tu infraestructura. Buenas prácticas:

• Usa módulos de fuentes fiables y verificadas (los «verified» del Registry, o los oficiales de AWS/HashiCorp).
• Fija siempre la versión (version = "5.0.0"), como en el ejemplo. Esto evita que una actualización inesperada del módulo cambie tu infraestructura sin avisar (lo veremos en el subcapítulo 18.4).
• Revisa qué hace el módulo antes de usarlo en producción. No metas código desconocido a ciegas.

⚠️ Atención a la inyección de confianza: un módulo malicioso podría crear recursos no deseados o exponer datos. Por eso, igual que con las dependencias de software, usa solo fuentes de confianza y fija versiones.

En la realidad, los equipos combinan ambos enfoques:

Por ejemplo, creas un módulo local red-empresa que internamente usa el módulo de VPC del Registry, pero le añade tus reglas de seguridad y convenciones. Así aprovechas lo mejor de ambos: la solidez del módulo público y la personalización de tu lógica.

• No tienes que escribir todos los módulos desde cero: existen módulos locales (los creas tú) y módulos del Terraform Registry (públicos, ya hechos).
• Módulos locales (source = "./ruta"): para tu lógica específica de empresa/proyecto, con control total.
• Módulos del Registry (source = "terraform-aws-modules/..."): para infraestructura común y estándar, hechos por expertos y probados por miles; ahorran muchísimo tiempo.
• Seguridad: usa solo fuentes fiables, fija siempre la versión y revisa el código antes de usarlo en producción (es código de terceros en tu infraestructura).
• En la práctica se combinan: módulos del Registry para lo común, módulos locales para lo propio, a veces unos dentro de otros.

En el siguiente subcapítulo veremos algo crucial para usar módulos de forma segura en equipo: el versionado de módulos con Git tags.