कन्सोलवरून 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 टॅबशी तंतोतंत जुळते, कनेक्शन-तास लोकांच्या मोजणीऐवजी जोडी बांधलेल्या लॉग घटनांमधून आले आहेत, प्रदेश आणि दराची तारीख लिहिलेली आहे, आणि प्रत्येक बाजूच्या खर्चाची स्वतःची ओळ आहे। या चारांपैकी एखादी राहिली तर तुमच्याकडे स्वरूपित अंदाज आहे।
आधी लॉग निर्यात घ्या। तोच एकमेव इनपुट आहे जो नंतर स्मरणातून पुन्हा तयार करता येत नाही, आणि पहिले बिल येण्यापूर्वी निष्क्रिय-सत्र समस्या दुरुस्त करण्यासारखी आहे का हेही सांगतो।