Alternativa a AWS IoT Core: broker MQTT estándar

Una alternativa a AWS IoT Core tiene sentido cuando tu proyecto necesita más un broker MQTT estándar que una plataforma IoT ligada a una nube concreta. Esta guía explica qué ofrece AWS IoT Core, qué diferencias conviene evaluar, cómo se comparan los modelos de autenticación y cuándo un broker MQTT gestionado basado en estándares es el camino más sencillo, con código que puedes usar para probar ambos.

En qué destaca AWS IoT Core

AWS IoT Core es un servicio gestionado que conecta dispositivos con la nube de AWS. Además de un endpoint MQTT, ofrece registro e identidad de dispositivos, autenticación basada en certificados X.509, políticas IoT detalladas, device shadows y un rules engine que enruta mensajes a otros servicios de AWS. Si tu back end ya está en AWS y quieres que los datos de los dispositivos fluyan hacia servicios de AWS con poco código intermedio, esa integración es el principal motivo para elegirlo.

Este artículo no trata de si AWS IoT Core es bueno, sino de si tiene la forma adecuada para tu proyecto. AWS actualiza el servicio con regularidad, así que verifica cada punto concreto en la guía para desarrolladores actual de AWS IoT Core.

Cuándo buscan los equipos una alternativa

Los motivos suelen agruparse en unos pocos grupos:

Necesitan un broker sin más. El proyecto consiste en mensajería entre dispositivos y aplicaciones, un dashboard o un hub de datos industrial, no en un pipeline de datos de AWS.
Su back end no está en AWS. Se ejecuta en otra nube, on-premises o en una combinación.
Fricción en el alta de dispositivos. El aprovisionamiento de certificados por dispositivo es una seguridad sólida, pero añade pasos para prototipos, aulas y flotas pequeñas.
Preocupación por la portabilidad. Quieren dispositivos que puedan pasar de un broker a otro cambiando unos pocos ajustes.
Modelos de precios predecibles. Algunos equipos prefieren precios por plan a una facturación por uso. Cuál resulta más barato depende por completo de tu carga de trabajo.

Qué evaluar: AWS IoT Core vs un broker MQTT estándar

AWS publica una página que describe en qué difiere su implementación de MQTT de la especificación MQTT. Léela junto a tus requisitos. La tabla enumera qué comprobar en lugar de afirmar detalles actuales.

Área	Qué comprobar en la documentación actual de AWS IoT Core	Broker basado en estándares (ConnectMQ)
Versiones del protocolo	Versiones de MQTT admitidas y qué funciones de MQTT 5 están implementadas	MQTT 3.1.1 y 5.0
Niveles de QoS	Qué niveles de QoS se admiten para publicar y suscribirse	QoS 0-1 en Serverless gratuito, QoS 0-2 en los planes de pago
Retained messages	Soporte, límites y precio de los retained messages	Admitidos
Reglas de topics	Prefijos de topic reservados, límites de longitud y de niveles	Topics estándar; `$SYS` para el estado del broker
Autenticación	Certificados X.509, autorizadores personalizados, opciones de usuario/contraseña	Usuario, contraseña y client ID generados
Autorización	Modelo de políticas IoT y cómo se relaciona con los topics	Aislamiento de tenants, client IDs vinculados a las credenciales
Límites de payload y de tasa	Tamaño de mensaje, tasas de publicación, tasas de conexión	Cuotas por plan, p. ej. mensajes de 256 KB o 1 MB
Enrutamiento de datos	Rules engine hacia servicios de AWS	Clientes MQTT externos (Node-RED, Telegraf, tus servicios)
Estado del dispositivo	Servicio de device shadow	Retained messages y tus propios topics de estado

Las dos últimas filas son donde AWS IoT Core ofrece más de serie. Si son centrales en tu diseño, puede que sea la mejor opción.

La diferencia en el modelo de autenticación

Esta suele ser la mayor diferencia práctica.

Un dispositivo típico de AWS IoT Core guarda un certificado de cliente y una clave privada, además de la CA raíz de Amazon, y se conecta con TLS mutuo. Las políticas asociadas al certificado controlan en qué puede publicar y a qué puede suscribirse. Es un modelo sólido y, a escala, requiere un proceso de aprovisionamiento.

Un broker estándar como ConnectMQ usa TLS del lado del servidor con un usuario, una contraseña y un client ID emitidos en un portal. Los dispositivos verifican el certificado de Let's Encrypt del broker con el almacén de CA del sistema, y el client ID está vinculado a las credenciales emitidas. Empezar es más sencillo; tu responsabilidad es almacenar las credenciales de forma segura en los dispositivos.

Ninguno es mejor en todos los casos. Evalúa qué modelo pueden soportar el tamaño de tu flota, tus requisitos de seguridad y tu proceso de fabricación.

Código de dispositivo que funcione con ambos

La mejor forma de evitar el lock-in es aislar los detalles de conexión de la lógica de la aplicación. Este ejemplo de MQTT.js v5 se conecta con un certificado (al estilo de AWS IoT Core) o con usuario y contraseña (broker estándar), y el resto del código permanece idéntico:

// npm install mqtt
const fs = require("fs");
const mqtt = require("mqtt");

const mode = process.env.BROKER_MODE || "standard"; // "standard" or "certificate"

const options = {
  clientId: process.env.MQTT_CLIENT_ID || "YOUR_CLIENT_ID",
  protocolVersion: 5,
  reconnectPeriod: 5000,
};

