కన్సోల్ నుండి 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 డాలర్ల కనెక్షన్-గంట రేటు తీసుకుని, రెండు అనుబంధాలను నెలంతా ఉంచి 100 మంది 20 పని దినాల్లో ఆరు గంటలు కనెక్ట్ అయ్యే 30 రోజుల నెలను లెక్కించండి:
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 ట్యాబ్తో సరిగ్గా సరిపోతుంది, కనెక్షన్-గంటలు వ్యక్తుల లెక్క నుండి కాదు, జతచేసిన లాగ్ సంఘటనల నుండి వచ్చాయి, ప్రాంతం మరియు రేటు తేదీ రాయబడ్డాయి, మరియు ప్రతి పక్క ఖర్చుకు దాని స్వంత వరుస ఉంది। ఈ నాలుగింటిలో ఏదైనా లేకపోతే మీ దగ్గర ఫార్మాట్ చేసిన ఊహ ఉంది।
మొదట లాగ్ ఎగుమతిని తీసుకోండి। తర్వాత జ్ఞాపకం నుండి తిరిగి నిర్మించలేని ఏకైక ఇన్పుట్ అది, మరియు మొదటి బిల్ రాకముందు నిష్క్రియ-సెషన్ సమస్యను సరిచేయడం విలువైనదా అని కూడా అది చెబుతుంది।