Alternativa ao AWS IoT Core: Quando um Broker MQTT Padrão é Mais Simples

Uma alternativa ao AWS IoT Core faz sentido quando o seu projeto precisa mais de um broker MQTT padrão do que de uma plataforma de IoT específica de uma nuvem. Este guia explica o que o AWS IoT Core oferece, quais diferenças avaliar, como os modelos de autenticação se comparam e quando um broker MQTT gerenciado baseado no padrão é o caminho mais simples, com código que você pode usar para testar os dois.

No que o AWS IoT Core é bom

O AWS IoT Core é um serviço gerenciado que conecta dispositivos à nuvem da AWS. Além de um endpoint MQTT, ele oferece registro e identidade de dispositivos, autenticação baseada em certificados X.509, IoT policies granulares, device shadows e um rules engine que roteia mensagens para outros serviços da AWS. Se o seu back-end já está na AWS e você quer os dados dos dispositivos fluindo para os serviços da AWS com pouco código de integração, essa integração é o principal motivo para escolhê-lo.

Este artigo não discute se o AWS IoT Core é bom; discute se ele tem o formato certo para o seu projeto. A AWS atualiza o serviço com frequência, então verifique cada ponto específico no guia do desenvolvedor do AWS IoT Core atual.

Quando as equipes procuram uma alternativa

Os motivos costumam se encaixar em alguns grupos:

• Precisam de um broker simples. O projeto é troca de mensagens entre dispositivos e aplicações, um dashboard ou um hub de dados industriais, não um pipeline de dados da AWS.
• O back-end não está na AWS. Ele roda em outra nuvem, on-premises ou em um modelo misto.
• Atrito no onboarding. O provisionamento de certificados por dispositivo é uma segurança forte, mas acrescenta etapas para protótipos, salas de aula e frotas pequenas.
• Preocupações com portabilidade. Querem dispositivos que possam migrar entre brokers mudando poucas configurações.
• Modelos de preço previsíveis. Algumas equipes preferem preços por plano à medição por uso. Qual sai mais barato depende inteiramente da sua carga de trabalho.

O que avaliar: AWS IoT Core vs. um broker MQTT padrão

A AWS publica uma página descrevendo onde a sua implementação de MQTT difere da especificação MQTT. Leia-a junto com os seus requisitos. A tabela lista o que verificar, em vez de afirmar detalhes atuais.

As duas últimas linhas são onde o AWS IoT Core oferece mais coisas integradas. Se elas forem centrais no seu projeto, ele pode ser a melhor escolha.

A diferença no modelo de autenticação

Essa costuma ser a maior diferença prática.

Um dispositivo típico do AWS IoT Core guarda um certificado de cliente e uma chave privada, além da CA raiz da Amazon, e se conecta com TLS mútuo. Policies anexadas ao certificado controlam onde ele pode publicar e o que pode assinar. É um modelo forte e, em escala, exige um processo de provisionamento.

Um broker padrão como a ConnectMQ usa TLS do lado do servidor com usuário, senha e client ID emitidos em um portal. Os dispositivos verificam o certificado Let's Encrypt do broker usando o repositório de CAs do sistema, e o client ID fica vinculado às credenciais emitidas. Começar é mais simples; a sua responsabilidade é armazenar as credenciais com segurança nos dispositivos.

Nenhum é melhor em todos os casos. Avalie qual modelo o tamanho da sua frota, os seus requisitos de segurança e o seu processo de fabricação conseguem sustentar.

Escrevendo código de dispositivo que funciona com os dois

A melhor forma de evitar o lock-in é isolar os detalhes de conexão da lógica da aplicação. Este exemplo MQTT.js v5 se conecta com certificado (no estilo do AWS IoT Core) ou com usuário e senha (broker padrão), e o restante do código permanece idêntico:

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

const mode = process.env.BROKER_MODE || "standard"; // "standard" ou "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));

