کنسول سے AWS Client VPN بل کا اندازہ کیسے لگائیں
AWS Client VPN کے اندازے کا سفر: اتصالات گنیں، سیشن لاگز سے کنکشن گھنٹے نکالیں، پھر endpoint فیس سے باہر کے اخراجات شامل کریں۔
پچھلے مہینے میں نے اسپریڈشیٹ میں Client VPN کا اندازہ بنایا، ایک گاہک کو بھیجا اور پھر دو بار اسے درست کیا: ایک بار کیونکہ میں نے اتصالات کو سب نیٹ سے ضرب دیا تھا، اور ایک بار کیونکہ میں نے سیشن ڈیٹا کی بجائے لوگوں کی تعداد استعمال کی تھی۔ جائزے سے بچنے والا نسخہ دو گھنٹہ وار میٹر اور مختصر ضمنی اخراجات کی فہرست پر کھڑا ہے۔ آپ اسے کنسول اور ایک لاگ ایکسپورٹ سے دوبارہ بنا سکتے ہیں، قیمت کیلکولیٹر کے بغیر۔
دو میٹر، اور endpoint پر اس کے سوا کچھ نہیں
AWS ایک Client VPN endpoint کا بل اتصال گھنٹوں اور کنکشن گھنٹوں پر کرتا ہے۔ اتصال گھنٹے endpoint سے جڑے ہر ہدف نیٹ ورک کے لیے چوبیس گھنٹے چلتے ہیں، چاہے کوئی جڑے یا نہ جڑے۔ کنکشن گھنٹے ہر جڑے ہوئے کلائنٹ کے لیے چلتے ہیں، جب تک وہ سیشن قائم رہے۔
| 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 |
اس جدول سے دو نتائج سیدھے نکلتے ہیں۔ جس endpoint پر کوئی نہ ہو وہ بھی پیسے خرچ کرتا ہے، اور ایک شخص بیک وقت لیپ ٹاپ اور فون چلائے تو دو کنکشن بنتے ہیں۔
اتصالات کنسول میں گنیں، VPC کے سب نیٹ نہیں
VPC کھولیں، پھر Client VPN endpoints، پھر اپنا endpoint، پھر Associations ٹیب۔ وہاں ہر قطار ایک سب نیٹ اتصال ہے، اور وہی قطاروں کی تعداد آپ کا اتصال ضرب ہے۔ VPC کے پیچھے موجود ایپلیکیشن سب نیٹ کی تعداد سے اس کا کوئی تعلق نہیں۔
endpoint کے راستے اور اجازت کے قواعد منزل کو ڈھانپ لیں تو مجاز VPC نیٹ ورک تک پہنچنے کے لیے ایک اتصال ہی کافی ہے۔ اضافی اتصالات اضافی رسائی نہیں، دستیابی زون کی خرابی کے خلاف مزاحمت خریدتے ہیں۔ اسی لیے دو AZ کا ڈیزائن اتصال گھنٹے دگنا کرتا ہے، جبکہ آٹھ سب نیٹ والا ایپلیکیشن 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 بڑھتے ہیں۔ یہی تناسب عام طور پر آپ کے لیے ڈیزائن کی بحث طے کر دیتا ہے: جو زائد چیز جائز نہ ہو اسے کم کریں، یا غیر فعال سیشنوں کے پیچھے جائیں، جو تعداد بڑی ہو۔ نتیجے کے ساتھ علاقہ اور نرخ کی تاریخ لکھیں، کیونکہ ان کے بغیر کوٹیشن چھ ہفتے بعد دوبارہ نہیں بن سکتا۔
وہ اخراجات شامل کریں جو ذیلی میزان چھوڑ دیتا ہے
endpoint کی فیس endpoint کے لیے ہے۔ اس کے بعد ٹریفک جس چیز کو چھوتی ہے اس کا اپنا میٹر ہے، اور انہی سطروں میں امید پرست VPN اندازے بکھر جاتے ہیں۔
- endpoint سے باہر جانے والی ٹریفک کے لیے انٹرنیٹ اخراج، GB کے حساب سے بل ہوتا ہے۔
- عوامی IPv4 پتے، جن پر VPN سے آزاد اپنی گھنٹہ وار فیس ہے۔
- ابھی ایکسپورٹ کیے گئے کنکشن لاگز کے لیے CloudWatch Logs میں وصولی اور ذخیرہ۔
- اگر آپ client-connect ہینڈلر چلاتے ہیں تو Lambda کالز۔
- اگر صارفین اسی طرح تصدیق کرتے ہیں تو Directory Service یا آپ کا SAML شناختی فراہم کنندہ، نیز اگر وہاں سرٹیفکیٹ جاری کرتے ہیں تو ACM Private CA کی فیس۔
- راستہ انہیں استعمال کرے تو NAT Gateway گھنٹے اور ڈیٹا پروسیسنگ، اور Transit Gateway اتصال گھنٹے مع ڈیٹا پروسیسنگ۔
ان میں سے کوئی بھی اتصالات کی تعداد کے ساتھ نہیں بڑھتا، اسی لیے صرف endpoint فیسوں سے بنایا گیا فی صارف عدد کاغذ پر اچھا لگتا ہے اور پھر حقیقی ٹریفک آنے پر بڑھ جاتا ہے۔ اندازہ لگانا پڑے تو بھی انہیں الگ سطروں میں رکھیں، تاکہ قاری دیکھ سکے کون سے حصے ناپے گئے اور کون سے اندازے ہیں۔
بھیجنے سے پہلے شیٹ جانچیں
چار جانچیں میری اصل غلطیاں پکڑتی ہیں: اتصالات کی تعداد Associations ٹیب سے بالکل میل کھاتی ہے، کنکشن گھنٹے لوگوں کی گنتی کی بجائے جوڑی بندھے لاگ واقعات سے آئے ہیں، علاقہ اور نرخ کی تاریخ لکھی ہوئی ہے، اور ہر ضمنی خرچ کی اپنی سطر ہے۔ ان چار میں سے کوئی رہ جائے تو آپ کے پاس فارمیٹ شدہ اندازہ ہے۔
پہلے لاگ ایکسپورٹ لیں۔ یہی واحد ان پٹ ہے جو بعد میں یادداشت سے دوبارہ نہیں بنایا جا سکتا، اور یہ بھی بتاتا ہے کہ پہلا بل آنے سے پہلے غیر فعال سیشن کا مسئلہ درست کرنے کے قابل ہے یا نہیں۔