چند سال پیش، در پروژه‌ای که یک پلتفرم SaaS را روی AWS میزبانی می‌کردیم، مدیر مالی شرکت با یک گزارش به جلسه آمد: هزینه ماهانه AWS از ۸ هزار دلار به ۲۳ هزار دلار رسیده بود، بدون آن‌که تیم مهندسی تغییری در معماری ایجاد کرده باشد. جلسه‌ای که در آن روز برگزار کردیم، یکی از آموزنده‌ترین تجربه‌های عمر حرفه‌ای من در حوزه ابر بود. بعد از سه هفته بررسی، متوجه شدیم که رشد هزینه، نه از یک تغییر بزرگ، بلکه از انباشت ده تصمیم کوچک آمده بود: یک حجم EBS که بعد از یک مهاجرت فراموش شده بود، یک NAT Gateway که ترافیک غیرضروری را از خودش عبور می‌داد، یک Snapshot قدیمی که سال‌ها کسی به آن سر نزده بود، و یک cluster Elasticsearch که برای workloadی استفاده می‌شد که دو ماه پیش منتقل شده بود. تجربه‌ام می‌گوید پشت هر قبض شوکه‌کننده AWS، مجموعه‌ای از فراموشی‌ها و بی‌توجهی‌ها نهفته است — نه یک تصمیم فاجعه‌بار. در این مقاله، همان تکنیک‌های عملی‌ای را می‌گویم که در پروژه‌های واقعی برای کاهش هزینه AWS به کار می‌برم؛ از تکنیک‌های ساده و پرتأثیر تا رویکردهای پیشرفته‌تر.

پیش‌نیاز ذهنی: هزینه AWS یک مسئله مهندسی است

پیش از ورود به تکنیک‌ها، لازم است یک تغییر ذهنی را روشن کنم. بسیاری از تیم‌ها هزینه AWS را به‌عنوان یک «مشکل مالی» می‌بینند که باید در جلسات ماهانه حل شود. تجربه‌ام می‌گوید این نگاه، شکست‌خورده است. هزینه AWS، دقیقاً مثل latency، throughput، یا availability، یک متریک فنی است که باید در طول توسعه و استقرار پایش شود. همان‌طور که یک مهندس خوب، در طراحی معماری به کارایی توجه می‌کند، باید به هزینه هم توجه کند.

این تغییر ذهنی، سه پیامد عملی دارد:

پیامد اول: هزینه، مسئولیت همه است، نه فقط تیم مالی

در تیم‌های بالغ، هر مهندسی که یک resource ایجاد می‌کند، مسئول هزینه آن resource است. یعنی انتخاب نوع instance، تصمیم درباره retention بکاپ، و انتخاب معماری ذخیره‌سازی — همه این‌ها تصمیم‌های مهندسی با پیامد مالی هستند.

پیامد دوم: Cost Awareness باید بخشی از Code Review باشد

همان‌طور که در Code Review به کیفیت کد، امنیت، و کارایی توجه می‌شود، باید به هزینه هم توجه شود. مثلاً اگر یک Pull Request یک NAT Gateway جدید اضافه می‌کند، یا یک instance گران‌تر را جایگزین می‌کند، این باید صریحاً در Review مطرح شود.

پیامد سوم: بهینه‌سازی، یک پروژه یک‌باره نیست

هزینه AWS، به‌طور مداوم انباشته می‌شود. یعنی پروژه‌ای که امروز ۳۰٪ کاهش هزینه داد، اگر پایش نشود، در سه ماه آینده ممکن است ۱۵٪ رشد کند. بهینه‌سازی، یک رویه مستمر است، نه یک کمپین یک‌باره.

در پروژه‌های ابری، هزینه AWS دقیقاً مثل latency و availability یک متریک مهندسی است. تیم‌هایی که این را می‌فهمند، کمتر شوکه می‌شوند.

گام اول: مشاهده‌پذیری هزینه

پیش از هر اقدامی، باید بدانید هزینه‌ها دقیقاً کجا می‌روند. تجربه‌ام می‌گوید ۸۰٪ تیم‌ها هیچ دید دقیقی از توزیع هزینه خود ندارند. سه ابزار بنیادین برای مشاهده‌پذیری:

Cost Explorer

