Vous aviez budgété la messagerie à quarante cents par million de requêtes, puis la facture AWS est arrivée trois fois plus élevée que ce que votre nombre de messages aurait dû produire. Le coupable n'est pas une hausse tarifaire. C'est la règle du découpage en blocs de 64 Ko : AWS ne facture pas un message logique, elle facture chaque bloc de 64 Ko de charge utile sur chaque appel API qui le touche. Un événement de commande de 200 Ko représente quatre requêtes facturables à l'envoi, quatre autres quand un worker le reçoit, et quatre de plus quand le worker le supprime. Douze facturations pour un seul message, avant même que le fan-out SNS ne multiplie à nouveau le tout.
Cet article explique comment SQS et SNS comptent réellement les requêtes, ce que cela coûte à un volume réaliste, pourquoi la messagerie de production relève du coût des marchandises vendues plutôt que des frais généraux, et comment la comptabiliser pour que votre marge brute dise la vérité.
Comment SQS transforme un message en de nombreuses requêtes facturables
La tarification de SQS paraît d'une simplicité trompeuse : les files Standard coûtent environ quarante cents par million de requêtes, les files FIFO environ cinquante cents par million, avec le premier million de requêtes Standard gratuit chaque mois. La complexité se cache dans la définition d'une requête.
Chaque bloc de 64 Ko est une requête
Chaque bloc de 64 Ko entamé dans la charge utile compte comme une requête à part entière. Un message de 30 Ko est une requête. Un message de 64 Ko est une requête. Un message de 65 Ko en est deux. Un message de 200 Ko en est quatre, un message de 256 Ko en est quatre, et une charge utile de 1 Mo en représente seize.
Ce dernier chiffre compte plus qu'autrefois. En août 2025, AWS a porté la taille maximale d'un message SQS de 256 Ko à 1 Mo, pour les files Standard comme FIFO. Cette marge est pratique pour l'événement volumineux occasionnel, mais tout ce que vous stockez au-delà de 64 Ko subit le multiplicateur de blocs à chaque traitement. Une équipe qui passe de charges utiles moyennes de 50 Ko à 200 Ko quadruple son nombre de requêtes SQS sans envoyer un seul message supplémentaire.
Chaque action API compte séparément
Chaque action API sur une file est une requête, et le multiplicateur de blocs s'applique à chacune. Envoyer, recevoir, supprimer et modifier la visibilité d'un message sont chacun mesurés indépendamment.
Parcourons le cycle de vie complet d'un message de 200 Ko sur une file Standard. L'envoi représente quatre requêtes facturables. La réception par le worker en ajoute quatre. La suppression après traitement réussi en ajoute quatre de plus. Un message logique, douze requêtes facturables, environ un demi-cent par millier aux tarifs catalogue. Le même cycle de vie pour un message de 30 Ko représente trois requêtes au total. La taille de la charge utile est la variable dominante de la plupart des factures SQS, pas le nombre de messages.
Deux autres compteurs surprennent les opérateurs débutants. Les réceptions vides sont facturables : chaque interrogation qui ne renvoie aucun message compte tout de même comme une requête, si bien qu'une boucle de short polling agressive sur une file inactive gaspille de l'argent pour rien. Et les files FIFO supportent une prime d'environ 25 pour cent par rapport aux files Standard à tous les paliers de volume, ce qui s'accumule vite quand le multiplicateur de blocs joue déjà contre vous. Réservez FIFO aux cas où l'ordre et le traitement exactly-once sont de véritables exigences, et Standard partout ailleurs.
Comment SNS multiplie une seconde fois
SNS ajoute une seconde dimension de facturation, car un message publié est mesuré une fois à l'arrivée et de nouveau à chaque livraison.
Les publications et les livraisons sont des compteurs distincts
Publier sur un topic coûte environ cinquante cents par million de requêtes, découpées de la même façon : une publication de 256 Ko compte pour quatre. Chaque livraison à chaque abonné est ensuite mesurée par bloc de 64 Ko également, le tarif dépendant du protocole de livraison.
Toutes les livraisons ne coûtent pas la même chose. Les livraisons vers des files SQS, des fonctions Lambda et des flux Firehose ne sont pas facturées, ce qui rend le fan-out SNS-vers-SQS quasiment gratuit côté livraison. Les livraisons HTTP et HTTPS, l'e-mail et les notifications push mobiles sont facturés, et les SMS sont tarifés séparément par segment de message. Un événement de 256 Ko diffusé vers trois files SQS et un webhook HTTP coûte donc quatre requêtes de publication, zéro pour les trois livraisons SQS, et quatre livraisons HTTP. Réduisez cet événement sous 64 Ko et le même fan-out coûte une publication plus une livraison HTTP.
SNS a suivi SQS vers des charges utiles plus grandes en septembre 2026, autorisant des messages de 1 Mo derrière un paramètre de taille maximale au niveau du topic. Les topics configurés au-delà de 256 Ko ne peuvent livrer qu'à SQS, Lambda et Firehose, avec au plus cent abonnements. Cette contrainte est un indice sur le schéma attendu : les événements volumineux appartiennent à un pipeline adossé à une file, pas à une diffusion massive vers tous les protocoles.
Pourquoi le fan-out reste gagnant
Le compteur de livraison pousse les équipes à abandonner SNS et à envoyer des messages SQS en double à chaque consommateur directement. Résistez-y. Les envois en double multiplient la partie la plus coûteuse du cycle, l'envoi plus la réception plus la suppression par consommateur, tandis que le fan-out SNS-vers-SQS ne paie qu'une publication et zéro frais de livraison SQS par abonné. Quand plusieurs consommateurs ont besoin du même événement, le fan-out est à la fois l'architecture la plus propre et la facture la plus légère.
Ce que cela coûte à un volume réel
Les tarifs catalogue sont des chiffres par million qui n'ont de sens qu'une fois multipliés, voici donc trois configurations réalistes.
Un projet secondaire envoyant 2 millions de petits messages par mois via une file Standard ne paie presque rien. Chaque message sous 64 Ko coûte un envoi, une réception et une suppression, soit 6 millions de requêtes. Le premier million est gratuit, laissant 5 millions à quarante cents par million : environ deux dollars.
Une plateforme SaaS de taille moyenne publiant 5 millions de notifications de 10 Ko par mois vers un topic Standard avec trois abonnés SQS et un webhook HTTP paie un montant à un chiffre pour la partie SNS. Les publications représentent environ deux dollars et cinquante cents. Les trois livraisons SQS sont gratuites. Les livraisons HTTP représentent environ trois dollars à six cents par cent mille. Les actions API SQS en aval doublent à peu près le total, laissant l'ensemble du pipeline de notifications sous quinze dollars par mois. C'est le cas de figure où la messagerie est véritablement négligeable.
Rejouons maintenant cette même charge de travail SaaS avec des charges utiles de 200 Ko, parce que chaque événement embarque un document de commande complet. Chaque compteur quadruple. Les publications passent à dix dollars, les livraisons HTTP à douze, et les réceptions et suppressions SQS en aval quadruplent aussi. Le pipeline atteint près de soixante dollars par mois, ce qui reste modeste en valeur absolue, mais représente quatre fois le coût de la même charge de travail avec des événements allégés, et l'écart se creuse à mesure que le volume croît. À 500 millions de requêtes découpées par mois, la différence entre événements allégés et gonflés devient un poste annuel à quatre chiffres.
Des paliers de volume existent mais comptent rarement pour les petites entreprises : les requêtes Standard diminuent au-delà de 100 milliards et 200 milliards de requêtes par mois. Votre levier réaliste n'est pas le palier, c'est le facteur de blocs moyen.
Pourquoi la messagerie de production est un COGS variable, pas un frais général
La messagerie qui délivre votre produit à des clients payants est un coût direct du chiffre d'affaires. Elle évolue avec l'usage, elle disparaît quand rien ne se vend, et les investisseurs s'attendent à la voir au-dessus de la ligne de marge brute, aux côtés du calcul, de la base de données, du stockage et de la bande passante pour la production.
Les normes comptables laissent ici une marge de manœuvre : les principes généralement admis ne définissent pas précisément le coût des marchandises vendues, et la pratique de la marge brute SaaS comble le vide par un test du coût direct. Demandez-vous si la dépense existe pour servir des clients en production. Les files de production transportant des événements de commande, les topics de notification diffusant vers des workers tournés vers le client, et les livraisons de webhooks vers les points de terminaison des clients passent tous le test. Les files de préproduction, les topics de tests de charge, les abonnements de bac à sable des développeurs, et la file de messages morts qui évacue le test de charge du trimestre dernier ne le passent pas. Ceux-là relèvent de la recherche et développement ou des frais généraux.
La frontière de la production est tout l'enjeu. Une facture AWS regroupe toutes les files et tous les topics, il faut donc étiqueter les ressources de production et scinder la facture chaque mois. Les équipes qui sautent la scission se trompent généralement dans le sens flatteur, enterrant l'infrastructure dans les frais généraux et affichant une marge brute que leur économie unitaire ne peut défendre. Un audit le reclasse en un après-midi, et la marge retraitée n'est jamais la plus élevée.
Comptabilisez le montant net que vous payez réellement. Le palier gratuit est une remise de facturation, pas un revenu, il n'y a donc rien à réintégrer. Si vous voulez savoir quelle part de la charge de travail le palier gratuit absorbe, suivez les requêtes facturables séparément dans vos métriques et laissez l'écriture comptable au coût réel.
Comment la comptabiliser pour que votre marge dise la vérité
Donnez à la messagerie son propre compte de coût des ventes plutôt que de la fondre dans une ligne cloud ou logicielle générique. Un compte dédié, par exemple messagerie cloud, vous permet de diviser la dépense du mois par les requêtes facturables du mois et de voir votre coût réel par requête découpée, le chiffre qui vous dit si la croissance des charges utiles ronge la marge.
La charge AWS est réglée après la clôture du mois, il faut donc la provisionner. Estimez la part de messagerie à partir de vos métriques de requêtes à la clôture, ajustez sur la facture quand elle arrive, et tenez la part du bac à sable hors du coût des ventes. Voici un cycle complet pour un mois où la messagerie de production s'est élevée à dix-huit dollars et quarante cents et le bac à sable à deux dollars et dix cents :
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 USDRapprochez le montant provisionné de votre explorateur de coûts groupé par service et type d'usage au moins mensuellement. SQS et SNS doivent apparaître en lignes séparées pour qu'un pic de l'un ne se cache pas dans la tendance plate de l'autre. Si vous tenez vos livres en texte brut, les modèles de suivi des coûts dans la documentation s'étendent naturellement à une répartition de la messagerie par service.
Un piège de classification à éviter : les primes FIFO et le stockage à rétention étendue restent des coûts de messagerie, mais une rétention étendue au-delà de votre véritable fenêtre de redrive est un choix de stockage, pas un coût de livraison. Raccourcissez la rétention ou déplacez la part de stockage là où elle appartient, au lieu de laisser une politique de rétention de quatorze jours gonfler discrètement le coût des ventes.
Cinq contrôles qui réduisent généralement la facture de 30 à 50 pour cent
Commencez par le long polling et le traitement par lots. Ensemble, ils réduisent régulièrement la dépense SQS de près de moitié et prennent un après-midi à mettre en œuvre.
1. Activez le long polling partout
Réglez le temps d'attente de réception à vingt secondes sur chaque file. Les workers gardent alors la connexion ouverte au lieu de marteler des interrogations vides, ce qui effondre la ligne des réceptions vides qui domine les factures de files inactives et lisse les pics de CPU chez les consommateurs.
2. Regroupez chaque appel API qui le permet
L'envoi, la réception et la suppression acceptent tous des lots allant jusqu'à dix messages. Un worker traitant un message par appel paie dix fois le nombre de requêtes d'un worker qui en vide dix à la fois. Les suppressions par lots sont les plus souvent oubliées : les équipes qui regroupent soigneusement les envois suppriment souvent un par un.
3. Mettez la charge utile au régime
Gardez chaque événement sous un bloc de 64 Ko. Stockez le document complet dans le stockage objet et envoyez une référence avec les identifiants dont le consommateur a besoin, le patron claim-check. Compressez quand les références sont impraticables, et retirez du chemin critique les blobs embarqués, les enregistrements clients dupliqués et le contexte de débogage verbeux. Chaque bloc que vous éliminez se multiplie à travers les envois, réceptions, suppressions, publications et livraisons.
4. Filtrez au niveau du topic
Attachez des politiques de filtre pour que chaque abonné ne reçoive que les événements qu'il traite. Un fan-out sans filtre paie la livraison et le traitement en aval de messages que le consommateur jette à l'arrivée. C'est un pur gaspillage avec une correction d'une ligne par abonnement.
5. Réservez FIFO aux cas où l'ordre est réel
Auditez quelles files ont véritablement besoin d'ordre et de déduplication. La prime FIFO s'applique à chaque requête découpée sur la file, si bien qu'une file FIFO transportant des événements que personne n'ordonne est une surcharge permanente de 25 pour cent. Pendant l'audit, fixez une rétention courte avec une file de messages morts pour les échecs plutôt que de laisser les messages empoisonnés se réessayer jusqu'à un nombre de requêtes élevé.
Surveillez les deux métriques qui prédisent la facture : le nombre approximatif de messages envoyés et le nombre de réceptions vides. Alertez quand les réceptions vides dépassent une petite part du total des réceptions, et examinez la taille moyenne des charges utiles par file chaque trimestre. La croissance des charges utiles est assez progressive pour échapper d'un mois à l'autre et assez importante pour compter d'une année sur l'autre.
Liste de contrôle de fin de mois pour les coûts de messagerie
Bouclez la boucle de la même façon chaque mois pour que les chiffres restent fiables :
- Récupérez les nombres de requêtes découpées pour SQS et SNS à partir de votre détail de facturation, et non des nombres de messages logiques tirés des journaux applicatifs.
- Divisez la dépense de chaque service par ses requêtes découpées pour obtenir le coût unitaire réel, et comparez-le aux repères catalogue de quarante et cinquante cents.
- Calculez le facteur de blocs moyen par file en divisant les requêtes facturables par les messages logiques ; tout ce qui dépasse 1,2 mérite une revue de la charge utile.
- Séparez la dépense de production de celle de préproduction et de bac à sable à l'aide des étiquettes de ressources, et confirmez que seule la production est entrée en coût des ventes.
- Ajustez la provision du mois dernier sur la facture réglée et reportez l'écart dans votre estimation.
- Vérifiez les réceptions vides en proportion du total des réceptions, et confirmez que le long polling est toujours activé après tout changement d'infrastructure.
- Confirmez que chaque nouvelle file et chaque nouveau topic créés pendant le mois ont hérité des étiquettes de production et des politiques de filtre.
Récupérez les lignes SQS et SNS de ce mois dans votre console de facturation dès aujourd'hui et calculez le facteur de blocs moyen. S'il dépasse 1,2, votre gain de marge le moins coûteux est une charge utile plus petite, pas un plan plus gros.
