قانون تکه‌بندی ۶۴ کیلوبایتی: ثبت قیمت‌گذاری پرداخت به ازای درخواست AWS SQS/SNS به‌عنوان COGS متغیر

شما پیام‌رسانی را با چهل سنت به ازای هر یک میلیون درخواست بودجه‌بندی کردید، اما صورتحساب AWS سه برابر بالاتر از آنچه تعداد پیام‌هایتان می‌گفت از راه رسید. مقصر افزایش قیمت نیست. مقصر قانون تکه‌بندی ۶۴ کیلوبایتی است: AWS یک پیام منطقی را صورتحساب نمی‌کند، بلکه هر تکه ۶۴ کیلوبایتی از بار داده را در هر فراخوانی API که به آن دست می‌زند صورت‌حساب می‌کند. یک رویداد سفارش ۲۰۰ کیلوبایتی وقتی آن را می‌فرستید چهار درخواست قابل‌صورتحساب است، وقتی یک کارگر آن را دریافت می‌کند چهار درخواست دیگر، و وقتی کارگر آن را حذف می‌کند چهار درخواست دیگر. دوازده هزینه برای یک پیام، پیش از آنکه fan-out در SNS دوباره آن را چند برابر کند.

این مقاله توضیح می‌دهد که SQS و SNS در واقع چگونه درخواست‌ها را می‌شمارند، این کار در حجم واقعی چه هزینه‌ای دارد، چرا پیام‌رسانی تولید به بهای تمام‌شده کالای فروش‌رفته تعلق دارد و نه سرباز، و چگونه آن را ثبت کنید تا حاشیه سود ناخالصتان حقیقت را بگوید.

چگونه SQS یک پیام را به چندین درخواست قابل‌صورتحساب تبدیل می‌کند​

قیمت‌گذاری SQS به‌طور فریب‌دهنده‌ای ساده به نظر می‌رسد: صف‌های Standard حدود چهل سنت به ازای هر یک میلیون درخواست هزینه دارند، صف‌های FIFO حدود پنجاه سنت به ازای هر یک میلیون، و یک میلیون درخواست Standard اول هر ماه رایگان است. پیچیدگی در تعریف یک درخواست پنهان است.

هر تکه ۶۴ کیلوبایتی یک درخواست است​

هر تکه ۶۴ کیلوبایتی شروع‌شده از بار داده، به‌عنوان یک درخواست مستقل شمرده می‌شود. یک پیام ۳۰ کیلوبایتی یک درخواست است. یک پیام ۶۴ کیلوبایتی یک درخواست است. یک پیام ۶۵ کیلوبایتی دو درخواست است. یک پیام ۲۰۰ کیلوبایتی چهار درخواست، یک پیام ۲۵۶ کیلوبایتی چهار درخواست، و یک بار داده ۱ مگابایتی شانزده درخواست است.

آن عدد آخر بیش از گذشته اهمیت دارد. در آگوست ۲۰۲۵، AWS حداکثر اندازه پیام SQS را از ۲۵۶ کیلوبایت به ۱ مگابایت برای صف‌های Standard و FIFO افزایش داد. این فضای اضافی برای رویداد بزرگ گاه‌به‌گاه راحت است، اما هر چیزی که بالای ۶۴ کیلوبایت نگه دارید، ضریب تکه‌بندی را در هر دست‌زدن می‌پردازد. تیمی که از بار داده متوسط ۵۰ کیلوبایتی به ۲۰۰ کیلوبایتی می‌رود، تعداد درخواست‌های SQS خود را چهار برابر می‌کند بدون آنکه یک پیام اضافه بفرستد.

هر اقدام API به‌طور جداگانه شمرده می‌شود​

هر اقدام API روی یک صف یک درخواست است، و ضریب تکه‌بندی روی هرکدام اعمال می‌شود. ارسال، دریافت، حذف و تغییر قابلیت مشاهده پیام هرکدام به‌طور مستقل اندازه‌گیری می‌شوند.

چرخه کامل عمر یک پیام ۲۰۰ کیلوبایتی روی یک صف Standard را مرور کنید. ارسال چهار درخواست قابل‌صورتحساب است. دریافت کارگر چهار درخواست دیگر است. حذف پس از پردازش موفق چهار درخواست دیگر است. یک پیام منطقی، دوازده درخواست قابل‌صورتحساب، تقریباً نیم سنت به ازای هر هزار در نرخ‌های فهرست. همان چرخه عمر برای یک پیام ۳۰ کیلوبایتی در مجموع سه درخواست است. اندازه بار داده متغیر غالب در بیشتر صورتحساب‌های SQS است، نه تعداد پیام.

