الخلاصة

  • وفق وثائق AWS، تُحسب الفاتورة الشهرية النهائية بتفضيلات مشاركة الخصومات المضبوطة عند 23:59:59 بالتوقيت العالمي في آخر يوم من الشهر. التقديرات خلال الشهر تستخدم أحدث إعدادات.
  • أولوية حساب المشتري وحدود المجموعة تغيّران وجهة الخصم. تحقيق أقل كلفة للمؤسسة والحفاظ على مسؤولية كل وحدة عن نفقاتها هدفان يحتاجان قرار توزيع واضحاً.

للهيكل الإداري موعد دقيق مع الفاتورة: الساعة 23:59:59 بالتوقيت العالمي، في آخر يوم من الشهر.

يحدد دليل تفضيلات الفوترة لدى AWS تلك اللحظة مرجعاً لإعدادات مشاركة الخصومات المستخدمة في الحساب النهائي. أما الفواتير التقديرية فتستخدم آخر إعدادات مضبوطة. وبين تقدير راقبته إدارة لأسابيع وحساب الشهر النهائي توجد خريطة يستطيع أحد المسؤولين تعديل حدودها.

الذي يتحرك هنا منفعة سعرية من Savings Plans. قد يستمر التطبيق على الموارد نفسها ويتبدل ترتيب استفادة حسابه من الخصم. نقل الخوادم غير ضروري؛ تغيير الحدود المالية يكفي كي يصبح السؤال: من يحصل على السعر الأقل أولاً؟

ثلاث خرائط للخصم نفسه

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

تُعرّف المجموعات عبر Cost Categories. ينتمي الحساب إلى مجموعة واحدة فقط، ولا تتداخل المجموعات، ولا يمكن لحساب الإدارة أن يكون عضواً في مجموعة. ويجب أن يكون حساب مالك Savings Plans مفعّلاً في تفضيلات المشاركة.

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

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

حساب بلا تطبيقات قد يشتري بصورة أفضل

تبدأ AWS بتطبيق منفعة Savings Plans على الاستخدام المؤهل في حساب المالك، ثم تشاركها مع الحسابات الأخرى. وداخل مرحلة التوزيع المعنية، تعطي الأولوية للاستخدام ذي نسبة التوفير الأعلى. أولوية المالك تسبق المنافسة المفتوحة بين كل استخدامات المؤسسة.

يعرض شرح رسمي نشرته AWS في 25 أكتوبر مثال حساب يستخدم Lambda ويشتري Compute Savings Plan بنفسه. يستفيد استخدامه أولاً، فتضيع أحياناً فرصة نسبة توفير أعلى على استخدام m8g Linux EC2 في حساب آخر. لا يضع المثال مبلغ خسارة مقاساً على ذلك؛ إنه يشرح كيف تدخل هوية المشتري في ترتيب التوزيع.

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

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

لماذا يرى المركز 100 ويرى مجموع الفروع 70؟

تستخدم مقالة AWS سيناريو تفسيرياً لخطة Compute Savings Plan مدتها سنة ومن دون دفعة مقدمة. التوصية على مستوى الإدارة 100 دولار في الساعة، ومجموع توصيات الحسابات الأعضاء 70 دولاراً. الأرقام مثال لشرح اختلاف المنظور.

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

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

لتسعير الأثر في مؤسسة بعينها نحتاج حسابات الملكية وإعدادات المشاركة والاستخدام المؤهل بالساعة ومخزون الالتزامات الحالي.

ما يُحسم في آخر ثانية من الشهر خريطة اقتصادية، لا ترتيباً تجميلياً للحسابات. من يملك تعديلها يشارك في تقرير من يستفيد من خصم ربما بنى عليه غيره ميزانية. الشركات تضع مسؤولاً واضحاً لإعادة تنظيم وحداتها. وخريطة الخصومات تستحق المسؤولية نفسها.

المصادر