فاتورتي السحابية انفجرت: رحلتي في مطاردة التكاليف الخفية على 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 فوراً. هذا غير قابل للتفاوض.
  • الوسوم هي مفتاحك: طبق سياسة توسيم صارمة. ستشكرني لاحقاً.
  • اجعلها عادة: راجع تكاليفك بانتظام كما تراجع بريدك الإلكتروني.

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

أبو عمر

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

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

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

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

آخر المدونات

الحوسبة السحابية

فاتورتنا السحابية كانت وحشًا يلتهم الميزانية: كيف أنقذتنا ‘الـ FinOps’ من جحيم التكاليف غير المتوقعة؟

أشارككم قصة حقيقية من تجربتي كمطور، حين تحولت فاتورة الحوسبة السحابية إلى كابوس مالي. اكتشفوا كيف تبنينا ثقافة الـ FinOps خطوة بخطوة، وحولنا الفوضى إلى...

16 أبريل، 2026 قراءة المزيد
التوظيف وبناء الهوية التقنية

مقابلاتي التقنية كانت كارثة صامتة: كيف أنقذني ‘التفكير بصوت عالٍ’ من جحيم الصمت المحرج؟

أشارككم قصة حقيقية عن فشلي الذريع في المقابلات التقنية بسبب الصمت القاتل. اكتشفوا كيف أنقذتني تقنية "التفكير بصوت عالٍ" وحولتها من نقطة ضعف إلى أقوى...

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

موقعنا كان سريعًا في بلد وبطيئًا في كل العالم: كيف أنقذتنا شبكة توصيل المحتوى (CDN) من جحيم زمن الاستجابة العالي؟

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

16 أبريل، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

معاملاتنا الاحتيالية كانت تُكتشف بعد فوات الأوان: كيف أنقذتنا ‘نماذج التعلم الآلي في الوقت الفعلي’ من جحيم الخسائر المالية؟

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

16 أبريل، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

سيرفراتنا كانت جزرًا منعزلة: كيف أنقذنا Kubernetes من جحيم الإدارة اليدوية للحاويات؟

أشارككم قصة حقيقية من قلب المعركة التقنية، كيف انتقلنا من فوضى إدارة عشرات الحاويات (Containers) يدويًا على سيرفرات متفرقة، إلى عالم الأتمتة والتناغم بفضل Kubernetes....

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

اختباراتنا كانت تجتاز والموقع ينهار: كيف أنقذنا ‘اختبار الحمل بالسيناريوهات الواقعية’ (k6) من جحيم الأداء الوهمي؟

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

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