Resource Access Manager सोबत Transit Gateway सामायिक करणे एक विशिष्ट काम करते: ते दुसऱ्या खात्याला ज्या संसाधनाचे ते मालक नाही अशा संसाधनाविरुद्ध ठरलेला जोडणी 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 दस्तऐवजीकरण करते। संसाधन व्यवस्थापित करण्याची परवानगी नाहीशी होते, तर आधीच अस्तित्वात असलेली जोडणी कोणी हटवेपर्यंत किंवा अक्षम करेपर्यंत पुढे पाठवत राहते। रद्द करणे दोन टप्प्यांत नियोजित करा: सामायिकरण काढा, नंतर जोडणी, आणि दुसरे मालक करेल।

सामायिकरण हेच तुमचे एकमेव नियंत्रण असेल, तर तुमच्याकडे नियंत्रण नाही।

सामायिकरण नोंद आणि रूटिंग नोंद एकत्र ठेवा

दोन कलाकृती दोन वेगळ्या प्रश्नांची उत्तरे देतात। सामायिकरण नोंद सांगते की संसाधनासोबत कोण काम करू शकते। रूट तक्ते सांगतात की कोणती नेटवर्क खरोखर बोलू शकतात। त्या एकाच मालक यादीसोबत एकत्र साठवा, नाहीतर पुढील घटना अशा कोणासोबत सुरू होईल जो कधीही समस्या नव्हती अशी परवानगी सिद्ध करत असेल।

नंतर प्रत्येक दिशेने एक प्रवाह आणि अगम्य राहिले पाहिजे असा एक प्रीफिक्स तपासा।

संबंधित लेख