স্পষ্ট কাঠামোটি হলো peering বনাম VPN, এবং এটি ভুল কাঠামো। পিয়ার করা VPC তার প্রতিবেশীর VPN সংযোগ ধার নিতে পারে না প্রান্ত-থেকে-প্রান্ত রাউটিংয়ের জন্য, তাই সেই বিকল্পটি কখনোই টেবিলে ছিল না, রুট টেবিল যা-ই প্রস্তাব করুক। আপনি আসলে বেছে নিচ্ছেন একটি শেয়ার করা নেটওয়ার্ক হাব, দুটি স্বাধীন VPN পথ এবং একটি সংকীর্ণ অ্যাপ্লিকেশন প্রবেশপথের মধ্যে। প্রতিটি রাউটিংয়ের মালিকানা নিয়ে ভিন্ন প্রশ্নের উত্তর দেয়।

তিনটি বিকল্প এবং যেটি বিকল্প নয়

peering-এর ধারণাটি মুছে দিয়ে শুরু করুন, তারপর যা থাকে তা ডায়াগ্রামের সরলতা নয়, মালিকানার ভিত্তিতে তুলনা করুন। নিচের টেবিলটি সংক্ষিপ্ত রূপে সিদ্ধান্ত।

OptionWho owns the pathMain cost
Shared transit gatewayHub owner, used by both VPC ownersShared blast radius, attachment and data-processing charges
Separate VPNs per accountEach account independentlyPeer capacity, duplicated tunnels, overlapping prefixes to coordinate
Application proxyThe account that hosts the intermediaryNew auth, logging and availability surface, and only one service

যদি অ্যাকাউন্ট A-এর সম্পূর্ণ লোকাল নেটওয়ার্কে পৌঁছানো প্রয়োজন হয়, তবে প্রক্সি সারিটি ভুল আকারের। যদি অ্যাকাউন্ট A-এর একটি API প্রয়োজন হয়, প্রথম দুটি সারি প্রয়োজনের চেয়ে বেশি নেটওয়ার্ক।

কখন শেয়ার করা Transit Gateway জেতে

Transit Gateway প্রতিটি VPC এবং VPN-কে আলাদা নেটওয়ার্ক হিসেবে সংযুক্ত করে, এবং অ্যাকাউন্টগুলোর মধ্যে শেয়ারিং VPC মালিকদের অ্যাকাউন্ট একীভূত না করেই হাব ব্যবহার করতে দেয়। এটাই আকর্ষণ: একটি জায়গা যেখানে লোকাল প্রিফিক্সগুলো AWS নেটওয়ার্কের সঙ্গে মেলে, এবং একটি জায়গা যেখানে ভাবা যায় কোন সংযুক্তি কোন রুট শেখে।

সবকিছু সংযুক্ত করা মানে সবকিছুর অনুমতি দেওয়া নয়। অ্যাসোসিয়েশন এবং প্রচার নির্ধারণ করে কোন সংযুক্তি কোন রুট টেবিল ব্যবহার করে, তাই দুটি VPC প্রিফিক্স প্রত্যেকে একটি লোকাল সেবায় পৌঁছাতে পারে, অথচ তাদের পারস্পরিক অ্যাক্সেস হাবের নকশায় বাদ থাকে। লোকাল দিকটির এখনও AWS প্রিফিক্সের জন্য ফেরত রুট প্রয়োজন, এবং এটি অন্য দলের পরিবর্তন-টিকিট।

খরচ আর্থিকের মতোই সাংগঠনিক। হাবের মালিক এমন রাউটিং সম্পর্ক নিয়ন্ত্রণ করেন যার উপর অন্য দলগুলো নির্ভর করে, তাই একটি সংযুক্তিতে পরিবর্তন এমন একটি সেবার ট্রাফিক সরাতে পারে যা হাবের মালিক কখনো শোনেননি। সংযুক্তির ঘণ্টা এবং ডেটা প্রসেসিং আপনি যত নেটওয়ার্ক সংযুক্ত করবেন তত যোগ হয়, তাই হাবগুলো সাধারণত তাদের পরিচালনাকারী দলের চেয়ে দ্রুত বাড়ে।

