साझा 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 दस्तावेज़ करता है कि गेटवे के साझाकरण से बाहर होने पर जोड़ कार्यशील रहता है। संसाधन प्रबंधित करने की अनुमति गायब हो जाती है, जबकि पहले से मौजूद जोड़ तब तक अग्रेषित करता रहता है जब तक कोई उसे हटाए या अक्षम न करे। रद्दीकरण दो चरणों में योजना बनाएँ: साझाकरण हटाएँ, फिर जोड़ हटाएँ, और दूसरा काम मालिक करे।
अगर साझाकरण ही आपका एकमात्र नियंत्रण है, तो आपके पास कोई नियंत्रण नहीं है।
साझाकरण रिकॉर्ड और रूटिंग रिकॉर्ड साथ रखें
दो कलाकृतियाँ दो अलग सवालों के जवाब देती हैं। साझाकरण रिकॉर्ड बताता है कि संसाधन के साथ कौन काम कर सकता है। रूट तालिकाएँ बताती हैं कि कौन-से नेटवर्क वास्तव में बात कर सकते हैं। उन्हें एक ही मालिक सूची के साथ साथ रखें, वरना अगली घटना किसी ऐसे व्यक्ति से शुरू होगी जो ऐसी अनुमति साबित कर रहा है जो कभी समस्या नहीं थी।
फिर हर दिशा में एक प्रवाह और एक ऐसा प्रीफ़िक्स परखें जो अगम्य रहना चाहिए।