Broker MQTT en la nube: la guía completa de MQTT alojado

Un broker MQTT en la nube ofrece a tus dispositivos, aplicaciones y servicios un centro de mensajería fiable y accesible desde internet sin que tengas que instalar, parchear ni escalar un servidor. Esta guía explica qué es un broker alojado, en qué se diferencian los modelos de despliegue, qué revisar en cuanto a seguridad, límites y coste, y cómo pasar de un prototipo en el portátil a producción. Al final tendrás una conexión funcionando con un broker privado y una lista de comprobación para elegir proveedor.

¿Qué es un broker MQTT en la nube?

Un broker MQTT es el servidor que recibe cada mensaje publicado y lo enruta a todos los suscriptores que coinciden. Si necesitas repasar ese papel, empieza por qué hace un broker MQTT. Un broker MQTT en la nube es ese mismo software ejecutándose en una infraestructura operada por un proveedor y expuesto mediante un nombre de host público. Tú obtienes endpoints, credenciales y una consola de gestión; el proveedor se ocupa de los servidores, los sistemas operativos, los certificados TLS, las actualizaciones y la capacidad.

La diferencia con "una VM con Mosquitto instalado" es la responsabilidad. Con una VM en la nube, el broker sigue siendo tuyo: la configuración, los certificados, la monitorización, los parches de seguridad y la caída de las 3 de la madrugada. Con un broker alojado, todo eso pasa a ser trabajo del proveedor y tú consumes MQTT como un servicio. Ese modelo suele llamarse broker MQTT como servicio, y es la razón por la que la mayoría de los proyectos IoT nuevos empiezan en la nube y no en un servidor guardado en un armario.

Por qué los equipos llevan MQTT a la nube

• Accesibilidad. Los dispositivos en campo se conectan por internet a un único nombre de host estable, sin reglas de firewall entrantes ni redirección de puertos en cada ubicación.
• Tiempo hasta el primer mensaje. Crear un broker lleva minutos en lugar de días de bastionado de servidores.
• Carga operativa. Las renovaciones de certificados, los parches del sistema operativo, las actualizaciones del broker y la planificación de capacidad dejan de ser trabajo de tu equipo.
• Crecimiento elástico. Pasar de diez dispositivos de prueba a miles es un cambio de plan, no una rearquitectura.
• Herramientas integradas. Un buen proveedor incluye un cliente web, un explorador de topics y visibilidad de las conexiones, que de otro modo tendrías que montar tú.

Los inconvenientes también son reales: dependes de la disponibilidad y la hoja de ruta del proveedor, los datos salen de tus instalaciones y trabajas dentro de las cuotas del plan. Sopesamos ambos lados en broker MQTT autoalojado vs gestionado.

Modelos de despliegue de un broker MQTT en la nube

"Broker en la nube" abarca varias arquitecturas muy distintas. Saber cuál estás contratando importa más que cualquier lista de funciones.

Serverless

Un broker MQTT serverless se ejecuta en un clúster compartido y multi-tenant. Creas un broker en segundos, pagas poco o nada a pequeña escala y nunca piensas en instancias. Los buenos proveedores aplican un aislamiento estricto entre tenants, cuotas por plan y protección contra inundaciones para que un tenant ruidoso no perjudique a los demás. Las restricciones son los límites de conexiones, tamaño de mensaje y rendimiento que fija el plan. Cómo funciona ese aislamiento se explica en brokers MQTT multi-tenant.

Dedicado

Un broker MQTT dedicado te da un clúster aislado. Nadie más comparte tu CPU, tu memoria ni tu red, así que la latencia y el rendimiento son más predecibles, y los límites se dimensionan para tu carga de trabajo en lugar de para un nivel compartido.

BYOC