ابزار رسمی AWS که نمای جامع از هزینه‌ها می‌دهد. قابلیت‌های کلیدی:

  • Group by: گروه‌بندی هزینه‌ها بر اساس سرویس، Region، Tag، Account.
  • Filters: فیلترکردن بر اساس سرویس یا Tag خاص.
  • Time Comparison: مقایسه دوره‌های زمانی مختلف برای تشخیص روند.
  • Forecast: پیش‌بینی هزینه ماه‌های آینده بر اساس روند فعلی.

یک عادت که در پروژه‌ها به کارم آمده: هر هفته در Cost Explorer نگاه کردن به سه نمودار ثابت: هزینه به تفکیک سرویس، هزینه به تفکیک Tag محیط (production، staging، dev)، و روند هزینه در سه ماه گذشته. این پنج دقیقه هفتگی، جلوی شوکه‌های ماهانه را می‌گیرد.

AWS Budgets

ابزار رسمی برای تعریف بودجه و دریافت هشدارها. سه نوع budget:

  • Cost Budget: هشدار در صورت عبور هزینه از آستانه.
  • Usage Budget: هشدار در صورت عبور مصرف از آستانه.
  • Reservation Budget: هشدار در صورت نرخ استفاده پایین از Reserved Instances.

پیشنهاد عملی: برای هر پروژه، سه بودجه تعریف کنید: یک بودجه ماهانه کل، یک بودجه به تفکیک محیط، و یک بودجه به تفکیک سرویس‌های اصلی. هشدارها را در دو سطح تعریف کنید: ۸۰٪ (هشدار زرد) و ۱۰۰٪ (هشدار قرمز). این کار، جلوی شوکه‌های پایان ماه را می‌گیرد.

Cost Anomaly Detection

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

گام دوم: Tagging — انضباط بنیادین

Tagging، یکی از ساده‌ترین و در عین حال پرتأثیرترین کارها در بهینه‌سازی هزینه AWS است. تجربه‌ام می‌گوید بدون Tagging، هیچ بهینه‌سازی جدی‌ای ممکن نیست، چون نمی‌دانید هزینه هر بخش به کدام تیم یا پروژه مربوط است.

استراتژی Tagging

سه دسته Tag که در پروژه‌ها به‌عنوان حداقل الزامی تعریف می‌کنم:

  • Tag های هویتی: Project، Team، Owner، Environment (production/staging/development).
  • Tag های عملیاتی: CostCenter، BusinessUnit، Compliance (اگر رعایت HIPAA، PCI و... لازم است).
  • Tag های مدیریتی: CreatedDate، LastReviewedDate، ExpirationDate (برای منابع موقت).

اجبار Tagging

Tagging اختیاری، در عمل کار نمی‌کند. یعنی هیچ‌کس voluntarily Tag اضافه نمی‌کند. سه راه برای اجبار:

  1. Service Control Policies (SCP): در AWS Organizations، می‌توانید policy بنویسید که تنها ایجاد منابع با Tag های الزامی را اجازه دهد.
  2. IAM Policies: در سطح کاربر، اجازه ایجاد منابع بدون Tag را ندهید.
  3. Automation: یک Lambda بنویسید که منابع بدون Tag را شناسایی و به‌طور خودکار تگ‌گذاری یا حذف کند.

در پروژه‌ای که برای یک شرکت SaaS کار می‌کردم، با اعمال SCP که ایجاد EC2 و RDS بدون Tag را مسدود می‌کرد، نرخ Tagging از ۴۰٪ به ۹۸٪ رسید. در ماه اول، هزینه به‌دلیل حذف خودکار منابع بدون Tag، ۱۲٪ کاهش یافت.

بهینه‌سازی Compute: از Right-Sizing تا Spot

Compute — یعنی EC2، ECS، EKS، Fargate — معمولاً بزرگ‌ترین بخش قبض AWS است. تجربه‌ام می‌گوید این حوزه، بیشترین پتانسیل کاهش هزینه را هم دارد.

تکنیک اول: Right-Sizing

Right-Sizing، یعنی انتخاب اندازه‌ی درست instance. بسیاری از تیم‌ها instance های بزرگ‌تر از نیاز انتخاب می‌کنند، به‌دلیل ترس از کمبود منابع. راه‌حل: استفاده از داده‌های CloudWatch برای تحلیل مصرف واقعی CPU، Memory، و Network در طول ۳۰ روز گذشته.

