DEV Community: Raghvendra Pandey

What's New in InfraSketch — May 2026: Pulumi & Kubernetes Support

Raghvendra Pandey — Thu, 30 Apr 2026 21:12:57 +0000

Two major new input formats land in InfraSketch this month: Pulumi TypeScript and Python, and Kubernetes YAML. Together they bring InfraSketch support to every major infrastructure-as-code tool in active use today.

Try the new formats now Click the Pulumi or Kubernetes tab and paste your code. Open InfraSketch →

Pulumi support — TypeScript & Python

New Pulumi tab

Parse Pulumi TypeScript (index.ts) and Python (__main__.py) directly — no compile step
95+ resource types across AWS, GCP, and Azure
VPC containment from vpcId: vpc.id / vpc_id=vpc.id references
Subnet placement from subnetId, subnets, subnetIds arguments
Connection arrows from variable references between resources
Auto-detects TypeScript vs Python from syntax
3 built-in examples: AWS production stack (TS), AWS serverless (Python), GCP Cloud Run (TS)

AWS resources covered: VPC, subnets, EC2, EKS, ECS, Lambda, RDS, DynamoDB, ElastiCache, S3, ALB, Route53, CloudFront, SQS, SNS, IAM, KMS, WAF, ECR, Auto Scaling, CloudWatch.

GCP resources covered: Compute Engine, GKE, Cloud Run, Cloud Functions, Cloud SQL, BigQuery, Spanner, Bigtable, Firestore, Redis, Pub/Sub, Cloud Storage, Secret Manager, KMS, IAM, DNS, Monitoring.

Azure resources covered: Virtual Networks, AKS, App Service, Functions, SQL, Cosmos DB, Key Vault, Container Groups, CDN Frontdoor, Redis, Service Bus, Event Hub.

Read the full guide: Pulumi Diagram Generator — Visualize Pulumi Infrastructure Instantly

Kubernetes YAML support

New Kubernetes tab

Parse multi-document YAML (documents separated by ---)
16 resource kinds: Deployment, StatefulSet, DaemonSet, Job, CronJob, Pod, ReplicaSet, Service, Ingress, NetworkPolicy, ConfigMap, Secret, PersistentVolumeClaim, PersistentVolume, ServiceAccount, HorizontalPodAutoscaler
Namespace grouping — resources grouped into labelled namespace boundaries from metadata.namespace
Selector-based connections — Service spec.selector matched to workload spec.selector.matchLabels
Ingress routing — spec.rules[].http.paths[].backend.service.name becomes Ingress→Service arrows
Volume/envFrom references — Deployment→ConfigMap and Deployment→Secret arrows from volume mounts and envFrom
HPA target links — spec.scaleTargetRef connects HPA to its scale target
1 built-in example: full-stack web app with Ingress, Service, Deployment, ConfigMap, Secret, HPA

Works with raw manifests, kubectl get all -o yaml output, Helm template output (helm template), and Kustomize builds (kustomize build).

Read the full guide: Kubernetes Diagram Generator — Visualize K8s YAML Instantly

Bug fixes

Fix Diagram display

Diagram panel no longer shows half the diagram when output is taller than the panel height
SVG height set to auto — aspect ratio preserved via viewBox
Diagram canvas scrolls from top rather than clipping vertically centered content

What's next

Auto-detect format — paste any IaC code and InfraSketch detects the format automatically
Keyboard shortcuts — generate, zoom, export without reaching for the mouse
More Kubernetes samples — microservices, ingress controller, monitoring stack
Bicep / ARM — Azure-native template formats

Feature requests and bug reports welcome on GitHub.

Try Pulumi and Kubernetes diagrams now Free, no login, nothing leaves your browser. Open InfraSketch →

Pulumi Diagram Generator — Visualize Pulumi Infrastructure Instantly

Raghvendra Pandey — Thu, 30 Apr 2026 21:12:25 +0000

InfraSketch now supports Pulumi. Paste your Pulumi TypeScript or Python code into the Pulumi tab and get a full architecture diagram in seconds — VPC containment, subnet grouping, resource connections, official AWS, GCP, and Azure icons. No login, no credentials, everything runs in your browser.

Try it now Paste your Pulumi TypeScript or Python code and see the diagram instantly. Open InfraSketch →

Why Pulumi needs a diagram tool

Pulumi lets you write infrastructure in real programming languages — TypeScript, Python, Go, C#. That's great for developer productivity, but it creates the same visibility problem every IaC tool has: your infrastructure lives in code, not in a picture. When a new engineer joins the team, or when you're reviewing a PR that adds a VPC and six new resources, reading TypeScript is not the fastest way to understand what gets built.

Unlike Terraform's HCL, Pulumi code doesn't have a declarative format that's easy to inspect at a glance. A function might conditionally create resources. Loops might generate dozens of similar components. The Pulumi console shows state, not topology. There's no built-in way to go from code to architecture diagram.

InfraSketch parses Pulumi TypeScript and Python directly — no compile step, no export, just paste and generate.

How to use it

Open infrasketch.cloud, click the Pulumi tab, paste your index.ts or __main__.py file, and click Generate Diagram. You can paste a partial file — InfraSketch handles incomplete code gracefully.

// Example: paste this into the Pulumi tab
import * as aws from "@pulumi/aws";

const vpc = new aws.ec2.Vpc("main", { cidrBlock: "10.0.0.0/16" });
const subnet = new aws.ec2.Subnet("public", {
vpcId: vpc.id,
cidrBlock: "10.0.1.0/24",
});
const igw = new aws.ec2.InternetGateway("igw", { vpcId: vpc.id });
const lb = new aws.lb.LoadBalancer("alb", { subnets: [subnet.id] });

Tip: Pulumi Python uses the same resource types with underscores — aws.ec2.Vpc in TypeScript is aws.ec2.Vpc in Python too. Both work with InfraSketch.

What gets visualized

VPC containment

Resources referencing a VPC via vpcId: vpc.id are drawn inside the VPC boundary automatically.

Subnet placement

Resources with subnetId or subnets arguments are placed in public or private subnet lanes.

Connection arrows

Variable references between resources — vpc.id, cluster.endpoint — become directed arrows on the diagram.

Multi-cloud

AWS, GCP, and Azure resources in the same stack all render on one diagram with their respective provider icons.

Supported Pulumi resource types

InfraSketch supports 95+ Pulumi resource types across AWS, GCP, and Azure. Key AWS resources include:

Networking: aws.ec2.Vpc, aws.ec2.Subnet, aws.ec2.InternetGateway, aws.ec2.NatGateway, aws.ec2.SecurityGroup, aws.ec2.TransitGateway
Compute: aws.ec2.Instance, aws.ec2.LaunchTemplate, aws.autoscaling.Group, aws.ecs.Cluster, aws.ecs.Service, aws.lambda_.Function
Containers: aws.eks.Cluster, aws.eks.NodeGroup, aws.ecr.Repository
Load balancing: aws.lb.LoadBalancer, aws.lb.TargetGroup, aws.alb.LoadBalancer
Data: aws.rds.Instance, aws.rds.Cluster, aws.dynamodb.Table, aws.elasticache.Cluster, aws.s3.Bucket
Messaging: aws.sqs.Queue, aws.sns.Topic
DNS & CDN: aws.route53.Zone, aws.cloudfront.Distribution
Security: aws.iam.Role, aws.kms.Key, aws.wafv2.WebAcl

GCP resources cover Compute Engine, GKE, Cloud Run, Cloud Functions, Cloud SQL, BigQuery, Spanner, Bigtable, Pub/Sub, Cloud Storage, Secret Manager, and more. Azure covers Virtual Networks, AKS, App Service, Functions, SQL, Cosmos DB, and Key Vault.

TypeScript vs Python

InfraSketch detects the language automatically. TypeScript uses camelCase arguments (cidrBlock, vpcId). Python uses snake_case (cidr_block, vpc_id). Both parse correctly — no pre-processing needed.

# Python example — works the same way
import pulumi_aws as aws

vpc = aws.ec2.Vpc("main", cidr_block="10.0.0.0/16")
subnet = aws.ec2.Subnet("public",
vpc_id=vpc.id,
cidr_block="10.0.1.0/24"
)
cluster = aws.eks.Cluster("eks", vpc_config=aws.eks.ClusterVpcConfigArgs(
subnet_ids=[subnet.id]
))

Use cases

Code reviews — paste a PR's Pulumi code and see the topology change visually before approving
Onboarding — share a diagram link instead of asking new engineers to read TypeScript they've never seen
Documentation — export as PNG or SVG and embed in Confluence, Notion, or your wiki
Architecture reviews — export as draw.io XML for a fully editable diagram in your design doc
Multi-stack visibility — paste each stack separately and compare their architectures side by side

Pulumi vs Terraform diagrams

If you're migrating from Terraform to Pulumi (or evaluating it), InfraSketch lets you diagram both. Paste your Terraform HCL in the Terraform tab and your equivalent Pulumi code in the Pulumi tab — the diagrams should look identical if the migration is complete. Differences become immediately visible.

