Terraform Module Registry – Hierarchical Inheritance

Editor's note (July 2025): Scalr's module registry was redesigned to a namespace-based model. All namespaces are now created at the account scope and can be shared with the entire account or a select set of environments — the legacy "account scope vs environment scope" split described below no longer applies. The historical framing is preserved here for context; for current behavior see the Scalr private module registry docs.

Terraform modules are a great way to simplify your Terraform code by writing it once and then reusing the modules in your templates. The module can contain a single resource or multiple resources with the result being a standard way of deploying infrastructure across your cloud ecosystem.

Create the module:

https://github.com/terraform-aws-modules/terraform-aws-vpc

Use the module in your templates:

https://github.com/terraform-aws-modules/terraform-aws-vpc

Creating and using the module is the first step to simplification and standardization, but how scalable is it?

Module Scalability

So you have created your module, you told your developers to use it and management of your Terraform code has become much simpler, but has it?

• You may assume developers are using the module to standardize, but how can you track or enforce that?
• If they are using it, do you know they are using the right version to avoid conflicts?
• Are you certain that if you make an update to the module it won't impact their existing Terraform deployment?
• Do they know when new versions are released or when old versions are deprecated?

You could build your own way to manage the module, but that adds work for you in peer reviews. Many teams instead keep a single monolithic repository that holds every module. It's easy to reference in code, but it brings its own problems around dependencies, ownership, and changes nobody asked for.

These challenges get real fast once modules are shared across teams. The more modules you have and the more developers using them, the bigger the problem. Users will keep asking for more modules and more services, and without a system it's hard to track what you have and who depends on it.

Module Registry to the Rescue

If these challenges apply to you then you would likely benefit from the Scalr Infrastructure as Code Platform module registry. The registry allows you to:

• Create a list of approved modules
• Create versions of the modules to allow users to pin
• Deprecate old modules
• Avoid impacting existing deployments through the versioning

Scalr Module Registry

Scalr allows you to store your modules in VCS, tag the module with a version, and then import it into Scalr for your users to view. The person writing the Terraform template simply needs to copy the code block from Scalr and will be aware of what version to use through the README that is imported as well.

A module registry greatly simplifies the management of modules, but what if it could be even easier?

Hierarchical Inheritance Module Registry

Scalr built a hierarchical inheritance module registry to spare the administrator that operations headache. You don't want teams stepping on each other when they deploy, so Scalr lets you create environments that give each team or app its own space for deployments and workspaces. Importing the same module into every single environment by hand would be a chore. The hierarchical inheritance model exists to avoid that:

Scalr Hierarchy

A module registry can be created at each level in the diagram above:

• Account scope: If created here, all environments will inherit the module.
• Environment scope: That environment is the only place the module can be used.

Create and maintain the module in one place and share with many teams and environments. This allows you to create account-wide standards, but also lets your individual teams add more modules at their respective scope if their permissions allow for it, but not change or remove modules from a higher scope. Introducing the hierarchy starts to enforce policy on modules, but can be taken even further with the Open Policy Agent integration.

Summary

With the Scalr hierarchical module registry you can easily and safely manage modules going forward. Scalr is the only solution that provides the various levels to reduce the operational overhead, while giving you the following benefits :

• List of approved modules
• Versioning of the modules to allow users to pin
• Deprecation of old modules
• Avoiding accidentally impacting existing deployments
• Restricting module usage to only those in your registry using OPA