If you’re leading a platform or DevOps team, you’ve probably gone to the trouble of building Terraform Modules — those reusable, policy-compliant blueprints for common resources like Azure Storage Accounts, AWS S3 Buckets, or GCP Network Load Balancers.
Like me, you probably did it because you wanted to move faster without sacrificing consistency – and bake best practices into the defaults. You wanted to stop catching the same issues – permissions, naming, tags – over and over in code review. Modules were supposed to solve that.
But the harsh reality is that just because you built the modules doesn’t mean your teams are actually using them.
Best Practice, Bypassed
Sometimes it’s deliberate. The module doesn’t quite fit, so someone works around it. More often, it’s unintentional. A new engineer copies a block from an old repo or Stack Overflow. It works, it passes review, and now your infrastructure is drifting—quietly, persistently—away from the standards you thought you were enforcing.
That’s the problem. Not just config drift, but intent drift. You defined a contract for how infrastructure should be provisioned. But the longer module usage remains optional, the less that contract holds. And with more teams spinning up infra every day—across environments, accounts, and regions—that gap doesn’t shrink on its own. It grows.
Have you ever looked for a resource and found that no one knows who made it? Do they know what it does or if it’s safe to delete? That’s where this ends up.
Even small improvements—like updating a module to enforce encryption or reduce instance size—become fragmented. The teams using your modules move forward. Everyone else gets left behind. And you can’t version or patch what you don’t control.
Cloud Governance by Memory Doesn’t Scale
Most teams try to manage this with documentation, education, and good-faith review. That works—until it doesn’t. At scale, governance by policy recall fails. What you thought was “standard” is really just “suggested.”
The shift is simple, but not easy: stop relying on people to remember the rules, and start designing systems that enforce them. Policy at the CI layer. Pattern detection in PRs. Exceptions with intent, not inertia.
The best systems make the right path easy—and the wrong path obvious. Developers move fast, safely. And infra leaders sleep better.
You built the modules for a reason–now it’s time to make sure they matter.
The Solution? Self-Enforcing Policy
If you want teams to use your Terraform modules, hope isn’t an enforcement strategy. But design is.
Start in your Terraform CI/CD pipelines. Put policies in place that validate module usage—checking that the module source comes from your approved registry, that the version used is the one you approved for using, and flagging any attempts to spin up resources (like S3 bucket) directly. If it’s not using the module, it shouldn’t ship. That’s how you make the contract real.
One way to do it would be to build your own policies with OPA (Open-policy agent), but from my experience doing so at scale, and supporting current and future use-cases requires a lot of maintenance and creates a technical debt.
Another way would be to use pre-defined out-of-the-box policies from a vendor you work with.
You’ll also need a second line of defense: periodic scans that audit your codebase for violations. Policy shouldn’t just live in the pipeline—it needs to run through your repos, catching legacy drift, spotting gaps, and surfacing patterns before they cause real issues.
Governance at scale means policy that remembers for you—when code gets written, and long after it’s merged.
And if you still need help–or just want to chat about modules– you know where to find us.
