AWS Transit Gateway पर कई VPC के लिए एक साइट-से-साइट VPN

इस तिमाही में दो VPC को ऑफ़िस नेटवर्क चाहिए, और दूसरी टनल पर ही अनुमान टूटता है। AWS Transit Gateway एक साझा रूटिंग हब की तरह काम कर सकता है: VPN एक बार जुड़ता है, और हर VPC उसी हब से जुड़ता है। फिर ऑन-प्रिमाइसेस नेटवर्क एक ही कनेक्शन से हर जुड़े VPC तक पहुँचता है। इससे यह बदलता है कि रूटिंग का फ़ैसला किसके पास है, और ज़्यादातर डिज़ाइन ठीक इसी हिस्से में गलती करते हैं।

VPN अटैचमेंट और VPC अटैचमेंट एक ही गेटवे पर अलग ऑब्जेक्ट हैं, इसलिए रूटिंग संबंध बाद में बनाने पड़ते हैं।

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

पीयरिंग वह शॉर्टकट क्यों नहीं है जिसकी लोग उम्मीद करते हैं

लुभावना विकल्प यह है कि VPN को VPC A पर ख़त्म करें और VPC B को उससे पीयर करें। साधारण VPC पीयरिंग A के VPN कनेक्शन से किनारे-से-किनारे ट्रांज़िट नहीं देती। पीयर सिर्फ़ उन पतों तक पहुँचता है जो पीयरिंग ख़ुद देती है, और VPN किनारा उनमें से एक नहीं है। ट्रांज़िट हब देता है; पीयरिंग आपको एक जोड़ी देती है।

यह सीमा पीयरिंग की विशेषता है, कोई कोटा नहीं जिसे आप बढ़ा सकें।

एसोसिएशन और प्रोपेगेशन अलग-अलग काम करते हैं

ट्रांज़िट गेटवे के अंदर एसोसिएशन वह रूट टेबल चुनता है जिससे अटैचमेंट से आने वाले ट्रैफ़िक को देखा जाता है। प्रोपेगेशन तय करता है कि किन टेबलों को अटैचमेंट के सीखे गए या जुड़े प्रीफ़िक्स मिलें। एक अटैचमेंट एक टेबल से जुड़ सकता है और साथ ही कई में प्रोपेगेट हो सकता है। दोनों को मिला देना ही वह तरीका है जिससे डिज़ाइन ऐसी पहुँच पर पहुँचता है जिसकी किसी ने योजना नहीं बनाई थी।

पूरी तरह जुड़ा छोटा हब आसान मामला है।

हर अटैचमेंट को एक टेबल में रखें और VPN सहित दोनों VPC प्रीफ़िक्स साफ़ हल हो जाते हैं। यह VPC-से-VPC पहुँच की भी अनुमति देता है जो संस्था ने शायद कभी नहीं चाही, क्योंकि साझा टेबल में स्पोक की कोई अवधारणा नहीं है।

वर्कलोड रूट कहीं और रहते हैं

हर वर्कलोड सबनेट को इच्छित स्थानीय प्रीफ़िक्स के लिए ट्रांज़िट गेटवे की ओर अपना रूट अब भी चाहिए। वे VPC रूट टेबल ट्रांज़िट गेटवे की अपनी टेबलों से अलग ऑब्जेक्ट हैं। ज़रूरी प्रीफ़िक्स जोड़ें और हर गंतव्य को नए डिफ़ॉल्ट से बदलने के बजाय मौजूदा रूट बनाए रखें। सबनेट रूट ग्राहक डिवाइस को कुछ भी विज्ञापित नहीं करता।

डायनामिक या स्टैटिक रूटिंग सोच-समझकर चुनें; पीयरिंग दोनों में से कुछ नहीं देती।

स्थानीय पहुँच खोए बिना स्पोक अलग रखें

जब A और B दोनों ऑफ़िस तक पहुँच सकते हैं पर एक-दूसरे की ओर रूट नहीं कर सकते, तो टेबल बाँटें। VPN अटैचमेंट की जुड़ी टेबल VPC प्रीफ़िक्स रखती है। VPC अटैचमेंटों की जुड़ी टेबल स्थानीय प्रीफ़िक्स रखती है, बिना किसी ऐसे रूट के जो A को B से जोड़े। प्रोपेगेशन ही वह संबंध बनाता है, इसलिए आपको कभी हर डिफ़ॉल्ट एसोसिएशन स्वीकार नहीं करनी पड़ती।

यह रूटिंग अलगाव है, और यह ऐप्लिकेशन प्राधिकरण नहीं है।

सिक्योरिटी ग्रुप, नेटवर्क ACL, होस्ट फ़ायरवॉल और हर सेवा की अपनी अनुमतियाँ अब भी तय करती हैं कि कौन-सा ट्रैफ़िक स्वीकार होगा। अगर निरीक्षण ज़रूरी है, तो हब इसे करेगा मानने के बजाय उसका समर्थित रास्ता स्पष्ट रूप से डिज़ाइन करें।

हब जो ठीक नहीं करता

पता योजनाएँ अब भी बिना अतिव्यापन के रहनी चाहिए, क्योंकि हब एक प्रीफ़िक्स को दो वर्कलोड पहचानने नहीं देता। हर VPC अटैचमेंट को वह Availability Zone कवरेज चाहिए जिसकी उसके वर्कलोड अपेक्षा करते हैं। BGP के साथ, ग्राहक डिवाइस के हर ज़रूरी प्रीफ़िक्स की ओर वापसी रूट डिज़ाइन और उसकी इम्पोर्ट नीति से मेल खाने चाहिए। गुम विज्ञापन ठीक टूटी टनल जैसा दिखता है।

VPN कनेक्शन और ट्रांज़िट गेटवे अब साझा अधोसंरचना हैं।

टनल रिडंडेंसी, डिवाइस क्षमता, मॉनिटरिंग और रखरखाव की योजना सभी निर्भर VPC के इर्द-गिर्द बनाएँ, हर एक को स्वतंत्र रूप से जुड़ा मानने के बजाय।

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