دو سنجه دیگر اپراتورهای تازه‌کار را غافلگیر می‌کند. دریافت‌های خالی قابل‌صورتحساب هستند: هر نظرسنجی که هیچ پیامی برنگرداند هنوز به‌عنوان یک درخواست شمرده می‌شود، بنابراین یک حلقه short-poll تهاجمی روی یک صف بیکار بی‌جهت پول می‌سوزاند. و صف‌های FIFO حدود ۲۵ درصد حق بیمه نسبت به Standard در هر سطح حجمی دارند، که وقتی ضریب تکه‌بندی از قبل علیه شما کار می‌کند، سریع جمع می‌شود. از FIFO جایی استفاده کنید که ترتیب و پردازش دقیقاً-یک‌بار واقعاً مورد نیاز است، و در همه جای دیگر از Standard.

چگونه SNS آن را بار دوم چند برابر می‌کند​

SNS یک بُعد دوم به صورتحساب اضافه می‌کند، چون یک پیام منتشرشده یک بار هنگام رسیدن و بار دیگر در هر تحویل اندازه‌گیری می‌شود.

انتشارها و تحویل‌ها سنجه‌های جداگانه هستند​

انتشار به یک تاپیک حدود پنجاه سنت به ازای هر یک میلیون درخواست هزینه دارد، با همان روش تکه‌بندی: یک انتشار ۲۵۶ کیلوبایتی چهار درخواست شمرده می‌شود. سپس هر تحویل به هر مشترک نیز به ازای هر تکه ۶۴ کیلوبایتی اندازه‌گیری می‌شود، با نرخی که به پروتکل تحویل بستگی دارد.

همه تحویل‌ها هزینه یکسانی ندارند. تحویل به صف‌های SQS، توابع Lambda و جریان‌های Firehose هزینه تحویل ندارند، که fan-out از SNS به SQS را در سمت تحویل تقریباً رایگان می‌کند. تحویل‌های HTTP و HTTPS، ایمیل و push موبایل اندازه‌گیری می‌شوند، و SMS به ازای هر بخش پیام جداگانه قیمت‌گذاری می‌شود. بنابراین یک رویداد ۲۵۶ کیلوبایتی که به سه صف SQS و یک وب‌هوک HTTP fan-out می‌شود، چهار درخواست انتشار، صفر برای سه تحویل SQS، و چهار تحویل HTTP هزینه دارد. آن رویداد را زیر ۶۴ کیلوبایت کوچک کنید و همان fan-out یک انتشار به‌علاوه یک تحویل HTTP هزینه دارد.

SNS در سپتامبر ۲۰۲۶ به دنبال SQS به بارهای داده بزرگ‌تر رفت و پیام‌های ۱ مگابایتی را پشت یک تنظیم حداکثر اندازه در سطح تاپیک مجاز کرد. تاپیک‌هایی که بالای ۲۵۶ کیلوبایت پیکربندی شده‌اند فقط می‌توانند به SQS، Lambda و Firehose تحویل دهند، با حداکثر صد اشتراک. این محدودیت اشاره‌ای به الگوی مورد نظر است: رویدادهای بزرگ به یک خط لوله متکی بر صف تعلق دارند، نه پخش به همه پروتکل‌ها.

چرا fan-out هنوز برنده است​

سنجه تحویل تیم‌ها را وسوسه می‌کند که SNS را کنار بگذارند و پیام‌های SQS تکراری را مستقیماً به هر مصرف‌کننده بفرستند. در برابر این وسوسه مقاومت کنید. ارسال‌های تکراری گران‌ترین بخش چرخه را چند برابر می‌کنند، یعنی ارسال به‌علاوه دریافت به‌علاوه حذف برای هر مصرف‌کننده، در حالی که fan-out از SNS به SQS یک انتشار و صفر هزینه تحویل SQS به ازای هر مشترک می‌پردازد. وقتی چندین مصرف‌کننده به یک رویداد یکسان نیاز دارند، fan-out هم معماری پاکیزه‌تری است و هم صورتحساب ارزان‌تری.

این کار در حجم واقعی چقدر هزینه دارد​

نرخ‌های فهرست اعداد به ازای هر میلیون هستند که فقط وقتی ضرب شوند معنا پیدا می‌کنند، پس در ادامه سه شکل واقعی آمده است.

