Presupuestaste la mensajería a cuarenta centavos por millón de solicitudes, y luego llegó la factura de AWS tres veces más alta de lo que tu conteo de mensajes decía que debería ser. El culpable no es un aumento de precios. Es la regla de fragmentación de 64 KB: AWS no factura un mensaje lógico, factura cada fragmento de 64 KB de carga útil en cada llamada a la API que lo toca. Un evento de pedido de 200 KB son cuatro solicitudes facturables cuando lo envías, cuatro más cuando un worker lo recibe, y cuatro más cuando el worker lo elimina. Doce cargos por un solo mensaje, antes de que el fan-out de SNS lo multiplique de nuevo.
Esta entrada explica cómo SQS y SNS cuentan realmente las solicitudes, cuánto cuesta eso con un volumen realista, por qué la mensajería de producción pertenece al costo de los bienes vendidos y no a los gastos generales, y cómo contabilizarla para que tu margen bruto diga la verdad.
Cómo SQS convierte un mensaje en muchas solicitudes facturables
El precio de SQS parece engañosamente simple: las colas Standard cuestan alrededor de cuarenta centavos por millón de solicitudes, las colas FIFO alrededor de cincuenta centavos por millón, con el primer millón de solicitudes Standard gratis cada mes. La complejidad se esconde en la definición de una solicitud.
Cada fragmento de 64 KB es una solicitud
Cada fragmento de 64 KB iniciado de carga útil cuenta como una solicitud propia. Un mensaje de 30 KB es una solicitud. Un mensaje de 64 KB es una solicitud. Un mensaje de 65 KB son dos. Un mensaje de 200 KB son cuatro, un mensaje de 256 KB son cuatro, y una carga útil de 1 MB son dieciséis.
Ese último número importa más de lo que solía importar. En agosto de 2025 AWS elevó el tamaño máximo de mensaje de SQS de 256 KB a 1 MB tanto para colas Standard como FIFO. El margen adicional es conveniente para el evento grande ocasional, pero cualquier cosa que dejes por encima de 64 KB paga el multiplicador de fragmentos en cada toque. Un equipo que pasa de cargas útiles promedio de 50 KB a 200 KB cuadruplica su conteo de solicitudes de SQS sin enviar un solo mensaje adicional.
Cada acción de la API cuenta por separado
Cada acción de la API contra una cola es una solicitud, y el multiplicador de fragmentos aplica a cada una. Enviar, recibir, eliminar y cambiar la visibilidad de un mensaje se miden de forma independiente.
Analiza el ciclo de vida completo de un mensaje de 200 KB en una cola Standard. El envío son cuatro solicitudes facturables. La recepción del worker son cuatro más. La eliminación tras el procesamiento exitoso son cuatro más. Un mensaje lógico, doce solicitudes facturables, aproximadamente medio centavo por millar a tarifas de lista. El mismo ciclo de vida para un mensaje de 30 KB son tres solicitudes en total. El tamaño de la carga útil es la variable dominante en la mayoría de las facturas de SQS, no el conteo de mensajes.
Dos medidores más sorprenden a los operadores primerizos. Las recepciones vacías son facturables: cada sondeo que no devuelve mensajes sigue contando como una solicitud, así que un bucle agresivo de sondeo corto en una cola inactiva quema dinero para nada. Y las colas FIFO conllevan una prima de aproximadamente el 25 por ciento sobre Standard en cada nivel de volumen, lo cual se acumula rápido cuando el multiplicador de fragmentos ya está jugando en tu contra. Usa FIFO donde el ordenamiento y el procesamiento exactamente una vez sean requisitos genuinos, y Standard en todo lo demás.
Cómo SNS lo multiplica una segunda vez
SNS añade una segunda dimensión de facturación, porque un mensaje publicado se mide una vez a la llegada y de nuevo en cada entrega.
Las publicaciones y las entregas son medidores separados
Publicar en un tema cuesta alrededor de cincuenta centavos por millón de solicitudes, fragmentado de la misma manera: una publicación de 256 KB cuenta como cuatro. Cada entrega a cada suscriptor se mide luego por fragmento de 64 KB también, con la tarifa dependiendo del protocolo de entrega.
No todas las entregas cuestan lo mismo. Las entregas a colas SQS, funciones Lambda y flujos de Firehose no conllevan cargo de entrega, lo que hace que el fan-out de SNS a SQS sea casi gratuito del lado de la entrega. Las entregas HTTP y HTTPS, el correo electrónico y las notificaciones push móviles se miden, y el SMS se factura por separado por segmento de mensaje. Un evento de 256 KB distribuido a tres colas SQS y un webhook HTTP cuesta por lo tanto cuatro solicitudes de publicación, cero por las tres entregas a SQS, y cuatro entregas HTTP. Reduce ese evento por debajo de 64 KB y el mismo fan-out cuesta una publicación más una entrega HTTP.
SNS siguió a SQS hacia cargas útiles más grandes en septiembre de 2026, permitiendo mensajes de 1 MB tras una configuración de tamaño máximo a nivel de tema. Los temas configurados por encima de 256 KB solo pueden entregar a SQS, Lambda y Firehose, con como máximo cien suscripciones. La restricción es una pista sobre el patrón previsto: los eventos grandes pertenecen a un pipeline respaldado por colas, no a un envío masivo a cada protocolo.
Por qué el fan-out sigue ganando
El medidor de entregas tienta a los equipos a saltarse SNS y enviar mensajes SQS duplicados a cada consumidor directamente. Resiste eso. Los envíos duplicados multiplican la parte más costosa del ciclo, el envío más la recepción más la eliminación por consumidor, mientras que el fan-out de SNS a SQS paga una publicación y cero cargos de entrega de SQS por suscriptor. Cuando varios consumidores necesitan el mismo evento, el fan-out es tanto la arquitectura más limpia como la factura más barata.
Cuánto cuesta esto con un volumen real
Las tarifas de lista son números por millón que solo tienen sentido al multiplicarlos, así que aquí hay tres formas realistas.
Un proyecto secundario que envía 2 millones de mensajes pequeños al mes a través de una cola Standard paga casi nada. Cada mensaje por debajo de 64 KB cuesta un envío, una recepción y una eliminación, es decir, 6 millones de solicitudes. El primer millón es gratis, quedando 5 millones a cuarenta centavos por millón: alrededor de dos dólares.
Una plataforma SaaS de tamaño medio que publica 5 millones de notificaciones de 10 KB al mes en un tema Standard con tres suscriptores SQS y un webhook HTTP paga un dígito por el tramo de SNS. Las publicaciones rondan los dos dólares con cincuenta centavos. Las tres entregas a SQS son gratis. Las entregas HTTP rondan los tres dólares a seis centavos por cien mil. Las acciones de la API de SQS posteriores aproximadamente duplican el total, dejando todo el pipeline de notificaciones por debajo de quince dólares al mes. Esta es la forma en la que la mensajería es genuinamente insignificante.
Ahora reproduce esa carga de trabajo SaaS con cargas útiles de 200 KB porque cada evento incrusta un documento de pedido completo. Cada medidor se cuadruplica. Las publicaciones saltan a diez dólares, las entregas HTTP a doce, y las recepciones y eliminaciones posteriores de SQS también se cuadruplican. El pipeline queda cerca de sesenta dólares al mes, todavía pequeño en términos absolutos, pero cuatro veces el costo de la misma carga de trabajo con eventos ligeros, y la brecha se agrava a medida que crece el volumen. Con 500 millones de solicitudes fragmentadas al mes, la diferencia entre eventos ligeros y pesados es una partida anual de cuatro cifras.
Existen niveles de volumen pero rara vez importan para las pequeñas empresas: las solicitudes Standard bajan después de 100 mil millones y 200 mil millones de solicitudes al mes. Tu palanca realista no es el nivel, es el factor de fragmentación promedio.
Por qué la mensajería de producción son COGS variables, no gastos generales
La mensajería que entrega tu producto a clientes que pagan es un costo directo de los ingresos. Escala con el uso, desaparece cuando no se vende nada, y los inversores esperan verla por encima de la línea del margen bruto junto con el cómputo, la base de datos, el almacenamiento y el ancho de banda de producción.
Las normas contables dejan margen aquí: los principios generalmente aceptados no definen con precisión el costo de los bienes vendidos, y la práctica del margen bruto de SaaS llena el vacío con una prueba de costo directo. Pregúntate si el gasto existe para servir a los clientes en producción. Las colas de producción que transportan eventos de pedidos, los temas de notificación que se distribuyen a workers orientados al cliente, y las entregas de webhooks a los endpoints del cliente, todos pasan la prueba. Las colas de staging, los temas de pruebas de carga, las suscripciones al sandbox de desarrolladores, y la cola de mensajes muertos que drena la prueba de carga del trimestre pasado no pasan. Esos pertenecen a investigación y desarrollo o a gastos generales.
La frontera de producción es todo el juego. Una factura de AWS agrupa todas las colas y temas, así que etiqueta los recursos de producción y divide la factura cada mes. Los equipos que se saltan la división suelen equivocarse en la dirección halagadora, enterrando la infraestructura en gastos generales y reportando un margen bruto que su economía unitaria no puede defender. Una revisión de diligencia debida lo reclasifica en una tarde, y el margen reexpresado nunca es el más alto.
Contabiliza el importe neto que realmente pagas. El nivel gratuito es un descuento de facturación, no ingresos, así que no hay nada que inflar. Si quieres visibilidad de cuánto de la carga de trabajo absorbe el nivel gratuito, rastrea las solicitudes facturables por separado en tus métricas y mantén el asiento contable al costo de caja.
Cómo contabilizarlo para que tu margen diga la verdad
Dale a la mensajería su propia cuenta de costo de ventas en lugar de mezclarla en una línea genérica de nube o software. Una cuenta dedicada como mensajería en la nube te permite dividir el gasto del mes entre las solicitudes facturables del mes y ver tu costo real por solicitud fragmentada, que es el número que te dice si el crecimiento de la carga útil se está comiendo el margen.
El cargo de AWS se liquida después del cierre de mes, así que devéngalo. Estima la porción de mensajería a partir de tus métricas de solicitudes al cierre, ajústala a la factura cuando llegue, y mantén la porción de sandbox fuera del costo de ventas. Aquí hay un ciclo completo para un mes en el que la mensajería de producción costó dieciocho dólares con cuarenta centavos y el sandbox añadió dos dólares con diez 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 USDConcilia el importe devengado con tu cost explorer agrupado por servicio y tipo de uso al menos mensualmente. SQS y SNS deberían aparecer como líneas separadas para que un pico en uno no se esconda dentro de la tendencia plana del otro. Si mantienes tus libros en texto plano, los patrones de seguimiento de costos en la documentación se extienden naturalmente a una división de mensajería por servicio.
Una trampa de clasificación que evitar: las primas de FIFO y el almacenamiento de retención extendida siguen siendo costos de mensajería, pero la retención extendida más allá de tu ventana genuina de redrive es una elección de almacenamiento, no un costo de entrega. O acorta la retención o mueve la porción de almacenamiento donde corresponde en lugar de dejar que una política de retención de catorce días infle silenciosamente el costo de ventas.
Cinco controles que normalmente reducen la factura entre un 30 y un 50 por ciento
Empieza con el sondeo largo y el procesamiento por lotes. Juntos suelen reducir el gasto de SQS en casi la mitad y tardan una tarde en implementarse.
1. Activa el sondeo largo en todas partes
Establece el tiempo de espera de recepción a veinte segundos en cada cola. Los workers entonces mantienen la conexión abierta en lugar de martillar sondeos vacíos, lo que reduce drásticamente la línea de recepciones vacías que domina las facturas de colas inactivas y suaviza los picos de CPU en los consumidores.
2. Procesa por lotes cada llamada a la API que lo permita
Enviar, recibir y eliminar admiten lotes de hasta diez mensajes. Un worker que procesa un mensaje por llamada paga diez veces el conteo de solicitudes de un worker que drena diez a la vez. Las eliminaciones por lotes son las que más se pasan por alto: los equipos que procesan cuidadosamente los envíos por lotes a menudo eliminan uno por uno.
3. Pon la carga útil a dieta
Mantén cada evento por debajo de un fragmento de 64 KB. Almacena el documento completo en el almacenamiento de objetos y envía una referencia con los identificadores que el consumidor necesita, el patrón de comprobación de reclamo. Comprime donde las referencias no sean prácticas, y elimina los blobs incrustados, los registros de clientes duplicados y el contexto de depuración verboso de la ruta caliente. Cada fragmento que eliminas se multiplica a través de envíos, recepciones, eliminaciones, publicaciones y entregas.
4. Filtra en el tema
Adjunta políticas de filtro para que cada suscriptor reciba solo los eventos que maneja. El fan-out sin filtro paga la entrega y el procesamiento posterior por mensajes que el consumidor descarta a la llegada. Esto es puro desperdicio con una solución de una línea por suscripción.
5. Reserva FIFO para donde el ordenamiento es real
Audita qué colas necesitan genuinamente ordenamiento y deduplicación. La prima de FIFO aplica a cada solicitud fragmentada en la cola, así que una cola FIFO que transporta eventos que nadie ordena es un recargo permanente del 25 por ciento. Mientras auditas, establece una retención corta con una cola de mensajes muertos para fallos en lugar de dejar que los mensajes envenenados se reintenten hasta un gran conteo de solicitudes.
Monitorea las dos métricas que predicen la factura: el número aproximado de mensajes enviados y el número de recepciones vacías. Alerta cuando las recepciones vacías superen una pequeña proporción del total de recepciones, y revisa el tamaño promedio de la carga útil por cola trimestralmente. El crecimiento de la carga útil es lo suficientemente gradual como para pasarse por alto mes a mes y lo suficientemente grande como para importar año a año.
Lista de verificación de fin de mes para los costos de mensajería
Cierra el ciclo de la misma manera cada mes para que los números sigan siendo confiables:
- Extrae los conteos de solicitudes fragmentadas de SQS y SNS de tu desglose de facturación, no los conteos de mensajes lógicos de los registros de la aplicación.
- Divide el gasto de cada servicio entre sus solicitudes fragmentadas para obtener el costo unitario real, y compáralo con los puntos de referencia de lista de cuarenta y cincuenta centavos.
- Calcula el factor de fragmentación promedio por cola dividiendo las solicitudes facturables entre los mensajes lógicos; cualquier valor por encima de 1.2 merece una revisión de la carga útil.
- Divide el gasto de producción del de staging y sandbox usando etiquetas de recursos, y confirma que solo la producción fue a parar al costo de ventas.
- Ajusta la acumulación del mes pasado a la factura liquidada y traslada la varianza a tu estimación.
- Verifica las recepciones vacías como proporción del total de recepciones, y confirma que el sondeo largo sigue habilitado tras cualquier cambio de infraestructura.
- Confirma que cada nueva cola y tema creados durante el mes heredaron las etiquetas de producción y las políticas de filtro.
Extrae hoy las líneas de SQS y SNS de este mes de tu consola de facturación y calcula el factor de fragmentación promedio. Si está por encima de 1.2, tu victoria de margen más barata es una carga útil más pequeña, no un plan más grande.
