High level diagrams

[dacacioa]

Is there a way to define the depth of the diagram detail? Currently, you have to specify for each resource type what type of things wants to exclude. When you have a large infrastructure, to manage exclusions is so complex.

One option to draw only resources types and relation between them could be great.

[ljacobsson]

Hi @dacacioa. Thanks for bringing this up. I've been thinking about solutions for this, but it's hard to know what people want to see in a simplified diagram.

One option to draw only resources types and relation between them could be great.
Can you elaborate on this?

I'm thinking of defining tags to resource types that automatically excludes noise like permissions, etc

[dacacioa]

Hi @ljacobsson, Thanks for your reply.

I'm thinking of defining tags to resource types that automatically excludes noise like permissions, etc

It can be a great solution, but the tag will be exported to the deployed infrastructure and may cause "noise". Another approach is to set an option to define what you want to include instead of defining what you want to exclude.

[gleclaire]

How about an input-file with run configurations.

I am current doing the following to filter some of my stacks:

cfn-dia d -o ./cdk.drawio --stacks $(cdk --profile sourcemain list 'dev*' | paste -sd ',' -) -c

or even having a depth option to control the depth

[tstibbs]

I think this would be a very useful feature. Tools like cloudformation designer generate diagrams containing every last resource (e.g. bucket policy, lambda permission etc) which don't really add anything to the diagram (except clutter). Such resources are usually implementation detail, or at best security or data architecture, and thus usually not helpful when trying to understand the overall (general) architecture of the solution.

A depth limit helps limit the noise, but of course there may be resources on level 2 that you want to hide but resources on level 4 that you want to show.

A separate exclusions list is useful, but there'll come a point where you spend a lot of time carefully curating your include/exclude lists, and that time might be better spent just maintaining a separate (non-generated) diagram.

@ljacobsson suggested using tags to define includes and excludes which I think is good because you're defining the include/exclude on the actual resource (not in a separate list) but also has another major advantage: you can specify things more than simply include/exclude. For example, most of my stacks have some kind of main 'entry point', usually an API gateway or similar. If I could tag that as "entry point" then that opens the possibility of the layout engine treating that node differently (e.g. making sure it appears at the edge of the diagram) which would be really useful for creating a high-level architecture diagram. One problem with this is that AWS doesn't allow many tags on a resource anyway, so perhaps taking up more just for diagramming might not be welcomed by most developers. You could probably solve this in CDK by having tags that were only added when you passed some "diagram mode" switch or something like that. Trickier when hand-writing raw cloudformation templates though (don't know if anyone still does that since CDK became generally available?).