جدول زیر، معیارهای تعیین Right-Sizing که در پروژه‌ها استفاده می‌کنم:

متریکمقدار پیشنهادیاقدام
CPU متوسطزیر ۲۰٪Downsize
CPU اوجبالای ۹۰٪Upsize یا Auto-scaling
Memory متوسطزیر ۴۰٪Downsize
Network I/Oزیر ۲۰٪بررسی معماری

در تجربه‌ام، Right-Sizing در بیش از ۶۰٪ موارد، امکان کاهش یک یا دو سطح instance را می‌دهد — یعنی کاهش ۳۰ تا ۶۰ درصدی هزینه آن instance. این کاهش، بدون افت کارایی و بدون تغییر در معماری اتفاق می‌افتد.

تکنیک دوم: Auto-scaling

به‌جای پرداخت هزینه برای حداکثر بار به‌صورت پیوسته، از auto-scaling استفاده کنید. سه رویکرد:

  • Target Tracking: تعریف یک هدف (مثلاً CPU ۷۰٪) و اجازه دادن به AWS که خودش تعداد instance ها را تنظیم کند.
  • Step Scaling: تعریف قواعد پله‌ای برای افزایش یا کاهش.
  • Scheduled Scaling: تنظیم تعداد instance بر اساس زمان (مثلاً کاهش در ساعات شب).

در پروژه‌ای برای یک پلتفرم آموزشی، با Scheduled Scaling که تعداد instance را از ۲۰ در ساعات اوج به ۵ در ساعات شب کاهش می‌داد، هزینه EC2 حدود ۴۵٪ کاهش یافت.

تکنیک سوم: Spot Instances

Spot Instances، ظرفیت اضافی AWS با تخفیف تا ۹۰٪ نسبت به On-Demand. چالش اصلی: AWS می‌تواند در هر لحظه آن‌ها را پس بگیرد (با اعلان دو دقیقه‌ای). مناسب workload های tolerance به قطع:

  • Batch Processing
  • CI/CD Pipelines
  • Data Processing
  • Stateless API Servers (با ترکیب On-Demand + Spot)

الگوی پیشنهادی: ترکیب On-Demand و Spot با نسبت ۳۰ به ۷۰. یعنی ۳۰٪ از ظرفیت همیشه On-Demand (برای پایداری) و ۷۰٪ Spot (برای هزینه). با این الگو، در پروژه‌ای که workload batch داشت، هزینه از ۴۵۰۰ دلار در ماه به ۱۴۰۰ دلار رسید.

تکنیک چهارم: Graviton Instances

Graviton، خانواده پردازنده‌های ARM که AWS طراحی کرده. مزیت: قیمت ۲۰٪ کمتر از x86 معادل، با عملکرد مشابه یا بهتر. چالش: نیاز به بازسازی Docker Images برای معماری ARM.

برای اکثر workload های مدرن (Node.js، Python، Go، Java، Nginx)، مهاجرت به Graviton بدون تغییر کد ممکن است. در پروژه‌ای، مهاجرت کل cluster Kubernetes به Graviton، هزینه EC2 را ۲۲٪ کاهش داد، با صرفه‌جویی کل شش‌رقمی در سال.

تکنیک پنجم: Compute Optimizer

سرویس رایگان AWS که با یادگیری ماشین، پیشنهادهای Right-Sizing می‌دهد. مزیت: مبتنی بر داده‌های واقعی، نه حدس. عیب: فقط EC2، EBS، Lambda و چند سرویس دیگر را پشتیبانی می‌کند. در تجربه‌ام، پیشنهادهای این سرویس، در ۷۰٪ موارد قابل اجرا هستند.

بهینه‌سازی Storage: S3 Lifecycle و EBS

Storage، بخش دوم قبض AWS است. تجربه‌ام می‌گوید این حوزه، بیشترین پتانسیل کاهش هزینه از طریق Lifecycle را دارد.

تکنیک اول: S3 Lifecycle Policies

S3 چند کلاس ذخیره‌سازی دارد با قیمت‌های بسیار متفاوت:

