1.579 iconos gratis de AWS, Azure y GCP en SVG

En pocas palabras: thesvg.org reúne 1.579 íconos SVG de arquitectura cloud en un solo registro: 739 de AWS, 626 de Azure y 214 de Google Cloud, más 38 de Kubernetes listados aparte, según un post publicado el 24 de septiembre de 2026 en dev.to.

El desarrollador que firma como GDS K S contó, en un post publicado el 24 de septiembre de 2026 en dev.to, que el registro de thesvg.org suma 1.579 íconos de arquitectura cloud entre AWS, Azure y Google Cloud: 739 de AWS, 626 de Azure y 214 de Google Cloud, además de 38 íconos de Kubernetes que el registro lista aparte. Si alguna vez armaste un diagrama con un Lambda de AWS y un BigQuery de Google en la misma imagen, este conteo te va a sonar conocido.

thesvg.org es un registro público y gratuito de íconos SVG para diagramas de arquitectura cloud que junta en un solo archivo JSON los sets oficiales de Amazon Web Services, Microsoft Azure, Google Cloud y Kubernetes. Sirve para buscar, filtrar y descargar el ícono exacto de un servicio sin abrir tres paneles de descarga ni descomprimir tres zips distintos.

Por qué existe este registro y qué resuelve

Los tres proveedores publican sus propios paquetes oficiales —uno de AWS, uno de Azure y uno de Google Cloud— pero thesvg.org los junta en un único registro con una API JSON pública, sin key, que lista título, slug y categoría de cada archivo. Ahí está el conteo que hizo GDS K S en su post: 739 íconos de AWS, 626 de Azure y 214 de Google Cloud —todos de la versión 2026-Q1—, que suman 1.579, más 38 de Kubernetes listados en el mismo registro.

Cualquiera que armó un README con un Lambda y un BigQuery en el mismo diagrama conoce la parte fea: dos zips, dos convenciones de nombres, y el ícono que buscás aparece recién en el tercer intento, después de abrir carpeta por carpeta hasta dar con el archivo correcto.

Cómo están organizados los 739 íconos de AWS

El set de AWS se divide en cuatro tipos, cada uno con su propio prefijo de slug en el registro. No es solo el ícono de color que ves en un diagrama típico: también hay glifos chicos para recursos puntuales y marcos para agrupar secciones.

• Service (300 íconos, prefijo aws-): los cuadrados de color que reconocés al toque, ejemplo aws-amazon-bedrock.
• Resource (400 íconos, prefijo aws-res-): glifos para un elemento específico dentro de un servicio, ejemplo aws-res-aws-lambda-lambda-function.
• Category (26 íconos, prefijo aws-cat-): marcos exteriores para agrupar, ejemplo aws-cat-databases.
• Group (13 íconos, prefijo aws-group-): encabezados de sección, ejemplo aws-group-region o aws-group-private-subnet.

Cada ícono de AWS viene en tamaño 16, 32 y 64 píxeles además del default, algo que ni Azure ni Google Cloud ofrecen (ahí solo hay una versión). En la categoría Compute, que sirve de comparación pareja entre proveedores, el registro lista 38 íconos AWS, 39 Azure y 13 Google Cloud.

Por qué el ícono de AWS Lambda no se llama “aws-lambda”

Porque el slug real es aws-aws-lambda, no aws-lambda. El primer aws es el prefijo de la colección y el segundo forma parte del nombre del producto, así que el resultado queda duplicado y nada intuitivo.

El propio autor lo probó contra la API y mostró la diferencia: pedir /icons/aws-lambda/default.svg devuelve un 404, mientras que /icons/aws-aws-lambda/default.svg y /icons/aws-aws-lambda/64.svg devuelven 200. La recomendación es no adivinar nunca el slug. El registro es un único archivo JSON estático (registry.json) que no pide autenticación, y con jq filtrás por título en segundos: buscás test("lambda"; "i") sobre el campo title y te devuelve el slug exacto junto con el nombre real. Ese mismo patrón sirve para armar listas completas, como todos los íconos de la categoría Database, en vez de tipear nombres a ciegas.

