🧬 Why DRY Matters: Scaling Infrastructure Across Clients or Business Units

Jonathon TroyJonathon Troy
3 min read

The DRY (Don't Repeat Yourself) principle is more than just a best practice — in a real-world infrastructure setup, it's a force multiplier.

Imagine you're managing:

  • Multiple business units with their own production, staging, and dev environments, or

  • Multiple clients with slight variations in architecture or compliance needs.

In both cases, 90% of your infrastructure is the same: VPCs, IAM boundaries, logging pipelines, Kubernetes base layers. But the 10% that's different — maybe one client needs an extra NAT Gateway, another skips RDS entirely — can turn into a maintenance nightmare if your code isn’t structured to handle it.

✅ DRY Helps You:

  • Replicate a known-good baseline quickly across multiple environments or clients.

  • Minimize the surface area for bugs — fix once, propagate everywhere.

  • Reduce onboarding friction for new engineers by giving them consistent structure.


🎭 When DRY Meets Reality: Not Every Client Needs the Same Thing

That’s the catch: not every client is a perfect clone. Some need custom networking. Some need different compliance layers. This is where Terragrunt shines — by using:

  • locals to manage dynamic inputs

  • dependencies to orchestrate resource relationships

  • include to inherit base configurations

But to go even further, you can supercharge your setup with Ansible and Cookiecutter.


🧵 Ansible + Cookiecutter + Terragrunt = Infrastructure Templating Done Right

Before your Terraform even runs, Ansible + Cookiecutter can:

  • Use Ansible to GROK and pre-fab variables

  • Clone pre-built folder structures for new clients or environments

  • Inject environment-specific variables via Jinja2 templates

  • Scaffold GitOps-ready directories with linter configs, docs templates, and security tools

  • Capture the planned output to a PR and review or have ore-conditioned approvals

  • After reviewing and approval commit the artifact and have a record of the change in history

This setup helps new teams learn by osmosis — seeing the rendered output teaches structure. It turns “How do I set up a new region for this client?” into “Run this playbook, commit the result.”

Example tools used together:

  • Ansible to automate file scaffolding and environment creation

  • Cookiecutter to templatize terragrunt.hcl files per region/env

  • Jinja2 to inject account-specific or region-specific values

  • Pre-commit hooks with:

    • tflint, tfsec, tfdocs, ansible-lint

    • Checkov and Trivy for security posture

    • Cost validators to avoid surprises


🌀 GitOps-Ready by Default

The ultimate goal? Infrastructure that:

  • Lives in Git

  • Is validated pre-merge

  • Is deployed via automation

With main tracked and protected, your team can catch mistakes early. Every merge is a verified commit — scanned, linted, and staged for deployment via your CI/CD system (like Atlantis, ArgoCD, or Spacelift).


🧭 Summary

DRY in infrastructure isn't just a coding principle — it’s a strategy for speed, scale, and safety.

  • Use Terragrunt to abstract and reuse Terraform modules across clients or tiers.

  • Use Ansible and Cookiecutter to bootstrap environments with precision.

  • Integrate GitOps and pre-commit tooling to shift compliance and security left.

This approach transforms infrastructure delivery from tribal knowledge into repeatable fabric, making every new environment a fast, confident deployment — not a guessing game.

0
Subscribe to my newsletter

Read articles from Jonathon Troy directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Jonathon Troy
Jonathon Troy