انتقل إلى المحتوى الرئيسي

مختبر: تحسين التكاليف

الهدف​

تحليل بنية تحتية لـ AWS وتقديم توصيات للتحسين مع تبريرات وتقديرات للتوفير.

السيناريو​

السياق​

TechStartup Inc. تنفق $15,000/شهريًا على AWS وترغب في تقليل تكاليفها بنسبة 30% دون التأثير على الأداء.

البنية التحتية الحالية​

┌─────────────────────────────────────────────────────────────┐
│              INFRASTRUCTURE TECHSTARTUP                      │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   COMPUTE ($8,500/mois)                                      │
│   ─────────────────────                                     │
│   • 10x m5.xlarge (production web)     24/7    $1,400      │
│   • 5x m5.large (production API)       24/7    $350        │
│   • 3x r5.2xlarge (production DB)      24/7    $900        │
│   • 5x m5.large (staging)              24/7    $350        │
│   • 8x c5.xlarge (batch processing)    24/7    $1,100      │
│   • 4x t3.large (dev)                  24/7    $250        │
│   • 2x m5.xlarge (CI/CD runners)       24/7    $280        │
│   Autres (Lambda, misc)                        $3,870      │
│                                                              │
│   STORAGE ($3,000/mois)                                      │
│   ─────────────────────                                     │
│   • EBS gp2 volumes                    5 TB    $500        │
│   • S3 Standard                        20 TB   $460        │
│   • EBS Snapshots                      10 TB   $500        │
│   • RDS Storage                        2 TB    $200        │
│   • Backup/Archive                             $1,340      │
│                                                              │
│   NETWORK ($2,500/mois)                                      │
│   ─────────────────────                                     │
│   • NAT Gateways (3x)                          $300        │
│   • Data Transfer                              $2,000      │
│   • Load Balancers (5x)                        $200        │
│                                                              │
│   AUTRES ($1,000/mois)                                       │
│   ───────────────────                                       │
│   • CloudWatch, Secrets Manager, etc.                       │
│                                                              │
│   TOTAL : $15,000/mois                                       │
│                                                              │
└─────────────────────────────────────────────────────────────┘

مقاييس الاستخدام​

الموردمتوسط CPUمتوسط الذاكرةساعات النشاط
Web (prod)35%45%24/7
API (prod)40%50%24/7
DB (prod)65%70%24/7
Staging15%20%9h-18h أيام الأسبوع
Batch80%60%2h/يوم (ليلًا)
Dev10%15%9h-18h أيام الأسبوع
CI/CD25%30%متغير

الجزء 1: تحليل التكاليف​

تمرين 1.1: تحديد المشاكل​

حدد المصادر الخمسة الرئيسية للهدر:

#الموردالمشكلةالتأثير المقدر
1??$?/شهر
2??$?/شهر
3??$?/شهر
4??$?/شهر
5??$?/شهر
💡 الحل
#الموردالمشكلةالتأثير المقدر
1Staging 24/7يجب إيقافه خارج الساعات$250/شهر
2Dev 24/7نفس الشيء، هدر ليلي/عطلة نهاية الأسبوع$180/شهر
3Batch 24/7يعمل فقط 2h/يوم$900/شهر
4Web مبالغ فيهCPU 35% → الحجم المناسب$400/شهر
5لا يوجد RI/SPكل شيء عند الطلب$2,500/شهر

تمرين 1.2: التحليل حسب العلامة​

العلامات الحالية غير مكتملة. اقترح استراتيجية للعلامات:

العلامةإلزاميالقيم الممكنة
?نعم/لا?
?نعم/لا?
?نعم/لا?
?نعم/لا?
💡 الحل
العلامةإلزاميالقيم الممكنة
Environmentنعمproduction, staging, development
Projectنعمweb-app, api, batch, infra
Ownerنعمteam-frontend, team-backend, team-data
CostCenterنعمCC-PROD, CC-DEV, CC-OPS
AutoShutdownلاtrue, false
ExpiryDateلاYYYY-MM-DD

الجزء 2: خطة التحسين​

تمرين 2.1: الحجم المناسب​

اقترح أنواع جديدة من المثيلات:

الحاليالجديدالتبريرالتوفير
m5.xlarge (web)??$?
m5.large (staging)??$?
t3.large (dev)??$?
💡 الحل
الحاليالجديدالتبريرالتوفير
10x m5.xlarge (web)10x m5.largeCPU 35% مناسب مع large$700/شهر
5x m5.large (staging)3x t3.mediumStaging مستخدم قليلًا، burstable مناسب$280/شهر
4x t3.large (dev)4x t3.mediumDev غير مستخدم بشكل كبير$100/شهر

تمرين 2.2: الجدولة​

قم بتكوين الإيقاف التلقائي للبيئات غير الإنتاجية:

# أكمل نص الجدولة
# Staging: إيقاف 18h، بدء 9h (أيام الأسبوع)
# Dev: إيقاف 19h، بدء 8h (أيام الأسبوع)

# EventBridge rule لإيقاف staging في 18h
aws events put-rule \
    --name stop-staging-evening \
    --schedule-expression "cron(_______________)" \
    --state ENABLED

# Lambda أو SSM Automation target
# ...
💡 الحل
# إيقاف staging في 18h UTC، الاثنين-الجمعة
aws events put-rule \
    --name stop-staging-evening \
    --schedule-expression "cron(0 18 ? * MON-FRI *)" \
    --state ENABLED

# بدء staging في 9h UTC، الاثنين-الجمعة
aws events put-rule \
    --name start-staging-morning \
    --schedule-expression "cron(0 9 ? * MON-FRI *)" \
    --state ENABLED

