01
Infrastructure is copy-pasted across accounts with no shared modules, versioning, or policy hooks.
Case 13
Terraform Platform Modules
Infrastructure as composable bricks: versioned Terraform modules, readable plans, and reviewable composition — not console snowflakes.
01
How it works
Compose known bricks — stop inventing snowflakes.
Terraform Platform Modules by Andrey Lesnikov — treat modules as versioned products that assemble reviewed stacks.
-
01
Pick the bricks
Network, IAM, baseline cluster, data, observability — reusable modules with clear contracts.
-
02
Pin the versions
Floating latest is how snowflakes return. Pins make rebuilds honest.
-
03
Read the plan
Composition is reviewable in a PR — infrastructure change as a product change.
-
04
Apply with ownership
No undocumented console state. Drift has nowhere polite to hide.
02
Evidence
From problem to proof.
How the system is framed, operated, and proven — not a slide deck summary.
02
The gap is Kubernetes delivery or twin state — modules alone will not replace GitOps or TwinOps control planes.
03
EKS Platform Foundation consumes modules as product layers. Policy as Code Guardrails keeps module outputs inside safe promote boundaries.
Constraints
Module versioning, state boundaries, reviewable plans, environment variance, and provider upgrade safety.
03
Related
Nearby systems.
EKS Platform Foundation
Kubernetes clusters become inconsistent when networking, identity, ingress, storage, and observability are assembled per project
Clusters as a repeatable product
GitOps: Argo CD & Flux
Teams need a clear delivery model before GitOps becomes another layer of operational confusion
Delivery as explicit platform contracts
Policy as Code Guardrails
Security and platform rules are often discovered only after deployment or during reviews
Standards enforced in CI, not slides
Available for meaningful infrastructure conversations