تحسين تكلفة السحابة: توقف عن الدفع الزائد لمنتجك الأولي (MVP)

في الربع الأخير، قمت بمراجعة فاتورة AWS لشركة ناشئة ووجدت أنها كانت تنفق 2,800 دولار شهريًا على بنية تحتية يمكن تشغيلها بسهولة مقابل 900 دولار. كان لديهم t3.2xlarge يشغل واجهة برمجة تطبيقات (API) مبنية على Node.js وبلغ ذروة استخدام وحدة المعالجة المركزية (CPU) 12%. ثلاث عناوين IP مرنة (Elastic IPs) غير مستخدمة كانت خاملة بتكلفة 3.65 دولار شهريًا لكل منها. نشر RDS Multi-AZ لقاعدة بيانات تحتوي على 200 صف. بوابة NAT تقوم بتوجيه حركة المرور التي كان يمكن أن تمر عبر نقطة نهاية VPC مجانًا. لم يكن أي من هذا خبيثًا أو حتى مهملًا بشكل خاص — لقد كان تراكمًا لقرارات "فقط قم بتوفير شيء يعمل" التي اتخذت خلال سباق لإطلاق المنتج.

هذا هو القاعدة، وليس الاستثناء. تهدر معظم الشركات الناشئة في مراحلها المبكرة 40-60% من إنفاقها السحابي لأنه لا يوجد أحد في الفريق لديه الوقت أو الحافز لتحسين التكاليف عندما تكون هناك ميزات لإطلاقها. تتفاقم المشكلة: بمجرد توفير البنية التحتية وتشغيلها، لا يلمسها أحد.

أكبر مصائد التكلفة التي أراها باستمرار

قبل الغوص في الحلول، من المفيد فهم أين تذهب الأموال بالفعل. هذه هي المصائد التي أواجهها بشكل متكرر عند مراجعة البنية التحتية للشركات الناشئة.

مثيلات الحوسبة المفرطة التوفير (Over-Provisioned Compute Instances)

هذا هو أكبر مصدر للهدر. تختار الفرق حجم المثيل أثناء الإعداد الأولي — عادةً بناءً على منشور مدونة أو عقلية "فقط لكي نكون في الجانب الآمن" — ولا تعود لمراجعته أبدًا. لقد رأيت مثيلات m5.xlarge تشغل مهام cron التي تنفذ لمدة 30 ثانية كل ساعة. يبقى المثيل خاملًا لمدة 59.5 دقيقة، ويحرق 0.192 دولارًا في الساعة (140 دولارًا شهريًا) ليفعل لا شيء تقريبًا.

السبب الجذري نفسي: لا أحد يريد أن يكون الشخص الذي وفر الخادم بشكل غير كافٍ وتسبب في انقطاع الخدمة. لذلك يقوم الجميع بالتقريب للأعلى. مرتين.

# Check your EC2 instance CPU utilization over the past 2 weeks
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average Maximum

إذا كان متوسط استخدام وحدة المعالجة المركزية (CPU) لديك أقل من 20% وذروة الاستخدام أقل من 50%، فمن شبه المؤكد أنك تفرط في التوفير. قم بتقليل حجم المثيل بمقدار واحد أو اثنين، راقب لمدة أسبوع، ثم اضبط.

وحدات تخزين EBS ولقطات الشاشة المنسية (Forgotten EBS Volumes and Snapshots)

عند إنهاء مثيل EC2، لا يتم حذف وحدات تخزين EBS المرفقة تلقائيًا ما لم تقم بتكوين ذلك عند الإطلاق. هذا يعني أن المثيلات المنهاة تترك وراءها وحدات تخزين يتيمة تستمر في الفوترة. لقد رأيت حسابات تحتوي على عشرات من وحدات تخزين gp3 غير المرفقة، تكلف كل منها 0.08 دولار/جيجابايت/شهريًا، بإجمالي مئات الدولارات لتخزين لا يستخدمه أحد.

اللقطات (Snapshots) أكثر خداعًا. تنشئ نصوص النسخ الاحتياطي التلقائية لقطات يومية بدون سياسة دورة حياة، لذلك تتراكم إلى أجل غير مسمى. وحدة تخزين بحجم 500 جيجابايت يتم التقاط لقطة لها يوميًا لمدة عام تولد 365 لقطة، وبينما تكون لقطات EBS تزايدية، فإن التكاليف تتراكم لتصبح أموالًا حقيقية.

# Find all unattached EBS volumes
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# Find snapshots older than 90 days
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-12-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
  --output table

بوابة NAT: قاتل الميزانية الصامت

تكلف بوابات NAT 0.045 دولارًا في الساعة (32.40 دولارًا شهريًا) لمجرد وجودها، بالإضافة إلى 0.045 دولارًا لكل جيجابايت من البيانات المعالجة. بالنسبة لشركة ناشئة تقوم بإجراء مكالمات API متكررة لخدمات خارجية من شبكات فرعية خاصة، يمكن أن تتجاوز رسوم معالجة البيانات وحدها 100 دولار شهريًا. لقد رأيت رسوم بوابة NAT تشكل 15-20% من إجمالي فاتورة AWS لشركة ناشئة صغيرة.