কখন আলাদা VPN বা সংকীর্ণ প্রক্সি জেতে

দুটি স্বাধীন VPN প্রকৃত পরিচালন সীমার একটি ছোট স্থাপনার জন্য উপযুক্ত: প্রতিটি অ্যাকাউন্ট নিজের টানেল পরিবর্তন করে, এবং কোনোটিই রুট টেবিল সম্পাদনা করে অন্যটিকে নষ্ট করতে পারে না। সীমাগুলো লোকাল দিকে। পিয়ার গেটওয়ের অতিরিক্ত টানেলের জন্য ধারণক্ষমতা দরকার, অ্যাড্রেস প্ল্যানগুলো ওভারল্যাপ করা যাবে না, এবং একই প্রিফিক্স ঘোষণাকারী দুটি কনফিগারেশনের আশার বদলে সচেতন পছন্দ দরকার।

প্রক্সি হলো সবচেয়ে সংকীর্ণ ইন্টারফেস। যদি অ্যাকাউন্ট A-এর অ্যাকাউন্ট B-তে একটি ডেটাবেস বা একটি API প্রয়োজন হয়, একটি সীমিত মধ্যস্থতাকারী আপনাকে নিজস্ব প্রমাণীকরণ, লগিং ও প্রাপ্যতার গল্পসহ একটি নির্দিষ্ট প্রবেশপথ দেয়। এটি সবচেয়ে বেশি অপব্যবহারের শিকার হওয়া বিকল্পও: যে মধ্যস্থতাকারী প্রতিটি ব্যক্তিগত গন্তব্যে ফরোয়ার্ড করে, সেটি অতিরিক্ত ধাপসহ একটি অবাধ রিলে হয়ে গেছে, এবং অন্য কিছুর জন্য এটি VPC থেকে লোকাল নেটওয়ার্কে স্বচ্ছ পরিবহন হিসেবে আচরণ করবে না।

এর আগে VPC peering-এর সীমাবদ্ধতাগুলো পড়া ভালো, কারণ সেগুলো ব্যাখ্যা করে কেন চতুর্থ ধারণাটি বারবার ফিরে আসে এবং কেন এটি কাজ করতে পারে না।

প্রয়োজন মেটায় এমন সবচেয়ে সংকীর্ণ ইন্টারফেস বেছে নিন

প্রশ্নগুলো সাজান: A-এর কি একটি নেটওয়ার্ক, একগুচ্ছ নেটওয়ার্ক, নাকি একটি সেবা দরকার? লোকাল দলটি একটি পথ চায় নাকি কয়েকটি? অন্য দলের ট্রাফিকের রাউটিং কে পরিবর্তন করতে পারবেন? যে প্রথম উত্তর সবচেয়ে সংকীর্ণ ইন্টারফেস তৈরি করে তা-ই স্থাপত্য, আর তারপর সবকিছু বাস্তবায়ন।

প্রিফিক্স প্ল্যান, রুটের মালিকানা, টানেল বা সংযুক্তির তালিকা এবং প্রতিটি পক্ষ যে ব্যর্থতার ধরন আশা করে তা সহ উত্তরটি লিখে রাখুন। পরে কেউ জিজ্ঞাসা করলে কেন অ্যাকাউন্ট A সহজভাবে অ্যাকাউন্ট B-এর VPN ব্যবহার করতে পারে না, সেই রেকর্ডই উত্তর, এবং পরবর্তী প্রকল্পে একই তিনটি বিকল্প নিয়ে আবার বিতর্ক করা থেকে আপনাকে বাঁচায়।

সম্পর্কিত নিবন্ধ