Mantenha os nomes dos topics livres de prefixos específicos do provedor e evite depender, no firmware dos dispositivos, de recursos exclusivos de um provedor. Assim, trocar de provedor vira uma mudança de configuração. O artigo sobre vendor lock-in em MQTT lista os padrões a observar.

Substituindo recursos específicos da AWS

Se você migrar para um broker simples, planeje como cobrir os recursos que usava:

1. Rules engine. Rode um serviço assinante, um fluxo do Node-RED ou um agente Telegraf que leia os topics e grave no seu banco de dados ou API.
2. Device shadows. Publique o estado desejado e o reportado em topics retidos, como site1/area1/pump7/state/reported e .../state/desired.
3. Identidade da frota. Emita um conjunto de credenciais por dispositivo e mantenha um inventário no seu próprio sistema.
4. Monitoramento. Use o topic de estado de conexão do broker ($SYS/broker/connection/{clientId}/state na ConnectMQ) e o dashboard do portal.

Um caminho de migração de baixo risco

Se você decidir migrar alguns ou todos os dispositivos, faça isso em etapas em vez de uma virada única:

1. Espelhe primeiro. Rode um pequeno serviço de bridge que assine topics selecionados no endpoint atual e os republique no novo broker. Dashboards e novos consumidores podem então passar para o novo broker enquanto os dispositivos ficam onde estão.
2. Faça um piloto com um grupo de dispositivos. Regrave ou reconfigure um pequeno lote de dispositivos com o novo endpoint e as novas credenciais. Observe o comportamento de reconexão, as taxas de mensagens e os tamanhos de payload em relação aos limites do novo plano.
3. Migre as integrações. Substitua cada regra por um assinante externo ou um fluxo do Node-RED, um destino de dados por vez, e compare as saídas lado a lado.
4. Vire a frota em ondas, mantendo a configuração antiga disponível para rollback até que cada onda esteja estável.

Como os dois lados falam MQTT, cada etapa é reversível, e esse é o principal motivo para manter o firmware livre de dependências específicas de um provedor.

Um checklist de decisão

• A maior parte do seu back-end está na AWS e você usa muito o rules engine? O AWS IoT Core provavelmente é a melhor escolha.
• Você precisa de um broker neutro para dispositivos, aplicações e sistemas on-premises em vários ambientes, como plantas e usinas espalhadas pelo Brasil? Um broker padrão é mais simples.
• Você precisa de QoS 2 ou de recursos específicos do MQTT 5? Verifique o suporte atual dos dois lados.
• O provisionamento de certificados por dispositivo é viável para você hoje?
• A sua equipe consegue operar as integrações que um broker enxuto deixa para ferramentas externas?

Experimente um broker baseado no padrão

Você pode avaliar a alternativa sem migrar nada. Crie um broker Serverless gratuito, sem cartão de crédito, rode o script acima no modo padrão e inspecione o tráfego no explorador de topics ao vivo. Para mais contexto, leia o guia de broker MQTT na nuvem, compare com a alternativa ao Azure IoT Hub e veja como um broker MQTT gerenciado difere de uma plataforma de IoT. Saiba mais em connectmq.com.

Perguntas frequentes

Dispositivos feitos para o AWS IoT Core conseguem se conectar a outro broker MQTT?

Sim, se usarem MQTT padrão. Normalmente você muda o endpoint, troca a autenticação por certificado pelo método do novo broker e remove qualquer uso de topics específicos da AWS.

Um broker padrão substitui o rules engine do AWS IoT?

Não sozinho. Você adiciona um assinante externo, o Node-RED ou o Telegraf para rotear os dados, o que mantém cada peça substituível.

O AWS IoT Core é mais seguro que um broker com usuário e senha?

TLS mútuo com certificados por dispositivo é um modelo forte. Um broker que usa TLS com credenciais únicas por dispositivo também é sólido quando as credenciais são armazenadas e rotacionadas corretamente.

Onde devo verificar os limites do AWS IoT Core?

Use o guia do desenvolvedor do AWS IoT Core e as páginas de service quotas atuais, já que limites e recursos suportados mudam.