کلاسقیمت نسبیمناسب برای
S3 Standard۱۰۰٪داده‌های پربازدید
S3 Standard-IA~۴۵٪داده‌های کم‌بازدید
S3 Glacier Instant~۱۵٪آرشیو با دسترسی آنی
S3 Glacier Flexible~۸٪آرشیو با دسترسی در دقیقه/ساعت
S3 Glacier Deep Archive~۲٪آرشیو طولانی‌مدت

الگوی Lifecycle که در پروژه‌ها به‌طور پیش‌فرض تنظیم می‌کنم:

روز ۰:    S3 Standard
روز ۳۰:   انتقال به S3 Standard-IA
روز ۹۰:   انتقال به S3 Glacier Instant Retrieval
روز ۱۸۰:  انتقال به S3 Glacier Flexible Retrieval
روز ۳۶۵:  انتقال به S3 Glacier Deep Archive
روز ۱۸۲۵: حذف (۵ سال)

با این الگو، در پروژه‌ای که log ها و backup ها حجم زیادی داشتند، هزینه S3 از ۱۸۰۰ دلار ماهانه به ۴۲۰ دلار رسید.

تکنیک دوم: حذف Snapshot های قدیمی

Snapshot های EBS، با گذشت زمان، به‌سرعت انباشته می‌شوند. قاعده: Snapshot هایی که بیش از ۹۰ روز قدمت دارند، معمولاً غیرضروری هستند. الگوی مدیریت:

  • Snapshot های روزانه با retention ۳۰ روز
  • Snapshot های هفتگی با retention ۹۰ روز
  • Snapshot های ماهانه با retention ۳۶۵ روز

در پروژه‌ای، با پاک‌سازی Snapshot هایی که از سیاست عبور کرده بودند، ۲۳۰۰ دلار در ماه صرفه‌جویی شد — در حالی که هیچ داده‌ای از دست نرفت.

تکنیک سوم: gp2 به gp3

اگر از EBS volumes نوع gp2 استفاده می‌کنید، مهاجرت به gp3 بدون تغییر عملکرد ممکن است. مزیت: قیمت ۲۰٪ کمتر، با امکان تنظیم جداگانه IOPS و Throughput. مهاجرت، بسیار ساده است: در Console، volume را انتخاب و Modify کنید.

تکنیک چهارم: حذف Unattached Volumes

Volumes که به هیچ instance متصل نیستند، همچنان هزینه می‌گیرند. در تجربه‌ام، در بیش از نیمی از پروژه‌های متوسط، چند volume بدون attachment وجود دارد که کسی به آن توجه نمی‌کند. یک اسکریپت ساده برای شناسایی:

aws ec2 describe-volumes 
  --filters Name=status,Values=available 
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}'

تکنیک پنجم: EFS Intelligent Tiering

اگر از EFS استفاده می‌کنید، قابلیت Intelligent Tiering به‌طور خودکار فایل‌های کم‌بازدید را به لایه ارزان‌تر منتقل می‌کند. در پروژه‌ای، فعال‌سازی این قابلیت، هزینه EFS را ۴۰٪ کاهش داد، بدون نیاز به تنظیم دستی.

بهینه‌سازی شبکه: NAT Gateway و Data Transfer

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

تکنیک اول: NAT Gateway Optimization

NAT Gateway، یکی از پرحاشیه‌ترین اجزای قبض است. قیمت‌گذاری:

  • هزینه ساعتی: حدود ۰.۰۴۵ دلار در ساعت
  • هزینه پردازش: ۰.۰۴۵ دلار به‌ازای هر گیگابایت

در پروژه‌ای که ۵ ترابایت ترافیک ماهانه از NAT Gateway عبور می‌کرد، هزینه فقط بخش پردازش، ۲۲۵ دلار در ماه بود. راه‌حل‌های کاهش:

  1. VPC Endpoints: برای سرویس‌های AWS (S3، DynamoDB، ECR، Secrets Manager)، از VPC Endpoint استفاده کنید. ترافیک، مستقیماً به سرویس می‌رود بدون عبور از NAT Gateway. صرفه‌جویی معمول: ۳۰ تا ۷۰٪.
  2. NAT Instance: در workload های کم‌حجم، یک EC2 با NAT Instance ارزان‌تر از NAT Gateway است. عیب: نیاز به مدیریت.
  3. کاهش ترافیک خروجی: بررسی کنید چه سرویس‌هایی ترافیک زیادی از VPC به اینترنت می‌فرستند.

