Agreed on the Visio comparison.
We've run into similar issues with clusters and security groups that span subnets/availability zones. In the end we decided on the following approach to keep auto-lay-out alive and commonly requires manual changes to insatnce lay-outs to capture the right set of instances in the AZ/ASG/SG/etc (the semi-transparent node alternative does not survive an auto-lay-out):
> We merge subnets and AZs as a single group, like web-az-1 and web-az-2 and web-az-1/2 for clusters
> Then we place single instances in web-az-1 and web-az-2, with an auto-scaling group encompassing both subnets and security groups encompassing auto-scaling groups
> Clusters we could depict the same way, but usually we depict those in the combined az subnet group like emr-az-1/2 as most clusters do not have an ELB to pint to each instance in each AZ. Without an ELB the split across two subnet/AZ groups will force edges to the cluster to be duplicated.
We then repeat the subnet/AZ group over and over again as necessary. I.e. multiple copies of the group within our diagram signifying the one single subnet/AZ combination in AWS.
You can of course choose any of the other groupings as your "redundant" version, but for us Subnet-AZ is the most stable one and the one with the least number of variations, thus the easiest to keep sane with redundancy.
Not ideal, but it keeps auto-formatting alive, which is why we use yEd in the first place.
Just started working towards extracting our AWS set-up using Python with boto3 and XLSXWriter to get it into yEd in a more automated manner. First goal VPC with Security Groups with their rules broken out as individual edges. Would love to know if you have anything going already. And we've been building out our palletes, maybe we can share? We're still trying to figure out how to best palletize groups (guess we'll have to start reading the manual soon :))