दोन AWS खाती, एक स्थानिक नेटवर्क: कोणता मार्ग?
सामायिक Transit Gateway, दोन स्वतंत्र VPN किंवा एक अरुंद प्रॉक्सी: आज कोणता मार्ग जोडणे सर्वात सोपे आहे यावरून नाही, तर मालकी आणि प्रभावाच्या व्याप्तीवरून निवडा।
स्पष्ट चौकट peering विरुद्ध VPN आहे, आणि ही चुकीची चौकट आहे। पीअर केलेले VPC त्याच्या शेजाऱ्याचे VPN कनेक्शन कडापासून कडापर्यंत राउटिंगसाठी उसणे घेऊ शकत नाही, त्यामुळे रूट तक्ता काहीही सुचवो, तो पर्याय कधीच टेबलावर नव्हता। तुम्ही प्रत्यक्षात सामायिक नेटवर्क हब, दोन स्वतंत्र VPN मार्ग आणि एक अरुंद अनुप्रयोग प्रवेशद्वार यांमध्ये निवडता। प्रत्येकजण राउटिंगची मालकी कोणाकडे आहे या वेगळ्या प्रश्नाचे उत्तर देतो।
तीन पर्याय आणि जो पर्याय नाही
peering ची कल्पना पुसून सुरुवात करा, नंतर जे उरते त्याची तुलना आकृतीच्या साधेपणावरून नाही, तर मालकीवरून करा। खालील तक्ता हा संक्षिप्त स्वरूपातील निर्णय आहे।
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New 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 का वापरू शकत नाही, तर ती नोंदच उत्तर आहे, आणि पुढील प्रकल्पात त्याच तीन पर्यायांवर पुन्हा वाद घालण्यापासून ती तुम्हाला वाचवते।