La regla práctica queda así: si el nombre del servicio tiene más de una palabra o repite el nombre del proveedor (Lambda es parte de AWS, DynamoDB también), asumí que el slug no va a ser el nombre obvio y filtrá el registro antes de escribir la URL a mano.

Qué licencia tiene cada set y qué te deja hacer

AWS licencia sus 739 íconos bajo CC-BY-ND-2.0, Azure usa MIT para sus 626, y Google Cloud usa Apache-2.0 para sus 214, según los datos que registra thesvg.org. La diferencia importa porque la licencia de AWS es la única que te prohíbe modificar el archivo.

Proveedor	Íconos	Versión del set	Licencia	Tamaños
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	sin listar	Apache-2.0	default

ND significa No Derivatives. En criollo: podés compartir el ícono tal cual, con crédito, pero no lo podés alterar. Recolorear un ícono de AWS para que combine con tu paleta cuenta como modificación. Recortar el borde o sacarle el fondo, también.

• Poner el ícono tal cual en un diagrama: permitido, es la misma obra sin tocar.
• Achicarlo o agrandarlo de forma proporcional: generalmente permitido, sigue siendo el mismo arte.
• Recolorearlo para que combine con tu tema visual: no permitido bajo la licencia ND.
• Redibujarlo en otro estilo: tampoco permitido.

El autor aclara que no es abogado y que el registro solo declara la licencia sin dar opinión legal. Los nombres de Amazon, Microsoft y Google siguen siendo marcas registradas de sus dueños más allá de la licencia del ícono, algo que conviene tener presente si vas a usar estos archivos en una landing comercial y no solo en un diagrama interno. Ahí el criterio de riesgo cambia: un diagrama interno para tu equipo es un uso de bajo riesgo, una imagen de marketing en una página pública que menciona a AWS, Azure o Google es otro terreno, y ahí conviene leer los términos de uso que cada compañía publica además de la licencia que declara el registro.

Cómo pegás estos íconos en un README o en un diagrama generado

Para un README alcanza con una etiqueta <img> apuntando al slug correcto, algo como src="https://thesvg.org/icons/aws-amazon-bedrock/64.svg", y GitHub la renderiza sin drama. El peso no es problema: el archivo default de AWS pesa en mediana 2.875 bytes (el más grande llega a 13.951), Azure mide 2.045 bytes de mediana (con picos de hasta 46.239) y Google Cloud es el más liviano, con 725 bytes de mediana y 3.517 como máximo.

Ahora bien, si el diagrama lo genera un script a partir de un archivo de configuración, mejor no depender de la red en tiempo de render. El propio post trae un loop en bash con curl -sf que baja cada slug a una carpeta local y avisa con un “missing” cuando algo no existe, en vez de guardar una página de error como si fuera un SVG válido. Commitear los archivos junto al proyecto, en vez de depender de una URL externa, evita que el diagrama se rompa el día que thesvg.org esté caído.

Ejemplo hipotético — para que la diferencia entre “embeber por URL” y “commitear el archivo” quede clara, pensá en dos equipos ficticios que necesitan lo mismo, un README con tres íconos (Lambda de AWS, un servicio de Azure y BigQuery de Google):

• El Equipo A mantiene un README que se edita a mano de vez en cuando. Ahí embeber la URL directa (<img src="https://thesvg.org/icons/...">) alcanza: el archivo pesa unos pocos kilobytes, GitHub lo renderiza al vuelo y no hay pipeline que dependa de esa red.
• El Equipo B genera sus diagramas de arquitectura con un script en cada build de CI. Ahí depender de una URL externa es un riesgo real: si thesvg.org está caído o cambia un slug entre versiones del set, el build falla sin aviso. La opción más segura es bajar los tres archivos una sola vez con el loop de curl -sf, commitearlos en docs/icons/, y que el script de diagramación lea del disco local en vez de la red.

El criterio para decidir entre una opción y otra no depende del tamaño del proyecto sino de quién dispara el render: si es una persona editando un archivo, la URL directa funciona; si es un pipeline automático que corre sin supervisión, conviene tener el archivo local y versionado.

Cómo evitás que un diagrama con los tres proveedores se vea inconsistente

