Free AWS, Azure and GCP architecture icons as SVG

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.

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:

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.