Terraform Guide

Azure Terraform diagram generator: the azurerm repo, drawn like the portal never will

Azure platform repos in Terraform tend to be dense: a resource group as the frame, VNets and subnets, Key Vaults, storage accounts, and increasingly a data platform on top, Databricks, Synapse, or SQL. The Azure portal shows you resources one blade at a time; the repo declares all of it at once. The diagram should come from the repo.

Try it free
6 min readFor teams running Azure through azurerm, including repos hosted on Azure DevOps

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

154/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

Azure specifics the diagram has to get right

Containment first: on Azure everything lives in a resource group, and resource_group_name references are containment, not data flow. Drawing them as arrows produces the classic every-box-points-at-one-box mess. Datadef classifies containment relationships and renders them as grouping and placement instead.

Real icons second: azurerm_databricks_workspace with the Databricks mark, azurerm_key_vault with the Key Vault mark, azurerm_storage_account, virtual networks, NSGs, VMs, all with their Azure icons. Role assignments, the azurerm hairball equivalent of IAM, are counted in a note rather than drawn.

Multi-environment honesty third: Azure platform repos commonly carry DEV, QUAL, and PROD tfvars. Those parse into real counts on the nodes, like 10 catalogs in DEV and 1 in PROD, instead of three cloned diagrams or a vague times-N.

Azure DevOps repos connect natively

Repositories on dev.azure.com connect with a read-only PAT, including project and repository names with spaces, and browser URLs paste directly. GitHub and GitLab work the same way. The connection never runs terraform and never touches your subscription.

For a data platform repo, the parsed graph captures the wiring that matters: storage accounts feeding external locations, the workspace consuming the access connector, catalogs sitting on the metastore, warehouses serving BI. Those references, resolved through module outputs, become the arrows.

What you get on every sync

A curated diagram, modules as zones with their real resources, refreshed daily and on demand, plus an architecture doc with a generated module reference table listing every module with its source and resource count.

Both are built for sharing: the diagram embeds as a live image in READMEs, Confluence, or Notion, and the doc is plain markdown you can commit next to the code.

FAQ

Does it support repositories hosted on Azure DevOps?

Yes, natively, with a read-only PAT scoped to code read. Organization, project, and repository names with spaces work, and pasting the browser URL of the repo is accepted.

How are resource groups drawn?

As containment. Resources referencing a resource group are grouped and placed rather than wired to it with arrows, which keeps the diagram about actual data and control flow.

What about role assignments and Key Vault access policies?

They are classified as wiring and summarized with counts in a note. On a real azurerm platform repo they can outnumber the infrastructure; drawing them would bury it.

We deploy the same repo to DEV, QUAL, and PROD. Three diagrams?

One diagram, honest counts. Per-environment tfvars are parsed, so a resource or module instantiated per environment shows its real numbers on a single node.

Does anything run against our Azure subscription?

No. The analysis is a parse of the repository source. No state, no init, no Azure credentials, nothing executed.