Con un broker MQTT BYOC, el broker se ejecuta dentro de tu propia cuenta en la nube, de modo que los datos permanecen en una infraestructura que controlas y el gasto computa en tus acuerdos de nube existentes, mientras el proveedor sigue operando el broker por ti. Suele ser la respuesta para sectores regulados; consulta residencia de datos en MQTT para la parte de cumplimiento normativo.

Enterprise autogestionado

Algunos entornos, como las plantas sin salida a internet, no pueden usar ningún servicio externo. Una edición autogestionada te permite ejecutar el mismo software de broker en tu propio hardware, operado por tu equipo.

Seguridad en un broker MQTT alojado

Pasar a la nube pone tu broker en internet, así que la seguridad no es opcional. Lo esencial, por orden de importancia:

1. TLS en todas las conexiones. Usa el puerto 8883 para MQTT sobre TLS y el 8084 para WebSocket seguro. El 1883 sin cifrar solo es aceptable para pruebas desechables con datos no sensibles.
2. Credenciales únicas por dispositivo o servicio. Las contraseñas compartidas convierten un dispositivo comprometido en una flota comprometida.
3. Vinculación del client ID. Cuando los client IDs están ligados a las credenciales emitidas, una contraseña robada no puede usarse para suplantar a otro dispositivo.
4. Protección contra fuerza bruta. El broker debe bloquear las direcciones IP tras varios inicios de sesión fallidos.
5. Aislamiento entre tenants. En una infraestructura compartida, verifica que los topics de un cliente son invisibles para los de otro.
6. Protección contra inundaciones y cuotas. Un cliente defectuoso atrapado en un bucle de publicación debe ser limitado, no poder tumbar el broker.
7. Higiene del payload. Nunca pongas secretos ni datos personales en los nombres de los topics; las cadenas de topic aparecen en logs y herramientas.

La lista completa, incluido el certificate pinning en dispositivos y la rotación de credenciales, está en nuestras buenas prácticas de seguridad en MQTT.

Límites y cuotas que debes entender

Todo broker alojado aplica límites, y condicionan tu diseño más de lo que la mayoría espera. Pide estas cifras antes de comprometerte:

Cuando un cliente supera una cuota en un broker MQTT 5, recibe un reason code en lugar de un descarte silencioso; el 0x97 (Quota exceeded) es el que debes vigilar. Nuestro artículo sobre cuotas de conexión en brokers MQTT explica cómo dimensionarlas.

Cómo funcionan los precios de MQTT en la nube

Los proveedores fijan el precio de MQTT alojado de unas pocas formas reconocibles:

• Por número de conexiones, a menudo el factor dominante en flotas de dispositivos.
• Por volumen de mensajes o rendimiento, lo que importa en la telemetría de alta frecuencia.
• Por clúster o instancia, habitual en despliegues dedicados.
• Por nivel de funciones, donde QoS 2, mensajes más grandes o suscripciones compartidas se desbloquean en planes superiores.

El plan más barato sobre el papel no siempre es el sistema más barato. Ten en cuenta el tiempo de ingeniería dedicado a operaciones, el coste de las caídas y el esfuerzo de marcharte si el proveedor no funciona. Precios de brokers MQTT desglosa los modelos, y coste total de propiedad compara el gasto gestionado y autoalojado a lo largo del tiempo. El riesgo de dependencia es mínimo cuando el proveedor habla MQTT estándar sin un SDK propietario, algo que tratamos en cómo evitar la dependencia de proveedor en MQTT.

Conectarse a un broker MQTT en la nube: práctica

La forma más rápida de entender MQTT alojado es usarlo. Empieza con el servidor MQTT público gratuito en broker.connectmq.com, que no necesita cuenta. Usa un client ID único y un prefijo de topic único, y recuerda que cualquiera puede leer el área pública: sirve para pruebas y prototipos, nunca para datos de producción.

# Terminal 1: suscribirse
mosquitto_sub -h broker.connectmq.com -p 1883 -i cloud-sub-r4t7 \
  -t "connectmq/demo/r4t7w2/#" -v

