कंसोल से 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 में अंतर्ग्रहण और भंडारण।
- अगर आप client-connect हैंडलर चलाते हैं तो Lambda इनवोकेशन।
- Directory Service या आपका SAML पहचान प्रदाता, अगर उपयोगकर्ता इसी तरह प्रमाणित होते हैं, साथ में ACM Private CA शुल्क अगर वहाँ प्रमाणपत्र बनाते हैं।
- NAT Gateway घंटे और डेटा प्रोसेसिंग, और Transit Gateway जोड़-घंटे साथ में डेटा प्रोसेसिंग, जब भी मार्ग इनका उपयोग करे।
इनमें से कोई भी जोड़-संख्या के साथ नहीं बढ़ता, इसलिए केवल एंडपॉइंट शुल्क से बना प्रति-उपयोगकर्ता आँकड़ा कागज़ पर अच्छा दिखता है और फिर वास्तविक ट्रैफ़िक आने पर बढ़ जाता है। अनुमान लगाना पड़े तो भी इन्हें अलग पंक्तियों में रखें, ताकि पाठक देख सके कौन-से हिस्से मापे गए हैं और कौन-से अनुमान।
भेजने से पहले शीट जाँचें
चार जाँचें मेरी वास्तविक गलतियाँ पकड़ती हैं: जोड़-संख्या Associations टैब से ठीक मेल खाती है, कनेक्शन-घंटे लोगों की गिनती के बजाय जोड़ी बनी लॉग घटनाओं से आए हैं, क्षेत्र और दर की तारीख लिखी है, और हर पार्श्व शुल्क की अपनी पंक्ति है। इन चार में से कोई छूटे तो आपके पास स्वरूपित अनुमान है।
पहले लॉग निर्यात निकालें। वही एकमात्र इनपुट है जिसे बाद में स्मृति से दोबारा नहीं बनाया जा सकता, और यह भी बताता है कि पहला बिल आने से पहले निष्क्रिय-सत्र समस्या ठीक करने लायक है या नहीं।