AWS i Azure otwierają podgląd prywatnej sieci multicloud o przepustowości do 100 Gb/s

AWS i Microsoft Azure uruchomiły 31 sierpnia 2026 r. publiczną wersję zapoznawczą bezpośredniej, prywatnej łączności sieciowej na żądanie między AWS i Azure. Rozszerza to usługę AWS Interconnect – multicloud poza dotychczasowe relacje z Google Cloud i Oracle Cloud Infrastructure. AWS przedstawia ją teraz jako wspólny model łączności z trzema głównymi dostawcami chmury spoza AWS. 7

Najważniejsze zastrzeżenie dotyczy dostępności: połączenie z Azure znajduje się w Public Preview, czyli publicznej wersji zapoznawczej. Zakres funkcji, dostępność regionów i oczekiwania dotyczące gotowości produkcyjnej nie są jeszcze ostateczne.

Jak działają oba elementy usługi

Rozwiązanie łączy dwa produkty po stronie dostawców:

• AWS Interconnect – multicloud zapewnia zarządzane połączenie po stronie AWS, wychodzące z Amazon VPC — wirtualnej sieci prywatnej w AWS.
• Azure Multicloud Interconnect pełni analogiczną funkcję po stronie Azure.

Wspólnie usługi mają zestawiać zarządzaną, prywatną ścieżkę sieciową warstwy 3 między środowiskami AWS i Azure. Taka architektura abstrahuje znaczną część złożoności leżącej pod spodem, ograniczając potrzebę wdrażania fizycznych routerów czy budowania własnej trasy przez infrastrukturę lokalną. 56

AWS i Microsoft podkreślają, że korzystają ze standaryzowanej, otwartej specyfikacji API, a nie z jednorazowego interfejsu stworzonego wyłącznie na potrzeby tej współpracy. AWS zaprezentował takie podejście do łączności multicloud podczas re:Invent 2025 i opublikował otwartą specyfikację w publicznym repozytorium GitHub, aby inni dostawcy chmury mogli przyjąć ten model. 1013

Konfiguracja z poziomu konsoli AWS

Proces uruchamiania ma ograniczyć liczbę czynności wykonywanych między dostawcami. Zgodnie z dokumentacją AWS klient przechodzi do konsoli AWS Direct Connect, wybiera AWS Interconnect, tworzy połączenie multicloud, wskazuje dostawcę docelowego i regiony, a następnie określa wymaganą przepustowość. Dostawcy będący w fazie publicznego podglądu są oznaczeni w konsoli etykietą „Preview”. 12

Wersja zapoznawcza ma jednak ograniczenia operacyjne. Dokumentacja AWS wskazuje, że na jednego klienta przypada najwyżej jedno połączenie Interconnect w każdym obsługiwanym regionie. W okresie podglądu połączenia można używać bez opłat, z zastrzeżeniem warunków właściwych dla usług Preview. 12

Początkowe regiony i przepustowość

W dostępnych materiałach wymieniono cztery lokalizacje po stronie AWS, w których działa podgląd połączenia z Azure:

• US East (N. Virginia)
• US West (N. California)
• Asia Pacific (Sydney)
• Europe (Frankfurt)

Źródła nie podają w sposób wystarczająco autorytatywny pełnej listy odpowiadających im regionów Azure. Dlatego na tym etapie nie należy przedstawiać kompletnej tabeli par regionalnych jako ostatecznej. 67

Microsoft mówi o możliwości uzyskania przepustowości do 100 Gb/s po osiągnięciu ogólnej dostępności usługi. Nie oznacza to, że pełna przepustowość będzie dostępna już w początkowej wersji zapoznawczej. 5

Bezpieczeństwo i odporność infrastruktury

AWS i Microsoft pozycjonują usługę jako prywatną, odporną na awarie i prostszą w obsłudze. Microsoft wymienia szyfrowanie MACsec, dostępność na poziomie „czterech dziewiątek” — czyli 99,99% — oraz skalowalność jako najważniejsze założenia wspólnie dostarczanego rozwiązania. Materiały opisują również bazową architekturę z czterokrotną redundancją. 56

Są to deklarowane przez dostawców właściwości i zobowiązania projektowe. Ponieważ integracja z Azure nadal znajduje się w publicznej wersji zapoznawczej, a dostarczone źródła nie potwierdzają niezależnie wszystkich szczegółów jej implementacji, przed wykorzystaniem usługi w produkcji lub przy obciążeniach regulowanych warto sprawdzić aktualną dokumentację dotyczącą regionów, przepustowości, SLA i architektury.

Azure w strategii multicloud AWS

Dodanie Azure nie oznacza odejścia AWS od dotychczasowej strategii multicloud. AWS twierdzi, że AWS Interconnect – multicloud obejmuje obecnie:

1. Microsoft Azure,
2. Google Cloud,
3. Oracle Cloud Infrastructure.

Usługa została początkowo uruchomiona z Google Cloud jako pierwszym partnerem, a dokumentacja AWS osobno wymienia pary regionalne AWS–Google Cloud, między innymi Northern Virginia–Northern Virginia oraz Northern California–Los Angeles. 10

Azure otrzymuje więc podobny model konfiguracji jak kolejny duży dostawca chmury. Dla AWS jest to także sprawdzian, czy wspólny model integracji może działać między konkurującymi dostawcami usług hyperscale, a nie tylko w ramach jednej dwustronnej współpracy.

Dlaczego konkurenci zdecydowali się na współpracę

Oficjalnie wskazywanym powodem jest zapotrzebowanie klientów. Organizacje coraz częściej rozdzielają aplikacje, dane i obciążenia związane ze sztuczną inteligencją między kilka chmur. Jednocześnie łączność między nimi może wymagać osobnych dostawców, projektowania tras, przekazywania konfiguracji i utrzymywania różnych procesów operacyjnych. AWS i Microsoft przedstawiają współpracę jako sposób na ograniczenie tej niestandardowej pracy i ujednolicenie prywatnej łączności. 56

Współpraca jest istotna także dlatego, że obie firmy pozostają bezpośrednimi rywalami na rynku infrastruktury chmurowej. Otwarta specyfikacja API daje im praktyczny powód do kooperacji: każdy dostawca może zachować własną usługę sieciową, a jednocześnie uprościć proces zestawiania połączeń dla klientów i potencjalnych kolejnych uczestników. 513

Co może wydarzyć się dalej

AWS i Microsoft zapowiadają zwiększanie liczby obsługiwanych par regionalnych oraz rozbudowę przepustowości. Microsoft przedstawia pierwszą wersję usługi jako fundament dla wymagań dotyczących jeszcze większej przepustowości w przyszłości. 56

Model może wyjść poza połączenia między samymi hyperscalerami. Dostawcy wskazują możliwość udziału operatorów usług sieciowych i firm telekomunikacyjnych. Taki kierunek mógłby pomóc ujednolicić sposób uruchamiania i obsługi połączeń między chmurami, sieciami operatorów oraz infrastrukturą przedsiębiorstw. 6

Nie jest to jeszcze ogólnobranżowy standard. Szersza konsekwencja może być jednak znacząca: jeśli kolejni dostawcy wdrożą wspólne API, organizacje będą mogły bardziej spójnie uruchamiać prywatne połączenia między różnymi chmurami i sieciami. Może to mieć szczególne znaczenie dla architektur AI, w których trenowanie, wnioskowanie, dane, przetwarzanie brzegowe i aplikacje są rozproszone między różne lokalizacje. Na razie pozostaje to zapowiadanym kierunkiem rozwoju, a nie ugruntowaną funkcją dostępną w całej branży. 6