How to Generate an AWS Architecture Diagram from Terraform (3 Methods)

You have a Terraform codebase. Someone on your team — a new hire, a security reviewer, a customer auditor — needs to see what it builds. Reading 600 lines of HCL is not a great answer to that question.

This guide walks through three practical ways to generate an AWS architecture diagram from Terraform, ranked by effort and accuracy. By the end you should know which approach fits your team.

Why Bother With a Diagram At All?#

Terraform tells you what resources exist. A diagram tells you how they relate. The two are not interchangeable.

A good architecture diagram answers questions Terraform can't answer at a glance:

• What's exposed to the public internet?
• Which services share a subnet?
• Where does data cross trust boundaries?
• What's the blast radius if this security group changes?

For small projects you can keep that mental model in your head. For anything bigger, you need a picture — and you need that picture to stay accurate as the code changes. This is the same cognitive load problem we cover in Cognitive Debt: The Hidden Cost of Infrastructure as Code.

Method 1: Draw It Yourself in draw.io#

The simplest answer is also the oldest one: open draw.io (now diagrams.net), pick the AWS shape library, and start dragging.

When this is fine:

• You're sketching a proposed architecture before writing any Terraform
• The infrastructure is small (under ~20 resources)
• You only need the diagram once — for a slide, an RFC, a customer pitch

Why it breaks down:

• The diagram and the code drift apart the moment someone changes either
• Manual diagrams reflect what the author thinks the system looks like, not what it actually is
• You'll do this twice and then never again

For a one-off, draw.io is great. The shape library is excellent and the export options (PNG, SVG, PDF, embedded XML) are mature. As a sustained workflow it falls apart fast — the diagram becomes a lie the moment the next pull request lands.

Method 2: Open-Source CLIs#

If you want something automated but self-hosted, two CLIs are worth knowing.

inframap#

inframap reads Terraform state or HCL and emits a Graphviz dot file. You pipe that through the dot command to get a PNG or SVG.

Strengths:

• Pure command-line, easy to wire into CI
• Reads both Terraform state and raw .tf files
• Outputs to any Graphviz format

Limitations:

• Output is a flat graph — no zones, no logical grouping
• Styling is bare; you get nodes and edges, not architectural layers
• Coverage of newer AWS resources lags behind the AWS provider

terravision#

terravision goes further. It uses the official AWS, GCP, and Azure icon sets and produces a more polished diagram, including some grouping by VPC and subnet.

Strengths:

• Real cloud icons (AWS, GCP, Azure)
• Interactive HTML output with pan/zoom
• Optional AI-generated annotations

Limitations:

• The layout algorithm doesn't separate concerns clearly (network vs security vs data live in the same view)
• AI annotations introduce probabilistic output — if you need deterministic diffs across versions, turn them off
• Requires you to manage Python deps, icon assets, and CI plumbing yourself

Both CLIs are great if you want a reasonable diagram you can generate locally with no external service. They're not great if you want diagrams that are good enough to show an auditor or a board, or that update automatically on every pull request.

Method 3: Hosted Tools#

If you want zero-effort diagrams that stay current with your Terraform, hosted services are the obvious next step. The main players are Infragr.am, Brainboard, Holori, and Pluralith. We compare all of them in 5 Best Terraform Diagram Tools in 2026.

The trade-off is straightforward: you send your Terraform somewhere (an API, a GitHub App, a CLI that uploads), and in return you get diagrams without managing any infrastructure of your own.

What you get with a hosted tool that you don't get with a CLI:

• Layered output — Network, Security, Compute, Data as separate lenses
• Automatic updates on every pull request, with before/after deltas
• Deterministic rendering, so the same Terraform always produces the same diagram (important for comparing versions and tracking drift)
• draw.io export for downstream editing, since most teams already have an existing workflow there

The trade-offs to know:

• Your Terraform leaves your machine (most tools process in memory and don't store it, but verify with the vendor)
• You're tied to the vendor's coverage of cloud resources
• Pricing scales with team size or resource count

For most teams beyond the prototyping stage, a hosted tool ends up being the lowest-overhead option. Setup is a few minutes, the diagrams stay current automatically, and you don't have to maintain a CI step nobody on the team understands.

Which Method Should You Pick?#

A rough decision tree:

• Just starting, less than 20 resources: draw.io. Don't over-engineer.
• Solo or hobby project, want something automated, comfortable with CLIs: inframap or terravision.
• Team setting, infrastructure under active development, multiple environments: a hosted tool.
• Compliance or audit context where determinism matters: a hosted tool with deterministic guarantees. We cover why determinism beats AI-generated output in detail.
• Need diagrams on every PR review: see How to Add Architecture Diagrams to Terraform Pull Requests.

Common Gotchas#

Whichever method you pick, three things will trip you up if you're not paying attention.

Terraform state versus Terraform code. State reflects what's actually deployed; code reflects what will be deployed on the next apply. They can diverge — by drift, by manual changes in the console, by a half-applied plan. Most tools let you pick which to diagram. For PR review, diagram the code. For incident response, diagram the state.

Modules hide architecture. A Terraform module is a black box from the outside. Tools that only read top-level resources will miss everything inside the module. Make sure your tool descends into module sources, or you'll get a diagram that's technically correct and practically useless.

Multi-environment confusion. If your repo provisions staging and production from the same root module, a naive diagram will conflate them. Hosted tools usually let you target a workspace or a specific tfvars file. Configure that explicitly.

FAQ#

Can I generate an AWS diagram from Terraform without running terraform plan?#

Yes. Both inframap and most hosted tools can parse HCL directly without executing a plan. This matters when you don't want to grant credentials to the diagram tool. Pluralith is the main exception — it specifically uses plan output for richer detail.

Do these tools work with Terraform modules from the registry?#

It depends. CLIs typically need the modules to be available locally (run terraform init first). Hosted tools either require the same or accept a repo reference and resolve modules themselves. Always test with one of your real modules before committing to a tool.

What about Terragrunt?#

Terragrunt support is uneven. inframap and terravision work if you generate the underlying Terraform first. Hosted tools vary — confirm Terragrunt support with the vendor before adopting.

Can I get the same diagram every time?#

Only with deterministic tools. AI-augmented options (Eraser AI, terravision's AI annotations) produce variable output by design. If you need diffs across versions or audit-grade evidence, pick a tool that explicitly guarantees deterministic rendering.

Is there a free option for production use?#

inframap and terravision are open source and free. For a hosted tool, Infragr.am and most competitors have a free tier sufficient for small teams or evaluation.

Closing#

The right method depends on what the diagram is for. A sketch on an RFC and an artifact you hand to an auditor are not the same deliverable, and the tool you reach for shouldn't be the same either. Start with draw.io, graduate to a CLI when you want automation, and reach for a hosted tool when the diagram has to stay current without anyone remembering to update it.