Generate your Pulumi diagram now Paste your index.ts or __main__.py into the Pulumi tab. Free, no login, nothing leaves your browser. Open InfraSketch →

Kubernetes Diagram Generator — Visualize K8s YAML Instantly

Raghvendra Pandey — Thu, 30 Apr 2026 21:12:22 +0000

InfraSketch now supports Kubernetes YAML. Paste one or more manifest files into the Kubernetes tab and get a full architecture diagram in seconds — namespace grouping, Ingress-to-Service connections, selector-based Service-to-Deployment wiring, ConfigMap and Secret references, and HPA targets. No login, no cluster access, everything runs in your browser.

Try it now Paste your Kubernetes YAML manifests and see the diagram instantly. Open InfraSketch →

Why Kubernetes needs a diagram tool

A production Kubernetes application typically spans dozens of YAML files — Deployments, Services, Ingresses, ConfigMaps, Secrets, PVCs, HPAs, NetworkPolicies. When something breaks, or when you're onboarding a new engineer, the mental model of "how does this all connect" is not obvious from reading YAML alone.

Tools like kubectl show you state, not topology. k9s gives you resource lists. Lens visualizes the cluster but requires actual cluster access. There's no fast, offline way to go from a set of YAML manifests to a clear connection diagram — until now.

InfraSketch reads your YAML, infers the topology from label selectors and resource references, and renders it as a navigable diagram. No cluster access needed.

How to use it

Open infrasketch.cloud, click the Kubernetes tab, paste your manifests (multiple documents separated by ---), and click Generate Diagram.

kubectl get all -n my-namespace -o yaml | pbcopy   # macOS
kubectl get all -n my-namespace -o yaml | xclip      # Linux

Tip: Paste manifests from multiple namespaces at once — InfraSketch groups resources by namespace automatically using metadata.namespace.

How connections are inferred

InfraSketch doesn't need a running cluster to understand topology. It infers connections from the YAML itself:

Ingress → Service

Every spec.rules[].http.paths[].backend.service.name becomes a directed arrow from the Ingress to the target Service.

Service → Deployment

Service spec.selector is matched against Deployment/StatefulSet/DaemonSet spec.selector.matchLabels. Matching labels = connection arrow.

Deployment → ConfigMap/Secret

Volume mounts (configMap.name, secret.secretName) and envFrom references become arrows from the workload to the config resource.

HPA → target

spec.scaleTargetRef.name and kind links the HorizontalPodAutoscaler to its Deployment, StatefulSet, or ReplicaSet.

Supported Kubernetes resource kinds

Kind	Category	Notes
Deployment	Workload	Main compute unit; selector matching for Service connections
StatefulSet	Workload	Persistent workloads; selector matching
DaemonSet	Workload	Node-level agents; selector matching
Job	Workload	Batch tasks
CronJob	Workload	Scheduled batch tasks
Pod	Workload	Standalone pods
ReplicaSet	Workload	HPA scale target
Service	Networking	ClusterIP, NodePort, LoadBalancer — selector → Deployment arrows
Ingress	Networking	HTTP routing rules → Service arrows
NetworkPolicy	Networking	Pod-level network rules
ConfigMap	Config	Referenced via volume mounts and envFrom
Secret	Config	Referenced via volume mounts and envFrom
PersistentVolumeClaim	Storage	Volume mount references from workloads
PersistentVolume	Storage	Cluster-wide storage resources
ServiceAccount	Security	Pod identity
HorizontalPodAutoscaler	Autoscaling	Linked to scale target via scaleTargetRef

Namespace grouping

Every resource is placed inside a namespace boundary drawn on the diagram. Resources with the same metadata.namespace value are grouped together in a labelled box. Resources without a namespace go into the default namespace group.

When you paste manifests from multiple namespaces — say production, staging, and monitoring — each namespace gets its own group and resources stay organized. Cross-namespace connections (e.g., an Ingress controller in ingress-nginx routing to a Service in production) are drawn as arrows between the groups.

Example: a typical web application

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
namespace: production
spec:
rules:
- http:
paths:
- path: /
backend:
service:
name: web-service
port:
number: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
namespace: production
spec:
selector:
app: web
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
namespace: production
spec:
selector:
matchLabels:
app: web
template:
spec:
containers:
- name: web
envFrom:
- configMapRef:
name: web-config
- secretRef:
name: web-secrets
---
apiVersion: v1
kind: ConfigMap
metadata:
name: web-config
namespace: production

Paste this and InfraSketch draws: Ingress → web-service → web-deployment → web-config with web-secrets also connected to the deployment. All resources inside a production namespace box.

Use cases

Onboarding — new engineers understand the application topology in minutes instead of reading dozens of YAML files
Code reviews — visualize the topology change when a PR adds a new Service or reconfigures selectors
Incident response — quickly see which Services connect to a misbehaving Deployment
Documentation — export as PNG or SVG and embed in runbooks, Confluence, or Notion
Architecture reviews — export as draw.io XML for a fully editable diagram in design docs

Works with Helm and Kustomize output too

InfraSketch reads rendered YAML — it doesn't need the original Helm chart or Kustomize overlay files. Render first, then paste:

helm template my-release ./my-chart | pbcopy          # macOS
kustomize build overlays/production | pbcopy            # macOS

This works especially well for understanding what a third-party Helm chart actually deploys before you install it in your cluster.

Generate your Kubernetes diagram now Paste your K8s manifests — or run kubectl get all -o yaml and paste. Free, no login, no cluster access needed. Open InfraSketch →

CDK Architecture Diagram Generator — Visualize AWS CDK Apps Instantly

Raghvendra Pandey — Fri, 24 Apr 2026 22:12:26 +0000

InfraSketch now supports AWS CDK. Run cdk synth, paste the JSON output into the CDK tab, and get a full architecture diagram in seconds — VPC containment, subnet lanes, resource connections, official AWS icons. No login, no credentials, everything in your browser.

Try it now Paste your cdk synth output and see the diagram instantly. Open InfraSketch →

Why CDK needs a diagram tool

CDK is increasingly the default way teams write AWS infrastructure — TypeScript, Python, or Go code that compiles down to CloudFormation. The abstractions are great for development velocity, but they create a visibility problem: when something goes wrong, or when you need to explain the architecture to someone outside your team, the source code is not the right artifact to share.

The CloudFormation console shows you a stack but won't visualize containment. The CDK tree view shows construct hierarchy, not network topology. There's no built-in way to go from a CDK app to a clean architecture diagram without manually drawing one.

InfraSketch fills that gap. One command, paste, done.

How to get your CDK synth output

cdk synth | pbcopy          # macOS — copies to clipboard
cdk synth > template.json  # save to file

Then open infrasketch.cloud, click the CDK tab, paste, and click Generate Diagram.

Tip: If your app has multiple stacks, use cdk synth MyStack to synthesize a specific stack, or paste each stack's output separately to diagram them individually.

How it works under the hood

CDK compiles to CloudFormation JSON. InfraSketch's CDK tab runs the same parser as the CloudFormation tab — it reads the Resources object, maps each Type to a visual category, and infers topology from Ref and Fn::GetAtt references between resources.

CDK logical IDs look different from hand-written CloudFormation — CDK generates names like VPCB9E5F0B4 and EKSCluster9EE0221C — but the diagram labels use the resource type and truncated logical ID, making it easy to identify resources without needing the CDK source code in front of you.

What gets visualized

VPC containment

Resources with VpcId: { Ref: VPC } are drawn inside the VPC box. CDK's ec2.Vpc construct generates this automatically.

Subnet placement

Public and private subnet lanes from CDK's SubnetSelection — SubnetIds in the synthesized JSON places resources in the right lane.

Connection arrows

Every Fn::GetAtt between supported resources becomes a directed arrow — Lambda → IAM Role, ECS Service → ALB Target Group, etc.

Zone grouping

Internet zone (IGW, CloudFront), messaging zone (SQS, SNS), data zone (RDS, ElastiCache, S3) — all inferred automatically from resource type.

Supported CDK constructs (L1 / Cfn*)

Any CDK L1 construct (prefixed Cfn) maps directly to a CloudFormation resource type and is fully supported. Common L2 constructs synthesize to the same underlying types:

ec2.Vpc → AWS::EC2::VPC + subnets + IGW + NAT gateways
eks.Cluster → AWS::EKS::Cluster + node groups + IAM roles
ecs.FargateService → AWS::ECS::Service + task definition
lambda.Function → AWS::Lambda::Function + IAM role
rds.DatabaseInstance → AWS::RDS::DBInstance + subnet group
elasticache.CfnReplicationGroup → AWS::ElastiCache::ReplicationGroup
s3.Bucket → AWS::S3::Bucket
sqs.Queue → AWS::SQS::Queue
sns.Topic → AWS::SNS::Topic
elbv2.ApplicationLoadBalancer → AWS::ElasticLoadBalancingV2::LoadBalancer
cloudfront.Distribution → AWS::CloudFront::Distribution
kms.Key → AWS::KMS::Key
iam.Role → AWS::IAM::Role
wafv2.CfnWebACL → AWS::WAFv2::WebACL
route53.HostedZone → AWS::Route53::HostedZone

