मल्टीक्लाउड नेटवर्किंग अब एक क्लाउड सेवा बन रही है: AWS, Google और Azure क्या मानकीकृत कर रहे हैं

AWS, Google Cloud और Azure क्रॉस-क्लाउड कनेक्टिविटी को एक मैनेज्ड सेवा में बदल रहे हैं। बड़ा बदलाव यह नहीं है कि सारी क्लाउड नेटवर्किंग एक जैसी बन गई है, बल्कि यह है कि प्रोवाइडर इंटरकनेक्ट परत को ही मानकीकृत करना शुरू कर रहे हैं।

कई सालों तक, एक से ज़्यादा क्लाउड इस्तेमाल करना एक अजीब नेटवर्किंग समस्या पैदा करता था।

कोई कंपनी AWS में एप्लिकेशन, Google Cloud में एनालिटिक्स, और Azure में Microsoft सेवाएँ चला सकती है। लेकिन इन माहौलों को निजी तौर पर जोड़ने का मतलब अक्सर इनके नीचे एक और परत बनाना होता था: डेडिकेटेड सर्किट, कोलोकेशन सुविधाएँ, राउटर, VPN, BGP कॉन्फ़िगरेशन, थर्ड-पार्टी नेटवर्क प्रोवाइडर, और अलग-अलग सपोर्ट व्यवस्थाएँ।

क्लाउड संसाधन माँग पर उपलब्ध थे।

क्लाउड को जोड़ने वाला नेटवर्क अक्सर नहीं था।

यह अब बदलना शुरू हो गया है।

AWS, Google Cloud, और Microsoft Azure एक ऐसे मॉडल की ओर बढ़ रहे हैं जहाँ क्लाउड-टू-क्लाउड कनेक्टिविटी को भी किसी क्लाउड सेवा की तरह ऑर्डर, कॉन्फ़िगर, और मैनेज किया जा सकता है।

और इस बदलाव के नीचे एक और ज़्यादा अहम चीज़ हो रही है: क्लाउड प्रोवाइडरों के बीच के कनेक्शन के कुछ हिस्से अब साझा स्पेसिफ़िकेशन और API इस्तेमाल करना शुरू कर रहे हैं।

इसका मतलब यह नहीं है कि मल्टीक्लाउड नेटवर्किंग एक मानकीकृत सिस्टम बन गई है।

लेकिन इसका मतलब यह ज़रूर है कि इंफ़्रास्ट्रक्चर का एक अहम हिस्सा कस्टम इंजीनियरिंग से दूर जा रहा है।

पुराना मल्टीक्लाउड नेटवर्क

एक कंपनी की कल्पना करें जिसका सेटअप यह है:

• उसका कस्टमर एप्लिकेशन AWS में चलता है।
• उसका डेटा प्लेटफ़ॉर्म Google Cloud में चलता है।
• Microsoft सेवाएँ और कुछ आंतरिक सिस्टम Azure में चलते हैं।

कंपनी इन तीनों के बीच निजी संचार चाहती है।

पारंपरिक रूप से, इसमें कई स्वतंत्र हिस्से शामिल हो सकते थे।

नेटवर्क टीम को क्लाउड इंटरकनेक्ट पोर्ट ऑर्डर करने पड़ सकते थे, किसी कैरियर या कोलोकेशन प्रोवाइडर के साथ काम करना पड़ सकता था, VLAN कॉन्फ़िगर करने पड़ सकते थे, BGP सेशन स्थापित करने पड़ सकते थे, रिडंडेंट कनेक्शन डिज़ाइन करने पड़ सकते थे, और कई प्रोवाइडरों के बीच बदलाव समन्वित करने पड़ सकते थे।

Google का दस्तावेज़ीकरण अब भी इस पारंपरिक Cross-Cloud Interconnect मॉडल का स्पष्ट वर्णन करता है। Google Cloud और किसी दूसरे प्रोवाइडर के बीच सीधे कनेक्शन के लिए, ग्राहकों को रिडंडेंट पोर्ट, रिमोट क्लाउड से मेल खाते पोर्ट, और दोनों तरफ़ BGP कॉन्फ़िगरेशन की ज़रूरत पड़ सकती है।

तकनीक काम करती है।

समस्या ऑपरेशनल बोझ की है।

क्लाउड प्रोवाइडर अब जो हटाने की कोशिश कर रहे हैं वह रूटिंग ख़ुद नहीं है। BGP, निजी नेटवर्क, और भौतिक कनेक्टिविटी अब भी नीचे मौजूद हैं।

जो बदल रहा है वह यह है कि इन हिस्सों को जोड़ने और चलाने का काम कौन करता है।

AWS और Google ने मॉडल बदल दिया

एक बड़ा क़दम AWS और Google Cloud की तरफ़ से आया।

2025 के अंत में, दोनों कंपनियों ने AWS Interconnect (मल्टीक्लाउड) और Google Cloud के Cross-Cloud Interconnect का इस्तेमाल करते हुए एक साझा रूप से इंजीनियर किया गया मल्टीक्लाउड नेटवर्किंग सिस्टम घोषित किया।

ग्राहकों से भौतिक कनेक्शन ख़ुद समन्वित करने की अपेक्षा करने के बजाय, नया मॉडल मैनेज्ड क्लाउड-टू-क्लाउड कनेक्टिविटी देता है जिसे क्लाउड इंटरफ़ेस और API के ज़रिए प्रोविज़न किया जा सकता है। AWS और Google ने कहा कि यह सिस्टम समर्थित कनेक्शनों के लिए प्रोविज़निंग को हफ़्तों या महीनों से घटाकर मिनटों तक लाने के लिए डिज़ाइन किया गया है।

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

यह एक अहम आर्किटेक्चरल बदलाव है।

ग्राहक अब कई नेटवर्किंग घटक ख़रीदकर उन्हें जोड़कर मल्टीक्लाउड कनेक्शन नहीं बना रहा।

ग्राहक एक मैनेज्ड सेवा के रूप में कनेक्शन इस्तेमाल कर रहा है।

ज़्यादा अहम हिस्सा: एक ओपन स्पेसिफ़िकेशन

AWS-Google सहयोग सिर्फ़ प्रोडक्ट इंटीग्रेशन से आगे गया।

दोनों कंपनियों ने नेटवर्क इंटरऑपरेबिलिटी के लिए एक ओपन स्पेसिफ़िकेशन विकसित किया।

AWS इस स्पेसिफ़िकेशन को मानकीकृत स्पेसिफ़िकेशन और API के एक सेट के रूप में बताता है, जिसे दूसरे क्लाउड प्रोवाइडर अपना सकते हैं। अंतर्निहित API स्पेसिफ़िकेशन सार्वजनिक रूप से प्रकाशित है और Apache 2.0 के तहत लाइसेंस प्राप्त है।

Google इस काम को भी इसी तरह बताता है: एक साझा रूप से इंजीनियर किया गया ओपन स्पेसिफ़िकेशन, जिसका मक़सद दूसरे प्रोवाइडरों को योगदान देने और इस मॉडल को अपने-अपने माहौल में लागू करने की इजाज़त देना है।

यहीं पर मानकीकरण शब्द सार्थक बनता है।

क्लाउड नेटवर्किंग की हर चीज़ को मानकीकृत नहीं कर रहे हैं।

वे यह मानकीकृत करना शुरू कर रहे हैं कि प्रोवाइडर अपने नेटवर्कों के बीच कनेक्शन के कुछ हिस्से कैसे स्थापित और स्वचालित करते हैं।

यह एक संकीर्ण दावा है, लेकिन ज़्यादा ठोस और उपयोगी भी है।

Microsoft Azure भी अब इसी दिशा में शामिल हो चुका है

अगस्त 2026 में, Microsoft और AWS ने इस मॉडल को Azure तक बढ़ाया।

Azure Multicloud Interconnect फ़िलहाल प्रीव्यू में है और इस प्रीव्यू के दौरान AWS को सपोर्ट करता है। Microsoft इसे Azure ExpressRoute पर बना मैनेज्ड प्राइवेट क्लाउड-टू-क्लाउड कनेक्टिविटी बताता है, जिसमें स्वचालित प्रोविज़निंग और मैनेज्ड रेज़िलिएंसी शामिल है।

ग्राहक एक Azure Multicloud Interconnect रिसोर्स बनाते हैं और दूसरे प्रोवाइडर के साथ एक्टिवेशन की का आदान-प्रदान करते हैं। Microsoft का कहना है कि इससे समर्थित मॉडल के लिए ग्राहक को अलग-अलग प्रोवाइडर सर्किट, राउटर, VLAN, पॉइंट-टू-पॉइंट एड्रेसिंग, और BGP सेशन समन्वित करने की ज़रूरत नहीं रहती।

