ಕನ್ಸೋಲ್‌ನಿಂದ 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 ಟ್ಯಾಬ್ಗೆ ನಿಖರವಾಗಿ ಹೊಂದುತ್ತದೆ, ಸಂಪರ್ಕ-ಗಂಟೆಗಳು ಜನರ ಎಣಿಕೆಯಿಂದ ಅಲ್ಲ, ಜೋಡಿಯಾದ ಲಾಗ್ ಘಟನೆಗಳಿಂದ ಬಂದಿವೆ, ಪ್ರದೇಶ ಮತ್ತು ದರದ ದಿನಾಂಕ ಬರೆಯಲಾಗಿದೆ, ಮತ್ತು ಪ್ರತಿ ಪಾರ್ಶ್ವ ವೆಚ್ಚಕ್ಕೂ ತನ್ನದೇ ಸಾಲು ಇದೆ। ನಾಲ್ಕರಲ್ಲಿ ಒಂದು ಕಾಣೆಯಾದರೆ ನಿಮ್ಮ ಬಳಿ ಸ್ವರೂಪಗೊಳಿಸಿದ ಊಹೆ ಇದೆ।
ಮೊದಲು ಲಾಗ್ ರಫ್ತು ತೆಗೆದುಕೊಳ್ಳಿ। ಅದು ನಂತರ ನೆನಪಿನಿಂದ ಮತ್ತೆ ನಿರ್ಮಿಸಲಾಗದ ಏಕೈಕ ಇನ್ಪುಟ್, ಮತ್ತು ಮೊದಲ ಬಿಲ್ ಬರುವ ಮೊದಲು ನಿಷ್ಕ್ರಿಯ-ಸೆಷನ್ ಸಮಸ್ಯೆ ಸರಿಪಡಿಸಲು ಯೋಗ್ಯವೇ ಎಂದೂ ಅದು ಹೇಳುತ್ತದೆ।