See it as a diagram
Everything below, as a diagram you can edit. Describe yours and see it in seconds.
No account needed · Editable canvas, not a picture
One source, one release, per diagram
Version skew is the most visible defect in a cloud diagram and the easiest to avoid. AWS restyled its iconography between the flat generation and the current one, and the two do not sit together: the silhouettes differ, not just the colours. A diagram that mixes them announces that the marks came from image search.
Pick one release of one vendor pack per diagram, and record which one where the reader can find it, in a legend line or in the document beside the diagram. The release stamps make this concrete: AWS is on 07312026, Microsoft on Azure_Public_Service_Icons_V24. When a new release lands, update the whole diagram or none of it. For choosing between the vendor pack and a repackaged set, see official vs community cloud icon sets.
Draw containment as containment, not as arrows
Every cloud has a nesting idiom, and every cloud diagram that ignores it turns into the same picture: a dozen boxes all pointing at one box. On AWS, a region contains VPCs, a VPC contains subnets, subnets contain compute, and the icon pack ships group icons specifically so those layers can be drawn as containers. On Azure, everything belongs to a resource group, so a resource group reference is a containment fact and never a flow. On Google Cloud, the project boundary comes first for the same reason.
Arrows should be reserved for things that move: requests, events, files, rows. When containment goes into the container and flow goes into the arrows, a reader can answer "where does this live" and "what talks to what" as two separate questions, which is the whole job of the diagram.
The same discipline applies to identity. Roles, policies, grants and access assignments are wiring, not architecture. On a real AWS or Azure estate they outnumber the infrastructure they secure, and drawing them as boxes buries the platform. Count them in a note.
Label everything, and label the edges too
Microsoft asks for the product name near the icon in its Azure guidance, and the rule earns its place on all three clouds. An icon is a recognition shortcut for readers who already know the service; the label is what makes the diagram correct for everyone else. Put it directly under the icon and spell out the product name rather than the internal abbreviation.
Then label the edges. An arrow with no text says "these two things are related", which the reader already assumed. An arrow reading "parquet, hourly" or "gRPC, synchronous" answers the question they actually had. Labelled edges are the single highest-value thing you can add to a cloud diagram that already has correct icons.
Where the diagram is about data rather than services, go one level further and show which columns move where. That is what column-level lineage is for, and it turns a data platform diagram from a picture of tools into a picture of data.
Weak edge labels Useful edge labels ---------------------- ------------------------------- uses parquet, hourly calls gRPC, synchronous, 40ms p99 sends to CDC events, at-least-once reads nightly full snapshot
Keep the icon layer and the meaning layer separate
An icon says what a component is. It should never be asked to say how important it is, how many there are, or what state it is in. Teams that resize icons to signal importance, or tint them to signal environment, break the vendor terms and lose the recognition benefit at the same time, since a resized or recoloured mark stops being the mark the reader knows.
Signal those things with the layer that is yours: node size and position, zone colour, a count on the label, a dashed outline for planned components, a legend entry. The artwork stays untouched and the diagram gains a second dimension of meaning.
Stop placing icons by hand
Every rule above is a rule about consistency, and consistency is what humans are worst at across a forty-node diagram assembled over three sittings. Describing the architecture in a paragraph and letting each component be matched to its mark from a 2,098-file library removes the whole class of error: one release, one visual language, labels attached from the start.
The harder half is deciding what not to draw, and it is the reason the sixth habit is a rule and not a preference. The first version of the Terraform repository parser here drew every resource it could justify: on a 123-resource repository that came out as 62 boxes in a column, correct and complete and unreadable. The curation that replaced it is deterministic rather than left to the model. Wiring is never a box and is counted in a note. A repeated minor type inside a module collapses into one node carrying its count and member names, drawn as "Storage credentials x2: external, root". A module that still overflows collapses its tail into one named supporting-resources node, capped at eight drawn nodes per module, or sixteen when a single module is the subject of the repository. Nothing is lost: the counts ride on the canvas and the full inventory lands in the module reference table of the generated architecture document.
The canvas is where judgement goes: adjust zones, rewrite an edge label, swap the one icon the generator got wrong. Export as PNG or JPEG for a deck, or publish a live embed so the shared picture stays the current one. And when the architecture is declared in code, repository sync regenerates the whole thing from the branch, which is the only version of consistency that survives the next six months.
FAQ
Do I need to download an icon pack to make a cloud architecture diagram?
Can I mix AWS, Azure and Google Cloud icons in one diagram?
Where should the label sit relative to the icon?
What is the most common mistake with cloud icons in diagrams?
Should I resize or recolour icons to show importance or environment?