AWS, अपनी ओर से, Azure को उस ओपन स्पेसिफ़िकेशन को अपनाने वाला बताता है जो AWS Interconnect (मल्टीक्लाउड) को शक्ति देती है।

तो यह अब सिर्फ़ एक AWS-Google प्रयोग नहीं रहा।

मॉडल फैल रहा है।

Google कई सालों से इसी दिशा में काम कर रहा है

Google की रणनीति नए साझा रूप से मैनेज्ड इंटरकनेक्ट मॉडल से कहीं ज़्यादा व्यापक है।

Cross-Cloud Interconnect ने Google Cloud और AWS, Azure, OCI, तथा Alibaba Cloud के बीच डेडिकेटेड कनेक्टिविटी को सपोर्ट किया है। Google, Network Connectivity Center का इस्तेमाल करके ग्राहकों को Google के नेटवर्क को बाहरी साइटों और क्लाउड के बीच एक वाइड एरिया नेटवर्क की तरह इस्तेमाल करने भी देता है।

उदाहरण के लिए, Google एक ऐसे आर्किटेक्चर का दस्तावेज़ीकरण करता है जहाँ एक Azure नेटवर्क और एक AWS नेटवर्क, दोनों Google Cloud में जुड़ते हैं और Network Connectivity Center उनके बीच ट्रैफ़िक ले जाता है।

यह एक पुरानी सीमा-रेखा को धुँधला करना शुरू करता है।

कोई क्लाउड प्रोवाइडर अब सिर्फ़ अपने ही क्लाउड के अंदर कंप्यूट, स्टोरेज, और नेटवर्किंग देने तक सीमित नहीं है।

वह दूसरे माहौलों को जोड़ने वाली ट्रांसपोर्ट परत का हिस्सा भी बन सकता है।

AWS भी वही बदलाव कर रहा है

AWS Interconnect (मल्टीक्लाउड) AWS और दूसरे क्लाउड प्रोवाइडरों के बीच एक मैनेज्ड प्राइवेट Layer 3 कनेक्टिविटी सेवा है।

Google Cloud इस मॉडल के ज़रिए आम तौर पर उपलब्ध (generally available) है। OCI भी generally available है, जबकि Azure सपोर्ट फ़िलहाल प्रीव्यू में है।

AWS, Interconnect (मल्टीक्लाउड) को Transit Gateway और Cloud WAN जैसी सेवाओं से जोड़ सकता है। Cloud WAN इन कनेक्शनों के चारों ओर एक ग्लोबल रूटिंग और पॉलिसी परत दे सकता है।

यह इसलिए मायने रखता है क्योंकि अब वैल्यू सिर्फ़ भौतिक सर्किट की नहीं रही।

बड़ा मॉडल यह बनता है: कनेक्टिविटी, रूटिंग, पॉलिसी, मॉनिटरिंग, रेज़िलिएंसी, और ऑटोमेशन, जो क्लाउड कंट्रोल प्लेन के ज़रिए दी जाती है।

यह पारंपरिक एंटरप्राइज़ नेटवर्किंग के मुक़ाबले किसी क्लाउड सेवा जैसा ज़्यादा दिखता है।

Azure भी पारंपरिक ExpressRoute मॉडल से आगे बढ़ रहा है

Azure ने कई सालों से ExpressRoute, VPN, और दूसरी नेटवर्क सेवाओं के संयोजन के ज़रिए मल्टीक्लाउड नेटवर्किंग को सपोर्ट किया है।

Azure Multicloud Interconnect, ExpressRoute की बुनियाद पर एक मैनेज्ड प्रोवाइडर-टू-प्रोवाइडर परत जोड़कर इस अनुभव को बदल देता है।

Microsoft यह फ़र्क़ सीधे तौर पर समझाता है: ExpressRoute निजी-कनेक्टिविटी की बुनियाद बना रहता है, जबकि Multicloud Interconnect मैनेज्ड क्लाउड-टू-क्लाउड कनेक्टिविटी, समर्थित प्रोवाइडरों के साथ स्वचालित प्रोविज़निंग, और अंतर्निहित रेज़िलिएंसी मैनेजमेंट जोड़ता है।

यह वही व्यापक पैटर्न है जो AWS और Google में भी दिखता है।

क्लाउड प्रोवाइडर नेटवर्किंग की जगह नहीं ले रहे हैं।

वे उसकी ज़्यादा ऑपरेशनल जटिलता ख़ुद उठा रहे हैं।

असल में मानकीकृत क्या हो रहा है?

