Technical Diagrams - Stop using cloud logos

Quick, what is this diagram trying to show?

An architecture diagram using AWS service logos. It intentionally does not use labels to force the reader to guess what the strangely colored logos are supposed to represent.

An architecture diagram using AWS service icons to describe services

I hope you know your AWS icons. There’s over 200 services and I have to guess frequently when playing the AWS Logo Quiz. While this diagram could easily add some descriptive labels to help, the icons assume developers can remember what the icon means. Some color-blind people may even struggle to see the difference in coloring that AWS uses for different types of services. These icons become visually cluttered and distract the viewer from what matters–your system.

Your design documents aren’t supposed to be AWS marketing material, they’re supposed to be refined, intuitive, and show how the parts fit together, not just show you can glue together these different services.

Compare that with the below diagram:

An architecture diagram showing a simple service using just solid color boxes and arrows instead of service logos. It still labels service names if relevant, for example using “Pending Work Topic (SNS)” to denote it’s an AWS SQS queue.

Here I use simple boxes and arrows to focus the viewer on the key parts that matter on each part. Service and component names become the primary focus with the service being a secondary detail on the label.

I also use colors and simple shading to signify which components are new, changing, or being removed in my projects. This helps to convey relative impact of projects to other engineers. Avoid using too many similar colors to ensure that color blind coworkers are still able to understand your diagrams.

Copyright - All Rights Reserved


Comments are currently unavailable while I move to this new blog platform. To give feedback, send an email to adam [at] this website url.