Cloud Diagram Guide

Multi-cloud architecture diagram: three icon sets on one canvas

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

A multi-cloud diagram is not three diagrams next to each other. It exists to show what crosses the boundary between providers, and everything inside a provider is just a normal single-cloud picture. The difficulty is visual: the three official icon sets were designed independently, they use colour to mean different things, and putting them side by side makes the eye read vendor as category. Here is how to keep it readable.

Try it free
7 min readFor architects presenting a genuinely multi-cloud estate

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

339/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

The three sets do not share a visual language

AWS uses filled squares with a category colour, so orange, purple, green, and blue already carry meaning inside the AWS half of your canvas. Microsoft uses flat glyphs with a category hue on a light ground. Google uses flat multi-colour marks drawn from its four brand colours, which read as decorative next to the other two.

Put all three on one canvas and the reader starts interpreting colour as importance or category when it actually just indicates who made the icon. The fix is structural rather than cosmetic: let the provider zone carry the vendor identity, with a clear label and a restrained background tint, and let the icons inside be nothing more than service identifiers. Do not recolour the marks. Every vendor asks that its icons stay unmodified.

Keep node sizes uniform across the zones. Google marks tend to sit inside a smaller optical box than the AWS squares, so a naive paste makes the AWS side look heavier and more important. Equal node sizing removes an implication nobody intended.

Draw the seams, that is the whole point

Connectivity: Direct Connect, ExpressRoute, and Cloud Interconnect for private links, or site-to-site VPN between a VPC, a VNet, and a VPC. Label each crossing edge with the mechanism and the direction. Peering between two clouds is not symmetric in practice, and the asymmetry is usually the interesting part.

Identity: this is the seam that gets omitted most often and asked about first. Entra ID as the identity provider federating into an AWS IAM role over SAML or OIDC, or workload identity federation into Google Cloud, is an architectural dependency as real as a network link. Draw it, and label the trust direction.

Data: for every replication or export edge, put the direction, the cadence, and the mechanism on the label. Nightly export to Cloud Storage is a different system from change data capture in near real time, and both get drawn as a plain arrow if nobody writes on it. DNS deserves one line too: which zone is authoritative, and what resolves across the boundary.

Say why each workload sits where it does

Multi-cloud is almost never a preference. It is data residency, an acquisition, a managed service only one vendor has, a negotiated commitment, or an exit plan. A diagram that shows the topology without the reason invites the same question at every review.

One line of annotation per provider zone fixes it: analytics on Google Cloud because of BigQuery, identity on Azure because the organisation is Microsoft 365, the customer application on AWS because that is where it was built. Annotations on zones are cheap, and they convert a topology picture into an architecture decision record people can argue with.

The same discipline applies to what is deliberately not duplicated. If observability is centralised in one provider, say so on the zone, because a reader will otherwise assume a second stack exists.

One canvas, three icon libraries

Datadef carries 2,098 icon files in one index: 439 AWS, 624 Azure, 226 Google Cloud, all 41 labelled Kubernetes resource marks, 373 tech-stack logos and 32 data tool marks. A multi-cloud description resolves every service name in one pass, so building the picture does not mean three downloads and a manual paste job. Browse the whole library at the icon index.

One caution specific to multi-cloud, and it is measurable. When three vendor sets share one index, an abbreviation stops being unambiguous. Querying that index for a bare alb returns two Azure load balancer marks, because Azure registered alb as an alias and AWS did not; a bare iam returns Azure IP Address Manager before anything from AWS. Neither answer is a bug in the matcher, it is what happens when an acronym belongs to two vendors. On a multi-cloud canvas, write the full product name, and check the one node where two clouds offer the same three letters.

Provider zones, labelled crossing edges, and uniform node sizing come out of the generation step, and the canvas stays editable for the annotations only you can write. Export to PNG or JPEG for the board deck, or keep a live embed in the platform wiki.

Terms differ per vendor, and a diagram carrying all three sets has to satisfy all three. The common denominators are the ones each vendor states plainly: use the marks as published rather than modified, do not use them to represent your own product, and do not imply endorsement. Microsoft adds the most specific version, asking that icons are not cropped, flipped, rotated or reshaped. The details are in Azure and Google Cloud icon terms and using AWS icons in presentations.

FAQ

How do I keep a multi-cloud diagram readable?

Let the provider zone carry the vendor identity with a label and a restrained background, keep node sizes uniform across zones, and do not recolour any vendor mark. Colour inside each official icon set already encodes product category, so adding your own colour meaning on top makes the canvas unreadable.

What should the arrows between clouds say?

The mechanism, the direction, and the cadence. Private interconnect or VPN for network links, SAML or OIDC for identity federation with the trust direction, and the replication method plus frequency for data edges. An unlabelled arrow between two clouds is the least informative element on the canvas.

Can I mix AWS, Azure, and Google Cloud icons in one diagram?

Yes, and a genuine multi-cloud architecture requires it. Each vendor publishes its own usage conditions and they differ in wording, but they share the same core requirements: use the marks as published rather than modified, do not present them as your own branding, and do not imply the vendor endorses your product. The mistake to avoid is mixing two releases of the same vendor set, not mixing vendors.

Should each cloud get its own diagram instead?

For anything below the seam, yes. Detailed per-provider diagrams stay readable, and the multi-cloud view should show only what crosses the boundary: connectivity, identity federation, data movement, and DNS. Trying to show three full estates on one canvas produces something nobody reads.

Which icon do I use for a cross-cloud VPN?

Draw the gateway on each side with the icon each provider publishes, for example a virtual private gateway on the AWS side and a Cloud VPN gateway on the Google Cloud side, and make the tunnel itself a labelled edge between them. There is no shared cross-vendor symbol, so the two endpoints plus a labelled link is the accurate rendering.