Infrastructure-as-Code Standardization
# Five teams had three different ways of provisioning infrastructure. Reviewing changes had become impossible.
CLIENT
// client.mdA technology company with five engineering teams operating on a shared cloud account but with materially different practices for how they provisioned and managed infrastructure. Some teams used Terraform. Others used CloudFormation. One team had grown organically with click-ops in the AWS console and was paying the operational cost of that history.
PAIN
// pain.mdInfrastructure changes across teams were genuinely difficult to review because the artifacts being reviewed were heterogeneous. Cost attribution was unreliable because tagging practices differed by team. Security posture review was time-consuming because the same baseline had to be verified differently for each team's stack. The leadership wanted standardization that didn't require a multi-quarter rebuild.
BUILT
// built.mdA standardization engagement structured to produce convergence without disruption.
Tooling decision — Terraform was selected as the standard. The decision was based on team familiarity (most teams had Terraform experience even where it wasn't their primary tool), ecosystem maturity, and the click-ops team's need for tooling that could import existing resources rather than recreate them.
Module library — A shared module library was built covering the common infrastructure patterns the teams used — networking, IAM, storage, common compute patterns. Teams using the modules got consistent baseline configuration without having to author it themselves.
Migration plan per team — Each team got a migration plan tailored to their starting point. The teams already on Terraform converged on the shared modules; the CloudFormation team migrated incrementally; the click-ops team's resources were imported into Terraform state and brought under declarative management without recreating them.
Pipeline integration — Terraform plans were generated automatically on infrastructure pull requests; reviewers could see the actual change being proposed without running anything locally. Apply was automated for low-risk changes and gated for high-risk ones.
Tagging and cost attribution — Standard tags were enforced through the module library. Cost attribution became reliable across teams without each team needing to remember the conventions independently.
OUTCOME
// outcome.mdInfrastructure review across teams became a uniform practice. Cost attribution became reliable. Security baseline verification could be performed against a single tooling target. The teams retained their autonomy on what they built; they converged on how they built it.
The migration was completed within a single quarter without disrupting any team's delivery cadence.