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 राउट टेबल गेटवेच्या स्वतःच्या टेबलांपेक्षा स्वतंत्र वस्तू आहेत। आवश्यक प्रिफिक्स जोडा आणि प्रत्येक गंतव्यस्थान नव्या डीफॉल्टने बदलण्याऐवजी विद्यमान मार्ग जपा। सबनेट मार्ग ग्राहक उपकरणाला काहीही जाहीर करत नाही।

डायनामिक किंवा स्टॅटिक राउटिंग जाणीवपूर्वक निवडा; पीअरिंग दोन्हींपैकी काहीही देत नाही।

स्थानिक प्रवेश न गमावता स्पोक वेगळे ठेवा

जेव्हा A आणि B दोघेही कार्यालयापर्यंत पोहोचू शकतात पण एकमेकांकडे राउट होऊ नयेत, तेव्हा टेबल विभागा। VPN जोडणीच्या सहयोगी टेबलमध्ये VPC प्रिफिक्स असतात। VPC जोडण्यांच्या सहयोगी टेबलमध्ये स्थानिक प्रिफिक्स असतात, A ला B शी जोडणारा मार्ग नसतो। प्रसारच तो संबंध निर्माण करतो, म्हणून प्रत्येक डीफॉल्ट सहयोग स्वीकारावा लागत नाही।

हे राउटिंग वेगळीकरण आहे, आणि हे ॲप्लिकेशन अधिकृतता नाही।

सुरक्षा गट, नेटवर्क ACL, होस्ट फायरवॉल आणि प्रत्येक सेवेच्या स्वतःच्या परवानग्या अजूनही ठरवतात कोणती रहदारी स्वीकारली जाते। तपासणी आवश्यक असल्यास, हब ते करेल असे गृहीत धरण्याऐवजी त्याचा समर्थित मार्ग स्पष्टपणे रचा।

हब जे दुरुस्त करत नाही

पत्ता योजना अजूनही आच्छादन-मुक्त राहिल्या पाहिजेत, कारण हब एका प्रिफिक्सला दोन वर्कलोड ओळखू देत नाही। प्रत्येक VPC जोडणीला तिचे वर्कलोड अपेक्षित असलेले Availability Zone व्याप्ती हवी आहे। BGP सह, ग्राहक उपकरणाचे प्रत्येक आवश्यक प्रिफिक्सकडे परतीचे मार्ग रचना आणि तिच्या इंपोर्ट धोरणाशी जुळले पाहिजेत। गहाळ जाहिरात तुटलेल्या बोगद्यासारखीच दिसते।

VPN कनेक्शन आणि ट्रान्झिट गेटवे आता सामायिक पायाभूत सुविधा आहेत।

बोगद्यांची अनावश्यकता, उपकरण क्षमता, देखरेख आणि देखभाल सर्व अवलंबून असलेल्या VPC भोवती नियोजित करा, प्रत्येकाला स्वतंत्रपणे जोडलेले मानण्याऐवजी।

विद्यमान virtual private gateway व्यवस्थेतून स्थलांतरालाही तोच स्पष्ट आराखडा हवा। जोडण्या आणि धोरणे तयार करा, एक नियंत्रित वर्कलोड मार्ग हलवा, आणि जुना मार्ग मागे घेण्यापूर्वी परवानगी असलेले व नाकारलेले संबंध पुष्टी करा। केंद्रीकरण नेटवर्क संघाला सामायिक कनेक्टिव्हिटी सांभाळण्यासाठी एक जागा देताना मदत करते, आणि एका मोठ्या टेबलामागे कोण कोणापर्यंत पोहोचू शकतो हे लपवताना हानी करते।