فاتورتي السحابية انفجرت: رحلتي في مطاردة التكاليف الخفية على AWS وإيقاف نزيف الميزانية

يا صباح الخير… أو هكذا كنت أظن. أذكر ذلك اليوم جيداً، استيقظت كالعادة، جهزت فنجان القهوة بالهيل وجلست أمام شاشة اللابتوب لأبدأ يومي البرمجي. فتحت البريد الإلكتروني لأجد رسالة من AWS بعنوان “Your AWS bill for the month is available”. إشي روتيني، أليس كذلك؟ لكن هذه المرة، كان الرقم بجانب علامة الدولار كفيلاً بأن يجعل القهوة تفقد طعمها. الرقم كان… فلكياً! عشرة أضعاف فاتورتي المعتادة.

أول كلمة خرجت من فمي كانت “يا ساتر! شُو هاد؟”. شعرت بذلك المزيج من الذعر والغضب والارتباك. هل اخترق أحدهم حسابي؟ هل نسيت خادماً عملاقاً يعمل في الخلفية؟ ألف سؤال وسؤال دار في رأسي وأنا أسارع بتسجيل الدخول إلى لوحة تحكم AWS. كانت تلك اللحظة هي بداية رحلة مطاردة لم أكن أتوقعها، رحلة في أعماق فواتيري السحابية لكشف اللغز وإيقاف نزيف الميزانية. اليوم، سأشارككم هذه التجربة، “بحذافيرها”، وكيف أصبح AWS Cost Explorer صديقي الصدوق في هذه المعركة.

الخطوة الأولى: من الصدمة إلى التحقيق المنهجي

بعد الدقائق الأولى من الصدمة ومحاولة فهم ما يجري، أدركت أن التحديق في لوحة التحكم الرئيسية لن يحل المشكلة. كان عليّ أن أتصرف كمحقق، لا كضحية. هنا يأتي دور الأداة التي أنقذت الموقف: AWS Cost Explorer.

كثيرون منا ينظرون إلى الفاتورة الشهرية كرقم نهائي، لكن الحقيقة أنها قصة مكونة من آلاف التفاصيل الصغيرة. Cost Explorer هو المجهر الذي يسمح لك بقراءة هذه القصة وفهم فصولها.

ما هو AWS Cost Explorer؟

ببساطة، هو أداة تحليلية مجانية داخل AWS تمنحك واجهة رسومية لتصور وفهم وتحليل تكاليفك واستخدامك للموارد. يمكنك اعتباره “المحقق كونان” الخاص بحسابك السحابي. يسمح لك بتقطيع البيانات وتصفيتها حسب معايير مختلفة لتحديد مصدر التكاليف بدقة متناهية. للوصول إليه، ما عليك سوى الذهاب إلى لوحة تحكم AWS والبحث عن “Cost Explorer”.

نصيحة من أبو عمر: قبل أن “تولع معك” وتغلق كل شيء بشكل عشوائي، خذ نفساً عميقاً وافتح Cost Explorer. التصرف المتسرع قد يؤدي إلى إيقاف خدمات حيوية. التحليل أولاً، ثم التصرف.

فن الحفر والتنقيب: استخدام فلاتر Cost Explorer كالمحترفين

عندما فتحت Cost Explorer لأول مرة، رأيت رسماً بيانياً ضخماً يظهر ارتفاعاً حاداً في التكاليف في الأيام القليلة الماضية. كان هذا هو الدليل الأول، لكنه لم يكن كافياً. القوة الحقيقية للأداة تكمن في قائمة الفلاتر (Filters) على يمين الشاشة.

1. التصفية حسب الخدمة (Service)

هذه هي الخطوة الأولى والمنطقية. أردت أن أعرف أي خدمة من خدمات AWS هي المسؤولة عن هذه الكارثة. من قائمة الفلاتر، اخترت “Group by: Service”.

وفجأة، اتضحت الصورة. كانت معظم الخدمات (S3, RDS, Lambda) ضمن نطاقها الطبيعي، لكن كان هناك عمود واحد ضخم بلون مختلف يصرخ “أنا المشكلة!”. كانت خدمة EC2-Instances، وتحديداً تكاليف نقل البيانات (Data Transfer) المرتبطة بها.

لقد حددت الجاني الرئيسي، لكن التحقيق لم ينتهِ. أي خادم EC2 تحديداً؟ وما نوع نقل البيانات هذا؟

2. التصفية حسب نوع الاستخدام (Usage Type)

هنا نتعمق أكثر. بعد تحديد الخدمة، أردت أن أعرف ما هو “نوع الاستخدام” الدقيق الذي تسبب في التكلفة. أبقيت على التصفية حسب الخدمة (EC2)، وأضفت فلتر “Usage Type”.

