كيف تقدّر فاتورة AWS Client VPN من وحدة التحكم
مراجعة عملية لتقدير AWS Client VPN: احسب الارتباطات، واستخرج ساعات الاتصال من سجلات الجلسات، ثم أضف التكاليف الواقعة خارج رسوم نقطة النهاية.
بنيتُ تقديرًا لـ Client VPN في جدول بيانات الشهر الماضي، وأرسلته إلى أحد العملاء، ثم راجعته مرتين: مرة لأنني ضربت الارتباطات في الشبكات الفرعية، ومرة لأنني استخدمت عدد الأشخاص بدلًا من بيانات الجلسات. النسخة التي صمدت أمام المراجعة تقوم على عدّادين بالساعة وقائمة قصيرة من التكاليف الجانبية. يمكنك إعادة بنائه من وحدة التحكم ومن تصدير سجل واحد، دون حاسبة تسعير.
عدّادان، ولا شيء آخر على نقطة النهاية
تحتسب AWS نقطة نهاية Client VPN على أساس ساعات الارتباط وساعات الاتصال. تعمل ساعات الارتباط لكل شبكة هدف مرتبطة بنقطة النهاية، على مدار الساعة، سواء اتصل أحد أم لم يتصل. أما ساعات الاتصال فتعمل لكل عميل متصل، ما دامت تلك الجلسة قائمة.
| Meter | What increments it | What does not change it |
|---|---|---|
| Association-hours | Each associated subnet or Transit Gateway attachment, per hour, 24/7 while attached | Number of users, traffic volume |
| Connection-hours | Each active client session, per hour | How many subnets that client can reach |
ينتج عن ذلك الجدول نتيجتان مباشرتان. نقطة النهاية التي لا يستخدمها أحد تكلّف مالًا رغم ذلك، وشخص واحد يشغّل حاسوبًا محمولًا وهاتفًا في الوقت نفسه ينتج اتصالين.
عُدّ الارتباطات في وحدة التحكم، لا الشبكات الفرعية في الـ VPC
افتح VPC، ثم Client VPN endpoints، ثم نقطة النهاية الخاصة بك، ثم تبويب Associations. كل صف هناك يمثل ارتباطًا بشبكة فرعية، وعدد الصفوف هو مضاعف الارتباط لديك. أما عدد شبكات التطبيقات الفرعية خلف الـ VPC فلا علاقة له بالأمر.
يكفي ارتباط واحد للوصول إلى شبكة VPC مُصرّح بها متى غطّت مسارات نقطة النهاية وقواعد التفويض الوجهة. والارتباطات الإضافية تشتري مرونة مناطق التوفر، لا وصولًا إضافيًا. لذلك يضاعف تصميم بمنطقتين ساعات الارتباط، بينما لا يضاعف VPC تطبيقي بثماني شبكات فرعية شيئًا بثمانية.
انتبه إلى نوع الارتباط وأنت في تلك الصفحة. ارتباط شبكة فرعية في VPC وارتباط مباشر بـ Transit Gateway ترتيبان مختلفان ببنود تكلفة مختلفة، فلا تنقل نموذجًا إلى عرض سعر الآخر. ولا تختبر العدد بفصل الأشياء: فإزالة شبكة الهدف الأخيرة تنهي الجلسات النشطة وتمنع الاتصالات الجديدة حتى يُعاد ارتباط شيء ما.
استخرج ساعات الاتصال من بيانات الجلسات
عدد الأشخاص مدخل خاطئ، وهو خاطئ في الاتجاهين. فالعشرة أشخاص الذين يبقى كل منهم على ثلاثة أجهزة متصلة يمثلون ثلاثين اتصالًا. ومئة شخص يتصل كل منهم عشرين دقيقة يوميًا لا ينتجون مئة جلسة متزامنة على الإطلاق.
تسجّل سجلات اتصال Client VPN أحداث الاتصال وفصل الاتصال لكل عميل، وهي بالضبط الأزواج التي تحتاجها. صدّر أسبوعًا تمثيليًا، وطابق الأحداث، واجمع المدد:
connection-hours = sum of (disconnect_time - connect_time) per session
sessions = one per client connection, not per personثم صحّح لعادتين. فالجلسات التي تبقى متصلة خلال الغداء أو الليل أو تعليق حاسوب لم يقطع النفق تُحتسب أيضًا، وهي غير مرئية في عدّ الأشخاص. والقياس بالساعة أيضًا، فاحسب جلسة من عشرين دقيقة ساعة كاملة بدل افتراض فوترة تناسبية؛ وإذا جاءت الفاتورة أقل، فاعتبر ذلك هامشًا لا مدخلًا للتخطيط.
نفّذ الحساب بأسعار منطقتك
تختلف الأسعار باختلاف المنطقة، فاسحبها من صفحة أسعار AWS VPN للمنطقة التي تنشر فيها وألصقها في الجدول كمدخلات. وعلى سبيل المثال فقط، خذ سعر ارتباط قدره 0.10 دولار للساعة وسعر ساعة اتصال قدره 0.05 دولار، ثم احسب شهرًا من 30 يومًا مع ارتباطين طوال الشهر و100 شخص يتصلون ست ساعات في 20 يوم عمل:
association-hours = 2 * 24 * 30 = 1,440
association fee = 1,440 * 0.10 = 144.00
connection-hours = 100 * 6 * 20 = 12,000
connection fee = 12,000 * 0.05 = 600.00
Client VPN subtotal = 744.00حرّك الآن مدخلًا واحدًا في كل مرة ولاحظ أي سطر يتفاعل. فمضاعفة الارتباطات تضيف 144 دولارًا هنا، ومضاعفة متوسط مدة الجلسة تضيف 600 دولار. وتلك النسبة تحسم عادةً جدال التصميم لصالحك: قلّل التكرار الذي لا يمكن تبريره، أو استهدف الجلسات الخاملة، بحسب الرقم الأكبر. واكتب المنطقة وتاريخ الأسعار بجانب النتيجة، لأن عرض سعر بدونها لا يمكن إعادة إنتاجه بعد ستة أسابيع.
أضف التكاليف التي يستبعدها المجموع الفرعي
رسوم نقطة النهاية تدفع مقابل نقطة النهاية. وكل ما تلمسه الحركة بعد ذلك له عدّاده الخاص، وهذه البنود هي التي تنهار عندها تقديرات VPN المتفائلة.
- حركة الخروج عبر الإنترنت للمرور الذي يغادر عبر نقطة النهاية، وتُحتسب لكل GB.
- عناوين IPv4 العامة، التي تحمل رسومًا بالساعة مستقلة عن الـ VPN.
- استقبال وتخزين CloudWatch Logs لسجلات الاتصال التي صدّرتها للتو.
- استدعاءات Lambda إذا كنت تشغّل معالج client-connect.
- Directory Service أو مزوّد هوية SAML لديك، إن كانت هذه طريقة مصادقة المستخدمين، إضافة إلى رسوم ACM Private CA إن كنت تصدر الشهادات هناك.
- ساعات NAT Gateway ومعالجة البيانات، وساعات ارتباط Transit Gateway مع معالجة البيانات، حيثما استخدم المسار هذه الخدمات.
لا شيء من هذه يتدرّج مع عدد الارتباطات، ولهذا يبدو رقم لكل مستخدم مبني على رسوم نقطة النهاية فقط جيدًا على الورق ثم ينمو عند ظهور حركة حقيقية. ضعها في صفوف منفصلة حتى حين تضطر إلى تقديرها، ليرى القارئ أي الأجزاء مقيس وأيها تخمين.
راجع الجدول قبل أن ترسله
أربعة فحوص تلتقط الأخطاء التي وقعت فيها فعلًا: عدد الارتباطات يطابق تبويب Associations تمامًا، وساعات الاتصال جاءت من أحداث سجل مقترنة لا من عدّ أشخاص، والمنطقة وتاريخ الأسعار مكتوبان، ولكل تكلفة جانبية صف خاص بها. وإن غاب أي من الأربعة، فلديك تخمين بتنسيق.
صدّر السجل أولًا. فهو المدخل الوحيد الذي لا يمكنك إعادة بنائه من الذاكرة لاحقًا، ويخبرك أيضًا هل مشكلة الجلسات الخاملة تستحق الإصلاح قبل وصول أول فاتورة.