दो बदलावों को अलग-अलग समझना उपयोगी है।

1. ऑपरेशनल मॉडल एक-दूसरे के क़रीब आ रहा है

AWS, Google, और Azure तेज़ी से इन चीज़ों की ओर बढ़ रहे हैं:

• निजी क्लाउड-टू-क्लाउड कनेक्टिविटी।
• मैनेज्ड प्रोविज़निंग।
• अंतर्निहित रिडंडेंसी।
• स्वचालित प्रोवाइडर समन्वय।
• क्लाउड API और कंसोल।
• इंटरकनेक्ट के चारों ओर केंद्रीकृत रूटिंग और पॉलिसी।
• एकीकृत मॉनिटरिंग।
• ग्राहक द्वारा मैनेज की जाने वाली भौतिक इंफ़्रास्ट्रक्चर की कम ज़रूरत।

यह कन्वर्जेंस (अभिसरण) है।

तीनों प्रोवाइडर एक जैसे ऑपरेशनल अनुभव की ओर बढ़ रहे हैं, भले ही अंदर मौजूद प्रोडक्ट अलग-अलग रहें।

2. प्रोवाइडर इंटरऑपरेबिलिटी के कुछ हिस्से मानकीकृत हो रहे हैं

AWS-Google के काम ने एक ओपन स्पेसिफ़िकेशन पेश किया।

AWS ने अंतर्निहित API स्पेसिफ़िकेशन दूसरे प्रोवाइडरों के लागू करने के लिए प्रकाशित किया।

Azure ने अब अपने AWS कनेक्टिविटी प्रीव्यू के लिए वही AWS Interconnect स्पेसिफ़िकेशन अपना लिया है।

यह असली मानकीकरण है, हालाँकि फ़िलहाल यह पूरे नेटवर्किंग स्टैक की सिर्फ़ एक सीमित परत तक है।

यह फ़र्क़ मायने रखता है।

चित्र 1 के लिए सुलभ पाठ विकल्प

पारंपरिक मॉडल: Cloud A, फिर कैरियर या कोलोकेशन सुविधा, फिर राउटर, फिर मैन्युअल रूप से कॉन्फ़िगर किया गया BGP और VLAN, फिर एक और राउटर, फिर Cloud B। उभरता हुआ मॉडल: Cloud A, फिर एक मैनेज्ड इंटरकनेक्ट रिसोर्स और API, फिर प्रोवाइडर-मैनेज्ड इंटरकनेक्ट, फिर Cloud B। एक समापन टिप्पणी बताती है कि भौतिक हिस्से अब भी दोनों मॉडल के नीचे मौजूद हैं, और प्रोवाइडर-विशिष्ट रूटिंग, सुरक्षा, क़ीमत, और कंट्रोल प्लेन अब भी बने रहते हैं।

क्या मानकीकृत नहीं है

किसी एंटरप्राइज़ को इन घोषणाओं को पढ़कर यह नहीं मान लेना चाहिए कि AWS, Azure, और Google Cloud एक ही नेटवर्क बन गए हैं।

ऐसा नहीं हुआ है।

हर प्रोवाइडर के पास अब भी अपना ख़ुद का है:

• वर्चुअल नेटवर्क मॉडल।
• रूटिंग कंट्रोल।
• सुरक्षा नीतियाँ।
• पहचान सिस्टम।
• प्राइवेट-सर्विस कनेक्टिविटी।
• ऑब्ज़र्वेबिलिटी टूल।
• क़ीमत।
• कोटा।
• क्षेत्रीय उपलब्धता।
• उभरते हुए इंटरकनेक्ट स्पेसिफ़िकेशन के बाहर की ऑपरेशनल API।

AWS Cloud WAN, Azure Virtual WAN नहीं है।

Azure Private Link, Google Private Service Connect नहीं है।

AWS में एक VPC, Azure में किसी VNet या Google Cloud में किसी VPC के बराबर ऑपरेशनली एक जैसा नहीं है।

ओपन इंटरकनेक्ट मॉडल प्रोवाइडरों के बीच की एक अहम सीमा-रेखा को आसान बनाता है।

यह उनके अंदर की सीमा-रेखाओं को नहीं हटाता।

एक व्यावहारिक एंटरप्राइज़ उदाहरण

एक ऐसी कंपनी की कल्पना करें जो अपना कस्टमर-फ़ेसिंग सिस्टम AWS में चलाती है।

