কনসোল থেকে 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 নেটওয়ার্কে পৌঁছাতে যথেষ্ট। বাড়তি অ্যাসোসিয়েশন বাড়তি পৌঁছানো নয়, কিনে Availability Zone-এর সহনশীলতা। তাই দুই-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 ট্যাবের সঙ্গে হুবহু মেলে, কানেকশন-ঘণ্টা মাথা গোনার বদলে জোড়া-বাঁধা লগ ইভেন্ট থেকে এসেছে, রিজিয়ন ও হারের তারিখ লেখা আছে, আর প্রতিটি পার্শ্ব-খরচের নিজের সারি আছে। এই চারটির কোনোটির অভাব থাকলে আপনার হাতে আছে ফরম্যাট করা একটি আন্দাজ।
প্রথমে লগ এক্সপোর্টটি নামান। এটিই একমাত্র ইনপুট যা পরে স্মৃতি থেকে ফেরানো যায় না, আর এটিই বলে দেয় অলস-সেশনের সমস্যাটি প্রথম বিল আসার আগে ঠিক করার মতোই কি না।