Cloud Icons Guide

Official vs community cloud icon sets: which one belongs in the diagram

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

Search for an icon pack and you get four different kinds of thing on the first page, all presented as equivalent. They are not. They differ on where the artwork came from, how old the underlying vendor release is, and what licence sits on the packaging. Those three questions decide whether a diagram survives a review by someone who works at the vendor.

Try it free
7 min readFor anyone choosing an icon source before standardising a team on it

See it as a diagram

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

178/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

The four kinds of source, and what each really is

Vendor packs. Published by AWS, Microsoft and Google on their own architecture pages. These are the artwork itself, released on a cadence, with terms attached. They are authoritative by definition and they are always ZIP-shaped, which is exactly why so few people use them directly.

Vendor-adjacent repositories. The clearest example is the awslabs PlantUML icon project, github.com/awslabs/aws-icons-for-plantuml, where the icons are distributed under CC-BY-ND 2.0 and the surrounding code under MIT, and every release names the dated AWS release it wraps: v23.0 is built on AWS Release 23 dated 2026-01-30, v22.0 on Release 22 dated 2025-07-31. That is the honest pattern to look for. A project that tells you which vendor release it wraps is a project you can audit against the vendor stamp; one that does not is a project you have to unzip and guess at.

Community mirrors and package-manager builds. npm packages, GitHub repositories of exploded ZIPs, sprite sheets. Convenience is genuine and freshness is a lottery. Several widely linked sets still ship the 2018 flat AWS style, which is why diagrams built from search results end up mixing two visual generations.

Icon marketplaces. Flaticon-style sites and stock libraries sell lookalikes drawn by illustrators. These are not the vendor marks. They will be close enough to fool you and not close enough to fool a reader who uses the service every day.

What actually goes wrong

Version skew inside one diagram. Half the marks from a current release, half from whatever a slide deck template shipped with. This is the most common defect and the most visible, because the two generations of AWS icons differ in silhouette, not just in colour.

A no-derivatives licence colliding with your habits. CC-BY-ND permits redistribution but not derivative works, so the recolouring or cropping some teams do routinely is exactly what that licence excludes, on top of whatever the vendor terms say.

A stopped set. Sets go unmaintained quietly. The tell is a missing recent service, and the dated vendor batches give you exact probes: no AKS Network Policy, Azure Local or Azure PubSub means the Azure set predates November 2025; no Azure DocumentDB or AI Gateway means it predates July 2026. If the newest service you can find is two years old, the set is two years old.

A redraw that reads as a fake. A lookalike S3 bucket with the wrong green, or an Azure Functions mark with the wrong lightning geometry, signals to a technical audience that nothing else in the diagram was checked either.

A three-question test before you adopt a set

Which vendor release is this built on, and is that date stated anywhere. AWS stamps its package 07312026 and Microsoft ships Azure_Public_Service_Icons_V24.zip, so both ends of the comparison are checkable in seconds. A set that will not name its base release is a set you cannot audit.

Is the file the vendor SVG or a redraw. Vendor packs keep their release naming inside the archive, so listing the archive is usually enough to answer it.

Does the packaging licence contradict what you intend to do with the files. Redistribution, recolouring and bundling into a product are three different asks, and the packaging licence sits on top of the vendor terms rather than replacing them.

# Vendor archives keep their release naming; redraws almost never do.
unzip -l Asset-Package.zip | head -20

# Expect paths that carry the release date and the vendor prefix:
#   Architecture-Service-Icons_07312026/Arch_Compute/64/Arch_AWS-Lambda_64.svg
#   Resource-Icons_07312026/Res_Compute/Res_48_Light/...
#
# Compare that date against the stamp on aws.amazon.com/architecture/icons.
# A flat folder of lambda.svg, s3.svg, ec2.svg is somebody else's build.
# That is fine, as long as you know whose.

Where Datadef sits in that taxonomy

A vendor-SVG mirror with per-service pages: the download endpoint serves the vendor file unchanged, and each icon page carries the creator, the copyright notice, the credit text and a link to the vendor licence page, so provenance travels with the mark. The count is 439 AWS, 624 Azure and 226 Google Cloud, plus 373 tech-stack marks, 336 general shapes, 41 Kubernetes, 32 data tooling and 27 networking icons: 2,098 SVG files.

Two honest limits. It mirrors the architecture service icon tier, not the vendor resource icon tier, so a mark for one named EC2 instance or one bucket still comes from the asset package. And a mirror keeps what it was given, retired names included, which is why the Google folder holds both gcp-stackdriver.svg and gcp-cloud-monitoring.svg rather than folding one into the other.

The reason the library exists is not to be a nicer ZIP. It is so the diagram generator can pick the right mark for each component without anyone opening a folder. Describe the architecture, get the marks assigned, edit on the canvas. See the AWS collection for the browsable set, or how to use official cloud icons in diagrams for the placement rules that matter more than the source.

FAQ

Is it safe to use community AWS icon packs?

It depends on what the pack contains. A repackaging of the vendor SVGs is the same artwork with different plumbing, and the risk is only staleness. A set of icons redrawn by a third party is not the vendor mark at all, and a technical audience will notice. Check whether the files are the vendor SVGs before deciding.

What licence do the AWS PlantUML icons use?

In the awslabs aws-icons-for-plantuml project, the icons are distributed under CC-BY-ND 2.0 and the code under MIT. The ND term matters on its own: no-derivatives excludes the recolouring and reshaping people sometimes do to fit a palette, independently of what the AWS terms say. Each release also names the AWS icon release it wraps, so you can tell how current it is.

How can I tell a real vendor icon from a redrawn lookalike?

Run unzip -l on the archive and read the paths. Vendor packages carry release dates and vendor prefixes in their folder and file names, such as an Architecture-Service-Icons folder stamped with the release date and per-size subfolders under it. A flat directory of short lowercase names is somebody else's build, which may still be the vendor artwork but has to be verified another way, by comparing a file against the same icon on the vendor page.

Why do two icon sets show different logos for the same service?

Almost always because one set is built on an older vendor release. Cloud vendors restyle their iconography periodically, and unmaintained mirrors freeze at whatever release they last imported. Comparing the newest service present in each set usually reveals which one stopped.

Does it matter if my icon set is a year old?

For long-standing services, rarely. For anything recent it does: a set that predates a restyle or a batch of new marks will silently lack them, and you end up substituting an unrelated icon. AWS ships three releases a year, at the end of January, April and July, so a year is three releases of drift. Microsoft ships in unscheduled batches, which is why the safer Azure check is probing for a named recent icon rather than counting months.