# Terminal 2: publicar
mosquitto_pub -h broker.connectmq.com -p 1883 -i cloud-pub-r4t7 \
  -t "connectmq/demo/r4t7w2/sensor1/temp" -m "22.4"

Para un broker privado, el flujo es este:

1. Regístrate en app.connectmq.com y elige un plan.
2. Crea un broker.
3. Copia del portal el nombre de usuario, la contraseña y el client ID generados.
4. Conéctate por TLS en el puerto 8883 (o por WSS en el 8084 con la ruta /mqtt desde navegadores).

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i YOUR_CLIENT_ID -u YOUR_USERNAME -P YOUR_PASSWORD \
  -t "plant1/#" -v

El certificado lo emite Let's Encrypt, así que los paquetes de CA estándar lo verifican. En macOS y Windows usa --cafile con un archivo de paquete de CA en lugar de --capath.

Un cliente de estilo producción en Python

Este cliente con paho-mqtt 2.x se conecta con credenciales, anuncia su presencia con un estado retenido y un Last Will, y usa la caducidad de mensajes de MQTT 5 para que las lecturas obsoletas no se entreguen a suscriptores que se conecten mucho después:

import json
import time

import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

BASE = "plant1/line1/sensor1"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd", qos=1)

def on_message(client, userdata, msg):
    print("Command:", msg.payload.decode())

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="YOUR_CLIENT_ID",
    protocol=mqtt.MQTTv5,
)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.on_connect = on_connect
client.on_message = on_message

client.connect("broker.connectmq.com", 8883, keepalive=30)
client.loop_start()

props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 60  # segundos

while True:
    payload = json.dumps({"temp": 22.4, "ts": int(time.time())})
    client.publish(f"{BASE}/telemetry", payload, qos=1, properties=props)
    time.sleep(10)

En el portal de ConnectMQ puedes ver cómo llegan estos mensajes en el explorador de topics en tiempo real, enviar un comando de vuelta desde el cliente MQTT del navegador y comprobar si un cliente concreto está conectado suscribiéndote a $SYS/broker/connection/{clientId}/state.

Integrar un broker en la nube con el resto de tu stack

Un broker enruta mensajes; no los guarda en tu base de datos ni llama a tus APIs. El patrón limpio y portable es conectar las herramientas de integración como clientes MQTT normales:

• Almacenamiento de series temporales: el consumidor MQTT de Telegraf escribiendo en InfluxDB, o un pequeño suscriptor en Python escribiendo en PostgreSQL o TimescaleDB.
• Flujos y automatización: Node-RED con un nodo de configuración mqtt-broker apuntando a tu broker en el 8883 con TLS.
• Dashboards: Grafana sobre la base de datos, o una app de navegador con MQTT.js sobre WSS.
• Hogar inteligente: la integración MQTT de Home Assistant.

Como cada uno de ellos es un cliente estándar, puedes cambiar o añadir herramientas sin tocar el firmware de los dispositivos. Para consumidores de backend con balanceo de carga, las suscripciones compartidas de MQTT 5 ($share/group/topic) reparten los mensajes entre varios workers; normalmente se reservan para los niveles de pago, como en la tabla de planes de más abajo.

Cómo elegir un proveedor de broker MQTT en la nube

Usa esta lista de comprobación al comparar proveedores. Complementa nuestra guía más amplia sobre cómo elegir un broker MQTT para IoT.

1. Admite MQTT 3.1.1 y 5.0 con clientes estándar, sin necesidad de un SDK propietario.
2. Ofrece endpoints TLS y WebSocket seguro con un certificado de confianza pública.
3. Publica cuotas claras de conexiones, tamaño de mensaje, QoS y tasa.
4. Ofrece un nivel gratuito o un broker público de pruebas para validar tus clientes antes de pagar.
5. Ofrece un camino del entorno compartido al dedicado o BYOC sin cambiar el código de los clientes.
6. Te da visibilidad: estado de las conexiones, vista de topics en tiempo real y alertas sobre los valores que importan.
7. Documenta el aislamiento entre tenants y la protección contra abusos en los planes compartidos.
8. Responde por escrito a tus preguntas sobre residencia de datos y soporte.