let url;
if (mode === "certificate") {
  url = `mqtts://${process.env.MQTT_ENDPOINT}:8883`;
  options.key = fs.readFileSync("device.private.key");
  options.cert = fs.readFileSync("device.cert.pem");
  options.ca = fs.readFileSync("root-ca.pem");
} else {
  url = "mqtts://broker.connectmq.com:8883";
  options.username = process.env.MQTT_USERNAME || "YOUR_USERNAME";
  options.password = process.env.MQTT_PASSWORD || "YOUR_PASSWORD";
}

const client = mqtt.connect(url, options);
const topic = "site1/area1/pump7/telemetry";

client.on("connect", () => {
  console.log("Connected in", mode, "mode");
  setInterval(() => {
    const reading = { pressure: 2.4 + Math.random() * 0.2, ts: Date.now() };
    client.publish(topic, JSON.stringify(reading), { qos: 1 });
  }, 5000);
});

client.on("error", (err) => console.error("MQTT error:", err.message));

Mantén los nombres de los topics libres de prefijos propios del proveedor y evita depender desde el firmware de funciones exclusivas de un proveedor. Así, cambiar de proveedor es solo un cambio de configuración. El artículo sobre vendor lock-in en MQTT enumera los patrones que conviene vigilar.

Sustituir las funciones específicas de AWS

Si pasas a un broker sin más, planifica cómo cubrir las funciones que usabas:

Rules engine. Ejecuta un servicio suscriptor, un flujo de Node-RED o un agente de Telegraf que lea los topics y escriba en tu base de datos o API.
Device shadows. Publica el estado deseado y el notificado en topics retenidos como site1/area1/pump7/state/reported y .../state/desired.
Identidad de la flota. Emite un juego de credenciales por dispositivo y mantén un inventario en tu propio sistema.
Monitorización. Usa el topic de estado de conexión del broker ($SYS/broker/connection/{clientId}/state en ConnectMQ) y el dashboard del portal.

Una ruta de migración de bajo riesgo

Si decides mover algunos dispositivos o todos, hazlo por etapas en lugar de con un único corte:

Primero, replica. Ejecuta un pequeño servicio puente que se suscriba a topics seleccionados en el endpoint actual y los republique en el nuevo broker. Así, los dashboards y los nuevos consumidores pueden pasar al nuevo broker mientras los dispositivos siguen donde están.
Pilota con un grupo de dispositivos. Reprograma o reconfigura un lote pequeño de dispositivos con el nuevo endpoint y las nuevas credenciales. Vigila el comportamiento de reconexión, las tasas de mensajes y el tamaño de los payloads frente a los límites del nuevo plan.
Traslada las integraciones. Sustituye cada regla por un suscriptor externo o un flujo de Node-RED, un destino de datos cada vez, y compara los resultados en paralelo.
Migra la flota por oleadas, manteniendo disponible la configuración anterior para poder volver atrás hasta que cada oleada sea estable.

Como ambos lados hablan MQTT, cada etapa es reversible, y esa es la principal razón para mantener el firmware libre de dependencias de un proveedor concreto.

Lista de decisión

¿Está la mayor parte de tu back end en AWS y usas mucho el rules engine? AWS IoT Core probablemente encaje mejor.
¿Necesitas un broker neutral para dispositivos, aplicaciones y sistemas on-premises en distintos entornos? Un broker estándar es más sencillo.
¿Necesitas QoS 2 o funciones concretas de MQTT 5? Comprueba el soporte actual en ambos lados.
¿Es viable hoy para ti aprovisionar certificados por dispositivo?
¿Puede tu equipo gestionar las integraciones que un broker ligero deja en manos de herramientas externas?

Prueba un broker basado en estándares

Puedes evaluar la alternativa sin migrar nada. Crea un broker Serverless gratuito sin tarjeta de crédito, ejecuta el script anterior en modo estándar e inspecciona el tráfico en el explorador de topics en vivo. Para un primer experimento sin registro, el servidor MQTT público gratuito de broker.connectmq.com sirve para pruebas y prototipos, nunca para datos de producción. Para más contexto, lee la guía de brokers MQTT en la nube, compara con la alternativa a Azure IoT Hub y descubre en qué se diferencia un broker MQTT gestionado de una plataforma IoT. Más información en connectmq.com.

Preguntas frecuentes

¿Pueden los dispositivos diseñados para AWS IoT Core conectarse a otro broker MQTT?

Sí, si usan MQTT estándar. Normalmente cambias el endpoint, pasas de la autenticación por certificado al método del nuevo broker y eliminas cualquier uso de topics específicos de AWS.

¿Sustituye un broker estándar al rules engine de AWS IoT?

No por sí solo. Añades un suscriptor externo, Node-RED o Telegraf para enrutar los datos, lo que mantiene cada pieza sustituible.

¿Es AWS IoT Core más seguro que un broker con usuario y contraseña?

El TLS mutuo con certificados por dispositivo es un modelo sólido. Un broker que usa TLS con credenciales únicas por dispositivo también es seguro cuando las credenciales se almacenan y rotan correctamente.

¿Dónde debo consultar los límites de AWS IoT Core?

En la guía para desarrolladores actual de AWS IoT Core y en las páginas de cuotas del servicio, ya que los límites y las funciones admitidas cambian.

Alternativa a AWS IoT Core: cuándo un broker MQTT estándar es más sencillo