# إيقاف dev في 19h UTC، الاثنين-الجمعة
aws events put-rule \
    --name stop-dev-evening \
    --schedule-expression "cron(0 19 ? * MON-FRI *)" \
    --state ENABLED

# بدء dev في 8h UTC، الاثنين-الجمعة
aws events put-rule \
    --name start-dev-morning \
    --schedule-expression "cron(0 8 ? * MON-FRI *)" \
    --state ENABLED

توفير staging: 14h/يوم × 5 أيام × 4 أسابيع = 280h/شهر (مقابل 720h) → تخفيض ~60% = $210/شهر

توفير dev: 13h/يوم × 5 أيام × 4 أسابيع = 260h/شهر → تخفيض ~65% = $160/شهر

تمرين 2.3: Spot Instances​

حدد أحمال العمل المرشحة لـ Spot:

حمل العملمرشح Spot؟التبرير
Web (prod)??
Batch processing??
CI/CD runners??
💡 الحل
حمل العملمرشح Spot؟التبرير
Web (prod)❌ لاحرج، لا يمكن مقاطعته
Batch processing✅ نعمتنفيذ قصير، يمكن استئنافه، 60-90% توفير
CI/CD runners✅ نعميتحمل الانقطاعات، يمكن إعادة المحاولة

توفير Spot:

  • Batch: $1,100 × 70% = $770/شهر توفير
  • CI/CD: $280 × 65% = $180/شهر توفير

تمرين 2.4: Reserved Instances / Savings Plans​

احسب التغطية المثلى:

حمل العمل الثابت 24/7 (مرشح RI/SP):
- إنتاج الويب: 10 مثيلات → ?
- إنتاج API: 5 مثيلات → ?
- إنتاج DB: 3 مثيلات → ?

حساب التوفير مع خطة توفير لمدة سنة (-30%):
💡 الحل

حمل العمل الثابت (بعد الحجم المناسب):

  • Web: 10x m5.large = ~$700/شهر
  • API: 5x m5.large = ~$350/شهر
  • DB: 3x r5.2xlarge = ~$900/شهر

إجمالي المؤهل لـ RI/SP: $1,950/شهر

مع خطة توفير الحوسبة لمدة سنة (-30%):

  • توفير: $1,950 × 30% = $585/شهر

الالتزام الشهري: $1,365/شهر (مقابل $1,950)

الجزء 3: تحسين التخزين​

تمرين 3.1: ترحيل gp2 → gp3​

EBS gp2 الحالي: 5 TB = $500/شهر
الترحيل إلى gp3: حساب التوفير
💡 الحل

تسعير gp2: $0.10/GB/شهر = 5000 × $0.10 = $500/شهر

تسعير gp3: $0.08/GB/شهر = 5000 × $0.08 = $400/شهر

توفير: $100/شهر (20%)

بالإضافة إلى ذلك: gp3 يوفر 3000 IOPS أساسي مجاني مقابل gp2 الذي يتدرج مع الحجم.

تمرين 3.2: سياسات دورة حياة S3​

اقترح قواعد دورة حياة لـ S3:

الفئةبعدالبياناتالتوفير
Standard0 يومنشطةمرجع
????
????
💡 الحل
الفئةبعدالبياناتالتكلفة/GB
Standard0 يوم< 30 يوم$0.023
Standard-IA30 يوم30-90 يوم$0.0125
Glacier90 يوم> 90 يوم$0.004

تقدير مع 20 TB:

  • إذا كان 30% نشط، 40% IA، 30% أرشيف
  • Standard: 6 TB × $0.023 = $138
  • IA: 8 TB × $0.0125 = $100
  • Glacier: 6 TB × $0.004 = $24
  • الإجمالي: $262/شهر مقابل $460 = $198 توفير (43%)

الجزء 4: الملخص​

تمرين 4.1: جدول ملخص​

أكمل جدول التوفير:

الفئةالإجراءالتوفير/شهر%
Computeالحجم المناسب$??%
Computeالجدولة$??%
ComputeSpot$??%
Computeخطط التوفير$??%
Storagegp2→gp3$??%
Storageدورة حياة S3$??%
الإجمالي$??%
💡 الحل
الفئةالإجراءالتوفير/شهر% من الإجمالي
Computeالحجم المناسب$1,0807.2%
Computeالجدولة$3702.5%
ComputeSpot (batch+CI)$9506.3%
Computeخطط التوفير$5853.9%
Storagegp2→gp3$1000.7%
Storageدورة حياة S3$1981.3%
الإجمالي$3,28321.9%

التكلفة الأولية: $15,000/شهر التكلفة المحسنة: $11,717/شهر التوفير: $3,283/شهر أي ~22%

للوصول إلى 30%، إجراءات إضافية:

  • مراجعة الهيكلية (بدون خادم؟)
  • التفاوض على EDP مع AWS
  • تحسين نقل البيانات

التسليم النهائي​

الوثيقة المطلوب إنتاجها​

  1. تحليل الوضع الحالي مع تحديد الهدر
  2. استراتيجية علامات كاملة
  3. خطة تحسين مفصلة مع الحسابات
  4. جدول ملخص للتوفير
  5. توصيات ذات أولوية (انتصارات سريعة مقابل طويل الأجل)

معايير التقييم​

المعيارالنقاط
تحليل صحيح للهدر/20
استراتيجية العلامات/15
حسابات التوفير/25
خطة قابلة للتنفيذ/25
جودة الوثيقة/15
الإجمالي/100

الأسبوع التالي: MODULE 15 - CloudFormation