If you lead a Platform or DevOps team, you likely spend time building Terraform modules. These are reusable blueprints for common cloud resources that follow policies, such as:
- Azure Storage Accounts
- AWS S3 Buckets
- GCP Network Load Balancers
You probably made them to:
- Move faster
- Stay consistent
- Include best practices in every deployment
This includes organizing permissions, naming, and tags.
But here’s the kicker: just because you built the modules… doesn’t mean anyone’s actually using them.
📘 Originally published on ControlMonkey Blog - terraform Modules-usage
🚨 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 code from an old repo or Stack Overflow.
- It works, passes review, and ships.
And now your infrastructure is drifting — not just in configuration, but in intent.
You defined a contract for how infra should be provisioned. But the longer module usage remains optional, the more that contract breaks down.
Sound familiar?
“Who created this resource?”
“Do we need it?”
“Can we delete it safely?”
You get the picture. Even small updates — like enabling encryption or downsizing instances — only benefit teams using the modules. Everyone else is stuck in the past.
🧠 Cloud Governance by Memory ≠ Scalable
Most teams try to solve this with documentation, education, and review.
It works — until it doesn’t.
At scale, governance by policy recall fails. What you thought was “standard” is actually just “suggested.”
The shift is simple — but not easy:
❌ Don’t rely on people to remember rules
✅ Build systems that enforce them
Here’s what that looks like:
- Policy checks in CI
- Pattern detection in PRs
- Clear exceptions — with intent, not inertia
The best systems make the right path easy and the wrong path obvious.
✅ The Solution: Self-Enforcing Policy
Hope isn’t an enforcement strategy. But design is.
Start in your Terraform CI/CD pipelines:
- Validate that module usage points to your approved registry
- Enforce usage of approved versions
- Flag attempts to directly declare resources (like
aws_s3_bucket)
If it’s not using the module, it shouldn’t ship. That’s how you make the contract real.
⚙️ Option 1: Build with OPA
You could build your own policies with OPA (Open Policy Agent).
But fair warning: supporting this at scale introduces technical debt and ongoing maintenance burden.
🛠️ Option 2: Use Out-of-the-Box Policies
Many vendors offer pre-built policies that integrate with Terraform pipelines. These are easier to implement, maintain, and evolve as your infra grows.
🔍 Bonus: Scan for Violations Regularly
CI policies aren’t enough. You also need periodic scans to:
- Audit codebases for legacy drift
- Surface non-compliant patterns
- Catch violations after code is merged
Policy shouldn't just live in your pipeline.
It should live in your repos — past, present, and future.
🧠 Cloud Governance by Memory ≠ Scalable
Most teams try to solve this with documentation, education, and review.
It works — until it doesn’t.
At scale, governance by policy recall fails. What you thought was “standard” is actually just “suggested.”
The shift is simple — but not easy:
❌ Don’t rely on people to remember rules
✅ Build systems that enforce them
Here’s what that looks like:
- Policy checks in CI
- Pattern detection in PRs
- Clear exceptions — with intent, not inertia
The best systems make the right path easy and the wrong path obvious.
And when policy isn’t enforced? Infrastructure drifts — sometimes from code, sometimes from ClickOps, when someone makes a manual change in the cloud console. Either way, the gap between intended and actual state just keeps growing.
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.