تکنیک دوم: VPC Endpoints

برای هر سرویس AWS که از داخل VPC به آن دسترسی دارید، VPC Endpoint ایجاد کنید. دو نوع:

  • Gateway Endpoints: برای S3 و DynamoDB، رایگان، بسیار مؤثر.
  • Interface Endpoints: برای بقیه سرویس‌ها، هزینه ساعتی کم، اما از ترافیک NAT جلوگیری می‌کنند.

در پروژه‌ای، فقط با اضافه کردن Gateway Endpoint برای S3، هزینه NAT Gateway از ۴۸۰ دلار به ۱۸۰ دلار کاهش یافت — چون ۷۰٪ ترافیک مربوط به S3 بود.

تکنیک سوم: Cross-AZ Traffic

در AWS، ترافیک بین Availability Zone ها (AZ ها) هزینه دارد. در معماری‌های چند-AZ، این هزینه می‌تواند قابل توجه باشد. راه‌حل: Topology Aware Routing و Zone-aware services برای کاهش ترافیک بین AZ.

تکنیک چهارم: CloudFront به‌جای ترافیک مستقیم

اگر ترافیک خروجی از EC2 به اینترنت زیاد است، استفاده از CloudFront می‌تواند هزینه را کاهش دهد. ترافیک از CloudFront به کاربر، ارزان‌تر از ترافیک مستقیم EC2 به کاربر است — به‌ویژه برای کاربران دور از Region اصلی.

بهینه‌سازی دیتابیس: RDS و Aurora

دیتابیس، یکی از گران‌ترین بخش‌های AWS است. تجربه‌ام می‌گوید این حوزه، هم پتانسیل کاهش هزینه دارد و هم ریسک بالا.

تکنیک اول: Right-Sizing RDS

RDS، اغلب با instance های بزرگ‌تر از نیاز اجرا می‌شود. استفاده از Performance Insights برای تحلیل واقعی مصرف CPU و Memory، و انتخاب instance مناسب. در پروژه‌ای، با کاهش یک رده instance RDS، هزینه ماهانه از ۸۰۰ دلار به ۳۸۰ دلار رسید، بدون افت عملکرد.

تکنیک دوم: Aurora Serverless v2

برای workload هایی با ترافیک متغیر، Aurora Serverless v2 انتخاب هوشمندانه‌ای است. مزیت: ظرفیت به‌طور خودکار با بار تنظیم می‌شود. یعنی در ساعات کم‌ترافیک، هزینه پایین است. در پروژه‌ای که ساعت‌های اوج و افت داشت، مهاجرت به Aurora Serverless v2، هزینه دیتابیس را ۴۰٪ کاهش داد.

تکنیک سوم: Reserved Instances برای RDS

اگر workload پایدار است، RDS Reserved Instances می‌تواند ۳۰ تا ۶۰٪ تخفیف بدهد. برای workload های پیش‌بینی‌پذیر، این انتخاب واضحی است.

تکنیک چهارم: حذف Read Replica های بی‌استفاده

Read Replica ها، اگرچه برای read scalability مفیدند، اما هزینه دارند. در پروژه‌ای، سه Read Replica وجود داشت که دو تای آن‌ها در طول ۶ ماه گذشته هیچ ترافیکی ندیده بودند. حذف آن‌ها، ۱۲۰۰ دلار در ماه صرفه‌جویی کرد.

تکنیک پنجم: Snapshot Management

Snapshot های RDS، اگر مدیریت نشوند، می‌توانند هزینه قابل توجهی بسازند. سیاست مشابه EBS: نگه‌داشتن snapshot های ضروری، حذف بقیه.

Lambda و Serverless: هزینه در برابر سادگی

Serverless، در نگاه اول، می‌تواند ارزان‌تر از EC2 باشد. ولی این بستگی به workload دارد. تجربه‌ام می‌گوید Serverless در workload های زیر پرتأثیر است:

  • Workload های با ترافیک متغیر: Lambda در ساعات کم‌ترافیک، هزینه نزدیک صفر دارد.
  • Workload های event-driven: اجرای پاسخ به رویداد (مثلاً آپلود فایل).
  • Workload های ناپیوسته: کارهای زمان‌بندی‌شده.