یک پروژه جانبی که ماهانه ۲ میلیون پیام کوچک از طریق یک صف Standard می‌فرستد تقریباً هیچ هزینه‌ای نمی‌پردازد. هر پیام زیر ۶۴ کیلوبایت یک ارسال، یک دریافت و یک حذف هزینه دارد، یعنی ۶ میلیون درخواست. یک میلیون اول رایگان است و ۵ میلیون باقی‌مانده با چهل سنت به ازای هر میلیون: حدود دو دلار.

یک پلتفرم SaaS میان‌رده که ماهانه ۵ میلیون اعلان ۱۰ کیلوبایتی را به یک تاپیک Standard با سه مشترک SQS و یک وب‌هوک HTTP منتشر می‌کند، برای بخش SNS مبلغی تک‌رقمی می‌پردازد. انتشارها حدود دو دلار و پنجاه سنت است. سه تحویل SQS رایگان هستند. تحویل‌های HTTP حدود سه دلار با شش سنت به ازای هر صد هزار. اقدامات API پایین‌دستی SQS تقریباً کل را دو برابر می‌کند و کل خط لوله اعلان زیر پانزده دلار در ماه می‌ماند. این همان شکلی است که پیام‌رسانی واقعاً ناچیز است.

حالا همان بار کاری SaaS را با بارهای داده ۲۰۰ کیلوبایتی بازپخش کنید، چون هر رویداد یک سند سفارش کامل را در خود جای می‌دهد. هر سنجه چهار برابر می‌شود. انتشارها به ده دلار می‌رسند، تحویل‌های HTTP به دوازده، و دریافت‌ها و حذف‌های پایین‌دستی SQS نیز چهار برابر می‌شوند. خط لوله نزدیک شصت دلار در ماه می‌رسد، که هنوز به‌طور مطلق کوچک است، اما چهار برابر هزینه همان بار کاری با رویدادهای سبک است، و این شکاف با رشد حجم بزرگ‌تر می‌شود. در ۵۰۰ میلیون درخواست تکه‌بندی‌شده در ماه، تفاوت بین رویدادهای سبک و حجیم یک قلم سالانه چهاررقمی است.

سطح‌های حجمی وجود دارند اما برای کسب‌وکارهای کوچک به‌ندرت اهمیت دارند: درخواست‌های Standard پس از ۱۰۰ میلیارد و ۲۰۰ میلیارد درخواست در ماه کاهش می‌یابند. اهرم واقعی شما سطح نیست، بلکه میانگین ضریب تکه‌بندی است.

چرا پیام‌رسانی تولید COGS متغیر است، نه سرباز​

پیام‌رسانی که محصول شما را به مشتریان پرداخت‌کننده می‌رساند، هزینه مستقیم درآمد است. با مصرف رشد می‌کند، وقتی چیزی فروخته نمی‌شود ناپدید می‌شود، و سرمایه‌گذاران انتظار دارند آن را بالای خط حاشیه سود ناخالص در کنار محاسبات، پایگاه داده، ذخیره‌سازی و پهنای باند برای تولید ببینند.

استانداردهای حسابداری در اینجا جای مانور می‌دهند: اصول پذیرفته‌شده عمومی حسابداری، بهای تمام‌شده کالای فروش‌رفته را دقیق تعریف نمی‌کنند، و رویه حاشیه سود ناخالص SaaS این شکاف را با آزمون هزینه مستقیم پر می‌کند. بپرسید آیا این هزینه برای خدمت به مشتریان در تولید وجود دارد. صف‌های تولید که رویدادهای سفارش را حمل می‌کنند، تاپیک‌های اعلان که به کارگرهای رو به مشتری fan-out می‌شوند، و تحویل‌های وب‌هوک به نقاط پایانی مشتری همه قبول می‌شوند. صف‌های staging، تاپیک‌های تست بار، اشتراک‌های سندباکس توسعه‌دهنده، و صف dead-letter که تست بار فصل گذشته را تخلیه می‌کند قبول نمی‌شوند. آن‌ها به تحقیق و توسعه یا سرباز عمومی تعلق دارند.

مرز تولید تمام بازی است. یک صورتحساب AWS همه صف‌ها و تاپیک‌ها را یک‌جا جمع می‌کند، پس منابع تولید را برچسب بزنید و هر ماه صورت‌حساب را تفکیک کنید. تیم‌هایی که تفکیک را نادیده می‌گیرند معمولاً در جهت چاپلوسانه‌تری خطا می‌کنند، زیرساخت را در سرباز دفن می‌کنند و حاشیه سود ناخالصی گزارش می‌دهند که اقتصاد واحدشان نمی‌تواند از آن دفاع کند. یک بررسی تفصیلی آن را در یک بعدازظهر دوباره طبقه‌بندی می‌کند، و حاشیه سود بازبیان‌شده هرگز بالاترین نیست.