النتائج كانت مذهلة. وجدت بنداً اسمه DataTransfer-Out-Bytes بتكلفة هائلة. هذا يعني أن أحد خوادمي كان يرسل كميات ضخمة من البيانات إلى الإنترنت. لم يكن استقبالاً للبيانات (وهو مجاني غالباً)، بل إرسالاً لها، وهذا ما تفرضه عليه AWS رسوماً باهظة.

3. التصفية حسب المنطقة (Region) والوسوم (Tags)

الآن بعد أن عرفت أن المشكلة تكمن في “Data Transfer Out” من EC2، احتجت لتحديد الخادم نفسه. هنا يأتي دور الفلاتر الأخرى:

  • المنطقة (Region): إذا كنت تستخدم مناطق متعددة، فهذا الفلتر يساعدك على تحديد المنطقة التي تحدث فيها المشكلة. في حالتي، كانت كل مواردي في منطقة واحدة، لذا لم يكن هذا الفلتر مفيداً جداً.
  • الوسوم (Tags): وهذه هي النصيحة الذهبية! لو كنت أتبع سياسة صارمة في “توسيم” (Tagging) كل مواردي منذ البداية، لكانت هذه الخطوة أسهل بكثير. الوسم هو مجرد ملصق (مفتاح-قيمة) تضعه على مواردك، مثل Project:WebApp أو Environment:Production.

لحسن الحظ، كنت قد بدأت بتطبيق نظام الوسوم مؤخراً. قمت بالتصفية حسب وسم “Project” لأرى أي مشروع يستهلك هذه التكلفة، وبالفعل، تمكنت من حصر المشكلة في خادم واحد مرتبط بمشروع تجريبي كنت أعمل عليه.

كشف الجاني واتخاذ الإجراءات اللازمة

بعد تحديد الخادم المشبوه، انتقلت إلى لوحة تحكم EC2 مباشرة. من خلال مراقبة الشبكة (Networking) في CloudWatch، رأيت بوضوح أن هذا الخادم يرسل تيراً-بايتات من البيانات. يا ويلي!

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

الإجراء الفوري:

  1. أوقفت الخادم (Stopped the instance) فوراً لإيقاف النزيف.
  2. عدّلت الإعدادات الخاطئة في الأداة.
  3. أعدت تشغيل الخادم ومراقبته عن كثب. عادت حركة البيانات إلى طبيعتها.

لقد تم احتواء الأزمة، لكن الدرس كان أكبر من مجرد حل مشكلة تقنية.

الوقاية خير من العلاج: بناء درع واقٍ من الفواتير المتفجرة

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

1. تفعيل ميزانيات وتنبيهات AWS (AWS Budgets & Alerts)

هذه هي أهم خطوة على الإطلاق. AWS Budgets هي خدمة تسمح لك بتحديد ميزانية شهرية أو يومية، وتنبيهك عبر البريد الإلكتروني أو SNS عندما تتجاوز التكلفة الفعلية أو المتوقعة حداً معيناً (مثلاً 80% من الميزانية).

  • اذهب إلى AWS Budgets.
  • أنشئ ميزانية جديدة (Create budget).
  • حدد المبلغ الشهري الذي تتوقعه (مثلاً 100$).
  • أنشئ تنبيهاً (Alert) عندما تصل التكلفة الفعلية إلى 50%، وآخر عند 80%، وآخر حرج عند 100%.

هذا هو نظام الإنذار المبكر الخاص بك. لو كنت قد فعلته، لكنت تلقيت تنبيهاً في اليوم الأول من المشكلة وليس في نهاية الشهر.

2. اجعل “التوسيم” (Tagging) ثقافة إلزامية

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

  • Project: اسم المشروع.
  • Environment: (Production, Staging, Development).
  • Owner: اسم الشخص أو الفريق المسؤول.

هذا لا يساعد فقط في تحليل التكاليف، بل في الأتمتة والأمان وإدارة الموارد بشكل عام. يمكنك حتى فرض سياسات تمنع إنشاء موارد بدون وسوم معينة باستخدام AWS Organizations.

3. المراجعة الدورية للتكاليف

خصص ساعة واحدة كل أسبوع أو أسبوعين لمراجعة Cost Explorer. اعتبرها جزءاً من روتين عملك، مثل مراجعة الكود. ابحث عن أي اتجاهات غير طبيعية أو خدمات بدأت تكلفتها في الزيادة. هذه العادة البسيطة يمكن أن توفر عليك آلاف الدولارات.

4. الاستفادة من AWS Trusted Advisor

هذه أداة أخرى رائعة. يقدم لك Trusted Advisor توصيات في خمس فئات، إحداها هي تحسين التكاليف (Cost Optimization). سيخبرك عن الموارد غير المستخدمة مثل:

  • خوادم EC2 الخاملة (Idle EC2 instances).
  • أقراص EBS غير المرفقة (Unattached EBS volumes).
  • عناوين IP المرنة غير المستخدمة (Unassociated Elastic IPs).

مراجعة هذه التوصيات وتطبيقها بانتظام هي طريقة سهلة لخفض التكاليف.

5. استخدام سطر الأوامر (CLI) للمحترفين

إذا كنت تفضل سطر الأوامر، يمكنك استخدام AWS CLI للحصول على بيانات التكلفة. هذا مفيد بشكل خاص لإنشاء تقارير تلقائية. على سبيل المثال، هذا الأمر البسيط يعطيك تفصيلاً للتكاليف حسب الخدمة لشهر معين:


aws ce get-cost-and-usage 
    --time-period Start=2023-10-01,End=2023-11-01 
    --granularity MONTHLY 
    --metrics "UnblendedCost" 
    --group-by Type=DIMENSION,Key=SERVICE

خلاصة الحكي والنصيحة الأخيرة 🙏

تجربة الفاتورة المتفجرة كانت قاسية، لكنها كانت أفضل درس تعلمته في مسيرتي مع الحوسبة السحابية. السحابة أداة جبارة تمنحنا قوة هائلة، لكن مع القوة العظيمة تأتي مسؤولية عظيمة، وجزء من هذه المسؤولية هو الفهم المالي والتحكم في التكاليف.

إليك خلاصة ما تعلمته:

  • لا للذعر: عند مواجهة فاتورة ضخمة، تنفس بعمق وابدأ التحقيق المنهجي.
  • صادق Cost Explorer: تعلم كيفية استخدام فلاتره القوية (Service, Usage Type, Tags).
  • الوقاية أولاً: قم بإعداد AWS Budgets and Alerts فوراً. هذا غير قابل للتفاوض.
  • الوسوم هي مفتاحك: طبق سياسة توسيم صارمة. ستشكرني لاحقاً.
  • اجعلها عادة: راجع تكاليفك بانتظام كما تراجع بريدك الإلكتروني.

في النهاية، لا تخف من الفاتورة، بل افهمها وسيطر عليها. كن أنت “ربان” سفينتك السحابية، وليس مجرد راكب. فالسحابة، مثلها مثل أي أداة قوية، تحتاج إلى حرفي ماهر يعرف كيف يتعامل معها ويطوعها لخدمته. خليك “شغيل” وتعلّم أسرارها، وستجد أنها أفضل صديق لمشاريعك. 💪

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوظيف وبناء الهوية التقنية

سيرتي الذاتية عبرت فلتر الـ ATS لكنها فشلت أمام المدير التقني: كيف أعدت بناءها لتتحدث لغة المهندسين؟

من واقع تجربة شخصية، أسرد لك كيف تحوّل سيرتك الذاتية من مجرد قائمة مهارات يتجاهلها المديرون التقنيون إلى قصة إنجازات مُقنعة تفتح لك أبواب المقابلات....

28 فبراير، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

خدمة واحدة فاشلة كادت أن تسقط النظام بأكمله: كيف أنقذني نمط ‘قاطع الدائرة’ (Circuit Breaker) من كارثة متتالية؟

أتذكر ذلك اليوم جيداً، حين كادت خدمة واحدة أن تتسبب في انهيار نظامنا بالكامل في ليلة نهاية أسبوع مزدحمة. في هذه المقالة، أشارككم قصة حقيقية...

27 فبراير، 2026 قراءة المزيد
اختبارات الاداء والجودة

لقد ‘هاجمت’ تطبيقي بنفسي عمداً: كيف كشفت لي ‘هندسة الفوضى’ نقاط الضعف التي لم تظهرها الاختبارات التقليدية

أشارككم قصة حقيقية حول إطلاق فاشل كاد أن يدمر سمعتنا، وكيف قادتنا هذه التجربة المريرة إلى تبني "هندسة الفوضى" (Chaos Engineering). اكتشفوا معنا كيف يمكن...

26 فبراير، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

عاصفة من الطلبات كادت أن تغرق تطبيقي: كيف أنقذتني طوابير الرسائل (Message Queues) من كارثة الجمعة السوداء؟

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

24 فبراير، 2026 قراءة المزيد
​معمارية البرمجيات

تحديث النظام القديم كان كابوساً: كيف ‘خنقت’ المونوليث تدريجياً بنمط Strangler Fig دون توقف الخدمة

أتذكر ذلك اليوم جيداً، يوم أردنا تحديث نظامنا المونوليث الضخم، فتحول الأمر إلى كابوس حقيقي. في هذه المقالة، أشارككم تجربتي كـ "أبو عمر" في استخدام...

23 فبراير، 2026 قراءة المزيد
البودكاست