در مقابل، Serverless در workload های زیر می‌تواند گران‌تر باشد:

  • Workload های پیوسته و پرترافیک: در ترافیک دائمی، EC2 یا Containers ارزان‌تر است.
  • Workload های طولانی: Lambda محدودیت ۱۵ دقیقه‌ای دارد، و برای کارهای طولانی گران‌تر است.

بهینه‌سازی Lambda

سه تکنیک کلیدی:

  1. Right-Sizing Memory: Lambda قیمت‌گذاری بر اساس memory-time است. با تنظیم دقیق memory، می‌توان هزینه را ۲۰ تا ۴۰٪ کاهش داد. ابزار AWS Lambda Power Tuning برای این کار مفید است.
  2. Graviton: Lambda روی Graviton، ۲۰٪ ارزان‌تر و سریع‌تر است. تغییر architecture به arm64 در تابع، تفاوت قابل توجهی در هزینه دارد.
  3. کاهش Cold Start: Cold Start، هم latency و هم هزینه را افزایش می‌دهد. با Provisioned Concurrency یا SnapStart می‌توان آن را کاهش داد.

Reserved Instances و Savings Plans

اگر workload پایدار است، استفاده از تخفیف‌های تعهدی می‌تواند تا ۷۲٪ کاهش هزینه بدهد. سه مدل:

مدل اول: Reserved Instances (RI)

تعهد یک یا سه ساله برای instance خاص. سه پرداخت:

  • All Upfront: پرداخت کل مبلغ در ابتدا — بیشترین تخفیف (تا ۷۲٪).
  • Partial Upfront: پرداخت بخشی در ابتدا — تخفیف متوسط (تا ۶۵٪).
  • No Upfront: بدون پرداخت اولیه — کمترین تخفیف (تا ۵۵٪).

مدل دوم: Compute Savings Plans

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

مدل سوم: EC2 Instance Savings Plans

مشابه Compute SP، ولی محدود به یک خانواده instance در یک Region. تخفیف بیشتر از Compute SP ولی انعطاف کمتر.

الگوی پیشنهاد: برای workload پایدار، ۷۰٪ تعهد با Savings Plan و ۳۰٪ On-Demand یا Spot. این ترکیب، هم صرفه‌جویی می‌دهد و هم انعطاف برای تغییرات آینده را حفظ می‌کند.

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

حذف منابع یتیم (Zombie Resources)

منابع یتیم یا Zombie Resources، منابعی هستند که هزینه می‌گیرند ولی استفاده نمی‌شوند. تجربه‌ام می‌گوید این منابع، بزرگ‌ترین فرصت کاهش هزینه هستند، چون معمولاً کسی به آن‌ها توجه نمی‌کند. انواع رایج:

  • EC2 Instances: instance هایی که در طول ۳۰ روز گذشته هیچ CPU فعالیتی نداشته‌اند.
  • EBS Volumes: volumes بدون attachment.
  • Elastic IPs: IP های اختصاصی بدون استفاده — هزینه‌دار در AWS جدید.
  • Load Balancers: LB هایی که به هیچ target گروهی متصل نیستند.
  • RDS Instances: دیتابیس‌هایی که کسی به آن‌ها وصل نمی‌شود.
  • S3 Buckets: bucket های بدون activity.
  • Snapshots: Snapshot های قدیمی که به هیچ volume اصلی اشاره نمی‌کنند.
  • NAT Gateways: NAT هایی که ترافیک صفر دارند.

اسکریپت شناسایی

# شناسایی Elastic IP های بدون استفاده
aws ec2 describe-addresses 
  --query 'Addresses[?AssociationId==null]'

# شناسایی Load Balancers بدون target
aws elbv2 describe-load-balancers 
  --query 'LoadBalancers[*].LoadBalancerArn' | \
  xargs -I {} aws elbv2 describe-target-groups \
  --load-balancer-arn {}

در پروژه‌ای، با یک اسکریپت شناسایی، ۴۷ منبع یتیم پیدا شد که در مجموع ۳۱۰۰ دلار در ماه هزینه می‌گرفتند. حذف آن‌ها، بدون هیچ اثر عملکردی، هزینه را ۳۱۰۰ دلار کاهش داد.

ابزارهای عملی کاهش هزینه

