Azure Marketplace es uno de esos componentes de Azure que muchos equipos usan de forma indirecta, pero que no siempre incorporan de manera explícita al diseño de arquitectura. Aparece cuando desplegamos una máquina virtual basada en una imagen de terceros, cuando contratamos una solución SaaS desde el portal, cuando un proveedor ofrece una appliance de seguridad o cuando necesitamos acelerar un piloto sin construir toda la plataforma desde cero.
Microsoft presenta Microsoft Marketplace como un destino para encontrar, probar y adquirir soluciones cloud, aplicaciones, agentes de IA, integraciones y servicios de partners. Dentro de esa experiencia, las soluciones desplegables en Azure siguen siendo especialmente relevantes para equipos de plataforma, seguridad, datos y operaciones.
La idea importante no es que Marketplace sea “una tienda” más. En entornos profesionales funciona como una capa de distribución y adquisición de software que puede integrarse con el modelo operativo de Azure: suscripciones, grupos de recursos, identidades, redes, facturación, políticas, permisos y despliegues automatizados.
Pero esa comodidad tiene una contrapartida: desplegar rápido no significa desplegar bien. Una oferta de Marketplace puede acelerar una prueba de concepto o reducir trabajo de instalación, pero no sustituye las decisiones de arquitectura, seguridad, gobierno, costes y ciclo de vida.
Qué es Microsoft Azure Marketplace
Azure Marketplace es el catálogo desde el que Microsoft y proveedores externos publican soluciones que pueden desplegarse, contratarse o integrarse con entornos Microsoft Cloud. En la práctica, muchos equipos usan el término “Azure Marketplace” para referirse a las ofertas que se despliegan o consumen desde Azure, mientras que Microsoft Marketplace agrupa una experiencia más amplia de soluciones cloud, SaaS, aplicaciones empresariales, integraciones, servicios profesionales y componentes relacionados con IA.
Según el tipo de oferta, Marketplace puede incluir:
- Imágenes de máquina virtual.
- Aplicaciones de Azure.
- Soluciones SaaS.
- Contenedores o componentes desplegables.
- Extensiones e integraciones con productos Microsoft.
- Servicios profesionales de partners.
- Aplicaciones y agentes de IA.
- Soluciones sectoriales o de negocio.
Desde el punto de vista técnico, una oferta de Marketplace no es solo una página comercial. Puede incluir metadatos de publicación, planes, precios, términos legales, regiones compatibles, requisitos de despliegue, versiones, identificadores técnicos, imágenes, plantillas, parámetros o integraciones con el portal de Azure.
En el caso de una imagen de máquina virtual, por ejemplo, Marketplace actúa como origen de una imagen preparada por el publicador. El cliente la despliega en su suscripción, pero sigue siendo responsable de operar correctamente la infraestructura resultante: red, identidad, actualizaciones, backups, monitorización, costes y cumplimiento.
Marketplace no sustituye a la arquitectura
El error habitual es pensar que una oferta de Marketplace resuelve automáticamente el diseño de plataforma. No lo hace.
Una imagen lista para desplegar puede acelerar el arranque, pero sigue necesitando decisiones sobre:
- Topología de red.
- Exposición pública o privada.
- Integración con DNS.
- Modelo de identidad y acceso.
- Gestión de secretos.
- Cifrado.
- Retención de datos.
- Backup y recuperación.
- Alta disponibilidad.
- Monitorización.
- Gestión de parches.
- Costes.
- Responsabilidades de soporte.
- Plan de salida.
Una appliance de logs, por ejemplo, puede ayudar a centralizar eventos de aplicaciones, sistemas y servicios. Pero si se despliega en una red plana, con disco insuficiente, sin estrategia de retención, sin control de acceso y sin integración con la observabilidad corporativa, el problema simplemente cambia de forma. Ya no estamos instalando software manualmente, pero seguimos operando una plataforma.
Marketplace reduce fricción de adopción. No elimina la responsabilidad técnica.
Tipos de ofertas que conviene distinguir
Marketplace agrupa productos muy distintos bajo una misma experiencia de catálogo. Para evaluar una solución correctamente, conviene distinguir varias familias.
Imágenes de máquina virtual
Las imágenes de máquina virtual son uno de los casos más reconocibles. El publicador proporciona una imagen con sistema operativo y software preinstalado. Al desplegarla, Azure crea una VM usando esa imagen y, en algunos casos, exige aceptar términos específicos del plan.
Este modelo es habitual para:
- Appliances de red.
- Firewalls.
- Herramientas de observabilidad.
- Plataformas de análisis.
- Sistemas de seguridad.
- Productos que necesitan control a nivel de sistema operativo.
- Software autogestionado por el cliente.
Su ventaja es la rapidez de despliegue. Su riesgo es que la organización puede acabar operando una caja parcialmente opaca si no revisa cómo está construida, cómo se actualiza y qué responsabilidades asume el publicador.
Aplicaciones de Azure y aplicaciones gestionadas
Algunas ofertas empaquetan una solución que despliega varios recursos de Azure. Dependiendo del modelo, la solución puede crear infraestructura en la suscripción del cliente y, en determinados escenarios, incorporar un esquema de administración gestionada por el proveedor.
Este patrón puede reducir fricción operativa, pero requiere revisar cuidadosamente:
- Qué recursos se crean.
- En qué grupos de recursos.
- Qué permisos se conceden.
- Qué visibilidad tiene el proveedor.
- Qué parte administra el cliente.
- Qué parte administra el publicador.
- Cómo se actualiza o elimina la solución.
SaaS
Las ofertas SaaS no siempre despliegan recursos complejos en la suscripción del cliente. En muchos casos, el servicio lo opera el proveedor y el cliente lo adquiere a través de Marketplace.
La ventaja suele estar en la adquisición centralizada, la integración contractual y la facturación. El control de infraestructura, en cambio, normalmente queda en manos del proveedor.
Antes de adoptar una oferta SaaS conviene revisar:
- Residencia de datos.
- Modelo de identidad.
- Integración con Entra ID, si aplica.
- Exportación de datos.
- Auditoría.
- SLA.
- Soporte.
- Condiciones de cancelación.
- Modelo de precios.
Integraciones, extensiones y servicios profesionales
Marketplace también puede incluir conectores, extensiones, herramientas complementarias y servicios profesionales. En arquitecturas modernas, estos componentes pueden ser tan importantes como una VM o una aplicación completa.
Un conector hacia una fuente corporativa, una herramienta de clasificación documental, una extensión de seguridad o un servicio profesional de implantación pueden acelerar un proyecto, pero deben evaluarse con el mismo rigor: permisos, dependencias, soporte, costes y ciclo de vida.
El ejemplo Graylog: qué validar en una oferta de terceros
La URL de referencia apunta a una ficha de Graylog publicada por un tercero en Azure Marketplace. Graylog es conocido como plataforma de gestión y análisis de logs, pero los detalles concretos de una oferta —versión, soporte, configuración, licencia, regiones, requisitos y condiciones— deben verificarse siempre en la ficha vigente del publicador y en la documentación contractual aplicable.
El interés arquitectónico del ejemplo no está en asumir que una oferta concreta sea adecuada para todos los entornos, sino en entender el patrón:
- Un publicador empaqueta una solución.
- La publica como oferta de Marketplace.
- El cliente puede desplegarla o contratarla desde Azure.
- La organización debe evaluarla antes de incorporarla a producción.
Si una imagen de Marketplace se presenta como “lista para usar” o “orientada a producción”, conviene interpretar esa afirmación con prudencia. Puede significar que el software arranca con una configuración inicial razonable, pero no que cumpla automáticamente los estándares de producción de una organización concreta.
Antes de usar una plataforma de logs en producción habría que responder, como mínimo:
- ¿Qué tamaño de VM se necesita para el volumen esperado?
- ¿Cómo se dimensiona el almacenamiento?
- ¿Qué política de retención se aplicará?
- ¿Dónde se almacenan los backups?
- ¿Qué puertos quedan expuestos?
- ¿Se accede por IP pública o por red privada?
- ¿Cómo se aplican actualizaciones del sistema operativo y del producto?
- ¿Qué credenciales iniciales existen y cómo se rotan?
- ¿Qué responsabilidades asume el publicador?
- ¿Qué responsabilidades quedan en manos del cliente?
- ¿Cómo se exportan los datos si se decide abandonar la solución?
Advertencia: una oferta de Marketplace puede acelerar el despliegue, pero no elimina la necesidad de revisar hardening, red, identidad, continuidad de negocio, cumplimiento y costes. La responsabilidad operativa sigue existiendo.
Cómo evaluar una oferta antes de desplegarla
La evaluación de una oferta de Marketplace debería ser una práctica formal, especialmente si la solución va a manejar datos sensibles, tráfico de red, identidades, eventos de seguridad o información de negocio.
1. Identidad del publicador
El primer criterio es saber quién publica la oferta.
No es lo mismo que la publique:
- Microsoft.
- El fabricante original del producto.
- Un partner autorizado.
- Un tercero que empaqueta software open source.
- Una consultora que ofrece una solución derivada.
Esta diferencia afecta a soporte, actualizaciones, confianza, respuesta ante vulnerabilidades y continuidad. En soluciones críticas, conviene comprobar si el publicador tiene relación oficial con el producto que empaqueta.
2. Tipo de oferta y modelo operativo
Antes de desplegar hay que entender qué estamos consumiendo:
- ¿Una VM?
- ¿Una aplicación gestionada?
- ¿Un SaaS?
- ¿Un contenedor?
- ¿Una integración?
- ¿Un servicio profesional?
Cada tipo implica responsabilidades distintas. Una VM suele exigir operación directa del sistema. Un SaaS reduce la gestión de infraestructura, pero aumenta la dependencia del proveedor. Una aplicación gestionada puede delegar parte de la operación, pero requiere revisar permisos y límites.
3. Plan, SKU y versión
Muchas ofertas tienen varios planes. Pueden variar por versión, licencia, capacidad, región, soporte o precio.
En imágenes de VM, los identificadores técnicos son especialmente importantes. Para automatizar despliegues no basta con conocer el nombre comercial; normalmente hay que identificar valores como publicador, oferta, SKU o plan, según el caso.
Estos identificadores deben obtenerse desde la oferta real o mediante consultas al catálogo. No conviene inferirlos a partir del nombre visible en la interfaz.
4. Coste total
Una oferta puede tener:
- Coste de licencia.
- Coste de infraestructura Azure.
- Ambos.
- Coste variable por consumo.
- Coste por usuario.
- Coste por volumen de datos.
- Coste por transacción.
- Coste asociado a soporte.
En una VM, aunque la licencia del software no tenga coste adicional, se siguen pagando cómputo, discos, snapshots, tráfico de red, backup, monitorización, almacenamiento y cualquier servicio Azure asociado.
En plataformas de logs, observabilidad o análisis, el volumen de datos puede pesar más que el coste inicial de despliegue. Un piloto barato puede convertirse en una plataforma cara si la retención, la ingesta o el almacenamiento no están controlados.
5. Disponibilidad regional
No todas las ofertas están disponibles en todas las regiones. Tampoco todas soportan las mismas configuraciones de red, tipos de VM, zonas de disponibilidad o modelos de residencia de datos.
Para sectores regulados, esta revisión es obligatoria. La región no es solo una decisión de latencia; puede afectar a cumplimiento, soberanía, residencia de datos, soporte y continuidad.
6. Seguridad y cumplimiento
La evaluación de seguridad debe cubrir:
- Superficie expuesta.
- Puertos abiertos.
- Credenciales iniciales.
- Integración con identidad corporativa.
- Gestión de secretos.
- Cifrado en tránsito y en reposo.
- Actualizaciones.
- Vulnerabilidades conocidas.
- Permisos requeridos.
- Auditoría.
- Logs generados por la propia solución.
- Tratamiento de datos personales o sensibles.
En imágenes de VM, el hardening del sistema operativo es especialmente relevante. Que una imagen arranque correctamente no significa que cumpla los estándares internos de seguridad.
7. Soporte y ciclo de vida
Para producción, el soporte no es un detalle comercial. Forma parte de la arquitectura.
Hay que revisar:
- Quién da soporte.
- En qué horario.
- Con qué SLA.
- Qué canales existen.
- Qué versiones están soportadas.
- Cómo se publican actualizaciones.
- Qué ocurre ante una vulnerabilidad crítica.
- Qué pasa si el publicador retira la oferta.
- Cómo se migra a otra versión o alternativa.
Una solución válida hoy puede quedar obsoleta si deja de recibir mantenimiento o si cambia su modelo de licencia.
Despliegue desde portal y automatización
Para exploración inicial, el portal de Azure suele ser suficiente. Permite buscar la oferta, revisar planes, leer detalles, seleccionar suscripción, grupo de recursos, región, tamaño, red y parámetros básicos.
Esa experiencia es útil para entender qué recursos crea la solución y qué opciones expone el publicador. Pero en entornos profesionales el despliegue manual debería ser la excepción.
Si una oferta entra en el catálogo interno de la organización, conviene automatizarla mediante:
- Bicep.
- Plantillas ARM.
- Terraform.
- Azure CLI.
- Pipelines de CI/CD.
- Catálogos internos de plataforma.
Marketplace no impide Infrastructure as Code. Lo importante es tratar correctamente los términos, planes, identificadores y dependencias.
Aceptación de términos en imágenes de Marketplace
Algunas imágenes de Marketplace requieren aceptar términos antes de desplegarse. Azure CLI permite consultar y aceptar esos términos para una combinación concreta de publicador, oferta y plan.
El siguiente ejemplo usa placeholders porque los valores reales deben obtenerse desde la oferta correspondiente:
az vm image terms show \
--publisher "<publisher>" \
--offer "<offer>" \
--plan "<plan>"
az vm image terms accept \
--publisher "<publisher>" \
--offer "<offer>" \
--plan "<plan>"
Lo relevante no es solo el comando, sino el paso de gobierno que representa. Aceptar términos de Marketplace es una acción explícita sobre una oferta concreta. Si un pipeline no contempla este requisito, puede fallar aunque la plantilla de infraestructura sea correcta.
Despliegue de una VM basada en imagen de Marketplace
Una vez aceptados los términos, una VM basada en una imagen de Marketplace puede desplegarse indicando la referencia correspondiente. De nuevo, los valores deben validarse en la suscripción y región objetivo.
az vm create \
--resource-group "<resource-group>" \
--name "<vm-name>" \
--image "<publisher>:<offer>:<sku>:<version>" \
--admin-username "<admin-user>" \
--generate-ssh-keys \
--size "<vm-size>" \
--vnet-name "<vnet-name>" \
--subnet "<subnet-name>"
Este ejemplo muestra el patrón general para una VM Linux con autenticación por SSH. En producción habría que completarlo con decisiones sobre:
- Discos de datos.
- Cifrado.
- IP pública o privada.
- Network Security Groups.
- Rutas.
- Bastion o acceso administrativo seguro.
- Identidad administrada, si aplica.
- Monitorización.
- Backup.
- Etiquetas corporativas.
- Políticas.
- Gestión de parches.
Nota: no conviene inventar identificadores de imagen a partir del nombre comercial de una oferta. Publisher, offer, SKU, plan y versión deben obtenerse desde la ficha real o mediante consultas soportadas al catálogo.
Gobierno: quién puede comprar, desplegar y operar
Marketplace introduce una cuestión organizativa que no siempre aparece en los diagramas: ¿quién puede incorporar software de terceros al entorno cloud?
En una organización pequeña puede bastar con control manual. En una empresa con varias suscripciones, equipos y unidades de negocio, hace falta un modelo de gobierno.
RBAC y separación de responsabilidades
No todo usuario con acceso al portal debería poder desplegar cualquier oferta en cualquier suscripción. Las capacidades de compra, despliegue y administración deben alinearse con roles internos.
Un modelo razonable suele separar:
- Evaluación técnica.
- Aprobación de seguridad.
- Aprobación financiera.
- Despliegue.
- Operación.
- Soporte.
- Revisión periódica.
El equipo de plataforma puede mantener un catálogo aprobado, mientras que los equipos de producto consumen plantillas validadas.
Azure Policy
Los recursos creados a partir de Marketplace siguen estando sujetos al gobierno de Azure.
Azure Policy puede ayudar a controlar:
- Regiones permitidas.
- Tipos de recursos.
- Tamaños de VM.
- Uso de IP pública.
- Etiquetas obligatorias.
- Configuraciones de diagnóstico.
- Requisitos de cifrado.
- Restricciones de red.
- Cumplimiento de estándares internos.
Esto es especialmente importante en soluciones empaquetadas que crean varios recursos o sugieren configuraciones por defecto que no encajan con las políticas corporativas.
Catálogo interno
No todas las ofertas disponibles públicamente deberían estar aprobadas para todos los equipos.
Un catálogo interno puede incluir:
- Ofertas validadas.
- Versiones aprobadas.
- Plantillas IaC.
- Guías de configuración.
- Propietario operativo.
- Modelo de soporte.
- Límites de uso.
- Costes estimados.
- Procedimiento de baja.
De este modo, Marketplace actúa como origen de soluciones, pero la decisión final queda dentro del modelo de plataforma de la organización.
Seguridad y observabilidad
Una solución de Marketplace debe tratarse como cualquier otro componente de terceros. La revisión de seguridad no debería ser más laxa solo porque la oferta aparezca en un catálogo.
En imágenes de VM, el cliente suele tener que revisar y operar:
- Sistema operativo.
- Parches.
- Acceso administrativo.
- Usuarios locales.
- Claves SSH o credenciales.
- Extensiones instaladas.
- Configuración de red.
- Discos.
- Agentes de monitorización.
- Backups.
- Protección antimalware, si aplica.
- Registros de actividad.
En SaaS, la revisión se desplaza hacia:
- Identidad.
- Permisos.
- Datos tratados.
- Auditoría.
- Integraciones.
- Exportación.
- Contrato.
- Cumplimiento.
- Continuidad del proveedor.
En plataformas de logs hay un matiz adicional: el sistema puede concentrar información sensible. Los logs suelen contener identificadores, errores de aplicación, nombres de recursos, direcciones IP, trazas de usuario, payloads parciales o incluso secretos mal gestionados. Centralizar logs mejora la capacidad de análisis, pero también aumenta el impacto de una mala configuración de acceso.
La observabilidad de la propia solución también importa. Una oferta crítica debe integrarse con los mecanismos corporativos de monitorización: métricas, alertas, logs de actividad, estado de backups, uso de capacidad y costes.
Buenas prácticas para adoptar Azure Marketplace
La adopción madura de Marketplace empieza con una regla sencilla: ninguna oferta debería entrar en producción solo porque se despliega rápido.
Para pruebas de concepto:
- Usar suscripciones aisladas.
- Definir presupuesto.
- Evitar datos sensibles.
- Limitar exposición de red.
- Documentar configuración.
- Medir consumo.
- Validar eliminación limpia.
Para producción:
- Revisar publicador y soporte.
- Validar arquitectura.
- Automatizar despliegue.
- Aplicar políticas corporativas.
- Definir responsable operativo.
- Integrar con monitorización.
- Configurar backup y recuperación.
- Revisar costes.
- Documentar actualización y baja.
- Mantener revisión periódica.
El plan de salida suele olvidarse. Antes de depender de una solución de Marketplace hay que saber cómo exportar datos, migrar configuración, sustituir la herramienta o reconstruir el servicio si el publicador cambia condiciones.
En plataformas de logs, esto incluye formatos de exportación, retención, snapshots, dependencias de índices internos y compatibilidad con otros sistemas de análisis.
Cuándo usar Marketplace y cuándo no
Marketplace encaja bien cuando necesitamos:
- Acelerar una evaluación.
- Desplegar una appliance conocida.
- Consumir una solución de proveedor con soporte.
- Reducir trabajo inicial de instalación.
- Integrar adquisición y facturación con Azure.
- Probar herramientas antes de una adopción mayor.
- Incorporar componentes especializados que no aportan diferenciación si se construyen internamente.
No encaja tan bien cuando:
- Se necesita control extremo sobre cada dependencia.
- El publicador no ofrece garantías suficientes.
- La solución no permite automatización adecuada.
- El modelo de costes es opaco.
- El producto introduce una caja negra difícil de operar.
- No hay claridad sobre soporte o actualizaciones.
- La solución complica cumplimiento o residencia de datos.
- Se usa como atajo para evitar revisiones de seguridad o compras.
Azure Marketplace aporta velocidad, catálogo y empaquetado. La arquitectura aporta criterio. Cuando ambas cosas se combinan, el resultado puede ser muy potente: soluciones desplegables con rapidez, pero gobernadas con la misma disciplina que cualquier otro componente cloud.
Ahí es donde Marketplace deja de ser una simple tienda y se convierte en una pieza real del modelo operativo de Azure.