Use cases

Code reviews — run cdk synth on a PR branch and paste the output to see what the architecture change looks like visually
Onboarding — share a diagram link with new team members instead of asking them to read CDK TypeScript they've never seen
Documentation — export as PNG or SVG and embed in Confluence, Notion, or your wiki
Architecture reviews — export as draw.io XML to get a fully editable diagram for your design doc
Drift detection — synthesize before and after a change and compare diagrams side by side

Works with CDK for Terraform too

CDK for Terraform (CDKTF) can synthesize Terraform JSON. If you're using CDKTF, use the Terraform tab and paste the synthesized JSON — InfraSketch's plan JSON parser handles it directly.

Generate your CDK diagram now Run cdk synth | pbcopy, paste into the CDK tab, click Generate. Free, no login, nothing leaves your browser. Open InfraSketch →

CloudFormation Diagram Generator — Visualize AWS Templates Instantly

Raghvendra Pandey — Fri, 24 Apr 2026 22:02:36 +0000

InfraSketch now supports CloudFormation. Paste a CloudFormation YAML or JSON template — including all the !Ref, !GetAtt, and !Sub shorthand you're used to writing — and get a clean architecture diagram in seconds. No login, no backend, everything runs in your browser.

Try it now Paste your CloudFormation template and see the diagram instantly. Open InfraSketch →

Why CloudFormation support matters

CloudFormation is still the most widely deployed IaC tool in AWS-heavy organizations. It ships with every AWS account, it integrates natively with CDK, SAM, and AWS Service Catalog, and most platform teams have years of existing templates they maintain. But CloudFormation has always been terrible at communicating what it actually does. A 400-line YAML file is not an architecture — it's a specification. Turning it into a diagram has always meant manual work in draw.io or Lucidchart.

InfraSketch eliminates that step. Paste the template, click Generate, get a diagram you can share or export.

How it works

CloudFormation templates use YAML shorthand tags like !Ref and !GetAtt that are not standard YAML — most parsers choke on them. InfraSketch registers custom YAML types for all CloudFormation intrinsic functions before parsing, so your templates load cleanly without any preprocessing.

Once parsed, the engine walks every resource's Properties block and:

Maps the Type field (e.g. AWS::ECS::Service) to a visual category with the correct AWS icon
Detects VpcId: !Ref MyVPC and draws the resource inside the VPC container
Detects SubnetId / SubnetIds / Subnets references and places the resource in the correct subnet lane
Infers directed connections from any other Ref or GetAtt between supported resources

The result is the same zoned layout InfraSketch uses for Terraform — Internet zone at the top, ingress layer, VPC with subnets, data zone, messaging zone, security zone — all inferred automatically from your template.

Quick start

Open infrasketch.cloud
Click the CloudFormation tab
Paste your template (YAML or JSON) and click Generate Diagram
Export as PNG, SVG, or draw.io XML — or click Share to copy a shareable URL

The parser auto-detects YAML vs JSON based on whether the template starts with {.

Example: a minimal web stack

AWSTemplateFormatVersion: '2010-09-09'
Resources:
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16

PublicSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.1.0/24

AppLoadBalancer:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
Properties:
Subnets:
- !Ref PublicSubnet

AppFunction:
Type: AWS::Lambda::Function
Properties:
Role: !GetAtt LambdaRole.Arn
Environment:
Variables:
QUEUE_URL: !Ref AppQueue

AppQueue:
Type: AWS::SQS::Queue

LambdaRole:
Type: AWS::IAM::Role

This produces a diagram with the VPC container, PublicSubnet with the ALB inside, Lambda connecting to SQS and IAM Role, and the messaging zone for the queue — all from the references in the template.

Supported resource types

Category	CloudFormation types
Networking	`AWS::EC2::VPC`, `AWS::EC2::Subnet`, `AWS::EC2::InternetGateway`, `AWS::EC2::NatGateway`, `AWS::EC2::EIP`, `AWS::EC2::RouteTable`, `AWS::EC2::TransitGateway`, `AWS::EC2::VPNGateway`, `AWS::EC2::NetworkInterface`
Compute	`AWS::EC2::Instance`, `AWS::EC2::LaunchTemplate`, `AWS::AutoScaling::AutoScalingGroup`, `AWS::EKS::Cluster`, `AWS::EKS::Nodegroup`, `AWS::ECS::Cluster`, `AWS::ECS::Service`, `AWS::ECS::TaskDefinition`, `AWS::Lambda::Function`
Data	`AWS::RDS::DBInstance`, `AWS::RDS::DBCluster`, `AWS::DynamoDB::Table`, `AWS::ElastiCache::CacheCluster`, `AWS::ElastiCache::ReplicationGroup`
Storage	`AWS::S3::Bucket`
Load balancing	`AWS::ElasticLoadBalancingV2::LoadBalancer` (ALB/NLB auto-detected), `AWS::ElasticLoadBalancingV2::TargetGroup`, `AWS::ElasticLoadBalancing::LoadBalancer`
Security	`AWS::EC2::SecurityGroup`, `AWS::IAM::Role`, `AWS::KMS::Key`, `AWS::WAFv2::WebACL`
Edge / DNS	`AWS::CloudFront::Distribution`, `AWS::Route53::HostedZone`, `AWS::Route53::RecordSet`, `AWS::Route53::RecordSetGroup`
Messaging	`AWS::SQS::Queue`, `AWS::SNS::Topic`
Containers	`AWS::ECR::Repository`
Observability	`AWS::CloudWatch::Alarm`, `AWS::Logs::LogGroup`

What gets inferred automatically

VPC containment

Any resource with VpcId: !Ref X is drawn inside the VPC box for resource X.

Subnet placement

SubnetId, SubnetIds, and Subnets properties place resources in the correct subnet lane.

ALB vs NLB

Type: network on a load balancer property selects the NLB icon; anything else is ALB.

Connection arrows

Every !Ref and !GetAtt between supported resources that isn't a VPC/subnet reference becomes a directed arrow.

Intrinsic functions supported

The YAML parser handles all standard CloudFormation shorthand tags without requiring you to expand them to long form:

!Ref — logical resource reference
!GetAtt — attribute reference (!GetAtt Resource.Attribute or list form)
!Sub — string substitution (scalar and list forms)
!If, !And, !Or, !Not — conditionals
!Select, !Join, !Split, !FindInMap
!Base64, !ImportValue, !Condition

JSON templates are also supported — { "Ref": "MyVPC" } and { "Fn::GetAtt": ["MyRole", "Arn"] } both work exactly the same way.

What's still Terraform-only

A few features remain Terraform-specific for now: module expansion (ZIP upload and registry auto-fetch), and the plan JSON workflow. CloudFormation doesn't have an equivalent to terraform show -json, but the template itself is already the resolved source of truth — there's no variable evaluation step needed.

Use cases

Code reviews — paste the template diff, see what changed in the diagram
Onboarding — new team member needs to understand the stack without reading 500 lines of YAML
Documentation — export as PNG or SVG and embed in a wiki, Confluence page, or design doc
draw.io integration — export as draw.io XML to get a fully editable diagram in diagrams.net or Confluence
Audit prep — show reviewers the actual infrastructure topology without sharing credentials

Try CloudFormation diagrams now Paste your template and get a diagram in seconds. Free, no login, nothing leaves your browser. Open InfraSketch →

Terraform Visualization: 5 Ways to See What Your Code Actually Builds

Raghvendra Pandey — Fri, 24 Apr 2026 12:20:16 +0000

You've got 3,000 lines of Terraform spread across 40 files, organized into modules, with variables referencing other variables referencing data sources. It works. It deploys. But can you actually see what it builds?

This is one of the most common challenges in infrastructure-as-code. The code is the source of truth, but it's not visual. You can't glance at a .tf file and immediately understand the architecture the way you can with a diagram.

Here are five practical approaches to visualize your Terraform infrastructure, ranked from simplest to most sophisticated.

1. terraform graph + Graphviz

Terraform has a built-in graph command that outputs a dependency graph in DOT format. You can pipe it through Graphviz to generate a visual diagram.

terraform graph | dot -Tpng > graph.png

This is the quickest approach — one command, no external tools needed (besides Graphviz). It shows every resource and its dependencies, which is useful for understanding execution order.

The problem is readability. For any real-world infrastructure, the output is a massive, tangled web of nodes and arrows. A typical production setup with 50+ resources generates a graph that's essentially unreadable. It includes internal Terraform resources (providers, data sources, variables) that add noise without adding understanding.

Terraform graph is useful for debugging dependency issues — "why is this resource waiting for that one?" — but it's not suitable for architecture documentation.

2. Terraform Visual (VS Code extension)

If you use VS Code, the Terraform Visual extension renders a visual graph of your Terraform resources directly in your editor. It reads your .tf files and generates an interactive diagram that you can zoom, pan, and click on.

The advantage over terraform graph is that it filters out noise and only shows the resources you care about. It also updates in real-time as you edit your code, which is useful during development.

The limitation is that it's tied to VS Code. You can't easily share the output with someone who uses a different editor, and the diagrams aren't suitable for documentation or presentations.

3. Python Diagrams library

The diagrams library for Python lets you define architecture diagrams programmatically. While it doesn't read Terraform files directly, you can write a Python script that mirrors your Terraform architecture.

from diagrams import Diagram, Cluster
from diagrams.aws.compute import EKS
from diagrams.aws.database import RDS, ElastiCache
from diagrams.aws.network import ELB, Route53

with Diagram("Production Architecture", show=False):
dns = Route53("Route 53")
lb = ELB("ALB")

with Cluster("EKS Cluster"):
services = [EKS("api"),
EKS("worker"),
EKS("scheduler")]

db = RDS("PostgreSQL")
cache = ElastiCache("Redis")

dns >> lb >> services
services >> db
services >> cache

This produces clean, professional diagrams with official AWS icons. The Python code can be committed alongside your Terraform code and updated in the same PR. It's a good approach for teams that want version-controlled diagrams.

The downside is duplication — you're maintaining two representations of the same infrastructure (Terraform and Python). When someone adds a new resource in Terraform but forgets to update the diagram code, they drift apart.

4. Paste your code into InfraSketch

This is the approach I built InfraSketch for. Instead of writing separate diagram code, you paste your existing Terraform HCL and the tool generates the architecture diagram automatically.

# Just paste this into InfraSketch:
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}