مبلغ خالصی را که واقعاً می‌پردازید ثبت کنید. سطح رایگان یک تخفیف صورتحساب است، نه درآمد، پس چیزی برای ناخالص‌سازی وجود ندارد. اگر می‌خواهید ببینید سطح رایگان چه مقدار از بار کاری را جذب می‌کند، درخواست‌های قابل‌صورتحساب را جداگانه در سنجه‌هایتان ردیابی کنید و ورودی دفتر را با هزینه نقدی نگه دارید.

چگونه آن را ثبت کنید تا حاشیه سودتان حقیقت را بگوید​

به پیام‌رسانی حساب بهای تمام‌شده فروش اختصاصی خودش بدهید به جای اینکه آن را با یک خط عمومی ابری یا نرم‌افزاری مخلوط کنید. حسابی اختصاصی مانند cloud messaging به شما اجازه می‌دهد هزینه ماه را بر درخواست‌های قابل‌صورتحساب ماه تقسیم کنید و هزینه واقعی خود به ازای هر درخواست تکه‌بندی‌شده را ببینید، که همان عددی است که به شما می‌گوید آیا رشد بار داده حاشیه سود را می‌خورد یا نه.

هزینه AWS پس از پایان ماه تسویه می‌شود، پس آن را تعهدی ثبت کنید. بخش پیام‌رسانی را هنگام بستن از سنجه‌های درخواستتان تخمین بزنید، وقتی صورت‌حساب رسید آن را تعدیل کنید، و بخش سندباکس را از بهای تمام‌شده فروش بیرون نگه دارید. در ادامه یک چرخه کامل برای ماهی آمده است که پیام‌رسانی تولید هجده دلار و چهل سنت بود و سندباکس دو دلار و ده سنت اضافه کرد:

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 USD

مبلغ تعهدی را حداقل ماهانه با cost explorer خود که بر اساس سرویس و نوع مصرف گروه‌بندی شده تطبیق دهید. SQS و SNS باید به‌صورت خطوط جداگانه ظاهر شوند تا جهش در یکی داخل روند مسطح دیگری پنهان نشود. اگر دفترهایتان را به‌صورت متن ساده نگه می‌دارید، الگوهای ردیابی هزینه در مستندات به‌طور طبیعی به تفکیک پیام‌رسانی به ازای هر سرویس تعمیم می‌یابند.

یک دام طبقه‌بندی که باید از آن اجتناب کنید: حق بیمه FIFO و ذخیره‌سازی نگهداری تمدیدشده هنوز هزینه‌های پیام‌رسانی هستند، اما نگهداری تمدیدشده فراتر از پنجره redrive واقعی شما یک انتخاب ذخیره‌سازی است، نه هزینه تحویل. یا نگهداری را کوتاه کنید یا بخش ذخیره‌سازی را به جایی که تعلق دارد منتقل کنید، به جای اینکه بگذارید یک سیاست نگهداری چهارده‌روزه بی‌سروصدا بهای تمام‌شده فروش را باد کند.

پنج کنترلی که معمولاً صورتحساب را ۳۰ تا ۵۰ درصد کاهش می‌دهند​

با long polling و دسته‌بندی شروع کنید. این دو با هم معمولاً هزینه SQS را تقریباً نصف می‌کنند و یک بعدازظهر برای پیاده‌سازی وقت می‌گیرند.

۱. long polling را همه‌جا روشن کنید​

زمان انتظار دریافت را روی هر صف بیست ثانیه تنظیم کنید. سپس کارگرها اتصال را باز نگه می‌دارند به جای اینکه به نظرسنجی‌های خالی بکوبند، که خط دریافت خالی را که بر صورتحساب‌های صف بیکار غالب است فرو می‌ریزد و جهش‌های CPU مصرف‌کننده‌ها را هموار می‌کند.

۲. هر فراخوانی API را که اجازه می‌دهد دسته‌بندی کنید​

ارسال، دریافت و حذف همگی از دسته‌های تا ده پیام پشتیبانی می‌کنند. کارگری که در هر فراخوانی یک پیام پردازش می‌کند، ده برابر تعداد درخواست کارگری را می‌پردازد که ده تا را یک‌جا تخلیه می‌کند. حذف‌های دسته‌ای رایج‌ترین مورد از قلم‌افتاده است: تیم‌هایی که ارسال‌ها را با دقت دسته‌بندی می‌کنند اغلب یکی‌یکی حذف می‌کنند.

