दुई 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 किन प्रयोग गर्न सक्दैन भनी सोध्दा, त्यो अभिलेख नै जवाफ हो, र अर्को परियोजनामा तीही तीन विकल्पमा फेरि बहस गर्नबाट यसले तपाईंलाई बचाउँछ।