resource "aws_eks_cluster" "app" {
name = "production"
vpc_config {
subnet_ids = [aws_subnet.private.id]
}
}

resource "aws_rds_cluster" "db" {
cluster_identifier = "app-db"
engine = "aurora-postgresql"
}

# InfraSketch parses this and generates a
# grouped diagram with AWS icons automatically

The tool parses resource types, detects references between resources, groups them by category (networking, compute, database, etc.), and renders a diagram with official AWS architecture icons. Everything runs in the browser — your code never leaves your machine.

This works well for quick visualization — "let me see what this Terraform actually creates" — and for generating diagrams to include in documentation or README files. The limitation is that it does static analysis only (it doesn't run terraform plan), so it may miss resources created by complex expressions or external modules.

5. Rover (Terraform Visualizer)

Rover is an open-source tool that reads Terraform state files or plan output and generates interactive diagrams. Unlike InfraSketch which does static analysis of HCL code, Rover works with the actual state — meaning it shows exactly what's deployed, including resources created by modules and count/for_each expressions.

# Generate a plan
terraform plan -out=plan.out

# Visualize it
rover -planPath plan.out

Rover produces an interactive web-based diagram that you can zoom, filter, and search. It's more accurate than static analysis because it uses the resolved state, but it requires you to have Terraform initialized and access to the state file.

Which approach should you use?

It depends on what you're trying to accomplish.

If you need a quick visualization while developing, use InfraSketch or the VS Code extension. Paste your code, see the diagram, iterate.

If you need accurate diagrams of what's actually deployed, use Rover with your state file. It's the most accurate because it works with resolved state rather than source code.

If you need presentation-ready diagrams that are version-controlled, use the Python Diagrams library. It takes more effort but produces the most polished output.

If you need to debug dependency chains, terraform graph is still the right tool despite its messy output.

The best approach for most teams is to combine methods: use InfraSketch or Rover for day-to-day visualization, and the Python Diagrams library for documentation that needs to look polished.

Visualize your Terraform instantly Paste your Terraform HCL and see the architecture diagram in seconds. Now with an interactive drag-and-drop editor, GCP support, and more. Open InfraSketch

How to Create AWS Architecture Diagrams in 2026: A Complete Guide

Raghvendra Pandey — Fri, 24 Apr 2026 12:19:45 +0000

Architecture diagrams are one of those things every team needs but nobody wants to maintain. You spend an hour in draw.io moving boxes around, and by the time you share it, someone has already changed the infrastructure.

After 9 years of building cloud infrastructure, I've tried every method — from whiteboards to $500/month enterprise tools. Here's a practical breakdown of every approach available in 2026, with honest pros and cons for each.

Why architecture diagrams matter

Before diving into tools, it's worth understanding why diagrams are worth the effort. They serve three critical purposes in any engineering team.

First, they accelerate onboarding. A new team member looking at 50 Terraform files has no idea how things connect. A diagram gives them the mental model in 30 seconds that would otherwise take days of reading code.

Second, they improve incident response. When something breaks at 3 AM, you need to quickly understand which services are affected. A clear architecture diagram shows blast radius instantly — which services talk to the broken database, which load balancer routes to the failing service.

Third, they enable architecture reviews. Whether you're pitching a migration to your CTO or doing a well-architected review, diagrams make the conversation concrete rather than abstract.

Method 1: Manual drawing tools

The traditional approach. Open a tool, drag boxes, draw arrows, label everything by hand.

Draw.io (diagrams.net) — Free

Draw.io is the most popular free option and for good reason. It has built-in AWS icon libraries, works in the browser, exports to PNG/SVG/PDF, and integrates with Confluence and Google Drive. For one-off diagrams that don't need frequent updates, it's hard to beat.

The downside is entirely about maintenance. The moment your infrastructure changes — a new subnet, a renamed service, an additional database — your diagram is out of date. Someone has to manually update it, and that someone is usually nobody.

Lucidchart — $7.95+/month

Lucidchart adds real-time collaboration on top of Draw.io's feature set. Multiple people can edit the same diagram simultaneously, which is useful for architecture review sessions. It also has better auto-layout and alignment tools.

The problem is the same as Draw.io — it's still manual. You're paying $8-15/month per user for a tool that produces diagrams that go stale immediately.

When to use manual tools

Manual tools work well for conceptual or aspirational diagrams — showing what you plan to build, not what currently exists. They're also good for presentations where you need a specific visual style or narrative flow that automated tools can't produce.

Method 2: Live cloud scanners

These tools connect to your actual AWS/Azure/GCP account and generate diagrams from live infrastructure.

Cloudcraft — $49+/month

Cloudcraft (now owned by Datadog) scans your AWS account and generates both 2D and 3D architecture diagrams. The 3D isometric view looks impressive in presentations. It also includes cost estimation — hover over any resource to see its monthly cost.

The catch: you need to give it read access to your cloud account. For many organizations, this is a non-starter — security teams don't want a third-party service scanning production infrastructure. It's also expensive at $49/month for individual use and more for teams.

Hava.io — $49+/month

Hava takes a similar approach but adds change tracking — it records every infrastructure change and lets you view historical diagrams. This is genuinely useful for debugging "what changed?" during an incident. It supports AWS, Azure, and GCP.

AWS Workload Discovery — Free (self-hosted)

Amazon's own solution, deployed as a CloudFormation stack in your account. It scans your resources and generates interactive diagrams. Being first-party, it avoids the credential-sharing concern. However, it only works for AWS (no multi-cloud), requires significant setup, and the diagrams aren't as polished as commercial tools.

When to use cloud scanners

Cloud scanners are ideal for large organizations with complex, frequently changing infrastructure where manual diagramming is impossible. They're also useful for cloud cost audits and compliance documentation. But they're overkill for small teams or individual developers.

Method 3: Diagram-as-code

Write code that generates diagrams. The diagram lives alongside your infrastructure code and can be version-controlled.

Python Diagrams library

The diagrams Python library lets you define architecture diagrams in Python code. It uses the official AWS/GCP/Azure icons and generates clean PNG output.

from diagrams import Diagram, Cluster
from diagrams.aws.compute import EKS
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB

with Diagram("Production", show=False):
lb = ELB("ALB")
with Cluster("EKS Cluster"):
svc = EKS("app")
db = RDS("postgres")
lb >> svc >> db

This approach is popular because diagrams can be committed to Git, reviewed in PRs, and updated alongside infrastructure changes. The downside is that you're still manually defining the diagram — it doesn't read your Terraform code automatically.

Mermaid.js

Mermaid uses a markdown-like syntax to define diagrams. It's built into GitHub (renders in README files), Notion, and many documentation tools. It's great for simple flowcharts and sequence diagrams, but it doesn't support AWS icons natively and the layout engine can produce awkward results for complex architectures.

When to use diagram-as-code

Diagram-as-code works well for teams that want version-controlled diagrams that evolve with the codebase. It's a good middle ground between manual tools and automated scanners. The trade-off is that someone still needs to write and maintain the diagram code.

Method 4: Generate from IaC (Infrastructure as Code)

This is the newest approach — tools that read your existing Terraform, CloudFormation, or Docker Compose files and automatically generate architecture diagrams. No manual drawing, no cloud credentials, no separate diagram code to maintain.

InfraSketch — Free, open source

Full disclosure: I built InfraSketch. It takes a different approach from all the tools above — you paste your Terraform HCL or Docker Compose YAML, and it generates an architecture diagram instantly in your browser. No signup, no cloud credentials, no server-side processing.

It parses 25+ AWS resource types, detects relationships between them, groups resources by category (networking, compute, database, storage, load balancing), and renders diagrams with official AWS architecture icons. You can export as PNG or SVG.

The advantage is simplicity and privacy. Your code never leaves your browser. The limitation is that it currently only supports AWS resources and the parser may not catch every edge case in complex Terraform configurations.

terraform graph

Terraform has a built-in terraform graph command that outputs a dependency graph in DOT format. You can pipe it through Graphviz to generate a visual diagram. It's technically accurate but produces overwhelming, unreadable graphs for any real-world infrastructure. It shows every single resource and dependency, including internal Terraform resources that aren't meaningful to humans.

Comparison summary

Method	Cost	Auto-updates	Credentials needed	Best for
Draw.io	Free	No	No	One-off diagrams
Lucidchart	$8+/mo	No	No	Team collaboration
Cloudcraft	$49+/mo	Yes	Yes	Enterprise documentation
Hava.io	$49+/mo	Yes	Yes	Change tracking
Python Diagrams	Free	Semi	No	Version-controlled docs
InfraSketch	Free	From code	No	Quick diagrams from IaC

My recommendation

There's no single best tool — it depends on your situation. If you're a solo developer or small team, start with InfraSketch for quick diagrams from your existing Terraform code, and use Draw.io when you need a custom presentation-ready diagram. If you're at a large organization with complex multi-account infrastructure, a cloud scanner like Cloudcraft or Hava pays for itself in time saved.

The key insight is this: the best diagram is one that actually exists. A rough, auto-generated diagram that's always up-to-date is infinitely more valuable than a beautiful hand-drawn diagram from six months ago that no longer matches reality.

Try InfraSketch Paste your Terraform code and get an architecture diagram in seconds. Now with an interactive editor, GCP support, and more. Free, no signup required. Generate a Diagram

Free vs Paid Cloud Architecture Diagram Tools — Honest Comparison 2026

Raghvendra Pandey — Fri, 24 Apr 2026 12:19:44 +0000

Cloudcraft charges $49 per month. Draw.io costs nothing. InfraSketch generates diagrams from your existing code for free. Are the paid tools actually worth the money, or are you paying for features you don't need?

I've used all of these tools in production environments over the past few years. Here's an honest breakdown — no affiliate links, no sponsored content, just what actually works and what doesn't.

The quick comparison

Tool	Price	Input method	AWS icons	Needs credentials	Real-time sync
Draw.io	Free	Manual drag & drop	Yes	No	No
InfraSketch	Free	Paste Terraform/Compose	Yes (official)	No	From code
Cloudcraft	$49+/mo	Live AWS scan	Yes (custom 3D)	Yes	Yes
Hava.io	$49+/mo	Live cloud scan	Yes	Yes	Yes + history
Lucidchart	$8+/mo	Manual + import	Yes	Optional	No
Lucidscale	Enterprise	Live cloud scan	Yes	Yes	Yes

Free tools: what you get and what you don't

Draw.io (diagrams.net)

Draw.io is the workhorse of architecture diagrams. It's completely free, runs in the browser, has a comprehensive AWS icon library, and exports to every format imaginable. It integrates with Google Drive, Confluence, and GitHub.

The experience is essentially like a simplified Visio. You drag resources onto a canvas, draw connections between them, and arrange everything manually. For a simple 10-resource diagram, this takes about 15-20 minutes. For a complex production environment with 50+ resources across multiple VPCs, you're looking at an hour or more.

The real cost of Draw.io isn't money — it's maintenance. Every time your infrastructure changes, someone needs to manually update the diagram. In my experience, diagrams in Draw.io go stale within a week of being created. Nobody wants to be the person who maintains them.

InfraSketch

InfraSketch takes a fundamentally different approach. Instead of manually drawing diagrams, you paste your Terraform HCL or Docker Compose YAML and the diagram is generated automatically. It parses resource types, detects relationships, and renders grouped diagrams with official AWS icons.

The advantage is speed and accuracy. Generating a diagram from 50 resources takes about 2 seconds — not an hour. And because it reads your actual code, the diagram always matches what's deployed (assuming your code matches your state).

The trade-off is flexibility. You can't customize the layout, add annotations, or include non-AWS resources. If you need a presentation-ready diagram with custom callouts and explanations, you'll still need a manual tool for the finishing touches.

Paid tools: when they're worth it

Cloudcraft ($49/month)

Cloudcraft's unique selling point is the 3D isometric view. It looks genuinely impressive in presentations and reports. Beyond aesthetics, Cloudcraft connects to your AWS account and scans live infrastructure, so diagrams are always accurate.

It also includes cost estimation — every resource in the diagram shows its monthly cost, which is useful for FinOps conversations and cost reviews.

Cloudcraft is worth the money if you regularly present architecture to non-technical stakeholders (executives, clients, investors) where the visual quality matters, or if you need cost estimation integrated into your diagrams. For day-to-day engineering documentation, it's overpriced.

Hava.io ($49/month)

Hava's differentiator is change tracking. It scans your cloud accounts periodically and records every change — new resources, deleted resources, configuration changes. You can view what your architecture looked like at any point in the past.

This is genuinely valuable during incident response. "What changed in the last 24 hours?" is a question that's hard to answer with other tools. Hava gives you a visual diff instantly.

Hava is worth the money for teams with complex, frequently changing infrastructure where change visibility is critical — especially in regulated industries where you need audit trails.

Lucidchart ($8-15/month)

Lucidchart is Draw.io with collaboration features. Multiple people can edit the same diagram simultaneously, there are better templates and auto-alignment tools, and it integrates with more business tools (Slack, Teams, Jira).

It's worth the money for teams that need to collaborate on diagrams in real-time — for example, during architecture review meetings where multiple engineers need to draw on the same canvas. For solo work, Draw.io does the same thing for free.

The real question: do you need a diagram tool at all?

Here's the uncomfortable truth: if you're writing infrastructure as code (Terraform, CloudFormation, Pulumi), your code IS your architecture documentation. The question is whether you need a visual representation on top of it.

For small teams (under 10 engineers) who all work with the same codebase, you might not. Everyone can read the Terraform and understand the architecture. A quick InfraSketch diagram for README files and onboarding docs might be all you need.

For larger teams, especially those with non-technical stakeholders, visual diagrams become essential. Executives and clients can't read Terraform. They need pictures. In that case, a combination of InfraSketch for quick engineering-level diagrams and Cloudcraft or manual tools for presentation-ready visuals is the sweet spot.

My recommendation by team size

For solo developers or very small teams: use InfraSketch for quick visualization from your Terraform code, and Draw.io when you need a custom diagram for a presentation. Total cost: $0.

For mid-size teams (10-50 engineers): add Lucidchart for collaborative diagramming during architecture reviews. Use InfraSketch for day-to-day visualization. Total cost: $8-15/month.

For large organizations (50+ engineers): invest in Cloudcraft or Hava for automated, always-current diagrams of production infrastructure. Use InfraSketch for development-time visualization. Total cost: $49-100/month.

The key principle: don't pay for features you won't use. If you're a solo developer paying $49/month for Cloudcraft to generate one diagram, you're wasting money. Start free, upgrade when you hit actual limitations.

Start with InfraSketch — it's free Generate architecture diagrams from your Terraform code in seconds. Now with an interactive editor and GCP support. No signup, no credentials. Try InfraSketch

How to Visualize Your Docker Compose Setup (With Examples)

Raghvendra Pandey — Fri, 24 Apr 2026 12:14:31 +0000

Docker Compose files start simple — a web server, a database, maybe a cache. Then requirements grow. You add a message queue, a worker service, a monitoring stack, a reverse proxy. Before you know it, your docker-compose.yml is 200 lines long and nobody on the team can explain how all the services connect.

This article covers practical ways to visualize your Docker Compose setup so you can understand, document, and communicate your container architecture.

Why visualize Docker Compose?

A docker-compose.yml file defines services, networks, volumes, and dependencies — but it does so in a flat YAML structure that doesn't visually convey how things connect. When someone new joins the team and asks "how do these containers talk to each other?", reading 200 lines of YAML isn't the answer.

Diagrams help in three specific situations. During onboarding, a new developer can look at a diagram and understand the service topology in 30 seconds. During debugging, when a service can't connect to another, a diagram shows you which network they're on and what sits between them. During architecture reviews, when you're discussing whether to split a monolith service or add a new dependency, a visual representation makes the conversation concrete.

Example: a typical web application

Let's start with a real-world example — a web application with a React frontend, a Python API, PostgreSQL, Redis, and Nginx as a reverse proxy.

version: "3.8"
services:
nginx:
image: nginx:alpine
ports:
- "80:80"
depends_on:
- frontend
- api

frontend:
build: ./frontend
depends_on:
- api

api:
build: ./api
depends_on:
- postgres
- redis
environment:
DATABASE_URL: postgresql://app:secret@postgres/appdb

postgres:
image: postgres:16
volumes:
- pgdata:/var/lib/postgresql/data

redis:
image: redis:7-alpine

worker:
build: ./worker
depends_on:
- redis
- postgres

volumes:
pgdata:

Reading this YAML, you can piece together the architecture — Nginx sits in front of everything, the frontend talks to the API, the API uses PostgreSQL and Redis, and a worker also connects to both data stores. But it takes a few minutes of careful reading to build that mental model.

Method 1: Use InfraSketch

The quickest approach is to paste your Docker Compose YAML directly into InfraSketch. Select the "Docker Compose" tab, paste your YAML, and click "Generate Diagram." The tool parses service definitions and generates a visual diagram showing each container and its connections.

This takes about 5 seconds and gives you a diagram you can export as PNG or SVG for your project README or documentation. The current version detects services from the YAML structure and shows them as container nodes.

Method 2: docker-compose-viz

The docker-compose-viz tool is a CLI that reads your compose file and generates a graph using Graphviz. It's available as a Docker container itself, which is convenient.

docker run --rm -it \
--name dcv \
-v $(pwd):/input:ro \
pmsipilot/docker-compose-viz \
render -m image docker-compose.yml

This produces a dependency graph showing which services depend on which. It's more detailed than a simple service list because it visualizes the depends_on relationships, links, and shared networks.

The output is functional but not pretty — it uses default Graphviz styling, which means tiny text and cramped layouts for complex setups. For a quick check of your dependency chain, it works. For documentation, you'll want something more polished.

Method 3: Mermaid.js in your README

If you want a diagram that lives in your README and renders automatically on GitHub, Mermaid is a great option. You define the diagram using a simple text syntax that GitHub renders as an image.

mermaid
graph TB
Client[Browser] --> Nginx
Nginx --> Frontend[React App]
Nginx --> API[Python API]
API --> Postgres[(PostgreSQL)]
API --> Redis[(Redis)]
Worker --> Postgres
Worker --> Redis

This renders as a clean flowchart directly in your GitHub README. The advantage is that the diagram is version-controlled alongside your code. When you add a new service, you update the Mermaid block in the same PR.

The limitation is manual maintenance — you need to keep the Mermaid diagram in sync with your actual docker-compose.yml. It's also limited to simple box-and-arrow diagrams without service-specific icons.

Method 4: Draw it manually (when you need polish)

For presentations, documentation sites, or client deliverables, sometimes you need a hand-crafted diagram. Tools like Draw.io, Excalidraw, or Figma give you full control over layout, styling, and annotations.

The key to making manual Docker diagrams useful is to include the right details: service names, exposed ports, volume mounts, and network boundaries. A diagram that just shows boxes with service names isn't much more useful than reading the YAML. A diagram that shows "Nginx (port 80) routes /api/* to API service (port 8000) on backend network" tells a real story.

Best practices for container architecture diagrams

Regardless of which tool you use, effective Docker Compose diagrams share a few characteristics.

First, show network boundaries. If your compose file defines multiple networks (frontend, backend, monitoring), group services by network. This immediately clarifies which services can communicate with each other.

Second, indicate data persistence. Services with volumes are stateful — they hold data that matters. Highlight databases and any service with persistent volumes differently from stateless application containers.

Third, show external access points. Which ports are exposed to the host? Which services are accessible from outside? This is critical for security reviews and debugging network issues.

Fourth, label the connections. Don't just draw arrows — label them with protocol and port. "HTTP :8000" is more useful than a plain line between two boxes.

Keep it simple

The best Docker Compose diagram is one that actually gets created and maintained. A rough auto-generated diagram that you update by re-running a tool is infinitely more valuable than a beautiful hand-drawn diagram from three months ago that no longer reflects reality.

Start with InfraSketch or Mermaid for a quick visualization. If you need more polish, refine it manually. The goal is understanding, not art.

Visualize your Docker Compose Paste your docker-compose.yml and see your container architecture instantly. Now with an interactive drag-and-drop editor. Open InfraSketch

AWS VPC Architecture Explained with Diagrams — From Simple to Production

Raghvendra Pandey — Fri, 24 Apr 2026 12:14:27 +0000

Every AWS architecture starts with a VPC. Whether you're deploying a single EC2 instance or a fleet of microservices on EKS, the network foundation determines your security posture, availability, and cost. Yet VPC networking is one of the most commonly misunderstood parts of AWS.

This guide walks through four VPC architecture patterns, from simplest to production-grade, with Terraform code for each. You can paste any of these into InfraSketch to see the architecture diagram.

Pattern 1: Single public subnet (development only)

The simplest possible setup — one VPC, one public subnet, one internet gateway. Every resource gets a public IP and is directly accessible from the internet.

resource "aws_vpc" "dev" {
cidr_block           = "10.0.0.0/16"
enable_dns_hostnames = true
tags = { Name = "dev-vpc" }
}

resource "aws_internet_gateway" "dev" {
vpc_id = aws_vpc.dev.id
}

resource "aws_subnet" "public" {
vpc_id                  = aws_vpc.dev.id
cidr_block              = "10.0.1.0/24"
availability_zone       = "ap-south-1a"
map_public_ip_on_launch = true
tags = { Name = "public-subnet" }
}

resource "aws_instance" "app" {
ami           = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
subnet_id     = aws_subnet.public.id
tags = { Name = "app-server" }
}

This pattern works for development environments, quick prototypes, and personal projects where you need something running fast without worrying about network security. Everything is on a public subnet, which means every resource is exposed to the internet.

Never use this pattern in production. Databases, application servers, and internal services should never be on public subnets. It's like putting your house keys under the doormat — technically works, but invites trouble.

Pattern 2: Public + private subnets with NAT

The standard two-tier architecture. Public subnets host load balancers and bastion hosts. Private subnets host application servers and databases. A NAT Gateway allows private resources to access the internet (for updates, API calls) without being directly accessible.

resource "aws_vpc" "main" {
cidr_block           = "10.0.0.0/16"
enable_dns_hostnames = true
tags = { Name = "main-vpc" }
}

resource "aws_internet_gateway" "main" {
vpc_id = aws_vpc.main.id
}

resource "aws_subnet" "public" {
vpc_id                  = aws_vpc.main.id
cidr_block              = "10.0.1.0/24"
availability_zone       = "ap-south-1a"
map_public_ip_on_launch = true
tags = { Name = "public-subnet" }
}

resource "aws_subnet" "private" {
vpc_id            = aws_vpc.main.id
cidr_block        = "10.0.10.0/24"
availability_zone = "ap-south-1a"
tags = { Name = "private-subnet" }
}

resource "aws_eip" "nat" {
domain = "vpc"
}

resource "aws_nat_gateway" "main" {
allocation_id = aws_eip.nat.id
subnet_id     = aws_subnet.public.id
tags = { Name = "main-nat" }
}

resource "aws_lb" "app" {
name               = "app-alb"
internal           = false
load_balancer_type = "application"
subnets            = [aws_subnet.public.id]
}

resource "aws_instance" "app" {
ami           = "ami-0c55b159cbfafe1f0"
instance_type = "t3.medium"
subnet_id     = aws_subnet.private.id
tags = { Name = "app-server" }
}

resource "aws_db_instance" "main" {
identifier     = "app-db"
engine         = "postgres"
instance_class = "db.t3.medium"
tags = { Name = "app-database" }
}

This is the most common VPC pattern and works well for small to medium applications. The ALB in the public subnet handles incoming traffic and forwards it to application servers in the private subnet. The database sits in the private subnet with no public access.

The NAT Gateway costs around $32/month (in ap-south-1) plus data transfer charges. For development environments where you want to save money, you can use a NAT Instance (a small EC2 instance configured as a NAT) instead, though it's less reliable.

Pattern 3: Multi-AZ for high availability

Pattern 2 has a single point of failure — everything is in one Availability Zone. If that AZ goes down (and they do, occasionally), your entire application is offline. Production workloads need multi-AZ redundancy.

resource "aws_vpc" "prod" {
cidr_block           = "10.0.0.0/16"
enable_dns_hostnames = true
tags = { Name = "prod-vpc" }
}

resource "aws_internet_gateway" "prod" {
vpc_id = aws_vpc.prod.id
}

# Public subnets in two AZs
resource "aws_subnet" "public_1" {
vpc_id            = aws_vpc.prod.id
cidr_block        = "10.0.1.0/24"
availability_zone = "ap-south-1a"
map_public_ip_on_launch = true
tags = { Name = "public-1a" }
}

resource "aws_subnet" "public_2" {
vpc_id            = aws_vpc.prod.id
cidr_block        = "10.0.2.0/24"
availability_zone = "ap-south-1b"
map_public_ip_on_launch = true
tags = { Name = "public-1b" }
}

# Private subnets in two AZs
resource "aws_subnet" "private_1" {
vpc_id            = aws_vpc.prod.id
cidr_block        = "10.0.10.0/24"
availability_zone = "ap-south-1a"
tags = { Name = "private-1a" }
}

resource "aws_subnet" "private_2" {
vpc_id            = aws_vpc.prod.id
cidr_block        = "10.0.11.0/24"
availability_zone = "ap-south-1b"
tags = { Name = "private-1b" }
}

# NAT Gateways - one per AZ for redundancy
resource "aws_eip" "nat_1" { domain = "vpc" }
resource "aws_eip" "nat_2" { domain = "vpc" }

resource "aws_nat_gateway" "az1" {
allocation_id = aws_eip.nat_1.id
subnet_id     = aws_subnet.public_1.id
}

resource "aws_nat_gateway" "az2" {
allocation_id = aws_eip.nat_2.id
subnet_id     = aws_subnet.public_2.id
}

# ALB spans both public subnets
resource "aws_lb" "prod" {
name               = "prod-alb"
internal           = false
load_balancer_type = "application"
subnets            = [aws_subnet.public_1.id, aws_subnet.public_2.id]
}

# EKS cluster spans both private subnets
resource "aws_eks_cluster" "prod" {
name     = "prod-cluster"
role_arn = aws_iam_role.eks.arn
vpc_config {
subnet_ids = [aws_subnet.private_1.id, aws_subnet.private_2.id]
}
}

resource "aws_iam_role" "eks" {
name = "eks-cluster-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "eks.amazonaws.com" }
}]
})
}

