Infrastructure Modules

Infrastructure modules encode safe defaults for common patterns. Treat them as product interfaces, not just reusable snippets.

Module design

A good module has:

• Clear ownership and versioning.
• Secure defaults.
• Minimal required inputs.
• Explicit outputs for downstream modules.
• Examples for common use cases.
• Upgrade notes and compatibility guidance.
• Tests or validation where practical.

Module boundaries

Use modules for stable platform primitives:

• Accounts, projects, or subscriptions.
• Networks, subnets, routes, and endpoints.
• Runtime platforms and service scaffolding.
• Databases, queues, buckets, and registries.
• IAM roles, policies, and workload identity.
• Monitoring and alerting defaults.

Avoid modules that hide too much provider behavior or make every edge case a boolean input. If a module has dozens of flags, split it or raise the abstraction.

Versioning

Pin module versions in consuming systems. Release module changes with:

• Changelog entries.
• Migration notes.
• Backward compatibility guidance.
• Deprecated input and output warnings.
• Examples updated with the new version.

Validation

Validate infrastructure before apply.

Watchouts

• Shared modules create shared blast radius.
• Breaking changes need migration support.
• Module ownership must include support and documentation, not only code.
• Copy-pasted modules become invisible forks.