Cloud Icons Guide

Cloud icon naming conventions: reading the pack, and naming your own

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

Open an unzipped AWS icon package and the first reaction is that somebody enjoyed underscores. There is a system, and knowing it turns a folder you scroll into a folder you can grep. The three clouds each chose a different one, and the differences explain why cross-cloud icon tooling is more work than it looks.

Try it free
6 min readFor whoever maintains the team icon folder or a diagram-as-code pipeline

See it as a diagram

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

164/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

How the AWS package is laid out

The archive starts with four top-level directories that each answer a different question. Architecture-Service-Icons holds the marks for managed services. Resource-Icons holds marks for concrete things inside those services. Category-Icons holds the family marks. Architecture-Group-Icons holds the containers you draw around other nodes, such as a VPC or an account boundary, several of which deliberately have no logo at all.

Each of those directories carries the release date in its name, which is the most useful fact in the whole archive: it tells you exactly how old the set is without checking a changelog. Inside, service icons are grouped by category, then by pixel size, then named with an Arch_ prefix, the service name and the size. Resource icons use a Res_ prefix and add a light or dark variant, because a resource mark is drawn to sit on a background rather than float.

Sizes commonly shipped are 16, 32, 48 and 64. Since the files are SVG, the size in the name describes the detail level the artwork was drawn for, not a resolution ceiling. A 16 pixel mark is simplified; a 64 pixel mark carries the full detail. For diagram nodes, take the largest.

AWS      Architecture-Service-Icons_07312026/
           Arch_Compute/64/Arch_AWS-Lambda_64.svg
         Resource-Icons_07312026/
           Res_Compute/Res_48_Light/Res_Amazon-EC2-Instance_48_Light.svg
         Architecture-Group-Icons_07312026/
           (containers: VPC, account, region; some carry no logo)

Azure    Azure_Public_Service_Icons_V24.zip
           Icons/<category>/<number>-icon-service-<Product-Name>.svg

Google   per-icon downloads plus one whole-set archive, SVG and PNG,
         with the pre-2025 set still published alongside

Datadef  /icons/cloud-providers/aws/aws-simple-queue-service.svg

Azure and Google made different choices

Microsoft ships one archive whose file name carries a version number, so the version is visible in your downloads folder without opening anything. Inside, icons are grouped by category and the file names combine a numeric identifier, the words icon-service, and the product name. There are no size folders, because there is exactly one SVG per product and no raster alternative at all.

That numeric prefix is stable per product and useful as a key, but it is meaningless to a human, which is why nobody can find an Azure icon by browsing. Sorting by name gives you numeric order, not alphabetical order by product.

Google publishes per-icon downloads alongside a whole-set archive, and since the 2025 iconography refresh distinguishes unique product icons from shared general category icons. The practical consequence for naming is that two different products can correctly resolve to the same file, which breaks any script that assumes a one-to-one mapping between service name and icon file.

Naming your own copy so it stays findable

The moment you copy icons into your own repository, the vendor naming becomes a liability, because nobody greps for Arch_Amazon-Simple-Storage-Service_64.svg when they are looking for S3. The convention that works is provider, then the common name, lowercase and hyphenated, with the vendor release recorded once at the folder level rather than repeated in every file name.

Keep an alias mapping next to the folder. It costs one small file and it is the difference between a set your teammates use and a set they abandon. That is what the registry behind this site is: the SVG sits at a predictable provider-and-name path, and a JSON record beside it lists every string that should reach it. The Simple Queue Service record below is the real one, and it is why typing sqs finds the file the vendor named simple-queue-service.

Two rules that save pain later. Never rename in a way that loses the vendor release date, because that date is how you audit staleness. And never mix releases inside one folder without marking which is which, because the whole point of the folder is that a diagram built from it is internally consistent.

One more, if anything downstream consumes those ids by name: assert them. The Terraform resource catalog here maps 196 explicit resource types onto 101 distinct icon ids, and a script checks every one of those ids against the registry on each run, so a typo fails at that check instead of quietly rendering a generic glyph in somebody's production diagram. An icon id referenced from code is a foreign key, and unchecked foreign keys rot.

"aws-simple-queue-service": {
  "name": "Aws simple Queue Service",
  "provider": "aws",
  "iconPath": "/icons/cloud-providers/aws/aws-simple-queue-service.svg",
  "aliases": [
    "aws-simple-queue-service", "simple-queue-service",
    "amazon-simple-queue-service", "awssimplequeueservice",
    "asqs", "sqs", "aws-sqs"
  ]
}

If you are building diagram-as-code

Icon path conventions are the part of a diagram-as-code pipeline that breaks on every vendor release. Pinning to a dated release folder and mapping aliases yourself is more durable than resolving names at build time. See the docs-as-code diagram limits guide for where that approach stops paying off.

What this buys you in the diagram

A searchable icon set is only worth the effort if it ends up on a canvas. The shortcut is to let the generator resolve names: describe the architecture, and each component is matched against the registry by alias rather than by the exact string you happened to type.

Browse the sets at the AWS collection or the Google Cloud download if you still need the files themselves. The mapping problem is the same either way; the difference is whether a person or the generator solves it each time.

FAQ

What does the Arch_ prefix mean in AWS icon file names?

Arch_ marks an architecture service icon, the mark for a managed service as a whole. It sits inside a category folder and a pixel-size folder, so a typical path ends in something like Arch_Compute/64/Arch_AWS-Lambda_64.svg. Resource icons use a Res_ prefix instead.

What are the sizes in the AWS icon package for?

The package commonly ships 16, 32, 48 and 64 pixel variants. Because the files are SVG, the number describes the level of detail the artwork was drawn for rather than a resolution limit: smaller variants are simplified. For diagram nodes, use the largest available.

What is the difference between Arch_ and Res_ icons?

Arch_ icons represent the managed service, Res_ icons represent a concrete resource inside it such as a single instance or a single bucket. Resource icons also ship in light and dark variants because they are designed to sit on a background rather than float on white.

How is the Azure icon download organised?

As a single SVG archive whose file name carries the version, currently Azure_Public_Service_Icons_V24.zip, with icons grouped by category inside. Individual file names combine a numeric identifier, the words icon-service and the product name. There are no size folders and no raster files, because Microsoft ships one general purpose SVG per product and no stencil or bitmap alternative.

How should I name icon files in my own diagram repository?

Provider first, then the common name, lowercase and hyphenated, with the vendor release date recorded once at the folder level. Keep a small alias file mapping abbreviations to file names, since nobody searches for the vendor long-form name. Never mix two vendor releases in one folder without marking which is which. And if code refers to those ids, assert they resolve, because an unchecked icon id degrades silently rather than failing.