# RDS with Multi-AZ enabled
resource "aws_db_instance" "prod" {
identifier     = "prod-db"
engine         = "postgres"
instance_class = "db.r5.large"
multi_az       = true
}

This pattern duplicates subnets and NAT Gateways across two Availability Zones. The ALB automatically distributes traffic across both AZs. EKS schedules pods across both private subnets. RDS Multi-AZ maintains a standby replica in the second AZ.

The cost increase from Pattern 2 is primarily the second NAT Gateway (~$32/month) and the additional EKS/RDS capacity in the second AZ. For production workloads, this cost is negligible compared to the downtime risk of a single-AZ deployment.

Paste any of these Terraform snippets into InfraSketch to see the architecture diagram generated automatically. You can visually verify your VPC layout matches your intent.

Pattern 4: Production-grade with security layers

The complete production pattern adds security groups, VPC endpoints, CloudFront CDN, and a WAF layer. This is what a well-architected AWS deployment actually looks like.

The full Terraform for this pattern is extensive — typically 500+ lines. The key additions beyond Pattern 3 are security groups with least-privilege rules for each service tier, VPC endpoints for S3 and ECR to keep traffic within the AWS network and reduce NAT costs, a CloudFront distribution in front of the ALB for caching and DDoS protection, a WAF (Web Application Firewall) attached to CloudFront or the ALB for Layer 7 filtering, and VPC Flow Logs sent to CloudWatch for network monitoring and incident investigation.

Each of these additions addresses a specific security or operational concern. Security groups control which services can communicate with each other — the database should only accept connections from the application tier, not from the entire VPC. VPC endpoints eliminate the need for traffic to S3 and ECR to traverse the public internet through the NAT Gateway, which both improves security and reduces NAT data transfer costs.

Common VPC mistakes to avoid

After managing VPCs for dozens of production workloads, these are the mistakes I see most often.

The first is using too-small CIDR blocks. A /24 VPC gives you 256 IPs, which sounds like plenty until you realize subnets, load balancers, and EKS each consume IPs. Start with a /16 (65,536 IPs) for production VPCs. You can always use smaller subnets within it.

The second is putting databases on public subnets. It happens more often than you'd think, usually because someone copied a tutorial that took shortcuts. Databases should always be on private subnets with security groups that only allow connections from the application tier.

The third is using a single NAT Gateway for production. NAT Gateways are zonal — if the AZ goes down, all private subnet internet access in that AZ is lost. Always use one NAT Gateway per AZ in production.

The fourth is overlapping CIDR blocks with other VPCs or on-premises networks. If you ever need VPC peering or a VPN connection, overlapping CIDRs will prevent it. Plan your IP addressing scheme across all environments before you deploy anything.

Visualize your VPC

Understanding your VPC architecture is much easier with a diagram. Take any of the Terraform snippets above, paste them into InfraSketch, and you'll see the resources grouped by category — networking resources (VPC, subnets, IGW, NAT) in one group, compute (EKS, EC2) in another, databases (RDS) in a third.

