[Veuxdo]

It is impossible to express all of the relevant information about an architecture in a single view. That's why a diagramming tool that natively supports multiple views/perspectives is a must-have. Anything less is just a toy, frankly.

[Supermancho]

> It is impossible to express all of the relevant information about an architecture in a single view.

Yet lots of people have been doing it, successfully, for decades with pen and paper (equivalent). I think you need to constrain your use case from "all architectures" to whatever it is you are trying to describe.

[jcims]

While I totally agree, I think we rely on people just making sense of the diagram based on context.

Say you're diagraming the architecture of the aforementioned app and you have your VPCs and your ELBs and compute and subnets and IGW and tidy little boxes containing them all to indicate this is everything in prod AWS account, us-west-1. Then you need to add an S3 bucket and dynamo db table. Most people would just drop a bucket icon outside of the VPC and label it...maybe dynamodb sits inside the region box and s3 kind of straddles it. Good enough conceptually to talk through the design.

Now imagine you want to automate the process of generating that view (or the associated resource graph) automatically. That's where it gets tricky. Tons of service-specific rules start to come into play. Kind of a mess.

[Veuxdo]

Furthermore, you have your security groups, roles, permissions, and policies. Plus you have build-time concerns (CF templates, CodeBuild builds, images, etc.). You simply cannot fit that into one view and have it make any kind of sense.

And those are just static relations. For interactions and data flows, you need sequence diagrams.

I wrote about this last month: https://blog.ilograph.com/posts/fixing-aws-architecure-diagr...

[jcims]

This is good stuff!!!