No official icon for that service: what to put in the box instead

Icon packs ship on a cadence, and the AWS one has a hole in it. Releases land at the end of January, the end of April and the end of July, and there is no Q4 release at all. So a service announced in February waits until the end of April, and a service announced at re:Invent in December waits until the end of January. Microsoft ships in batches on no calendar, which makes the wait unpredictable rather than bounded: between November 2024 and July 2026 there were five batches at irregular intervals.

The second cause is by design. The 2025 Google Cloud iconography update published marks for core products and for general product categories together, so some services resolve to a category mark rather than a bespoke one, permanently. That is a published decision, not an omission, and treating it as a gap to fill yourself makes your diagram less correct rather than more.

The third cause is that most real architectures are not one cloud. Half the boxes are third-party SaaS and internal services, and no cloud vendor is going to draw those for you.

One: the category or general icon the vendor itself publishes. This is the sanctioned answer when the vendor has one, it stays inside the terms you already accepted, and it is visually consistent with everything else on the canvas. Label it with the exact product name and it carries all the meaning it needs to.

Two: a group or container shape with a text label. The AWS package ships architecture group icons specifically for boundaries, and several of them deliberately carry no logo. A labelled container is the correct way to draw an account, a region, a VPC or a logical subsystem that is not a product.

Three: the third party logo, taken from that vendor's own brand or press page. Fivetran, dbt, Snowflake and most SaaS companies publish a brand kit with usage terms, and those terms govern, not the cloud vendor terms. This is the right move for a SaaS box, and the wrong move for anything you found through image search.

Four: a neutral shape with a clear label and a legend entry. Unglamorous and completely defensible. For an internal service, this is usually the only option and it is fine.

The one to avoid: borrowing an unrelated service icon because it looks close enough. A Lambda mark on a box that is not Lambda will be read as Lambda by every reader who recognises it, and the person on the team that owns that service will notice within seconds.

The Terraform repository parser here has to answer this question on every sync, without a person in the loop, and the rules it uses are the same four ranked above turned into policy. They are worth reading even if you never connect a repository, because they are the ranking made explicit.

First, some resources are never a box at all. Nine providers are classified as wiring outright: random, null, local, time, tls, archive, template, external and terraform. A random_password has no architecture in it, so no icon is needed and none is invented. The same applies to any resource type whose name matches role, permission, grant, policy attachment, member, iam, entitlement or acl. Those are counted in a note instead, which on a real Azure or AWS estate is a large number.

Second, when a type is genuinely unknown, the fallback is deliberately not a guess. An unrecognised azurerm, aws or google resource renders with the Terraform mark rather than the nearest-looking service icon. The reasoning is exactly the reasoning of this page: a wrong Azure service icon asserts something false about the component, while "a Terraform-managed resource" is always true and keeps the canvas honest. Third-party providers keep their own vendor mark when there is one, so a Datadog or Snowflake resource still reads as Datadog or Snowflake.

Third, an explicit table wins over both. 196 resource types are classified by hand, 155 of them carrying a hand-checked icon id, and the 101 distinct ids those resolve to are asserted against the registry before the code is allowed to be wrong about them.

Unknown resource type, ranked fallbacks
  1  explicit catalog entry        exact vendor mark
  2  known third-party provider    that vendor mark (datadog, snowflake, ...)
  3  unknown aws/azurerm/google    the Terraform mark, never a guessed service
  4  wiring provider or keyword    no node at all; counted in a note

Microsoft states it directly in the Azure guidance: put the product name close to the icon. The reasoning generalises. Icons are recognition aids that let a reader skip ahead; labels are identifiers that make the diagram correct. A labelled neutral box is unambiguous, while an unlabelled icon is a guess the reader is making on your behalf.

A legend costs three lines and settles the question for every box that had to fall back. State what an icon means, what a plain box means, and what any line style means. Diagrams that get argued about in review are usually diagrams without one.

Legend
  [icon]   official vendor mark, release 2026-07
  [logo]   third-party brand mark, used per that vendor brand terms
  [box]    no published mark; the name in the box is authoritative
  dashed   planned, not built yet

The gap is smaller than the cloud packs alone suggest. Alongside 439 AWS, 624 Azure and 226 Google Cloud marks, the library carries 373 tech-stack icons, 41 Kubernetes, 32 data-tooling and 27 networking icons, which covers the pieces cloud vendors never draw: Kafka, Flink, Spark, Airflow, dbt, Fivetran, Airbyte, Dagster, Prefect, ClickHouse, Druid, Elasticsearch, Grafana, Looker, Metabase, Superset and the rest of the surrounding stack.

When nothing fits, add the node with its label and note it in the legend. The canvas treats a labelled box as a first-class node, so it groups, connects and lays out exactly like the ones that got a mark. That is the point: the missing icon should cost you one legend line, not a redesign.

• Which icon is which service
• Azure icons: free SVG download
• Official vs community icon sets
• Draw a diagram from a description