This visual grouping makes it immediately obvious whether your architecture follows the patterns described here — are databases in private subnets? Is there a NAT Gateway in each AZ? Is the ALB spanning multiple public subnets? A quick diagram answers these questions faster than reading through Terraform files.

See your VPC architecture Paste your VPC Terraform code and visualize the network architecture instantly. InfraSketch now supports Route Tables, Transit Gateways, and VPN Gateways — see what's new. Generate VPC Diagram

What's New in InfraSketch — April 2026: Interactive Editor, GCP Support & More

Raghvendra Pandey — Fri, 24 Apr 2026 00:04:37 +0000

This is a big update. We shipped an interactive drag-and-drop diagram editor, full GCP support across 23 resource types, new AWS networking resources that were previously missing from diagrams, a data zone visualization, and a round of UI polish across the board. Here's everything that changed.

Interactive Diagram Editor

The most requested feature since launch. After generating a diagram, click Edit in the toolbar to enter interactive mode. In edit mode you can drag any node to reposition it — connection arrows update live as you drag, following both endpoints in real time.

When you're happy with the layout, click Done to lock it in. If you want to go back to the auto-generated layout at any point, click Reset Layout. The original positions are always preserved.

A few technical details worth knowing:

Dragging works correctly at any zoom level — the coordinate math accounts for the current zoom scale and pan offset, so nodes land exactly where you drop them regardless of how zoomed in or out you are.
Clicking the diagram background deselects the current node.
In edit mode, pan is disabled on nodes (so you can drag them) but still works on empty canvas areas.
Exported PNG, SVG, and draw.io XML reflect your repositioned layout.

Try the editor Generate any diagram and click Edit in the toolbar to start repositioning nodes. Open InfraSketch

Full GCP Support

InfraSketch now supports 23 Google Cloud resource types across all major categories, with official Google Cloud category icons in every diagram.

Category	Terraform types
Networking	`google_compute_network`, `google_compute_subnetwork`, `google_compute_firewall`, `google_compute_router`, `google_compute_address`
Compute	`google_compute_instance`, `google_compute_instance_group`, `google_compute_autoscaler`, `google_container_cluster`, `google_container_node_pool`
Serverless	`google_cloud_run_service`, `google_cloud_run_v2_service`, `google_cloudfunctions_function`, `google_cloudfunctions2_function`
Data	`google_sql_database_instance`, `google_bigquery_dataset`, `google_spanner_instance`, `google_bigtable_instance`, `google_firestore_document`, `google_redis_instance`
Storage	`google_storage_bucket`
Security	`google_kms_key_ring`, `google_secret_manager_secret`, `google_service_account`
Messaging	`google_pubsub_topic`, `google_pubsub_subscription`
Observability	`google_monitoring_alert_policy`, `google_logging_metric`, `google_logging_project_sink`

GCP resources follow the same layout logic as AWS and Azure: VPC networks become containment boxes, subnets group their member resources, Pub/Sub lands in the Messaging zone, security resources cluster in the Security zone, and Load Balancer resources appear in the Ingress row.

To try it, select the Terraform tab, load the Production GCP stack example from the dropdown, and click Generate Diagram.

New AWS Networking Resources

Four resource types that commonly appear in real-world Terraform configs were previously silently dropped from diagrams. They're now fully supported:

Route Tables

aws_route_table, aws_route_table_association, aws_main_route_table_association — placed in the Internet zone alongside the IGW they route through.

Transit Gateway

aws_transit_gateway, aws_transit_gateway_attachment, aws_transit_gateway_vpc_attachment — the hub for multi-VPC and hybrid connectivity.

VPN Gateway

aws_vpn_gateway, aws_vpn_connection, aws_customer_gateway — for site-to-site VPN connections to on-premises networks.

Network Interfaces

aws_network_interface, aws_network_interface_attachment — explicit ENI definitions, common in appliance and multi-homed instance configs.

If you've been pasting real production Terraform configs and wondering why certain networking resources didn't appear — this is the fix.

Data Zone Visualization

Database and storage resources — RDS, DynamoDB, ElastiCache, S3, Cloud SQL, BigQuery, Azure SQL, and all the others — now render inside a labelled DATA zone box. Previously these resources appeared without any visual grouping, making it hard to distinguish the data tier from compute at a glance.

