Read a diagram
A single plan describes far more than one picture can hold. Infragr.am draws it as four diagrams, called lenses. Each lens answers one question and leaves out what doesn’t help answer it.
Lenses
Section titled “Lenses”Network: how does traffic flow?
Section titled “Network: how does traffic flow?”Routing and connectivity: VPCs, subnets with their CIDRs, internet and NAT gateways, transit gateways, VPC endpoints, route tables, and load balancers with their listeners. Arrows follow routes, and WAF web ACLs are shown on the resources they protect. Subnets show a summary of their routes, for example 0.0.0.0/0 → IGW.
Compute: what runs where?
Section titled “Compute: what runs where?”EC2 instances, Auto Scaling groups, ECS services, EKS clusters and Lambda functions, placed in the subnets they run in. Auto Scaling groups show their desired, minimum and maximum size and instance type. Connections show load balancer targets, cluster membership, event triggers (such as a queue or stream invoking a Lambda), and access to other resources granted through security groups and IAM. VPCs and subnets are drawn lightly so the workloads stand out.
Data: where does data live, and who reaches it?
Section titled “Data: where does data live, and who reaches it?”Databases, caches, warehouses, search domains, object storage and file systems: RDS and Aurora, DynamoDB, ElastiCache, Redshift, DocumentDB, Neptune, MemoryDB, OpenSearch, S3, EFS, EBS and more. Each store is drawn with the workloads that access it, and encryption is marked on the stores that have it.
Security: what is the trust boundary?
Section titled “Security: what is the trust boundary?”Security groups, network ACLs, IAM, and WAF. You can see which security group is attached to what, and which rules permit traffic from where. Resources exposed to the public internet are highlighted. Other resources appear as light annotations, so the controls themselves are what you read first.
Every diagram is laid out in horizontal trust zones, from the most exposed at the top to the most protected at the bottom. A resource’s zone tells you how reachable it is before you read a single rule.
| Zone | What lands here |
|---|---|
| Perimeter | The internet itself, and global entry points in front of your network. |
| External DMZ | Services between the internet and your VPCs, outside any subnet. |
| Internal DMZ | Public subnets and what runs in them, such as internet-facing load balancers and NAT gateways. |
| Private | Private subnets and the workloads and data stores inside them. |
| Managed Services | Regional AWS services that live outside your VPCs, such as S3 and DynamoDB. |
Public or private?
Section titled “Public or private?”A subnet is public if either of these is true:
map_public_ip_on_launch = true, or- its route table sends
0.0.0.0/0to an internet gateway.
Otherwise it is private. The second rule matters for registry modules such as terraform-aws-modules/vpc. Those modules leave map_public_ip_on_launch off on their public subnets and make them public through routing alone.
A route to a NAT gateway doesn’t make a subnet public. Outbound internet access isn’t the same as being reachable from the internet.
Things worth knowing
Section titled “Things worth knowing”- Modules are flattened. Resources from child modules, including registry modules, are drawn alongside your own. Connections are followed across module boundaries and through
locals. - Resources spanning subnets appear in each. A load balancer or database subnet group in three subnets is drawn in all three, so every subnet shows what it hosts.
- Unsupported types are left out. Only supported resources are drawn. The rest of the plan still renders.
- Same plan, same picture. Rendering is deterministic, so a diagram only changes when the infrastructure does. That makes two builds easy to compare by eye.