Agrupando cada proveedor en su propia región con un borde etiquetado, porque la licencia ND de AWS te impide resolver el desajuste visual recoloreando nada. Los íconos de AWS vienen dentro de badges de color, los de Azure son glifos más planos, y los de Google Cloud usan una paleta más amplia sin marco. Puestos uno al lado del otro sin criterio, el lector pierde un segundo preguntándose si el cambio de estilo significa algo.

Como no se puede arreglar con un filtro CSS ni con un recoloreo rápido, al menos no con el set de AWS, lo que sí controlás es el layout: mantené cada ícono al mismo tamaño renderizado, dale a cada nube su caja con nombre, y dejá que el borde de la región cargue con la identidad del proveedor. El desajuste deja de parecer un accidente en cuanto la agrupación lo hace ver deliberado. Como resume el propio autor, GDS K S, en su perfil: “tres nubes, un diagrama, y una licencia que vale la pena leer antes de recolorear nada”.

Errores comunes al usar íconos de arquitectura cloud

• Adivinar el slug por el nombre del servicio: escribir aws-lambda en vez de aws-aws-lambda te tira un 404. Filtrá registry.json con jq antes de tipear nada.
• Recolorear un ícono de AWS para que combine con la paleta del deck: viola la licencia CC-BY-ND-2.0, que prohíbe derivados aunque el cambio sea mínimo.
• Pegar la URL externa directo en un pipeline de CI: si el dominio cae o el slug cambia de versión, el build se rompe sin aviso previo.
• Bajar archivos en lote sin el flag -f de curl: guardás una página de error 404 con extensión .svg y no te enterás hasta que el diagrama sale en blanco.

Preguntas frecuentes

¿Cuántos íconos tiene en total el registro de thesvg.org?

1.579 íconos entre AWS, Azure y Google Cloud (739, 626 y 214 respectivamente), más 38 de Kubernetes que el registro lista aparte, según el conteo que publicó el autor en su post de dev.to.

¿Puedo recolorear los íconos de AWS para mi diagrama?

No. El set de AWS usa licencia CC-BY-ND-2.0, que significa No Derivatives: podés usar el ícono tal cual y con crédito, pero recolorearlo o redibujarlo cuenta como modificación no permitida. Azure (MIT) y Google Cloud (Apache-2.0) sí admiten modificaciones, según lo que declara el registro.

¿Cómo encuentro el slug real de un ícono sin adivinar?

Descargando registry.json desde la API pública y filtrando con jq por el campo title, por ejemplo con una expresión que busque “lambda” ignorando mayúsculas. Eso te devuelve el slug exacto junto con el nombre del producto, sin errores de 404.

¿Sirven estos SVG si ya dibujo diagramas en draw.io?

Para draw.io no hace falta nada extra, porque ya trae shape libraries propias de AWS, Azure, Google Cloud y Kubernetes. Los SVG sueltos de thesvg.org ganan terreno en READMEs, slides, Figma y diagramas armados por script, donde un archivo con ruta estable resuelve más rápido que una librería interna.

Conclusión

Lo que cambió acá no es que existan íconos gratis de AWS, Azure y Google Cloud —eso ya lo sabías—, sino que alguien los juntó en un registro único con API propia y documentó la trampa de nombres y la letra chica de cada licencia. Si laburás con documentación multi-cloud, el ahorro real está en dejar de adivinar slugs y en leer la licencia ND antes de tocar un color. Y si tu diagrama lo arma un script en vez de una persona, la diferencia entre embeber la URL y commitear el archivo deja de ser un detalle: es lo que evita que un build se rompa por una dependencia que no controlás.

Antes de meter esto en un proyecto grande, probalo con dos o tres íconos primero. Pedí el slug por jq, bajalo con curl -sf, y fijate que el archivo pese lo que dice la tabla (unos pocos kilobytes, no más). Si te devuelve un archivo de 0 bytes o un HTML de error disfrazado de SVG, el slug estaba mal y mejor lo corregís antes de commitearlo.

Fuentes

• Free AWS, Azure and GCP architecture icons as SVG – post original de GDS K S en dev.to (24/09/2026)
• thesvg.org – registro público de íconos SVG citado como fuente de los datos y la API