ਪਿਛਲੇ ਮਹੀਨੇ ਮੈਂ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਿੱਚ Client VPN ਦਾ ਅੰਦਾਜ਼ਾ ਬਣਾਇਆ, ਉਹ ਇੱਕ ਗਾਹਕ ਨੂੰ ਭੇਜਿਆ ਅਤੇ ਫਿਰ ਦੋ ਵਾਰ ਸੁਧਾਰਿਆ: ਇੱਕ ਵਾਰ ਕਿਉਂਕਿ ਮੈਂ ਜੋੜਾਂ ਨੂੰ ਸਬਨੈੱਟਾਂ ਨਾਲ ਗੁਣਾ ਕੀਤਾ ਸੀ, ਅਤੇ ਇੱਕ ਵਾਰ ਕਿਉਂਕਿ ਮੈਂ ਸੈਸ਼ਨ ਡੇਟਾ ਦੀ ਥਾਂ ਲੋਕਾਂ ਦੀ ਗਿਣਤੀ ਵਰਤੀ ਸੀ। ਸਮੀਖਿਆ ਵਿੱਚ ਟਿਕਿਆ ਸੰਸਕਰਣ ਦੋ ਘੰਟੇ-ਮੀਟਰਾਂ ਅਤੇ ਛੋਟੀ ਪਾਸੇ ਵਾਲੇ ਖਰਚਿਆਂ ਦੀ ਸੂਚੀ ਉੱਤੇ ਟਿਕਿਆ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਕੰਸੋਲ ਅਤੇ ਇੱਕ ਲੌਗ ਨਿਰਯਾਤ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾ ਸਕਦੇ ਹੋ, ਕੀਮਤ ਕੈਲਕੁਲੇਟਰ ਤੋਂ ਬਿਨਾਂ।

ਦੋ ਮੀਟਰ, ਅਤੇ endpoint ਉੱਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ

AWS Client VPN endpoint ਦਾ ਬਿੱਲ ਜੋੜ-ਘੰਟਿਆਂ ਅਤੇ ਕਨੈਕਸ਼ਨ-ਘੰਟਿਆਂ ਉੱਤੇ ਲਾਉਂਦਾ ਹੈ। ਜੋੜ-ਘੰਟੇ endpoint ਨਾਲ ਜੁੜੇ ਹਰ ਟਾਰਗਟ ਨੈੱਟਵਰਕ ਲਈ ਦਿਨ-ਰਾਤ ਚੱਲਦੇ ਹਨ, ਕੋਈ ਜੁੜੇ ਜਾਂ ਨਾ ਜੁੜੇ। ਕਨੈਕਸ਼ਨ-ਘੰਟੇ ਹਰ ਜੁੜੇ ਕਲਾਇੰਟ ਲਈ, ਜਿੰਨੀ ਦੇਰ ਉਹ ਸੈਸ਼ਨ ਚਾਲੂ ਰਹੇ, ਚੱਲਦੇ ਹਨ।

MeterWhat increments itWhat does not change it
Association-hoursEach associated subnet or Transit Gateway attachment, per hour, 24/7 while attachedNumber of users, traffic volume
Connection-hoursEach active client session, per hourHow 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 ਟੈਬ ਨਾਲ ਬਿਲਕੁਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਕਨੈਕਸ਼ਨ-ਘੰਟੇ ਲੋਕਾਂ ਦੀ ਗਿਣਤੀ ਦੀ ਥਾਂ ਜੋੜੀ ਬੱਧੀ ਲੌਗ ਘਟਨਾਵਾਂ ਤੋਂ ਆਏ ਹਨ, ਖੇਤਰ ਅਤੇ ਦਰ ਦੀ ਤਾਰੀਖ਼ ਲਿਖੀ ਹੋਈ ਹੈ, ਅਤੇ ਹਰ ਪਾਸੇ ਵਾਲੇ ਖਰਚ ਦੀ ਆਪਣੀ ਕਤਾਰ ਹੈ। ਇਨ੍ਹਾਂ ਚਾਰਾਂ ਵਿੱਚੋਂ ਕੋਈ ਰਹਿ ਜਾਏ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਫਾਰਮੈਟ ਕੀਤਾ ਅੰਦਾਜ਼ਾ ਹੈ।

ਪਹਿਲਾਂ ਲੌਗ ਨਿਰਯਾਤ ਲਵੋ। ਇਹ ਇੱਕੋ-ਇੱਕ ਇਨਪੁਟ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਯਾਦ ਤੋਂ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ, ਅਤੇ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਪਹਿਲਾ ਬਿੱਲ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਸ਼ਕਿਰਿਆ-ਸੈਸ਼ਨ ਸਮੱਸਿਆ ਸੁਧਾਰਨ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਲੇਖ