Um broker MQTT BYOC roda dentro da sua própria conta de nuvem enquanto um provedor especializado cuida do trabalho operacional. Este artigo explica como funciona o modelo bring your own cloud, onde ficam as responsabilidades, quando ele é a escolha certa em vez da hospedagem compartilhada ou dedicada e como preparar a sua conta antes da implantação.
O Que É um Broker MQTT BYOC?
"Bring your own cloud" (traga sua própria nuvem) descreve um modelo de implantação em que o software roda em uma infraestrutura que você possui e paga, normalmente em uma conta ou assinatura de nuvem sob controle da sua organização, enquanto o fornecedor a gerencia. As máquinas virtuais ou contêineres do broker, a rede, os discos e os load balancers ficam na sua conta. Os engenheiros ou a automação do provedor implantam, configuram, atualizam e monitoram o broker por meio do acesso que você concede.
Compare isso com as duas opções de hospedagem mais conhecidas:
- Hospedagem compartilhada (serverless). Muitos clientes compartilham um cluster que roda na conta do provedor. Você recebe endpoints e credenciais em minutos e não paga por capacidade ociosa, mas não escolhe a infraestrutura subjacente.
- Hospedagem dedicada. Você recebe o seu próprio cluster isolado, ainda na conta do provedor. O desempenho não é compartilhado com ninguém, mas a infraestrutura continua pertencendo ao fornecedor.
- BYOC. O seu próprio broker isolado, na sua própria conta. O tráfego de mensagens passa por uma infraestrutura que você controla, sob as suas políticas de segurança em nuvem e o seu faturamento.
Se você ainda está conhecendo o papel dos brokers em um sistema IoT, o que um broker MQTT faz cobre o básico.
Por Que as Equipes Escolhem Bring Your Own Cloud
Controle de Dados e Conformidade
O motivo mais comum é o controle dos dados. Algumas organizações, como uma mineradora, uma distribuidora de energia ou uma empresa de saneamento, têm uma política de que os dados de produção, incluindo a telemetria dos dispositivos, precisam ficar dentro de contas que elas possuem (especialmente quando há dados pessoais sujeitos à LGPD), onde valem os seus próprios logs, chaves de criptografia, controles de rede e auditorias. Uma implantação BYOC permite que a camada MQTT cumpra essa política sem que a equipe precise virar operadora de brokers. Nosso guia de residência de dados MQTT aprofunda as questões de localização e regulação.
Proximidade de Rede
Quando os seus consumidores, como processadores de streams, bancos de dados e serviços de analytics, já rodam em uma conta e região de nuvem específicas, colocar o broker ao lado deles mantém o tráfego em rede privada. Assinantes dentro da sua rede virtual podem se conectar sem passar pela internet pública, enquanto os dispositivos continuam acessando um endpoint público.
Aproveitamento de Compromissos de Nuvem Existentes
Muitas empresas negociaram compromissos de consumo com um provedor de nuvem. Rodar a infraestrutura do broker na sua conta faz com que os gastos de computação e rede contem para esses compromissos e apareçam nos seus relatórios de custos atuais.
Revisão de Segurança Mais Simples
Equipes de segurança costumam achar mais fácil aprovar uma infraestrutura que fica em uma conta que já monitoram, sob políticas que já aplicam, do que avaliar do zero um novo ambiente de terceiros.
Quem É Responsável pelo Quê em uma Implantação BYOC
A divisão exata é definida pelo seu contrato com o provedor, mas o padrão típico é este:
| Área | Você (dono da conta) | Provedor (operador) |
|---|---|---|
| Conta de nuvem, faturamento, políticas da organização | Sim | Não |
| Design de rede, faixas de IP, peering, política de firewall | Aprova e é dono | Propõe e implementa as partes específicas do broker |
| Instalação e configuração do broker | Revisa | Sim |
| Upgrades e patches de segurança do broker | Aprova janelas de manutenção | Sim |
| Certificados TLS dos endpoints do broker | Decisões de domínio | Emissão e renovação |
| Monitoramento da saúde do broker e resposta a incidentes | Contato de escalonamento | Sim |
| Firmware dos dispositivos e aplicações cliente | Sim | Não |
| Consumidores de dados e integrações downstream | Sim | Não |
A ideia central: você mantém a propriedade e a visibilidade da infraestrutura, e o provedor fica com a carga operacional. Vocês devem acordar por escrito o escopo de acesso, as janelas de manutenção, os caminhos de escalonamento e como o acesso é revogado.
BYOC vs Compartilhado, Dedicado e Auto-Hospedado
| Critério | Serverless compartilhado | Dedicado | BYOC | Auto-hospedado |
|---|---|---|---|---|
| Onde a infraestrutura roda | Conta do provedor | Conta do provedor | Sua conta | Sua conta ou data center |
| Quem opera o broker | Provedor | Provedor | Provedor | Sua equipe |
| Isolamento de outros clientes | Lógico | Cluster físico | Físico, na sua conta | Total |
| Tempo até a primeira conexão | Minutos | Curto | Mais longo (configuração da conta) | Depende da sua equipe |
| Conta de infraestrutura | Incluída no plano | Incluída no plano | Sua fatura de nuvem mais o serviço | Sua fatura de nuvem ou de hardware |
| Seu esforço operacional | Muito baixo | Muito baixo | Baixo | Alto |
O BYOC fica entre a hospedagem dedicada e a auto-hospedagem. Se não tiver certeza de que precisa dele, um broker MQTT dedicado muitas vezes oferece isolamento suficiente com menos configuração. Se você quer controle total e tem pessoas para operar, compare o esforço em broker MQTT auto-hospedado vs gerenciado.
Como Funciona o BYOC do ConnectMQ
O ConnectMQ oferece BYOC como um dos seus planos: o broker roda na sua conta de nuvem e é gerenciado para você. Ele se comporta da mesma forma que nos outros planos. Os clientes se conectam usando MQTT 3.1.1 ou MQTT 5.0 nas portas padrão, TCP 1883, TLS 8883, WebSocket 8083 e Secure WebSocket 8084 com caminho /mqtt, então firmware e aplicações escritos para um broker Serverless ou Dedicated não precisam de alterações no código, apenas de novos dados de conexão.
Os recursos da plataforma continuam disponíveis: credenciais geradas com client IDs vinculados a elas, isolamento multi-tenant e cotas por plano, proteção contra flood, bloqueio de IP após repetidas falhas de login, recursos do MQTT 5 como shared subscriptions, session expiry e message expiry, e decodificação de Sparkplug B com republicação em topics ISA-95 para projetos industriais.
Como o BYOC depende do seu ambiente de nuvem, confirme diretamente com a equipe os provedores de nuvem, as regiões e o modelo de acesso suportados antes de planejar a implantação.
Preparando a Sua Conta de Nuvem
Seja qual for o provedor, a mesma preparação encurta o onboarding de BYOC:
- Crie uma conta ou assinatura dedicada para o broker, para que permissões, faturamento e logs de auditoria fiquem separados de outras cargas de trabalho.
- Escolha a região com base em onde os dispositivos se conectam, onde os consumidores rodam e em eventuais requisitos de residência.
- Reserve faixas de rede que não colidam com as suas VPCs atuais ou redes on-premises, caso planeje peering ou conectividade VPN.
- Verifique as cotas de serviço para instâncias de computação, load balancers e endereços IP públicos nessa região.
- Defina o modelo de acesso: um papel com escopo restrito que o provedor possa assumir, com logs habilitados e uma forma documentada de revogá-lo.
- Decida sobre o DNS dos endpoints do broker e quem gerencia os registros.
- Acorde janelas de manutenção e como você será notificado antes dos upgrades.
- Configure tags de custo para que a infraestrutura do broker fique visível nos seus relatórios.
Valide Seus Clientes Antes da Migração
Enquanto o ambiente BYOC está sendo preparado, você pode testar o comportamento dos clientes contra o servidor MQTT público (gratuito, apenas para testes, nunca para dados de produção) e depois contra um broker privado gratuito. Este exemplo em Python usa paho-mqtt 2.x e se conecta via TLS. Depois, substitua o host e as credenciais pelo seu endpoint BYOC; nada mais muda.
import ssl
import paho.mqtt.client as mqtt
HOST = "broker.connectmq.com" # substitua pelo seu endpoint BYOC
PORT = 8883
CLIENT_ID = "YOUR_CLIENT_ID"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("connectmq/demo/byoc-7c21/#", qos=1)
client.publish("connectmq/demo/byoc-7c21/status", "online", qos=1, retain=True)
def on_message(client, userdata, msg):
print(msg.topic, msg.payload.decode())
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
protocol=mqtt.MQTTv5)
# Para um broker privado, descomente:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT, keepalive=60)
client.loop_forever()
Rode o mesmo script em cada ambiente e mantenha a estrutura de topics idêntica. Quando o broker BYOC entrar no ar, a troca será apenas uma mudança de configuração.
Armadilhas Comuns
- Acesso amplo demais para o operador. Conceda apenas o que o broker precisa e registre cada ação em log.
- Esquecer os custos de egress. Se dispositivos ou consumidores estiverem em outras regiões ou nuvens, tarifas de transferência de dados aparecerão na sua fatura.
- Bloquear upgrades. Políticas que impedem o operador de aplicar patches criam o mesmo risco de um broker auto-hospedado sem manutenção.
- Não ter ambiente de staging. Mantenha um pequeno broker de não produção, por exemplo no plano Serverless gratuito, para testes de firmware e integração.
Comece com o ConnectMQ
Você pode explorar a plataforma hoje mesmo no plano Serverless gratuito, sem cartão de crédito, em app.connectmq.com. Desenvolva e teste seus dispositivos ali e depois converse com a equipe sobre migrar para BYOC quando os seus requisitos de controle de dados exigirem. Para uma visão mais ampla das opções de hospedagem, leia o guia de broker MQTT na nuvem ou compare os planos na visão geral do broker MQTT gerenciado.
Perguntas frequentes
Um broker MQTT BYOC é o mesmo que auto-hospedagem?
Não. A infraestrutura fica na sua conta, mas o provedor instala, atualiza e monitora o broker. Na auto-hospedagem, a sua própria equipe faz tudo isso.
Meus dispositivos precisam de um firmware diferente para BYOC?
Não, se o broker fala MQTT padrão. No ConnectMQ, o BYOC usa os mesmos protocolos e portas dos outros planos, então você só troca o hostname e as credenciais.
Quem paga pela infraestrutura de nuvem no BYOC?
A infraestrutura aparece na sua própria fatura de nuvem, e o serviço de gerenciamento é cobrado separadamente pelo provedor. Confirme o arranjo exato com o seu provedor.
Quando o BYOC é exagero?
Se você não tem nenhuma política que exija que os dados fiquem na sua própria conta, um broker MQTT gerenciado compartilhado ou dedicado é mais rápido de começar e mais simples de operar.
