Composition and Module Best Practices — Terraform & Infrastructure as Code

Individual modules become truly powerful when composed together. A network module provides the VPC; a security module provisions firewall rules and security groups; a compute module deploys EC2 autoscaling groups; a database module provisions RDS. Each module has a clean interface. Composing them means passing outputs from one module as inputs to another, building a complete infrastructure stack from standardised components. But module composition introduces design challenges: how do you structure modules so they're independently testable but work together seamlessly? How deep should module nesting go? When should you build a new module versus extending an existing one? When should you use `depends_on` explicitly? This lesson addresses the practical design principles that distinguish a maintainable module library from a tightly coupled mess.

Analogy🏏Cricket

🏏 Think of it like cricket: Before standardised cricket rulebooks existed, every ground played by its own local customs — different LBW interpretations, different wide-ball rules, inconsistent DRS protocols. A touring team playing in a new city had to learn an entirely different set of rules. The standardised ICC rulebook is IaC: a version-controlled document that specifies exactly how cricket is played anywhere in the world. When any ground host asks 'how should this match be set up?', they apply the rulebook — not their memory, not local tradition, not a wiki page from 2019. Every ground becomes reproducible because they're all applying the same version-controlled specification. The insight is that codifying rules enables consistency at scale — you can run a thousand simultaneous cricket matches and every one follows the same rules because they all reference the same canonical document.