איך להעריך חשבון 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, שעות החיבור הגיעו מאירועי לוג מותאמים ולא מספירת אנשים, האזור ותאריך התעריפים כתובים, ולכל עלות צד יש שורה משלו. אם אחד מהארבעה חסר, יש לכם ניחוש עם עיצוב.
הוציאו קודם את ייצוא הלוג. הוא הקלט היחיד שאי אפשר לשחזר מהזיכרון אחר כך, והוא גם אומר לכם אם שווה לתקן את בעיית הפעלות הסרק לפני שהחשבון הראשון מגיע.