स्पष्ट ढाँचा peering बनाम VPN है, और यह गलत ढाँचा है। पीयर किया गया VPC अपने पड़ोसी के VPN कनेक्शन को किनारे से किनारे तक रूटिंग के लिए उधार नहीं ले सकता, इसलिए वह विकल्प कभी मेज़ पर नहीं था, चाहे रूट तालिका कुछ भी सुझाए। आप वास्तव में साझा नेटवर्क हब, दो स्वतंत्र VPN पथों और एक संकीर्ण एप्लिकेशन प्रवेश द्वार में से चुनते हैं। हर एक रूटिंग का स्वामी कौन है, इस पर एक अलग प्रश्न का उत्तर देता है।

तीन विकल्प और वह जो विकल्प नहीं है

peering के विचार को मिटाकर शुरू करें, फिर जो बचता है उसकी तुलना आरेख की सरलता के बजाय स्वामित्व पर करें। नीचे दी गई तालिका संक्षिप्त रूप में निर्णय है।

OptionWho owns the pathMain cost
Shared transit gatewayHub owner, used by both VPC ownersShared blast radius, attachment and data-processing charges
Separate VPNs per accountEach account independentlyPeer capacity, duplicated tunnels, overlapping prefixes to coordinate
Application proxyThe account that hosts the intermediaryNew 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 क्यों नहीं उपयोग कर सकता, तो वह अभिलेख ही उत्तर है, और यह अगली परियोजना में उन्हीं तीन विकल्पों पर फिर से बहस करने से बचाता है।

संबंधित लेख