I queried the registry and counted. Amazon publishes 739 architecture icons, Microsoft 626, and Google 214. Together that is 1,579 icons across three download pages, three zip files, and three different ideas of what an icon should look like.
If you write architecture docs, you have lived this. You want a Lambda box and a BigQuery box in the same README, and you end up unzipping two archives to find them.
This post is the practical version. What is in each set, how the files get their names (the naming has a trap), what each license allows, and a script that pulls any icon you name.
theSVG - 7,422+ Free Brand SVG Icons for Developers and Designers
Search, copy, and ship 7,422+ brand SVG icons. Open-source library with npm, React, Vue, Svelte, CLI, CDN, and MCP server support.
thesvg.org
TL;DR
| Provider | Icons | Set version | License in the registry | Sizes |
|---|---|---|---|---|
| AWS | 739 | 2026-Q1 | CC-BY-ND-2.0 | 16, 32, 64, default |
| Azure | 626 | 2026-Q1 | MIT | default |
| Google Cloud | 214 | 2026-Q1 | Apache-2.0 | default |
| Kubernetes | 38 | none listed | Apache-2.0 | default |
The AWS license is the one that changes what you may do, and I cover it in section 3.
1. What is inside the AWS set
Amazon's set is bigger than most people expect, because the set holds more than service icons. The 739 files split into four kinds, and the registry tags each one.
| Kind | Count | Slug prefix | Example |
|---|---|---|---|
| Service | 300 | aws- |
aws-amazon-bedrock |
| Resource | 400 | aws-res- |
aws-res-aws-lambda-lambda-function |
| Category | 26 | aws-cat- |
aws-cat-databases |
| Group | 13 | aws-group- |
aws-group-region, aws-group-private-subnet
|
Service icons are the colored squares you know from every AWS diagram. Resource icons are the small glyphs for specific things inside a service, like a single Lambda function. Category and group icons cover the outer frames and the section headers.
Each AWS icon ships in 16, 32, and 64 pixel versions as well as the default, so you can pick a small one for a dense diagram and a large one for a slide.
Compute is a good comparison point, since every provider has it. The registry lists 38 AWS icons, 39 Azure icons, and 13 Google Cloud icons in the Compute category.
2. The naming trap
Slugs are the file names, and they follow the provider's own product naming. That produces some results you cannot guess.
The AWS Lambda icon is aws-aws-lambda, not aws-lambda. The first aws is the collection prefix and the second is part of the product name. I checked the obvious guess against thesvg.org:
404 /icons/aws-lambda/default.svg
200 /icons/aws-aws-lambda/default.svg
200 /icons/aws-aws-lambda/64.svg
Do not guess. Filter the registry instead. The registry is a single static JSON file with every slug, title, and category, and it needs no key.
BASE=https://thesvg.org
curl -s "$BASE/api/registry.json" > registry.json
# every AWS service icon in the Database category
jq -r '.icons[]
| select(.slug | startswith("aws-"))
| select(.categories | index("Database"))
| .slug' registry.json
That command printed aws-amazon-aurora, aws-amazon-documentdb, aws-amazon-dynamodb, aws-amazon-elasticache, and more. To find a service by name, match on the title:
jq -r '.icons[]
| select(.title | test("lambda"; "i"))
| "\(.slug)\t\(.title)"' registry.json
Once you have the slug, the file path follows one pattern: /icons/{slug}/{variant}.svg. Variants for AWS are default, 16, 32, and 64. The other providers only ship default.
3. The license question
This is where cloud icons differ from ordinary brand icons, so read it before you ship anything.
The registry records a license per icon, and for the AWS set it says CC-BY-ND-2.0. ND stands for No Derivatives. In plain terms, you may share the icons unmodified, with credit, and you may not alter them. Recoloring an AWS icon to match your palette counts as a change. Cropping the badge or stripping the background counts too.
That rule shapes how you use them:
| You want to | AWS icons |
|---|---|
| Place the icon as-is in a diagram | Fine |
| Resize it proportionally | Generally fine, same artwork |
| Recolor it to match your theme | Not allowed under ND |
| Redraw it in a different style | Not allowed under ND |
I am not a lawyer, and the registry records the declared license and offers no legal opinion. For Azure the registry lists MIT and for Google Cloud it lists Apache-2.0, but both companies also publish their own usage terms for these icons, and those terms are what you should read before putting one in a product page. An internal architecture diagram is a lower-risk use than a customer-facing landing page. The Amazon, Microsoft, and Google names remain trademarks of their owners either way, which the project states in its legal notice.
4. Where they are useful, and where they are not
Be honest about the alternative. If you draw diagrams in draw.io, the built-in shape libraries already cover AWS, Azure, Google Cloud, and Kubernetes. You do not need to import anything for that.
The SVG files earn their place everywhere else a diagram lives. A README wants an <img> tag that renders on GitHub. A slide deck or Figma frame wants a real vector you can drag in. A generated diagram, built by a script from a config file, wants a stable file path.
For a README, the embed is one line:
<img src="https://thesvg.org/icons/aws-amazon-bedrock/64.svg" width="64" height="64" alt="Amazon Bedrock" />
Weight is not a concern here. The median AWS default file is 2,875 bytes and the largest is 13,951. The median Azure file is 2,045 bytes, though the largest is 46,239. Google Cloud icons are the lightest, with a median of 725 bytes and a largest of 3,517.
If you are building something generated, pull the file once and commit it, so your diagram does not depend on a network call at render time:
mkdir -p docs/icons
for slug in aws-aws-lambda aws-amazon-dynamodb gcp-bigquery; do
curl -sf "$BASE/icons/$slug/default.svg" -o "docs/icons/$slug.svg" \
|| echo "missing: $slug"
done
The -f flag makes curl fail on a 404, and the || echo prints which slug missed. Without them you would save an error page under an .svg name and not notice until the diagram rendered blank.
5. Mixing three providers in one picture
The visual mismatch is the real cost of a multi-cloud diagram, more than the file hunt. AWS icons sit inside colored badges, Azure icons are flatter glyphs, and Google Cloud icons use a wider palette with no frame. Put them side by side and the reader wastes a second wondering whether the style change means something.
Because of the ND license, you cannot fix that by recoloring the AWS set. What you can control is the layout. Give each provider its own bounded region with a labeled outline, keep every icon the same rendered size, and let the region border carry the provider identity. The mismatch stops looking like an accident once the grouping makes it deliberate.
I wrote a longer comparison of the three visual styles in AWS vs Azure vs GCP Icons, and each collection has its own browse page: AWS, Azure, and Google Cloud.
The bottom line
The files are the easy part. The slug prefix and the license are what trip people up, so filter the registry instead of guessing names, and check the ND terms before you touch a color.
Pull what you need from free SVG brand icons and cloud architecture icons and commit the files next to your docs.
Which provider's icons do you find hardest to place next to the others?
GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks
Three clouds, one diagram, and a license worth reading before you recolor anything.
Top comments (0)