در کنار ابزارهای رسمی AWS، چند ابزار جانبی مفید در پروژه‌ها به کارم آمده:

ابزارهای متن‌باز

  • aws-nuke: برای حذف منابع در حساب‌های تست و sandbox.
  • Cloud Custodian: برای تعریف policy های خودکار برای مدیریت منابع.
  • Infracost: برای برآورد هزینه در زمان Pull Request — یک ابزار مؤثر برای Cost Awareness در تیم مهندسی.
  • Komiser: داشبورد متن‌باز برای مشاهده هزینه‌ها.

ابزارهای تجاری

  • AWS Cost Explorer (Extended): ارتقاء Cost Explorer با قابلیت‌های پیشرفته.
  • CloudHealth (VMware): ابزار جامع مدیریت هزینه multicloud.
  • Cloudability (Apptio): ابزار سازمانی مدیریت هزینه.
  • Vantage: رابط کاربری ساده برای مشاهده و تحلیل هزینه.

ابزارهای بومی AWS

  • Trusted Advisor: بررسی‌های خودکار AWS برای صرفه‌جویی.
  • Compute Optimizer: توصیه‌های Right-Sizing.
  • Cost Optimization Hub: سرویس جدید AWS که توصیه‌های چند سرویس را یکجا ارائه می‌دهد.

در پروژه‌ام، ابزار Infracost ارزش زیادی داشته. با اضافه کردن آن به CI/CD، هر Pull Request یک comment خودکار می‌گیرد که می‌گوید این تغییر چقدر هزینه ماهانه اضافه یا کم می‌کند. این سادگی، تفاوت بین تیمی که هزینه را می‌فهمد و تیمی که نمی‌فهمد را می‌سازد.

حاکمیت هزینه: بودجه، هشدارها و انضباط تیمی

بهینه‌سازی تکنیک‌ها، فقط بخشی از ماجراست. برای پایداری، حاکمیت هزینه لازم است.

سه سطح حاکمیت

سطح اول: بودجه و هشدار

برای هر پروژه، حساب، و تیم، بودجه ماهانه تعریف کنید. هشدار در دو سطح: ۸۰٪ و ۱۰۰٪.

سطح دوم: اجبار و انضباط

سیاست‌هایی که جلوی هزینه‌های ناخواسته را می‌گیرند:

  • اجبار Tagging برای منابع جدید.
  • اجبار استفاده از instance types مجاز (مثلاً عدم استفاده از GPU در dev).
  • اجبار backup retention محدود.

سطح سوم: بازبینی منظم

یک رویه هفتگی یا ماهانه برای بررسی هزینه‌ها. سه فعالیت:

  • Weekly Cost Review: ۱۵ دقیقه جلسه با نگاه به Cost Explorer و Anomaly Detection.
  • Monthly Deep Dive: جلسه دو ساعته برای بررسی عمیق‌تر و تصمیمات Right-Sizing.
  • Quarterly Architecture Review: بازبینی معماری کلی با تمرکز بر هزینه.
حاکمیت هزینه، یک رویه است، نه یک پروژه. تیم‌هایی که این رویه را دارند، حتی در رشد سریع، هزینه را کنترل می‌کنند.

مطالعه موردی: بازگرداندن هزینه از ۲۳ هزار به ۹ هزار دلار

بگذارید همان پروژه‌ای که در ابتدای این مقاله اشاره کردم را با جزئیات باز کنم. پلتفرم SaaS، قبض ماهانه از ۸ هزار به ۲۳ هزار دلار رسیده بود. پروسه‌ای که طی سه ماه انجام دادیم:

هفته اول: مشاهده‌پذیری

با Cost Explorer، توزیع هزینه در سرویس‌های مختلف:

  • EC2: ۴۵٪ (۱۰,۳۵۰ دلار)
  • RDS: ۱۸٪ (۴,۱۴۰ دلار)
  • S3: ۱۲٪ (۲,۷۶۰ دلار)
  • NAT Gateway: ۱۱٪ (۲,۵۳۰ دلار)
  • Elasticsearch: ۸٪ (۱,۸۴۰ دلار)
  • سایر: ۶٪ (۱,۳۸۰ دلار)

هفته دوم و سوم: Right-Sizing EC2

