Você orçou a mensageria a quarenta centavos por milhão de requisições, mas então chegou a fatura da AWS três vezes maior do que a contagem de mensagens dizia que deveria ser. O culpado não é um aumento de preço. É a regra de fragmentação de 64 KB: a AWS não cobra uma mensagem lógica, ela cobra cada fragmento de 64 KB de payload em cada chamada de API que o toca. Um evento de pedido de 200 KB equivale a quatro requisições faturáveis quando você o envia, mais quatro quando um worker o recebe, e mais quatro quando o worker o exclui. Doze cobranças para uma mensagem, antes de o fan-out do SNS multiplicá-la novamente.
Este artigo explica como o SQS e o SNS realmente contam requisições, quanto isso custa em volume realista, por que a mensageria de produção pertence ao custo dos produtos vendidos e não às despesas gerais, e como registrá-la para que sua margem bruta diga a verdade.
Como o SQS Transforma Uma Mensagem em Muitas Requisições Faturáveis
O preço do SQS parece enganosamente simples: filas Standard custam cerca de quarenta centavos por milhão de requisições, filas FIFO cerca de cinquenta centavos por milhão, com o primeiro milhão de requisições Standard gratuito a cada mês. A complexidade se esconde na definição de requisição.
Cada fragmento de 64 KB é uma requisição
Cada fragmento iniciado de 64 KB de payload conta como uma requisição própria. Uma mensagem de 30 KB é uma requisição. Uma mensagem de 64 KB é uma requisição. Uma mensagem de 65 KB são duas. Uma mensagem de 200 KB são quatro, uma de 256 KB são quatro, e um payload de 1 MB são dezesseis.
Esse último número importa mais do que costumava. Em agosto de 2025 a AWS elevou o tamanho máximo de mensagem do SQS de 256 KB para 1 MB, tanto para filas Standard quanto FIFO. A folga é conveniente para o evento grande ocasional, mas qualquer coisa que você deixe acima de 64 KB paga o multiplicador de fragmentos em cada toque. Uma equipe que passa de payloads médios de 50 KB para 200 KB quadruplica sua contagem de requisições do SQS sem enviar uma única mensagem adicional.
Cada ação de API conta separadamente
Cada ação de API contra uma fila é uma requisição, e o multiplicador de fragmentos se aplica a cada uma. Enviar, receber, excluir e alterar a visibilidade da mensagem são medidos de forma independente.
Percorra o ciclo de vida completo de uma mensagem de 200 KB em uma fila Standard. O envio são quatro requisições faturáveis. A recepção pelo worker são mais quatro. A exclusão após o processamento bem-sucedido são mais quatro. Uma mensagem lógica, doze requisições faturáveis, cerca de meio centavo por milhar às tarifas de tabela. O mesmo ciclo de vida para uma mensagem de 30 KB são três requisições no total. O tamanho do payload é a variável dominante na maioria das faturas do SQS, não a contagem de mensagens.
Dois outros medidores surpreendem operadores de primeira viagem. Recebimentos vazios são faturáveis: toda sondagem que não retorna mensagens ainda conta como uma requisição, então um loop agressivo de short polling em uma fila ociosa queima dinheiro à toa. E as filas FIFO carregam um prêmio de cerca de 25 por cento sobre as Standard em todas as faixas de volume, o que se acumula rápido quando o multiplicador de fragmentos já está trabalhando contra você. Use FIFO onde a ordenação e o processamento exatamente uma vez são requisitos genuínos, e Standard em todo o resto.
Como o SNS Multiplica Isso Uma Segunda Vez
O SNS adiciona uma segunda dimensão de cobrança, porque uma mensagem publicada é medida uma vez na chegada e novamente em cada entrega.
Publicações e entregas são medidores separados
Publicar em um tópico custa cerca de cinquenta centavos por milhão de requisições, fragmentado da mesma forma: uma publicação de 256 KB conta como quatro. Cada entrega a cada assinante é então medida por fragmento de 64 KB também, com a tarifa dependendo do protocolo de entrega.
Nem todas as entregas custam o mesmo. Entregas para filas SQS, funções Lambda e streams do Firehose não têm cobrança de entrega, o que torna o fan-out de SNS para SQS quase gratuito do lado da entrega. Entregas HTTP e HTTPS, e-mail e push móvel são medidas, e o SMS é precificado separadamente por segmento de mensagem. Um evento de 256 KB distribuído em fan-out para três filas SQS e um webhook HTTP custa, portanto, quatro requisições de publicação, zero para as três entregas SQS, e quatro entregas HTTP. Reduza esse evento para menos de 64 KB e o mesmo fan-out custa uma publicação mais uma entrega HTTP.
O SNS seguiu o SQS rumo a payloads maiores em setembro de 2026, permitindo mensagens de 1 MB por trás de uma configuração de tamanho máximo no nível do tópico. Tópicos configurados acima de 256 KB só podem entregar para SQS, Lambda e Firehose, com no máximo cem assinaturas. A restrição é uma dica sobre o padrão pretendido: eventos grandes pertencem a um pipeline apoiado por filas, não a um disparo para todos os protocolos.
Por que o fan-out ainda vale a pena
O medidor de entregas tenta as equipes a pular o SNS e enviar mensagens SQS duplicadas diretamente a cada consumidor. Resista a isso. Envios duplicados multiplicam a parte mais cara do ciclo, o envio mais recebimento mais exclusão por consumidor, enquanto o fan-out de SNS para SQS paga uma publicação e zero cobranças de entrega SQS por assinante. Quando vários consumidores precisam do mesmo evento, o fan-out é tanto a arquitetura mais limpa quanto a fatura mais barata.
Quanto Isso Custa em Volume Real
As tarifas de tabela são números por milhão que só fazem sentido quando multiplicados, então aqui estão três formatos realistas.
Um projeto paralelo enviando 2 milhões de mensagens pequenas por mês por meio de uma fila Standard paga quase nada. Cada mensagem abaixo de 64 KB custa um envio, um recebimento e uma exclusão, ou 6 milhões de requisições. O primeiro milhão é gratuito, deixando 5 milhões a quarenta centavos por milhão: cerca de dois dólares.
Uma plataforma SaaS de médio porte publicando 5 milhões de notificações de 10 KB por mês em um tópico Standard com três assinantes SQS e um webhook HTTP paga um dígito pela parte do SNS. As publicações ficam em cerca de dois dólares e cinquenta centavos. As três entregas SQS são gratuitas. As entregas HTTP ficam em cerca de três dólares a seis centavos por cem mil. As ações de API do SQS a jusante aproximadamente dobram o total, deixando todo o pipeline de notificações abaixo de quinze dólares por mês. Este é o formato em que a mensageria é genuinamente negligenciável.
Agora repita essa carga de trabalho SaaS com payloads de 200 KB porque cada evento embute um documento de pedido completo. Cada medidor quadruplica. As publicações saltam para dez dólares, as entregas HTTP para doze, e os recebimentos e exclusões do SQS a jusante também quadruplicam. O pipeline chega perto de sessenta dólares por mês, ainda pequeno em termos absolutos, mas quatro vezes o custo da mesma carga de trabalho com eventos enxutos, e a diferença se acumula à medida que o volume cresce. A 500 milhões de requisições fragmentadas por mês, a diferença entre eventos enxutos e inflados é um item anual de quatro dígitos.
Existem faixas de volume, mas raramente importam para pequenas empresas: as requisições Standard diminuem além de 100 bilhões e 200 bilhões de requisições por mês. Sua alavanca realista não é a faixa, é o fator de fragmentação médio.
Por que a Mensageria de Produção é COGS Variável, Não Despesa Geral
A mensageria que entrega seu produto a clientes pagantes é um custo direto da receita. Ela escala com o uso, desaparece quando nada é vendido, e os investidores esperam vê-la acima da linha da margem bruta, ao lado de computação, banco de dados, armazenamento e largura de banda para produção.
As normas contábeis deixam espaço aqui: os princípios geralmente aceitos não definem precisamente o custo dos produtos vendidos, e a prática de margem bruta do SaaS preenche a lacuna com um teste de custo direto. Pergunte se o gasto existe para atender clientes em produção. Filas de produção que carregam eventos de pedidos, tópicos de notificação que fazem fan-out para workers voltados ao cliente, e entregas de webhook para endpoints de clientes passam no teste. Filas de staging, tópicos de teste de carga, assinaturas de sandbox de desenvolvedor e a fila de mensagens mortas drenando o teste de carga do trimestre passado não passam. Esses pertencem à pesquisa e desenvolvimento ou às despesas gerais.
A fronteira de produção é todo o jogo. Uma fatura da AWS agrupa todas as filas e tópicos juntos, então marque os recursos de produção e divida a fatura todo mês. As equipes que pulam a divisão geralmente erram na direção lisonjeira, enterrando infraestrutura nas despesas gerais e relatando uma margem bruta que sua economia unitária não consegue defender. Uma revisão de due diligence reclassifica isso em uma tarde, e a margem reapresentada nunca é a maior.
Registre o valor líquido que você realmente paga. O nível gratuito é um desconto de cobrança, não receita, então não há nada a acrescentar. Se você quiser visibilidade de quanto da carga de trabalho o nível gratuito absorve, rastreie as requisições faturáveis separadamente em suas métricas e mantenha o lançamento contábil pelo custo em caixa.
Como Registrar para que Sua Margem Diga a Verdade
Dê à mensageria sua própria conta de custo das vendas em vez de misturá-la em uma linha genérica de nuvem ou software. Uma conta dedicada, como mensageria em nuvem, permite dividir o gasto do mês pelas requisições faturáveis do mês e ver seu custo real por requisição fragmentada, que é o número que lhe diz se o crescimento do payload está comendo a margem.
A cobrança da AWS é liquidada após o fim do mês, então acumule-a. Estime a parcela de mensageria a partir de suas métricas de requisições no fechamento, ajuste à fatura quando ela chegar, e mantenha a parcela do sandbox fora do custo das vendas. Aqui está um ciclo completo para um mês em que a mensageria de produção ficou em dezoito dólares e quarenta centavos e o sandbox acrescentou dois dólares e dez centavos:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Expenses:CostOfSales:Cloud-Messaging USD
2026-01-01 open Expenses:Research:Cloud-Sandbox USD
2026-01-01 open Liabilities:Accrued:AWS USD
2026-01-31 * "AWS" "January SQS prod 8.2M chunked requests plus SNS publishes and HTTP deliveries"
Expenses:CostOfSales:Cloud-Messaging 18.40 USD
Liabilities:Accrued:AWS -18.40 USD
2026-02-03 * "AWS" "January AWS charge settles, prod messaging plus 2.10 sandbox"
Liabilities:Accrued:AWS 18.40 USD
Expenses:Research:Cloud-Sandbox 2.10 USD
Assets:Cash:Operating -20.50 USDReconcilie o valor acumulado com seu cost explorer agrupado por serviço e tipo de uso pelo menos mensalmente. O SQS e o SNS devem aparecer como linhas separadas para que um pico em um não se esconda dentro da tendência estável do outro. Se você mantém seus livros em texto simples, os padrões de rastreamento de custos na documentação se estendem naturalmente a uma divisão de mensageria por serviço.
Uma armadilha de classificação a evitar: os prêmios de FIFO e o armazenamento de retenção estendida ainda são custos de mensageria, mas a retenção estendida além da sua janela legítima de redrive é uma escolha de armazenamento, não um custo de entrega. Encurte a retenção ou mova a parcela de armazenamento para onde ela pertence, em vez de deixar uma política de retenção de quatorze dias inflar silenciosamente o custo das vendas.
Cinco Controles que Costumam Reduzir a Fatura em 30 a 50 Por Cento
Comece com long polling e batching. Juntos, eles costumam reduzir o gasto com SQS em quase metade e levam uma tarde para implementar.
1. Ative o long polling em todos os lugares
Defina o tempo de espera de recebimento para vinte segundos em cada fila. Os workers então mantêm a conexão aberta em vez de martelar sondagens vazias, o que reduz a linha de recebimentos vazios que domina as faturas de filas ociosas e suaviza picos de CPU nos consumidores.
2. Faça batching de toda chamada de API que permitir
Enviar, receber e excluir suportam lotes de até dez mensagens. Um worker que processa uma mensagem por chamada paga dez vezes a contagem de requisições de um worker que drena dez de cada vez. As exclusões em lote são as mais comumente esquecidas: equipes que fazem batching cuidadoso de envios frequentemente excluem uma a uma.
3. Coloque o payload em dieta
Mantenha cada evento abaixo de um fragmento de 64 KB. Armazene o documento completo em armazenamento de objetos e envie uma referência com os identificadores de que o consumidor precisa, o padrão claim-check. Comprima onde as referências são impraticáveis, e remova blobs embutidos, registros de clientes duplicados e contexto de depuração verboso do caminho crítico. Cada fragmento que você remove se multiplica por envios, recebimentos, exclusões, publicações e entregas.
4. Filtre no tópico
Anexe políticas de filtro para que cada assinante receba apenas os eventos que ele trata. O fan-out sem filtro paga entrega e processamento a jusante por mensagens que o consumidor descarta na chegada. Isso é puro desperdício com uma correção de uma linha por assinatura.
5. Reserve o FIFO para onde a ordenação é real
Audite quais filas genuinamente precisam de ordenação e desduplicação. O prêmio do FIFO se aplica a cada requisição fragmentada na fila, então uma fila FIFO carregando eventos que ninguém ordena é uma sobretaxa permanente de 25 por cento. Durante a auditoria, defina retenção curta com uma fila de mensagens mortas para falhas, em vez de deixar mensagens envenenadas se repetirem até uma grande contagem de requisições.
Monitore as duas métricas que preveem a fatura: o número aproximado de mensagens enviadas e o número de recebimentos vazios. Alerte quando os recebimentos vazios excederem uma pequena parcela do total de recebimentos, e revise o tamanho médio do payload por fila trimestralmente. O crescimento do payload é gradual o suficiente para passar despercebido mês a mês e grande o suficiente para importar ano a ano.
Checklist de Fim de Mês para Custos de Mensageria
Feche o ciclo da mesma forma a cada mês para que os números permaneçam confiáveis:
- Extraia as contagens de requisições fragmentadas do SQS e do SNS do seu detalhamento de cobrança, não as contagens de mensagens lógicas dos logs da aplicação.
- Divida o gasto de cada serviço por suas requisições fragmentadas para obter o custo unitário real, e compare-o com os benchmarks de tabela de quarenta e cinquenta centavos.
- Calcule o fator de fragmentação médio por fila dividindo as requisições faturáveis pelas mensagens lógicas; qualquer coisa acima de 1,2 merece uma revisão de payload.
- Separe o gasto de produção do de staging e sandbox usando tags de recursos, e confirme que apenas a produção entrou no custo das vendas.
- Ajuste o acúmulo do mês passado à fatura liquidada e transporte a variação para sua estimativa.
- Verifique os recebimentos vazios como parcela do total de recebimentos, e confirme que o long polling ainda está ativado após qualquer mudança de infraestrutura.
- Confirme que toda nova fila e tópico criados durante o mês herdaram as tags de produção e as políticas de filtro.
Extraia as linhas de SQS e SNS deste mês do seu console de cobrança hoje e calcule o fator de fragmentação médio. Se estiver acima de 1,2, sua vitória de margem mais barata é um payload menor, não um plano maior.
