শেয়ার করা Transit Gateway: AWS RAM-এ রুটের মালিক কে
RAM শেয়ারিং অন্য অ্যাকাউন্টকে একটি VPC সংযুক্ত করতে দেয়, কিন্তু রুট টেবিল, অ্যাসোসিয়েশন ও প্রচার গেটওয়ে মালিকের কাছেই থাকে। সীমান্ত এখানেই।
Resource Access Manager-এর সাথে একটি Transit Gateway শেয়ার করা একটি নির্দিষ্ট কাজ করে: এটি অন্য অ্যাকাউন্টকে এমন একটি রিসোর্সে নির্দিষ্ট সংযুক্তি API সেট কল করার অনুমতি দেয় যা তার মালিকানাধীন নয়। এটি গেটওয়ে, তার রুট টেবিল বা ট্রাফিক কীভাবে ফরোয়ার্ড হবে তা নির্ধারণের অধিকার হস্তান্তর করে না। মানুষ অন্যথা ধরে নেয় কারণ সংযুক্তিটি প্রাপকের কনসোলে দেখা যায় এবং সঙ্গে সঙ্গে কাজ করে, যা মালিকানার মতো মনে হয়। এর নিচের প্রক্রিয়াটি একটি শেয়ার করা রিসোর্সে অনুমতি প্রদান, এবং প্রতিটি চাইল্ড অবজেক্ট মালিকের অ্যাকাউন্ট সীমার ভেতরেই থাকে। এই বিভাজনটি শেয়ার করা ট্রানজিট ঘিরে বেশিরভাগ অ্যাক্সেস-ডিনাইড টিকিট ব্যাখ্যা করে।
শেয়ারটি আসলে কী অর্পণ করে
একটি রিসোর্স শেয়ার একটি রিসোর্স, একটি প্রিন্সিপাল এবং একটি পরিচালিত অনুমতি নাম দেয়। অনুমতিটি সেই প্রিন্সিপাল যে কাজগুলো করতে পারে তা তালিকাভুক্ত করে, এবং Transit Gateway-এর জন্য সেই তালিকা শেয়ার করা রিসোর্সে সংযুক্তি অপারেশনগুলো কভার করে।
তালিকার বাইরের যেকোনো কিছু কনসোলে নয়, API-তে ব্যর্থ হয়, তাই স্ক্রিপ্ট প্রথম চালানোর সময়েই ত্রুটিটি প্রায়ই দেখা যায়।
রুট টেবিল, অ্যাসোসিয়েশন ও প্রচার মালিকের কাছেই থাকে
ফরোয়ার্ডিং তিনটি চাইল্ড অবজেক্ট দ্বারা নির্ধারিত হয়: একটি সংযুক্তি কোন রুট টেবিলের সাথে যুক্ত, এটি কোন টেবিলে প্রচারিত হয়, এবং সেই টেবিলগুলো কোন রুট ধরে রাখে। AWS-এর শেয়ারিং ডকুমেন্টেশন বলে যে প্রাপক শেয়ারের মাধ্যমে ট্রানজিট গেটওয়ে রুট টেবিল বা তাদের অ্যাসোসিয়েশন ও প্রচার তৈরি, পরিবর্তন বা মুছতে পারে না। সেই কলগুলো মালিক অ্যাকাউন্টের। যে প্রাপকের নতুন অ্যাসোসিয়েশন দরকার সে একটি প্রশাসনিক পরিবর্তন চাইছে, সে চালু করতে ভুলে যাওয়া কোনো অনুমতি প্রয়োগ করছে না।
নিচের টেবিলটি আমি ডিজাইন ডকুমেন্টে রাখা বিভাজন, কারণ এটি কর্মী পরিবর্তনেও টিকে থাকে।
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
মাঝের সারিটি মন দিয়ে পড়ুন: VPC মালিক তার সাবনেট রুট নিয়ন্ত্রণ করে, গেটওয়ে মালিক কেন্দ্রীয় ফরোয়ার্ডিং সিদ্ধান্ত নিয়ন্ত্রণ করে, এবং কাজ করা একটি পথের জন্য দুটিই দরকার। কোনো একটি অ্যাকাউন্ট একা এটি সম্পূর্ণ করতে পারে না।
একটি পথ, দুটি অ্যাকাউন্ট
একটি স্পোক VPC থেকে অন-প্রিমাইজেস প্রিফিক্স পর্যন্ত একটি প্যাকেট অনুসরণ করুন। স্পোক সাবনেট রুট টেবিলকে সেই প্রিফিক্স ট্রানজিট গেটওয়ে সংযুক্তিতে পাঠাতে হবে, যা VPC মালিক পরিবর্তন করতে পারে। তারপর গেটওয়ের সংযুক্তির সংশ্লিষ্ট টেবিলে VPN সংযুক্তির দিকে নির্দেশ করা একটি রুট থাকতে হবে, যা কেবল মালিকই পরিবর্তন করতে পারেন। ফেরত ট্রাফিকের জন্য দুটিরই প্রতিচ্ছবি দরকার। যেকোনো পাশ বাদ দিলে আপনি অর্ধেক ইনস্টল করা একটি পথ পাবেন যা ফায়ারওয়াল সমস্যার মতো দেখায়।
দুটি পরিবর্তনই দুইজন দায়িত্বপ্রাপ্তসহ একটি টিকিটে লিখুন, নইলে সেগুলো ভিন্ন সপ্তাহে শেষ হবে।
স্থান গুরুত্বপূর্ণ হলে Availability Zone ID ব্যবহার করুন
জোনের নামগুলো অ্যাকাউন্ট-স্থানীয় উপনাম। এক অ্যাকাউন্টে us-east-1a অন্য অ্যাকাউন্টের us-east-1a-এর মতো একই ভৌত জোন হবে তা নিশ্চিত নয়। যখন ডিজাইনে একটি সংযুক্তি ও একটি ওয়ার্কলোড একই জোনে দরকার, AZ ID তুলনা করুন এবং লিখে রাখুন।
নাম তুলনা করলে একটি ডায়াগ্রাম পাওয়া যায় যা সঠিক দেখায় এবং একটি লেটেন্সি প্রোফাইল যা সঠিক নয়। ডায়াগ্রাম আঁকা চলাকালীনই এটি যাচাই করুন, কেউ পার্থক্য মাপার পরে নয়।
শেয়ার বাতিল করলে ডেটা পথ কাটে না
শেয়ার সরানো প্রত্যাহারের মতো মনে হয়, এবং এটি তাৎক্ষণিক ট্রাফিক বন্ধ নয়। AWS নথিভুক্ত করে যে গেটওয়ে শেয়ারমুক্ত হলে সংযুক্তি কার্যকর থাকে। রিসোর্স পরিচালনার অনুমতি অদৃশ্য হয়, অথচ ইতিমধ্যে থাকা সংযুক্তি কেউ এটি মুছে ফেলা বা নিষ্ক্রিয় করার আগ পর্যন্ত ফরোয়ার্ড করতে থাকে। প্রত্যাহার দুই ধাপে পরিকল্পনা করুন: শেয়ার সরান, তারপর সংযুক্তি সরান, দ্বিতীয়টি মালিক সম্পাদন করবেন।
শেয়ারই যদি আপনার একমাত্র নিয়ন্ত্রণ হয়, তাহলে আপনার কোনো নিয়ন্ত্রণ নেই।
শেয়ার রেকর্ড ও রাউটিং রেকর্ড একসাথে রাখুন
দুটি নিদর্শন দুটি ভিন্ন প্রশ্নের উত্তর দেয়। শেয়ার রেকর্ড বলে কে রিসোর্সের সাথে কাজ করতে পারে। রুট টেবিল বলে কোন নেটওয়ার্ক সত্যিই কথা বলতে পারে। সেগুলো একই মালিক তালিকাসহ একসাথে সংরক্ষণ করুন, নইলে পরবর্তী ঘটনা শুরু হবে এমন কেউ একটি অনুমতি প্রমাণ করে যা কখনোই সমস্যা ছিল না।
তারপর প্রতিটি দিকে একটি ফ্লো এবং এমন একটি প্রিফিক্স পরীক্ষা করুন যা অপ্রাপ্য থাকা উচিত।