با تحلیل CloudWatch، از ۴۵ instance، ۲۸ تا زیر مصرف بودند. Right-Sizing به کاهش ۳,۲۰۰ دلاری منجر شد.

هفته چهارم: RDS و Elasticsearch

دیتابیس‌ها یک رده بزرگ‌تر از نیاز بودند: صرفه‌جویی ۱,۴۰۰ دلار. یک cluster Elasticsearch بدون ترافیک بود: حذف، ۱,۸۰۰ دلار.

هفته پنجم و ششم: S3 و Storage

Lifecycle policy روی S3 و حذف Snapshot های قدیمی: ۱,۹۰۰ دلار.

هفته هفتم: NAT Gateway و VPC Endpoints

اضافه کردن Gateway Endpoints برای S3 و DynamoDB: ۱,۹۰۰ دلار.

هفته هشتم به بعد: Spot و Reserved

Spot برای batch processing و Reserved برای workload پایدار: ۲,۸۰۰ دلار.

نتیجه نهایی

جمع صرفه‌جویی: ۱۴,۰۰۰ دلار، یعنی کاهش هزینه از ۲۳ هزار به ۹ هزار دلار در ماه. این کاهش، بدون افت عملکرد، بدون تغییر معماری اساسی، و فقط با تکنیک‌های نسبتاً ساده به دست آمد.

اشتباهات پرهزینه در بهینه‌سازی

در تجربه‌ام، پنج اشتباه زیاد دیده‌ام که هر کدام می‌تواند یک پروژه بهینه‌سازی موفق را به شکست بکشاند:

  • بهینه‌سازی کورکورانه: تغییر instance types یا معماری بدون اندازه‌گیری اولیه. راه‌حل: همیشه ابتدا اندازه‌گیری، سپس اقدام.
  • نادیده‌گرفتن زمان مهندسی: کاهش ۱۰۰ دلاری ماهانه در مقابل ۴۰ ساعت کار مهندسی، توجیه ندارد. راه‌حل: ROI (بازگشت سرمایه) را محاسبه کنید.
  • قطع تعهد طولانی بدون تحلیل: خرید RI سه‌ساله برای workloadی که ممکن است شش ماه دیگر کنار گذاشته شود. راه‌حل: تحلیل دقیق پایداری workload.
  • بهینه‌سازی بدون monitoring پیوسته: کاهش هزینه امروز، اما بازگشت به همان سطح سه ماه بعد. راه‌حل: پایش مستمر هزینه.
  • تعطیل کردن محیط‌های توسعه: تلاش برای کاهش هزینه با محدود کردن محیط dev — نتیجه: کندی تیم توسعه و هزینه بیشتر در بلندمدت.

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

خط پایانی این نقشه

کاهش هزینه AWS، نه یک جادو است و نه یک پروژه پیچیده. مجموعه‌ای از تکنیک‌های ساده است که با انضباط و مشاهده‌پذیری، می‌تواند ۴۰ تا ۶۰ درصد کاهش هزینه بیاورد — بدون افت عملکرد و بدون تغییر اساسی در معماری. تجربه‌ام می‌گوید کلید اصلی، در سه چیز خلاصه می‌شود: مشاهده‌پذیری (باید بدانید پول کجا می‌رود)، انضباط (Tagging، بودجه، رویه‌های منظم)، و طراحی (معماری‌ای که از ابتدا هزینه‌محور باشد). تیم‌هایی که این سه را دارند، در رشد سریع هم هزینه را کنترل می‌کنند. تیم‌هایی که ندارند، دیر یا زود با یک قبض شوکه‌کننده روبه‌رو می‌شوند.

قدم عملی امشب: به Cost Explorer وارد شوید و سه نمودار را ببینید — هزینه به تفکیک سرویس، روند سه ماه گذشته، و توزیع Tag های محیط. حتی اگر همین یک کار را انجام دهید، احتمالاً یک یا دو فرصت صرفه‌جویی بزرگ را همین امشب می‌بینید. اگر تجربه‌ای از کاهش هزینه AWS در پروژه‌های خودتان دارید — چه موفق، چه ناموفق — آن را در دیدگاه بنویسید. این نوع داده واقعی، برای خواننده بعدی که در همان مرحله ایستاده، از هر راهنمای عمومی ارزشمندتر است. ☁️