उसकी एनालिटिक्स टीम Google Cloud इस्तेमाल करती है क्योंकि कई डेटा सेवाएँ पहले से वहाँ मौजूद हैं।

उसके कॉर्पोरेट एप्लिकेशन और Microsoft-आधारित वर्कलोड Azure में चलते हैं।

पुराने मॉडल में, इंफ़्रास्ट्रक्चर टीम आख़िरकार तीन अलग-अलग नेटवर्किंग प्रोजेक्ट बना सकती थी:

• AWS से Google Cloud तक।
• AWS से Azure तक।
• Azure से Google Cloud तक।

हर एक में अलग-अलग कैरियर, सर्किट, रूटिंग डिज़ाइन, और सपोर्ट प्रक्रियाएँ शामिल हो सकती थीं।

उभरता हुआ मॉडल अलग है।

समर्थित क्लाउड जोड़ों के लिए, संगठन अब तेज़ी से एक मैनेज्ड क्लाउड रिसोर्स से शुरुआत करता है: इस क्लाउड नेटवर्क को उस क्लाउड नेटवर्क से, इस जगह, इतनी बैंडविड्थ के साथ जोड़ें।

प्रोवाइडर नीचे की भौतिक कनेक्टिविटी, रिडंडेंसी, और प्रोविज़निंग का ज़्यादा हिस्सा ख़ुद संभालते हैं।

नेटवर्क आर्किटेक्ट को अब भी अहम फ़ैसले लेने होते हैं:

• कौन-से वर्कलोड एक-दूसरे से संपर्क कर सकते हैं?
• कौन-से प्रीफ़िक्स विज्ञापित किए जाने चाहिए?
• इंस्पेक्शन कहाँ होनी चाहिए?
• अगर कोई प्रोवाइडर या क्षेत्र विफल हो जाए तो क्या होगा?
• कितना डेटा क्लाउड सीमाओं को पार करेगा?
• उस ट्रैफ़िक की लागत क्या होगी?
• कौन-सा प्रोवाइडर ट्रांज़िट पॉइंट बनेगा?

काम ग़ायब नहीं होता।

लेकिन यह ऊपर की ओर खिसक जाता है।

कनेक्टिविटी बनाने में उतना समय लगाने के बजाय, टीमें यह तय करने में ज़्यादा समय लगा सकती हैं कि उस कनेक्टिविटी का इस्तेमाल कैसे किया जाए।

एक नया आर्किटेक्चरल जोखिम भी है

मैनेज्ड मल्टीक्लाउड नेटवर्किंग इंफ़्रास्ट्रक्चर को आसान बना सकती है, लेकिन यह एक और तरह की निर्भरता भी पैदा कर सकती है।

अगर कोई संगठन किसी एक प्रोवाइडर के वैश्विक नेटवर्क को कई माहौलों के बीच ट्रांज़िट परत के रूप में इस्तेमाल करता है, तो वह प्रोवाइडर रणनीतिक रूप से अहम बन जाता है, भले ही वर्कलोड कई क्लाउड में बिखरे रहें।

उदाहरण के लिए, Google यह दस्तावेज़ीकरण करता है कि Network Connectivity Center और उसका नेटवर्क AWS और Azure नेटवर्कों के बीच ट्रैफ़िक ले जाने के लिए कैसे इस्तेमाल किया जाता है।

AWS Cloud WAN भी इसी तरह AWS Interconnect अटैचमेंट के चारों ओर ग्लोबल रूटिंग और पॉलिसी परत बन सकता है।

हो सकता है यह किसी एंटरप्राइज़ को बिल्कुल वही चाहिए जो वह चाहता है।

लेकिन “मल्टीक्लाउड” का मतलब अपने-आप “प्रोवाइडर-स्वतंत्रता” नहीं होता।

नेटवर्क आर्किटेक्चर ही तय करता है कि ऑपरेशनल निर्भरता कहाँ टिकी है।

लागत भी ज़्यादा अहम बन जाती है

मल्टीक्लाउड कनेक्टिविटी को आसान बनाना एप्लिकेशनों को क्लाउड सीमाओं के पार ज़्यादा बार संपर्क करने के लिए प्रोत्साहित कर सकता है।

इससे डेटा मूवमेंट मुफ़्त नहीं हो जाता।

ग्राहकों को अब भी यह समझना ज़रूरी है:

• इंटरकनेक्ट क्षमता शुल्क।
• डेटा-ट्रांसफ़र शुल्क।
• क्षेत्रीय क़ीमत।
• प्रोवाइडर-विशिष्ट एग्रेस नियम।
• ट्रैफ़िक इंस्पेक्शन की लागत।
• अतिरिक्त क्षेत्रों या हब के ज़रिए रूटिंग की लागत।

उदाहरण के लिए, AWS, Interconnect की क़ीमत बैंडविड्थ और भौगोलिक दायरे के हिसाब से तय करता है, जबकि दूसरा क्लाउड प्रोवाइडर अपने ख़ुद के शुल्क तय करता है।

बेहतर ऑटोमेशन प्रोविज़निंग की रुकावट को हटाता है।

यह नेटवर्क अर्थशास्त्र को नहीं हटाता।

यह बदलाव क्यों मायने रखता है

क्लाउड कंप्यूटिंग ने इंफ़्रास्ट्रक्चर को आंशिक रूप से इसलिए बदला क्योंकि सर्वर, स्टोरेज, और डेटाबेस ऐसे प्रोजेक्ट नहीं रह गए जिन्हें इस्तेमाल करने से पहले भौतिक रूप से जोड़ना पड़े।

नेटवर्किंग को उसी स्तर के एब्स्ट्रैक्शन तक पहुँचने में ज़्यादा समय लगा है।

क्रॉस-क्लाउड नेटवर्किंग अब उसी राह पर चलना शुरू कर रही है।

भौतिक लिंक अब भी मौजूद हैं। BGP अब भी मौजूद है। राउटर अब भी मौजूद हैं। रिडंडेंसी अब भी मायने रखती है।

लेकिन तेज़ी से, ये सारी बारीकियाँ किसी मैनेज्ड प्रोवाइडर सेवा का हिस्सा बन रही हैं, न कि वह कुछ जिसे हर एंटरप्राइज़ को ख़ुद जोड़ना पड़े।

यही असली बदलाव है।

आज हम कहाँ खड़े हैं

हम अभी तक एक सार्वभौमिक मल्टीक्लाउड नेटवर्क तक नहीं पहुँचे हैं।

Google का स्थापित Cross-Cloud Interconnect कई प्रोवाइडरों को सपोर्ट करता है, लेकिन नया साझा रूप से मैनेज्ड मॉडल हर क्लाउड जोड़े के हिसाब से अलग-अलग परिपक्वता पर है। AWS Interconnect (मल्टीक्लाउड), Google Cloud और OCI के साथ generally available है, जबकि Azure कनेक्टिविटी सितंबर 2026 तक अब भी प्रीव्यू में है।

इसलिए इस तकनीक को “पूरी हो चुकी” नहीं कहा जाना चाहिए।

इसका एक बेहतर विवरण यह है: इंडस्ट्री क्लाउड-टू-क्लाउड कनेक्टिविटी की पहली परत को मानकीकृत कर रही है, जबकि बाक़ी मल्टीक्लाउड नेटवर्किंग धीरे-धीरे मैनेज्ड सेवाओं के इर्द-गिर्द एक-दूसरे के क़रीब आ रही है।

यह एक सार्थक बदलाव है।

कुछ साल पहले, मल्टीक्लाउड नेटवर्किंग का मतलब था ख़ुद कई क्लाउड और कैरियर प्रोडक्ट जोड़ना।

अब तेज़ी से इसका मतलब है किसी क्लाउड प्लेटफ़ॉर्म से ही यह कनेक्शन देने के लिए कहना।

और यह आख़िरकार क्लाउड के बीच के नेटवर्क को क्लाउड की तरह ही महसूस करा सकता है: प्रोग्राम-योग्य, मैनेज्ड, और माँग पर उपलब्ध।

संदर्भ और आगे पढ़ने के लिए

• AWS: AWS and Google Cloud collaborate to simplify multicloud networking
• AWS: AWS Interconnect, multicloud
• AWS: AWS Interconnect is now generally available, with a new option to simplify last-mile connectivity
• AWS: AWS and Microsoft Azure collaborate to expand multicloud networking
• AWS / GitHub: Connection Coordinator API Specification
• Google Cloud: AWS and Google Cloud collaborate to simplify multicloud networking
• Google Cloud: Expanding Google Cloud’s Cross-Cloud Network with a groundbreaking AWS collaboration
• Google Cloud: Cross-Cloud Interconnect overview
• Microsoft Learn: What is Azure Multicloud Interconnect Preview?
• AWS: AWS announces AWS Interconnect, multicloud connectivity with Microsoft Azure in preview