Infrastructure Blueprint System

Teams were provisioning AWS infrastructure through the console, copying configs between projects, and handling DR requirements inconsistently. This platform replaced that with a structured Terraform catalog: 43 single-purpose modules, thin composition wrappers, and 8 pre-composed application stacks that bundle everything a service needs to go to production. New environments that previously took weeks to stand up now come from a single parameterised call against the catalog.

Infrastructure was fragmented across teams and consoles. Every new environment meant re-implementing the same decisions from scratch, security posture was reimplemented rather than inherited, and DR-readiness was an afterthought rather than a default.

Infrastructure platform design, Terraform authoring, engineering standards, and CI conformance tooling.

• Terraform
• HCL
• AWS
• GitHub Actions
• Bash

• • 50 reusable Terraform units across three tiers: 43 single-purpose modules, thin wrappers, and 8 pre-composed application stacks
• • Mandatory DR-readiness tags enforced at the module level so every resource inherits the requirement rather than relying on teams to remember it
• • Version pinning and harmonisation across the catalog so a dependency upgrade happens once and propagates consistently
• • CI conformance tooling that validates format, linting, and plan output on every PR before any change reaches AWS

GitHub Actions runs conformance checks on every pull request. An approved Terraform apply targets AWS only after all checks pass. Environment-specific sizing keeps dev and staging costs low while production stacks carry full DR and observability configuration.

• • 50 reusable Terraform units across three tiers, covering every environment the teams needed from one shared catalog
• • New environment provisioning dropped from weeks of manual console work to a single parameterised call against a composed stack
• • Security posture and DR-readiness are inherited from modules rather than reimplemented per project, with zero exceptions enforced at the module interface

All credentials stay in deployment secrets and never touch the catalog itself. Version pinning across providers and modules prevents supply-chain drift. DR-readiness tags are mandatory at the module level, so IAM scoping and backup configuration are inherited by every resource that uses a module rather than added after the fact.

• • Deciding module granularity: too thin and every stack becomes a sprawl of wires, too fat and nothing composes. The answer was strict single-concern modules with explicit composition layers above them.
• • Making DR-readiness mandatory without blocking teams: enforcing it as a required tag at the module interface rather than a policy check after apply meant teams could not ship without it, but also did not need to think about it.
• • Version chain coupling: pinning providers and modules across 50 units created a harmonisation problem whenever a dependency moved. Decoupling those chains is the first thing I would change.

• • Documentation and automation should be foundational from day one, not added after the catalog grows. Every module that shipped without inline docs created friction that compounded as the catalog scaled.
• • Naming taxonomy matters more than it seems at small scale. Inconsistent module names made discovery harder as the catalog grew beyond what one person could hold in memory.
• • Inherited defaults outperform policy checks. Putting DR-readiness into the module interface rather than a CI gate meant it was impossible to skip, not just discouraged.

• Case study
• Architecture