The zone uses the same dashed-border pattern as the existing Internet, Messaging, and Security zones, keeping the visual language consistent across the diagram.

Toast Notifications

Every error and confirmation in InfraSketch previously used the browser's built-in alert() dialog — a blocking modal that interrupts your flow and looks out of place in a dark-themed tool.

All nine of those alerts are now in-page toast notifications that appear at the bottom of the screen. They dismiss automatically after a few seconds, or immediately on click. Errors are red, successes are green, and informational messages are muted. Parse errors also give you specific guidance now — if you paste terraform plan text output instead of JSON, you'll see a message telling you to run terraform show -json instead of a generic "no resources found".

UI Polish

A set of smaller visual improvements that add up:

Generate button gradient — the flat green button is now a teal-to-blue gradient with a stronger glow on hover.
Node hover animation — hovering a resource node now scales it up slightly (scale(1.05)) with a green drop shadow, making the diagram feel interactive even in view mode.
Code editor focus indicator — a green left border appears when the editor textarea is focused, giving a clear active state.
Diagram panel accent border — the diagram panel now has a subtle green top border, visually distinguishing it from the editor panel.
Export toolbar separator — a thin vertical divider separates the Share/Edit buttons from the format export buttons (PNG, SVG, draw.io), reducing visual noise.
Edit button default state — the Edit button previously showed a permanent accent border even before any diagram existed. It now looks like any other export button and only lights up when edit mode is active.
Feature card hover — homepage feature cards now pick up a subtle green background tint on hover alongside the existing lift animation.

What's Next

A few things on the near-term roadmap:

Keyboard shortcuts — E for edit mode, R for reset layout, Escape to deselect.
Snap-to-grid in the editor — hold Shift while dragging to snap nodes to a 16px grid.
Multi-select — Shift-click to select multiple nodes and move them as a group.
GCP zone grouping — region and zone containment boxes for GCP, similar to how AWS diagrams show AZ grouping.
CloudFormation support — parsing .yaml CloudFormation stacks as a new input format.

If there's a specific resource type that's missing from your diagrams, or a workflow that doesn't work as expected, open an issue or send a note. Real-world Terraform configs are the best test cases we have.

Try everything in your browser No account, no install. Paste your Terraform, plan JSON, Terragrunt, or docker-compose.yml and generate a diagram in seconds. Open InfraSketch →

"I built a free tool to generate AWS & Azure architecture diagrams from Terraform — no signup needed"

Raghvendra Pandey — Sat, 18 Apr 2026 19:37:33 +0000

When someone asks "can you show me the architecture?",
most DevOps engineers groan internally.

Not because the architecture is complicated — because
drawing it is. You open draw.io, spend 45 minutes dragging
boxes, and by the time you share it, someone has already
changed the infrastructure.

Existing automated tools like Cloudcraft want $49/month
and read access to your AWS account. That's a non-starter
for most individual engineers and small teams.

So I built InfraSketch.

What it does

Paste your Terraform HCL or docker-compose.yml → get a
clean architecture diagram instantly.

Parses 25+ AWS resource types
Detects relationships between resources automatically
Groups by category (Networking, Compute, Database, Storage, Load Balancing, Messaging, Security)
Uses official AWS Architecture icons
Export as PNG, SVG, or draw.io file
100% client-side — your code never leaves your browser
No signup, no cloud credentials, completely free

How it works

The tool does static analysis of your HCL code using a
custom JavaScript parser. It extracts resource type and
name from each resource block, detects cross-references
between resources, groups them visually by category, and
renders the diagram as SVG with official AWS icons.

Everything runs in your browser. There is no backend server.

Try it with this example

Paste this into InfraSketch:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main.id
}

resource "aws_lb" "app" {
  name               = "app-alb"
  load_balancer_type = "application"
  subnets            = [aws_subnet.public.id]
}

resource "aws_eks_cluster" "main" {
  name     = "production"
  role_arn = aws_iam_role.eks.arn
  vpc_config {
    subnet_ids = [aws_subnet.public.id]
  }
}

resource "aws_iam_role" "eks" {
  name = "eks-role"
  assume_role_policy = jsonencode({})
}

resource "aws_db_instance" "db" {
  identifier     = "prod-db"
  engine         = "postgres"
  instance_class = "db.t3.medium"
}

resource "aws_s3_bucket" "assets" {
  bucket = "my-app-assets"
}

resource "aws_sqs_queue" "events" {
  name = "event-queue"
}

You'll see VPC, subnet, IGW, ALB, EKS, IAM, RDS, S3, and
SQS — all grouped, connected, and rendered with official
AWS icons.

The draw.io export

One feature people find particularly useful — after
generating the diagram you can export it as a draw.io file.
This means InfraSketch generates the base structure
automatically, then you open it in diagrams.net and
customize it for presentations or documentation. Best of
both worlds.

What's next

CloudFormation template support
Kubernetes manifest visualization
Azure and GCP resource icons
Terragrunt support (top community request already!)
Better connection routing and layout engine

DEV Community: Raghvendra Pandey

What's New in InfraSketch — May 2026: Pulumi & Kubernetes Support

Try the new formats now Click the Pulumi or Kubernetes tab and paste your code. Open InfraSketch →

Pulumi support — TypeScript & Python

New Pulumi tab

Kubernetes YAML support

New Kubernetes tab

Bug fixes

Fix Diagram display

What's next

Try Pulumi and Kubernetes diagrams now Free, no login, nothing leaves your browser. Open InfraSketch →

Pulumi Diagram Generator — Visualize Pulumi Infrastructure Instantly

Try it now Paste your Pulumi TypeScript or Python code and see the diagram instantly. Open InfraSketch →

Why Pulumi needs a diagram tool

How to use it

What gets visualized

VPC containment

Subnet placement

Connection arrows

Multi-cloud

Supported Pulumi resource types

TypeScript vs Python

Use cases

Pulumi vs Terraform diagrams

Generate your Pulumi diagram now Paste your index.ts or __main__.py into the Pulumi tab. Free, no login, nothing leaves your browser. Open InfraSketch →

Kubernetes Diagram Generator — Visualize K8s YAML Instantly

Try it now Paste your Kubernetes YAML manifests and see the diagram instantly. Open InfraSketch →

Why Kubernetes needs a diagram tool

How to use it

How connections are inferred

Ingress → Service

Service → Deployment

Deployment → ConfigMap/Secret

HPA → target

Supported Kubernetes resource kinds

Namespace grouping

Example: a typical web application

Use cases

Works with Helm and Kustomize output too

Generate your Kubernetes diagram now Paste your K8s manifests — or run kubectl get all -o yaml and paste. Free, no login, no cluster access needed. Open InfraSketch →

CDK Architecture Diagram Generator — Visualize AWS CDK Apps Instantly

Try it now Paste your cdk synth output and see the diagram instantly. Open InfraSketch →

Why CDK needs a diagram tool

How to get your CDK synth output

How it works under the hood

What gets visualized

VPC containment

Subnet placement

Connection arrows

Zone grouping

Supported CDK constructs (L1 / Cfn*)

Use cases

Works with CDK for Terraform too

Generate your CDK diagram now Run cdk synth | pbcopy, paste into the CDK tab, click Generate. Free, no login, nothing leaves your browser. Open InfraSketch →

CloudFormation Diagram Generator — Visualize AWS Templates Instantly

Try it now Paste your CloudFormation template and see the diagram instantly. Open InfraSketch →

Why CloudFormation support matters

How it works

Quick start

Example: a minimal web stack

Supported resource types

What gets inferred automatically

VPC containment

Subnet placement

ALB vs NLB

Connection arrows

Intrinsic functions supported

What's still Terraform-only

Use cases

Try CloudFormation diagrams now Paste your template and get a diagram in seconds. Free, no login, nothing leaves your browser. Open InfraSketch →

Terraform Visualization: 5 Ways to See What Your Code Actually Builds

1. terraform graph + Graphviz

2. Terraform Visual (VS Code extension)

3. Python Diagrams library

4. Paste your code into InfraSketch

5. Rover (Terraform Visualizer)

Which approach should you use?

Visualize your Terraform instantly Paste your Terraform HCL and see the architecture diagram in seconds. Now with an interactive drag-and-drop editor, GCP support, and more. Open InfraSketch

Related articles

How to Create AWS Architecture Diagrams in 2026: A Complete Guide

Generate your Pulumi diagram now Paste your `index.ts` or `main.py` into the Pulumi tab. Free, no login, nothing leaves your browser. Open InfraSketch →

Generate your Kubernetes diagram now Paste your K8s manifests — or run `kubectl get all -o yaml` and paste. Free, no login, no cluster access needed. Open InfraSketch →

Try it now Paste your `cdk synth` output and see the diagram instantly. Open InfraSketch →

Generate your CDK diagram now Run `cdk synth | pbcopy`, paste into the CDK tab, click Generate. Free, no login, nothing leaves your browser. Open InfraSketch →