چگونه صورتحساب 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 مجاز برسید. ارتباط‌های اضافی تاب‌آوری در برابر از کار افتادن ناحیه دسترس‌پذیری می‌خرند، نه دسترسی بیشتر. پس طراحی دو 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 دلار اضافه می‌کند. آن نسبت معمولاً بحث طراحی را به‌جای شما حل می‌کند: اضافه‌هایی را که نمی‌توانید توجیه کنید بزنید یا سراغ نشست‌های بیکار بروید، هر کدام که عدد بزرگ‌تر است. منطقه و تاریخ نرخ‌ها را کنار نتیجه بنویسید، چون پیشنهادی بدون آن‌ها شش هفته بعد قابل بازتولید نیست.
هزینه‌هایی را که جمع جزء جا می‌گذارد اضافه کنید
هزینه نقطه پایانی برای خود نقطه پایانی است. هر چیزی که ترافیک بعد از آن لمس می‌کند شمارنده خودش را دارد و همان ردیف‌ها جایی است که برآوردهای خوش‌بینانه VPN فرو می‌ریزد.
- خروج اینترنت برای ترافیکی که از نقطه پایانی بیرون می‌رود، به ازای هر GB.
- نشانی‌های عمومی IPv4 که هزینه ساعتی خودشان را مستقل از VPN دارند.
- دریافت و ذخیره در CloudWatch Logs برای گزارش‌های اتصالی که همین حالا خروجی گرفتید.
- فراخوانی‌های Lambda اگر یک گرداننده client-connect اجرا می‌کنید.
- Directory Service یا ارائه‌دهنده هویت SAML شما، اگر احراز هویت کاربران این‌طور است، به‌علاوه هزینه‌های ACM Private CA اگر آنجا گواهی صادر می‌کنید.
- ساعت‌های NAT Gateway و پردازش داده، و ساعت‌های اتصال Transit Gateway به‌علاوه پردازش داده، هر زمان مسیر از آن‌ها استفاده کند.
هیچ‌کدام از این‌ها با تعداد ارتباط مقیاس نمی‌گیرد، به همین دلیل رقمی به‌ازای هر کاربر که فقط از هزینه‌های نقطه پایانی ساخته شده روی کاغذ خوب به نظر می‌رسد و بعد با آمدن ترافیک واقعی بزرگ می‌شود. حتی وقتی مجبورید برآوردشان کنید آن‌ها را در ردیف‌های جدا بگذارید تا خواننده ببیند کدام بخش اندازه‌گیری شده و کدام حدس است.
صفحه را پیش از فرستادن بررسی کنید
چهار بررسی خطاهایی را که واقعاً مرتکب شدم می‌گیرد: تعداد ارتباط دقیقاً با زبانه Associations می‌خواند، ساعت‌های اتصال از رویدادهای جفت‌شده گزارش آمده نه از شمارش افراد، منطقه و تاریخ نرخ‌ها نوشته شده‌اند، و هر هزینه جانبی ردیف خودش را دارد. اگر یکی از این چهار نباشد، شما یک حدس قالب‌بندی‌شده دارید.
اول خروجی گزارش را بگیرید. آن تنها ورودی‌ای است که بعداً نمی‌توانید از حافظه بازسازی کنید و همچنین می‌گوید آیا مشکل نشست‌های بیکار ارزش اصلاح پیش از رسیدن اولین صورتحساب را دارد یا نه.