Terraform Guide

AWS Terraform diagram generator: your VPCs and clusters, drawn from the repo

AWS Terraform repos have a recognizable shape: a VPC module, an EKS or ECS cluster, RDS somewhere, IAM everywhere, and half of it composed from terraform-aws-modules. A good diagram of that repo uses the AWS icons your team already reads, keeps the IAM noise out of the boxes, and treats the registry modules as the first-class components they are.

Try it free
6 min readFor teams running AWS through Terraform who need the platform on one readable canvas

See it as a diagram

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

151/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

The AWS-specific parts of a good Terraform diagram

Icons carry AWS diagrams. An aws_eks_cluster should render with the EKS mark, aws_s3_bucket with the S3 mark, and a resource type the catalog does not know should still render with the Terraform mark rather than an anonymous box. Datadef maps the common AWS resource types to their icons and falls back honestly.

IAM is the hairball generator on AWS. Roles, policies, and attachments frequently outnumber the real infrastructure. They are classified as wiring: counted in a note, never drawn as boxes, so the diagram stays about the platform.

Containment is the AWS idiom: VPC contains subnets, subnets contain compute. Where the source declares those relationships, they render as nesting and placement instead of arrows.

Registry modules are half of real AWS repos

A typical production repo declares module "vpc" from terraform-aws-modules/vpc/aws and module "eks" from terraform-aws-modules/eks/aws rather than raw resources. Datadef recognizes those calls, draws each as one component with its source and version, and wires them through their references: module.eks consuming module.vpc.vpc_id becomes an edge from eks to vpc labelled vpc_id.

The hashicorp learn repo for EKS provisioning, three registry modules and almost no raw resources, comes out as exactly the three-node diagram a human would sketch: vpc, eks, and the IRSA role, with the real wiring. Repos that mix raw resources with registry calls get both, each drawn appropriately.

From connection to current diagram

Connect the GitHub, GitLab, or Azure DevOps repo read-only, pick the branch, and the first diagram generates immediately: no state file, no init, no AWS credentials. The daily sync keeps it matching the branch; unchanged commits are skipped.

The companion doc includes a generated module reference table, and the diagram embeds in your README or Confluence page as a live image that updates when the canvas does.

FAQ

Which AWS resource types get their own icons?

The common architecture-bearing types: VPC and networking, EC2, EKS, ECS, Lambda, S3, RDS and Aurora, DynamoDB, ElastiCache, Redshift, Kinesis, SQS, SNS, API Gateway, CloudFront, and more. Types outside the catalog render with the Terraform mark instead of a wrong guess.

How is IAM handled?

Roles, policies, attachments, and grants are classified as wiring. They are summarized in a note with counts rather than drawn as nodes, because on most AWS repos they would otherwise outnumber the actual infrastructure.

Does it need AWS credentials or a state file?

No. The diagram is parsed from the .tf source of the connected repository. Nothing touches your AWS account.

What happens with terraform-aws-modules registry modules?

Each call is drawn as one component carrying its name, source, and version, with edges resolved from its input references. A repo that is pure registry composition still produces a meaningful diagram.

Can I edit the generated diagram?

Yes, it lands on a normal Datadef canvas. Note that a later sync regenerates the diagram from the code, so treat the synced project as the always-current view and copy it if you want a frozen annotated version.