يعتمد الحل على نوع حركة المرور التي تمر عبر NAT:

• حركة المرور إلى خدمات AWS (S3, DynamoDB, SQS): استخدم نقاط نهاية بوابة VPC (VPC Gateway Endpoints) (مجانية لـ S3 و DynamoDB) أو نقاط نهاية الواجهة (Interface Endpoints) (7.20 دولارًا شهريًا لكل منها، ولكنها لا تزال أرخص من NAT لحركة المرور عالية الحجم).
• حركة المرور إلى الإنترنت من دوال Lambda: فكر فيما إذا كانت هذه الدوال تحتاج بالفعل إلى أن تكون في VPC. يتم وضع العديد من دوال Lambda في VPC "لأسباب أمنية" عندما لا تصل إلى أي موارد VPC.
• حركة المرور الصادرة منخفضة الحجم: يمكن لمثيل NAT على t4g.nano (3.02 دولارًا شهريًا) التعامل مع حركة المرور المتواضعة بجزء بسيط من تكلفة بوابة NAT.

رسوم نقل البيانات

تفرض AWS رسومًا قدرها 0.09 دولارًا/جيجابايت للبيانات التي تغادر المنطقة، وتكلف حركة المرور عبر مناطق التوفر (cross-AZ) 0.01 دولارًا/جيجابايت في كل اتجاه. هذه الرسوم غير مرئية حتى تصبح كذلك. يمكن لبنية الخدمات المصغرة (microservices) الكثيرة الاتصال المنتشرة عبر ثلاث مناطق توفر، مع استدعاء الخدمات لبعضها البعض مئات المرات في الثانية، أن تولد فواتير نقل بيانات مفاجئة.

الحل المعماري: ضع الخدمات التي تتواصل بشكل متكرر في نفس منطقة التوفر (AZ) لأحمال العمل غير الحرجة، أو استخدم موازنات التحميل الداخلية مع تقارب منطقة التوفر (AZ affinity).

ضبط الحجم الصحيح: نهج منهجي

ضبط الحجم الصحيح ليس تمرينًا لمرة واحدة. إنه شيء يجب عليك مراجعته ربع سنويًا. إليك العملية التي أتبعها.

الخطوة 1: جمع بيانات الاستخدام

AWS Compute Optimizer مجاني ويوفر توصيات لضبط الحجم الصحيح لـ EC2 و EBS و Lambda و ECS. قم بتمكينه ودعه يجمع 14 يومًا على الأقل من البيانات قبل التصرف بناءً على توصياته.

لتحليل أكثر تفصيلاً، تعد مقاييس CloudWatch مصدر بياناتك الأساسي. المقاييس الرئيسية التي يجب مراقبتها:

• EC2: CPUUtilization, NetworkIn/Out, MemoryUtilization (يتطلب وكيل CloudWatch)
• RDS: CPUUtilization, DatabaseConnections, FreeableMemory, ReadIOPS, WriteIOPS
• ElastiCache: CPUUtilization, CurrConnections, BytesUsedForCache

الخطوة 2: تصنيف أعباء العمل

لا ينبغي ضبط حجم كل عبء عمل بنفس الطريقة. أقوم بتصنيفها إلى ثلاث فئات:

أعباء العمل ذات الحالة المستقرة (خوادم API، قواعد البيانات): تحتاج هذه إلى سعة ثابتة. اضبط الحجم الصحيح عن طريق إيجاد أصغر مثيل يتعامل مع ذروة الحمل مع هامش 30%. استخدم المثيلات المحجوزة (Reserved Instances) أو خطط التوفير (Savings Plans) للخط الأساسي.

أعباء العمل المتغيرة (معالجة الدفعات، خوادم البناء): يجب أن تستخدم هذه مجموعات التحجيم التلقائي (Auto Scaling Groups) مع سياسات التحجيم المناسبة، أو مثيلات Spot للوظائف الدفعية المتسامحة مع الأخطاء.

أعباء العمل الدورية (مهام cron، التقارير المجدولة): يجب ألا تعمل هذه على مثيلات مخصصة على الإطلاق. انقلها إلى Lambda أو Fargate Spot أو Step Functions.

الخطوة 3: التصرف بشكل تدريجي

لا تقم بضبط حجم كل شيء دفعة واحدة أبدًا. قم بتقليل حجم المثيل بمقدار واحد في كل مرة، راقب لمدة أسبوع، ثم قرر ما إذا كنت ستستمر. تكلفة فترة قصيرة من التوفير الزائد أقل بكثير من تكلفة انقطاع الإنتاج الناجم عن تقليص الحجم العدواني.

المثيلات المحجوزة (Reserved Instances) مقابل خطط التوفير (Savings Plans) مقابل Spot

