Como o tamanho das mensagens e o agrupamento mudam sua fatura de IoT
A maioria dos preços de IoT conta mensagens ou blocos de dados, não bytes. Isso faz da forma como seus dispositivos empacotam as leituras uma das maiores alavancas de custo que você controla, muitas vezes maior que a escolha da nuvem.
Como cada serviço conta
| Serviço | Conta o uso como |
|---|---|
| Azure IoT Hub | Mensagens em blocos de 4 KB, contra uma cota diária por unidade |
| AWS IoT Core | Mensagens em blocos de 5 KB, mais regras acionadas e ações executadas |
| Azure Event Hubs | Eventos em blocos de 64 KB, mais unidades de throughput dimensionadas por eventos por segundo |
| Amazon Kinesis (sob demanda) | GB gravados e GB lidos |
| Google Pub/Sub | Volume de dados, com tamanho mínimo por requisição |
| OCI Streaming | GB enviados e GB lidos, mais dados retidos |
| Oracle IoT Platform | Horas de computação (ECPUs), não mensagens, então o agrupamento só economiza pelos serviços a jusante |
Disso decorrem dois padrões:
- Mensagens minúsculas são caras. Uma leitura de 200 bytes é cobrada como uma mensagem inteira de 4 KB ou 5 KB no gateway, e como um evento inteiro no Event Hubs.
- Mensagens um pouco grandes demais também são caras. Uma mensagem de 4,1 KB são duas mensagens no IoT Hub. Uma de 5,1 KB são duas no IoT Core.
Agrupamento: a maior economia isolada
Em vez de enviar cada leitura de sensor no momento em que é feita, um dispositivo (ou um gateway edge) junta leituras por alguns segundos e as envia como uma só mensagem.
Pegue uma máquina com 20 sensores, cada um lendo uma vez por segundo, com cerca de 100 bytes por leitura:
- Sem agrupar: 20 mensagens por segundo, cada uma cobrada como um bloco inteiro. São mais de 50 milhões de mensagens por mês de uma única máquina.
- Agrupando a cada segundo: 1 mensagem por segundo de cerca de 2 KB. Ainda abaixo de um bloco, e 20 vezes menos mensagens.
- Agrupando a cada 5 segundos: 1 mensagem de cerca de 10 KB a cada 5 segundos. Dois ou três blocos no gateway, mas muito menos eventos em tudo que vem depois.
A contrapartida é a latência: um lote de 5 segundos significa que os alertas chegam até 5 segundos mais tarde. Para a maior parte do monitoramento de fábrica, tudo bem. Para intertravamentos de segurança não, mas esses devem rodar localmente, não pela nuvem.
Intervalo de envio: 10, 30 ou 60 segundos
A frequência com que cada dispositivo informa é a alavanca mais simples de todas. Reduza a taxa à metade e você reduz as mensagens à metade, e com elas cada cobrança por mensagem. Aqui está a planta média de 1.000 dispositivos em quatro intervalos, com todo o resto igual:
| Nuvem | A cada 5 s | A cada 10 s | A cada 30 s | A cada 60 s |
|---|---|---|---|---|
| Amazon Web Services | ₹ 139.836menor | ₹ 97.531menor | ₹ 69.366menor | ₹ 62.405menor |
| Microsoft Azure | ₹ 189.374 | ₹ 154.100 | ₹ 112.809 | ₹ 99.153 |
| Oracle Cloud | ₹ 80.315incompleto | ₹ 76.353incompleto | ₹ 73.712incompleto | ₹ 73.052incompleto |
| Google Cloud | ₹ 93.929incompleto | ₹ 87.438incompleto | ₹ 83.111incompleto | ₹ 82.030incompleto |
O total de Oracle Cloud deixa de fora Ambiente de execução na borda (edge) (não oferecido), Banco de dados de séries temporais (não oferecido) e Gateway de dispositivos IoT (não dimensionável com as informações publicadas). Um total incompleto nunca é marcado como o menor.
O total de Google Cloud deixa de fora Gateway de dispositivos IoT (não oferecido) e Ambiente de execução na borda (edge) (não oferecido). Um total incompleto nunca é marcado como o menor.
Estimativa ao vivo: Índia (Mumbai / Pune), preços de tabela atualizados em 27 de out. de 2026, recalculada a cada atualização. Abra no estimador para mudar qualquer dado: A cada 5 s, A cada 10 s, A cada 30 s, A cada 60 s.
Três coisas se destacam:
- Intervalos curtos ficam caros rápido. Passar de 10 segundos para 5 dobra as mensagens. A linha do gateway IoT dobra na AWS, que cobra por mensagem, e sobe cerca de metade no Azure, que adiciona unidades em degraus.
- Intervalos longos economizam menos do que se espera. Passar de 30 segundos para 60 reduz as mensagens à metade de novo, mas o total cai só um pouco. A essa altura a fatura é principalmente custo fixo: o banco de séries temporais, o processamento de fluxos e os servidores de aplicação, que não dependem do número de mensagens.
- O Azure se move em degraus. O IoT Hub é vendido em unidades com cota diária, então uma pequena mudança no intervalo pode mudar o número de unidades ou passar para outro tamanho de unidade.
Escolha o maior intervalo que cada sinal tolera. Vibração e valores rápidos de processo podem precisar de segundos. Temperaturas, contadores e medidores de energia costumam ir bem com 30 ou 60 segundos, sobretudo combinados com envio por alteração (abaixo).
Outras formas de reduzir a fatura
- Enviar por alteração, não por agenda. Uma temperatura que não mudou não precisa ser reenviada a cada segundo. Muitos dispositivos e ambientes de execução edge suportam banda morta (só enviar quando o valor muda mais que uma quantidade definida).
- Usar um formato compacto. Um JSON com nomes de campo longos pode ser várias vezes maior que os mesmos dados em um formato binário como Protocol Buffers ou CBOR, ou mesmo em JSON com chaves curtas.
- Mirar abaixo do tamanho do bloco. Se as mensagens passam por pouco de 4 KB ou 5 KB, cortar alguns campos pode reduzir à metade a cobrança do gateway.
- Agregar na borda. Envie mínimo, máximo e média de um minuto em vez de 60 leituras brutas, e guarde os dados brutos localmente para diagnóstico. Veja ambientes de execução edge comparados.
Veja o efeito em números
Nosso estimador de Indústria 4.0 aceita tamanho de mensagem e intervalo de envio como dados de entrada. Teste suas configurações atuais, depois a versão agrupada, e compare as linhas do gateway e do streaming. Para ver em mais detalhe como funciona o modelo de preços de cada gateway, veja como funcionam os preços de plataformas IoT.