Elastic Beanstalk يجمع التطبيقات على EKS، والفاتورة لا تختفي
أطلقت AWS في 17 سبتمبر 2026 وضع Cluster Mode المتاح في Elastic Beanstalk، لتشغيل تطبيقات متعددة على بنية مشتركة مدعومة بـAmazon EKS بدلاً من منح كل تطبيق بيئة حوسبة مخصصة. ويوضح إعلان AWS الرسمي أن الوضع متاح في المناطق التجارية التي تتوافر فيها Elastic Beanstalk، وأن استخدامه لا يضيف رسماً مستقلاً للخدمة.
هذا الإصدار قد يخفض كلفة الحوسبة لكل تطبيق عندما تتشارك التطبيقات العنقود وسعة العقد، لكنه لا يلغي الفاتورة. يظل العميل يدفع مقابل عنقود EKS وموارد الحوسبة التي يوفرها EKS Auto Mode، فضلاً عن الخدمات التابعة التي يستهلكها كل تطبيق.
ما الذي يتغير عن Standard Mode؟
في Standard Mode، يشغّل Elastic Beanstalk التطبيق مباشرة على مثيلات EC2 داخل مجموعة Auto Scaling مخصصة للبيئة. أما Cluster Mode فيشغّل التطبيق كصورة حاوية على عنقود EKS ينشئه Elastic Beanstalk ويشغّله، سواء قدّم العميل صورة جاهزة أو Dockerfile أو شيفرة مصدرية تتولى الخدمة تحويلها إلى صورة.
تحدد مجموعة الشبكات الفرعية في VPC كيفية تجميع البيئات. وتبين وثائق بنية Beanstalk Cluster أن البيئات في الحساب نفسه تتشارك عنقوداً عندما تستخدم مجموعة الشبكات الفرعية ذاتها، بينما تؤدي مجموعة مختلفة إلى عنقود منفصل. لا يختار العميل عنقوداً موجوداً أو إصدار Kubernetes؛ فالخدمة تنشئ العنقود وتجدول التطبيقات عليه، فيما يضيف EKS Auto Mode العقد ويزيلها وفق الحاويات المجدولة.
يتغير التوسع بدوره من زيادة مثيلات EC2 داخل مجموعة Auto Scaling إلى ضبط عدد نسخ التطبيق بين min-replica وmax-replica. ويعني نموذج النسخ أن التطبيق يجب ألا يعتمد على ملفات محلية يلزم بقاؤها بعد إعادة التشغيل، لأن التخزين المحلي مؤقت ويحتاج المحتوى الدائم إلى مخزن خارجي.
كيف يمكن أن تنخفض كلفة التطبيق؟
مصدر الوفر هو تجميع التطبيقات على بنية مشتركة، وليس تخفيضاً جديداً في أسعار AWS. عندما تستخدم بيئات متعددة العنقود نفسه، يمكن توزيع رسم العنقود والاستفادة من سعة العقد عبر عدد أكبر من التطبيقات بدلاً من الاحتفاظ ببنية حوسبة مخصصة لكل بيئة.
لذلك يرتبط الوفر بحجم المحفظة ونمط الاستهلاك. قد تستفيد مجموعة خدمات صغيرة أو متوسطة لا تبلغ ذروة الطلب في الوقت نفسه، بينما قد يحقق تطبيق كبير يشغل السعة باستمرار وفراً محدوداً أو معدوماً. ولا تنشر AWS نسبة توفير عامة؛ فالحصيلة تتغير بحسب المنطقة، وعدد العناقيد، وأنواع المثيلات، وعدد النسخ، والاستخدام الفعلي، وحدود العزل المطلوبة.
المقارنة العادلة تكون على مستوى المحفظة: تكلفة مثيلات EC2 والبنية المكررة في Standard Mode مقابل رسوم عناقيد EKS والحوسبة ورسوم إدارة Auto Mode والخدمات التابعة في Cluster Mode. وكل مجموعة شبكات فرعية تُستخدم كحد مستقل تنشئ عنقوداً منفصلاً، فتقل مساحة المشاركة ويظهر رسم عنقود إضافي.
ما الذي يبقى في الفاتورة؟
عدم وجود رسم إضافي لـCluster Mode لا يعني أن موارده مجانية. البنود الأساسية هي رسم عنقود Amazon EKS، وكلفة مثيلات EC2 التي يطلقها EKS Auto Mode، ورسم إدارة Auto Mode فوق كلفة تلك المثيلات.
في اختبار مستقل نُشر في 18 سبتمبر 2026، وثّق اختبار DevelopersIO لنشر تطبيق PHP رسماً قدره 0.10 دولار في الساعة لعنقود يستخدم إصداراً ضمن الدعم القياسي. كما أورد مثال AWS لمثيل c6a.2xlarge، وفيه بلغت كلفة EC2 نحو 0.306 دولار في الساعة ورسوم إدارة Auto Mode نحو 0.03672 دولار في الساعة. هذه أرقام مرجعية مرتبطة بالمثال وتاريخ الاختبار، وليست سعراً ثابتاً لكل منطقة أو تكوين.
تضاف بنود أخرى وفق مسار النشر: تخزين صور الحاويات في ECR، واستخدام CodeBuild عند بناء صورة من الشيفرة، وإدخال السجلات والمقاييس وتخزينها في CloudWatch، وموازن الحمل والشهادات وحركة البيانات عند استخدامها. مشاركة العنقود قد تقلل تكرار البنية، لكنها لا تخفض تلقائياً استهلاك التطبيق أو حجم سجلاته أو حركة مروره.
أدوار IAM تحدد ما يمكن مشاركته
تشغيل AWS للعنقود لا يلغي مسؤولية العميل عن الهوية والصلاحيات. تحتاج بيئة Cluster Mode إلى دور للعنقود يفترضه EKS، ودور للعقد تفترضه مثيلات EC2، ودور للمراقبة يسمح بإرسال المقاييس والسجلات والتتبعات. ويلزم دور بناء إذا حوّل CodeBuild الشيفرة إلى صورة، بينما يبقى دور التطبيق اختيارياً ويُستخدم لمنح الحمل أقل الصلاحيات اللازمة لاستدعاء خدمات AWS.
يجب أن يستطيع الكيان الذي ينشئ البيئة تمرير الأدوار المطلوبة. كما يلزم أن تتطابق أدوار العنقود والعقد والمراقبة بين البيئات المنضمة إلى العنقود نفسه؛ فاختلافها لا يؤدي إلى إنشاء عنقود جديد، بل إلى رفض الإعداد. ولا يمكن تغيير الشبكات الفرعية أو هذه الأدوار الأساسية لبيئة Cluster Mode قائمة، لذلك يتطلب الانتقال إلى حد شبكة أو هوية مختلف إنشاء بيئة جديدة.
- حدد مجموعة الشبكات الفرعية التي ستعمل كحد لتجميع البيئات قبل إنشاء أول بيئة.
- وفّر أدوار العنقود والعقد والمراقبة، وأضف دور البناء أو التطبيق فقط عندما يتطلب مسار النشر ذلك.
- افصل صلاحيات التطبيقات بأدوار تطبيق محدودة بدلاً من منح الأحمال دوراً واسعاً مشتركاً.
- احسب عدد العناقيد الذي تفرضه متطلبات العزل قبل تقدير مقدار الوفر.
- أدخل ECR وCodeBuild وCloudWatch وموازن الحمل وحركة البيانات في النموذج المالي.
مخطط القرار بين الوضعين
يبقى Standard Mode أبسط عندما يحتاج التطبيق إلى منصة Beanstalk الحالية المبنية على EC2، أو يعتمد على خصائص لا تلائم الحاويات والنسخ المتطابقة، أو يستحق بنية مخصصة بالكامل. أما Cluster Mode فيلائم محفظة تطبيقات قابلة للحاويات تستطيع مشاركة العنقود والعقد، مع بقاء Elastic Beanstalk واجهة النشر والتوسع والمراقبة.
الخلاصة أن Cluster Mode إصدار متاح منذ 17 سبتمبر 2026، وأن وعد خفض كلفة التطبيق مشروط بكفاءة المشاركة وليس نتيجة تلقائية للنقل. القرار المالي يتوقف على عدد العناقيد الذي تفرضه حدود الشبكة والعزل، وعلى استهلاك العقد والخدمات التابعة؛ ولهذا تبقى الفاتورة قائمة حتى عندما تختفي بعض البنية المكررة.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.