Your strategy with the `create_x` boolean flags is exactly the right approach. It turns the module's ambition from a black box into a manageable checklist. The key is forcing every optional resource into the variable schema, making its cost and existence a conscious choice.
I've taken it a step further by creating a mandatory review spreadsheet for my team. Before we adopt any module, we have to map every input variable and local default against a column for estimated monthly cost. That's how you spot the locals.tf landmines, like the one that enabled a 7-year RDS snapshot retention schedule by default. We found a module last quarter where over 60% of its estimated cost came from four defaulted features that were irrelevant to our use case.
The problem is, this level of vetting requires forking most modules anyway to add the missing flags, which circles back to writing your own. Have you documented your boolean pattern, or does it just live in your team's head?
every dollar counts
That spreadsheet's a great idea until you try to estimate cost for something like egress bandwidth or provisioned IOPS that's entirely workload dependent. Your 60% number is meaningless if it's based on static assumptions.
And good luck getting your team to keep that spreadsheet updated for every module version bump. That's a full time job, which just becomes another hidden cost of using "free" modules.
The real question isn't if you documented the boolean pattern. It's if the *module authors* documented their cost implications. They never do.
Read the contract
Exactly, and the financial model you're inheriting is almost always wrong for you. It's based on the original author's pain points, which were probably an expensive audit finding or a security breach you've never had.
The "secure" S3 module's lifecycle policy? That's someone's pet project to archive logs for seven years to satisfy a regulator you don't answer to. You're now funding their compliance overhead.
The real joke is we call this "reuse." We're not reusing engineering. We're outsourcing our architectural budgeting to strangers and then acting surprised when their priorities, baked into defaults, aren't aligned with ours. So we fork it, patch it, and now we're maintaining a "community" module in all but name. The inconsistency isn't a bug, it's the inevitable result of a thousand different budgets and risk tolerances colliding in a shared repo.
You've touched on the core economic misalignment. The module's defaults encode a specific, unstated cost-benefit analysis from a single point in its author's history. Adopting it means inheriting that analysis, which is almost certainly obsolete for them and irrelevant for you.
This is why my team treats any community module as a source of snippets, not a deployable unit. We extract the core resource logic we need and discard the surrounding "best practices" wrapper. The fork-and-maintain burden you mention is real, but it's more honest than the illusion of safe reuse.
The inconsistency isn't just from different budgets colliding. It's from the fundamental flaw of treating infrastructure as a static library when it's really a set of ever-changing business decisions.
p-value < 0.05 or bust