هنا تحدث المدخرات الحقيقية — خصم 30-72% على أسعار عند الطلب — لكن آليات الالتزام مربكة بما يكفي لدرجة أن العديد من الشركات الناشئة تتجنبها تمامًا.

المثيلات المحجوزة (RIs)

تلتزم بنوع مثيل محدد في منطقة معينة لمدة سنة أو 3 سنوات. في المقابل، تحصل على خصم يتراوح من 30-40% (بدون دفع مقدم، سنة واحدة) إلى 60% (دفع مقدم كامل، 3 سنوات). المشكلة: إذا احتجت إلى تغيير أنواع المثيلات، فإن RIs القياسية ليست مرنة. توفر RIs القابلة للتحويل مرونة أكبر بخصم أقل قليلاً (حوالي 45% لمدة 3 سنوات مع دفع مقدم كامل).

متى تستخدم RIs: قواعد البيانات وأعباء العمل الأخرى حيث يكون نوع وحجم المثيل مستقرين حقًا. المثيلات المحجوزة لـ RDS تستحق العناء دائمًا تقريبًا — فقواعد البيانات نادرًا ما يتغير حجمها.

خطط التوفير (Savings Plans)

خطط التوفير هي البديل الحديث للمثيلات المحجوزة (RIs) للحوسبة. تلتزم بمبلغ دولاري من الحوسبة في الساعة (على سبيل المثال، 0.10 دولار/ساعة) لمدة سنة أو 3 سنوات. ينطبق الالتزام تلقائيًا على استخدام EC2 و Fargate و Lambda، وهو مرن عبر عائلات المثيلات والأحجام وأنظمة التشغيل والمناطق.

متى تستخدم خطط التوفير: دائمًا تقريبًا مفضلة على مثيلات EC2 المحجوزة لأعباء عمل الحوسبة. توفر خطط توفير الحوسبة أفضل نسبة مرونة إلى خصم. ابدأ بالتزام يغطي الحد الأدنى من إنفاقك الأساسي.

# Example: Calculating Savings Plan commitment
# Current on-demand spend: $500/month on EC2
# Minimum baseline (never drops below): $350/month
# Recommended Savings Plan commitment: $350/month = ~$0.48/hour
# Expected savings: ~30% on the committed amount = ~$105/month
# Remaining $150/month stays on-demand for flexibility

مثيلات Spot

توفر مثيلات Spot خصومات تتراوح بين 60-90% ولكن يمكن مقاطعتها بإشعار مدته دقيقتان. إنها مثالية لـ:

• وكلاء بناء CI/CD (استخدم Spot Fleet مع أنواع مثيلات متعددة)
• وظائف معالجة الدفعات التي يمكنها حفظ التقدم واستئنافه
• بيئات التطوير والتجهيز (staging)
• اختبار التحميل

إنها غير مناسبة لخوادم API الإنتاجية، أو قواعد البيانات، أو أي شيء لا يمكنه التعامل مع الإنهاء المفاجئ.

# Example: GitHub Actions self-hosted runner on Spot
# This saves roughly 70% compared to GitHub-hosted runners
# for compute-heavy builds
Resources:
  SpotFleet:
    Type: AWS::EC2::SpotFleet
    Properties:
      SpotFleetRequestConfigData:
        IamFleetRole: !GetAtt SpotFleetRole.Arn
        TargetCapacity: 2
        AllocationStrategy: lowestPrice
        LaunchSpecifications:
          - InstanceType: c5.xlarge
            SpotPrice: "0.06"
          - InstanceType: c5a.xlarge
            SpotPrice: "0.06"
          - InstanceType: c6i.xlarge
            SpotPrice: "0.06"

نماذج تكلفة Serverless: ليست دائمًا أرخص

هناك أسطورة مستمرة مفادها أن Serverless دائمًا أرخص للشركات الناشئة. غالبًا ما تكون أرخص عند النطاق المنخفض، لكن الاقتصاديات تتغير مع نمو حركة المرور.

واقع تسعير Lambda

تفرض Lambda رسومًا لكل طلب (0.20 دولار لكل مليون) ولكل جيجابايت-ثانية من الحوسبة (0.0000166667 دولار). لنقطة نهاية API نموذجية تعمل لمدة 200 مللي ثانية بذاكرة 256 ميجابايت:

• 1,000 طلب/يوم: حوالي 0.03 دولار/شهر. مجاني فعليًا.
• 100,000 طلب/يوم: حوالي 3.00 دولارات/شهر. لا يزال رخيصًا جدًا.
• 1,000,000 طلب/يوم: حوالي 30 دولارًا/شهر. تبدأ المقارنة مع مثيل EC2 صغير.
• 10,000,000 طلب/يوم: حوالي 300 دولار/شهر. يمكن لمثيل t3.medium (30 دولارًا/شهر) مع التخزين المؤقت المناسب التعامل مع هذا بسهولة.

تعتمد نقطة التحول بشكل كبير على مدة التنفيذ وتخصيص الذاكرة، ولكن بالنسبة لمعظم أعباء