Transit Gateway लाई Resource Access Manager सँग साझा गर्नुले एउटा विशेष काम गर्छ: यसले अर्को खातालाई आफ्नो नभएको स्रोतमा परिभाषित जोडाइ API समूह कल गर्न दिन्छ। यसले गेटवे, यसका रुट तालिका वा ट्राफिक कसरी अगाडि पठाइन्छ भन्ने निर्णय गर्ने अधिकार स्थानान्तरण गर्दैन। मानिसहरू उल्टो मान्छन् किनभने जोडाइ प्राप्तकर्ताको कन्सोलमा देखिन्छ र तुरुन्तै काम गर्छ, जुन स्वामित्वजस्तो लाग्छ। यसको तलको संयन्त्र साझा स्रोतमा अनुमति दिनु हो, र प्रत्येक चाइल्ड वस्तु मालिकको खाता सीमाभित्रै रहन्छ। यो विभाजनले साझा ट्रान्जिट वरपरका अधिकांश पहुँच-अस्वीकृत टिकटहरू व्याख्या गर्छ।

साझेदारीले वास्तवमा के सुम्पन्छ

स्रोत साझेदारीले स्रोत, प्रिन्सिपल र व्यवस्थित अनुमतिको नाम दिन्छ। अनुमतिले त्यो प्रिन्सिपलले गर्न सक्ने कार्यहरू सूचीबद्ध गर्छ, र Transit Gateway का लागि त्यो सूचीले साझा स्रोतमा जोडाइ कार्यहरू समेट्छ।

सूचीबाहिरको कुरा कन्सोलमा होइन API मा असफल हुन्छ, त्यसैले स्क्रिप्ट पहिलो पटक चल्दा त्रुटि प्रायः देखिन्छ।

रुट तालिका, सम्बन्ध र प्रसारण मालिकसँगै रहन्छन्

अगाडि पठाउने कुरा तीन चाइल्ड वस्तुले निर्धारण गर्छन्: जोडाइ कुन रुट तालिकासँग सम्बन्धित छ, त्यो कुन तालिकामा प्रसारित हुन्छ, र ती तालिकामा कुन रुट छन्। AWS को साझेदारी दस्तावेजले प्राप्तकर्ताले साझेदारीमार्फत ट्रान्जिट गेटवेका रुट तालिका वा तिनका सम्बन्ध र प्रसारण सिर्जना, परिवर्तन वा मेटाउन नसक्ने बताउँछ। ती कल मालिक खाताका हुन्। नयाँ सम्बन्ध चाहिने प्राप्तकर्ता प्रशासनिक परिवर्तन मागिरहेको छ, सक्षम गर्न बिर्सेको अनुमति प्रयोग गरिरहेको छैन।

तलको तालिका मैले डिजाइन दस्तावेजमा राख्ने विभाजन हो, किनभने यो कर्मचारी परिवर्तनमा टिक्छ।

RoleWhat it controls
Transit Gateway ownerThe gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here.
VPC owner using the shareIts own attachment, subnet route tables and security policy for the workloads.
Shared-subnet participantWorkload 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 दस्तावेज गर्छ। स्रोत व्यवस्थापन गर्ने अनुमति हराउँछ, जबकि पहिले नै रहेको जोडाइ कसैले मेटाउने वा निष्क्रिय नगरेसम्म अगाडि पठाइरहन्छ। रद्द गर्ने काम दुई चरणमा योजना गर्नुहोस्: साझेदारी हटाउनुहोस्, त्यसपछि जोडाइ, र दोस्रो मालिकले गर्नेछ।

यदि साझेदारी नै तपाईंको एकमात्र नियन्त्रण हो भने, तपाईंसँग नियन्त्रण छैन।

साझेदारी अभिलेख र रुटिङ अभिलेख सँगै राख्नुहोस्

दुई कलाकृतिले दुई फरक प्रश्नको उत्तर दिन्छन्। साझेदारी अभिलेखले स्रोतसँग को काम गर्न सक्छ भन्छ। रुट तालिकाले कुन नेटवर्कले साँच्चै कुरा गर्न सक्छन् भन्छन्। तीनलाई एउटै मालिक सूचीसँग सँगै भण्डारण गर्नुहोस्, नत्र अर्को घटना कहिल्यै समस्या नभएको अनुमति प्रमाणित गर्ने व्यक्तिबाट सुरु हुनेछ।

त्यसपछि प्रत्येक दिशामा एउटा प्रवाह र पहुँचयोग्य नरहनुपर्ने एउटा प्रिफिक्स परीक्षण गर्नुहोस्।

सम्बन्धित लेखहरू