Antes del lanzamiento, repasa la checklist de producción para MQTT, y si vienes de un Mosquitto autoalojado, los pasos de migrar Mosquitto a un broker MQTT en la nube te ahorrarán algunas sorpresas. Una vez en marcha, monitorización de brokers MQTT explica qué señales vigilar.

Cómo encaja ConnectMQ

ConnectMQ es un broker MQTT gestionado construido en torno a los modelos de despliegue descritos arriba:

Todos los brokers admiten MQTT 3.1.1 y 5.0 en TCP 1883, TLS 8883, WebSocket 8083 y WebSocket seguro 8084, con un certificado de Let's Encrypt. El portal incluye un cliente MQTT en el navegador, un explorador de topics en tiempo real, un dashboard, una vista de dispositivos organizada por niveles ISA-95 y reglas de alerta por umbral con un registro de alertas, en inglés o turco. En el plano de la seguridad tienes aislamiento multi-tenant, cuotas por plan, protección contra inundaciones, bloqueo de IP tras varios inicios de sesión fallidos y client IDs vinculados a las credenciales emitidas. Para los usuarios industriales, ConnectMQ también detecta topics ISA-95 y Unified Namespace y decodifica payloads Sparkplug B.

Lo que deliberadamente no hace es sustituir tu stack de datos: no hay un motor de reglas integrado ni un puente a bases de datos, así que el almacenamiento y la automatización se resuelven con clientes MQTT estándar como Telegraf, Node-RED o tus propios servicios, tal como se describe arriba.

Empieza gratis con tu broker MQTT en la nube

Prueba hoy tus clientes en broker.connectmq.com y después crea un broker privado en app.connectmq.com. El plan Serverless gratuito no requiere tarjeta de crédito, y las mismas credenciales y el mismo código te sirven cuando pases a un plan de pago, dedicado o BYOC.

Preguntas frecuentes

¿Qué diferencia hay entre un broker MQTT en la nube y un broker MQTT gestionado?

En la práctica, los términos se solapan. "En la nube" describe dónde se ejecuta el broker y cómo llegan a él los dispositivos, mientras que "gestionado" describe quién lo opera; la mayoría de las ofertas alojadas son ambas cosas, pero una VM con tu propio Mosquitto está alojada en la nube sin estar gestionada.

¿Es un broker MQTT en la nube lo bastante seguro para datos industriales?

Puede serlo, si usas TLS en todas las conexiones, credenciales únicas por dispositivo y un modelo de despliegue que se ajuste a tus requisitos. Las plantas con normas estrictas de residencia de datos suelen elegir despliegues dedicados o BYOC en lugar de un nivel compartido.

¿Puedo usar un broker MQTT gratuito en la nube en producción?

Un nivel gratuito es adecuado para despliegues pequeños y no críticos dentro de sus límites, como hasta 25 conexiones en el plan Serverless gratuito de ConnectMQ. El broker público anónimo nunca es adecuado para producción, porque cualquiera puede leer su área pública.

¿Necesito un SDK especial para conectarme a un broker MQTT alojado?

No con un proveedor basado en estándares. Cualquier cliente MQTT 3.1.1 o 5.0 funciona, incluidos paho-mqtt, MQTT.js, MQTTnet, PubSubClient y las herramientas CLI de Mosquitto.

¿Cómo guardo en una base de datos los datos de un broker MQTT en la nube?

Ejecuta un suscriptor que escriba en tu base de datos, como Telegraf para InfluxDB o un breve script de Python para PostgreSQL. El broker entrega los mensajes; el suscriptor decide dónde se almacenan.