۳. بار داده را کم‌حجم کنید​

هر رویداد را زیر یک تکه ۶۴ کیلوبایتی نگه دارید. سند کامل را در ذخیره‌سازی شیء نگه دارید و یک ارجاع همراه با شناسه‌هایی که مصرف‌کننده نیاز دارد بفرستید، الگوی claim-check. جایی که ارجاع‌ها غیرعملی هستند فشرده کنید، و بلاب‌های جاسازی‌شده، سوابق تکراری مشتری و زمینه اشکال‌زدایی پرحرف را از مسیر داغ حذف کنید. هر تکه‌ای که حذف می‌کنید در ارسال‌ها، دریافت‌ها، حذف‌ها، انتشارها و تحویل‌ها ضرب می‌شود.

۴. در سطح تاپیک فیلتر کنید​

سیاست‌های فیلتر را متصل کنید تا هر مشترک فقط رویدادهایی را دریافت کند که مدیریت می‌کند. fan-out بدون فیلتر هزینه تحویل و پردازش پایین‌دستی را برای پیام‌هایی می‌پردازد که مصرف‌کننده هنگام رسیدن دور می‌ریزد. این اتلاف محض است با یک اصلاح یک‌خطی به ازای هر اشتراک.

۵. FIFO را برای جایی که ترتیب واقعی است نگه دارید​

بررسی کنید کدام صف‌ها واقعاً به ترتیب و حذف تکراری نیاز دارند. حق بیمه FIFO روی هر درخواست تکه‌بندی‌شده روی صف اعمال می‌شود، بنابراین یک صف FIFO که رویدادهایی را حمل می‌کند که هیچ‌کس ترتیبشان را نمی‌خواهد، یک اضافه‌هزینه همیشگی ۲۵ درصدی است. در حین بررسی، نگهداری کوتاه با یک صف dead-letter برای شکست‌ها تنظیم کنید به جای اینکه بگذارید پیام‌های سمی به یک تعداد درخواست بزرگ دوباره تلاش کنند.

دو سنجه‌ای را که صورتحساب را پیش‌بینی می‌کنند پایش کنید: تعداد تقریبی پیام‌های ارسال‌شده و تعداد دریافت‌های خالی. وقتی دریافت‌های خالی از سهم کوچکی از کل دریافت‌ها فراتر رفت هشدار بدهید، و هر سه ماه میانگین اندازه بار داده هر صف را بررسی کنید. رشد بار داده به‌قدری تدریجی است که ماه‌به‌ماه از دست برود و به‌قدری بزرگ که سال‌به‌سال اهمیت داشته باشد.

چک‌لیست پایان ماه برای هزینه‌های پیام‌رسانی​

هر ماه چرخه را به همین روش ببندید تا اعداد قابل‌اعتماد بمانند:

1. تعداد درخواست‌های تکه‌بندی‌شده را برای SQS و SNS از تفکیک صورتحساب خود بگیرید، نه تعداد پیام‌های منطقی از گزارش‌های برنامه.
2. هزینه هر سرویس را بر درخواست‌های تکه‌بندی‌شده آن تقسیم کنید تا هزینه واقعی واحد را به دست آورید، و آن را با معیارهای فهرست چهل و پنجاه سنت مقایسه کنید.
3. میانگین ضریب تکه‌بندی هر صف را با تقسیم درخواست‌های قابل‌صورتحساب بر پیام‌های منطقی محاسبه کنید؛ هر چیزی بالای ۱.۲ مستحق بررسی بار داده است.
4. هزینه تولید را از staging و سندباکس با استفاده از برچسب‌های منابع تفکیک کنید، و تأیید کنید که فقط تولید در بهای تمام‌شده فروش قرار گرفته است.
5. تعهدی ماه گذشته را با صورت‌حساب تسویه‌شده تعدیل کنید و مغایرت را در تخمین خود به جلو ببرید.
6. دریافت‌های خالی را به‌عنوان سهمی از کل دریافت‌ها بررسی کنید، و تأیید کنید که long polling پس از هر تغییر زیرساختی هنوز فعال است.
7. تأیید کنید که هر صف و تاپیک جدیدی که در طول ماه ایجاد شده، برچسب‌های تولید و سیاست‌های فیلتر را به ارث برده است.

امروز خطوط SQS و SNS این ماه را از کنسول صورتحساب خود بگیرید و میانگین ضریب تکه‌بندی را محاسبه کنید. اگر بالای ۱.۲ باشد، ارزان‌ترین برد حاشیه سود شما یک بار داده کوچک‌تر است، نه یک پلن بزرگ‌تر.