Łączenie dwóch dostawców chmury to nie ćwiczenie teoretyczne. To wymaganie, które pojawia się w każdej strategii multi-cloud, każdej stopniowej migracji i każdej architekturze, gdzie zespoły wybrały najlepsze usługi od różnych dostawców. Połączenie sieciowe między VPC AWS i VPC GCP musi obsługiwać ruch produkcyjny, spełniać wymagania latency a nie stać się niespodzianką kosztową.
Wdrażaliśmy wszystkie trzy podejścia opisane w tym artykule. Każde rozwiązywało problem na konkretnym etapie dojrzałości infrastruktury i czasie. Właściwy wybór zależy od Twoich potrzeb przepustowości, budżetu i tego, ile odpowiedzialności operacyjnej chcesz wziąć na siebie.
Dlaczego łączność multi-cloud ma znaczenie
Najczęstsze scenariusze wymagające cross-cloud networking:
- Stopniowa migracja - przenoszenie środowisk z AWS do GCP (lub odwrotnie), gdy obie chmury obsługują ruch produkcyjny w okresie przejściowym
- Najlepsze usługi z każdego dostawcy - Kubernetes na GKE, ale z usługami specyficznymi dla AWS (RDS, Kinesis, SQS), które nie mają odpowiednika na GCP
- Replikacja danych - synchronizacja baz danych między chmurami dla disaster recovery lub replik do odczytu w różnych regionach
- Wspólne usługi - scentralizowane logowanie, monitoring lub systemy tożsamości obsługujące środowiska na obu chmurach
- Wymagania regulacyjne - przechowywanie oraz rzetwarzanie danych w określonych regionach/u określonych dostawców, podczas gdy inne środowiska działają gdzie indziej
W każdym przypadku rozwiązanie łączności musi zapewniać przewidywalne wydajność, wystarczającą przepustowość i szyfrowanie w tranzycie. Różnica między podejściami polega na tym, kto zarządza złożonością i za co płacisz.
Generacja 1: VPN na maszynach wirtualnych (OpenVPN / WireGuard)
To było standardowe podejście, zanim usługi cloud-native VPN dojrzały. Uruchamiasz instancję VPN (lub parę dla HA) w każdej chmurze, konfigurujesz routing między VPC i sam zarządzasz tunelami.
Jak to działa
- Deploy VM w AWS (np. t3.medium) z zainstalowanym OpenVPN lub WireGuard
- Deploy odpowiadającej VM w GCP (np. e2-medium)
- Konfiguracja tunelu między dwoma publicznymi IP
- Ustawienie tabel routingu w obu VPC, aby kierować ruch cross-cloud przez instancje VPN
- Zarządzanie failover, monitoringiem i rotacją certyfikatów samodzielnie
Do czego tego używaliśmy
W naszych wcześniejszych projektach (2018-2020) to było domyślne podejście do łączenia małych i średnich środowisk między AWS i GCP. Typowy use case: startup z głównym deploymentem na GCP potrzebujący dostępu do integracji hostowanej na AWS. Łączyliśmy w ten sposób np. dwa odległe regiony AWS.
Zalety
- Pełna kontrola nad szyfrowaniem, protokołem i konfiguracją
- Działa między dowolnymi dwoma endpointami (cloud-to-cloud, cloud-to-on-premises, cloud-to-colo)
- WireGuard dodaje minimalny narzut latency (~0.5ms na hop)
- Bardzo tanie - tylko koszt dwóch małych VM + ruch sieciowy.
Wady
- Single point of failure - chyba że wdrożysz pary HA z keepalived lub rozwiązaniem podobnej klasy
- Przepustowość ograniczona typem instancji VM - t3.medium ma cap ~5 Gbps, a szyfrowanie VPN redukuje efektywną przepustowość do ~2-3 Gbps
- Obciążenie operacyjne - Ty odpowiadasz za patching, monitoring, failover, rotację kluczy i planowanie pojemności. To potencjalny problem z compliance.
- Brak SLA od dostawcy chmury - jeśli tunel padnie, to Twój problem do zdiagnozowania
- Złożoność routingu - w miarę rosnięcia liczby subnetów, zarządzanie tabelami routingu staje się podatne na błędy
Kiedy nadal ma sens
- Środowiska dev/test, gdzie HA nie jest krytyczne
- Bardzo niskie wymagania przepustowości (<100 Mbps)
- Łączenie z dostawcami, którzy nie oferują managed VPN (mniejsze firmy hostingowe, laboratoria on-premises)
- Budżet poniżej $50/miesiąc na warstwę łączności
Generacja 2: Cloud-native Site-to-Site VPN
Zarówno AWS, jak i GCP oferują managed VPN, które eliminują zarządzanie VM, utrzymując rozsądne koszty.
AWS Site-to-Site VPN + GCP Cloud VPN (HA)
Standardowy wzorzec:
- Utworzenie Virtual Private Gateway (lub Transit Gateway) na AWS
- Utworzenie HA Cloud VPN Gateway na GCP
- Konfiguracja dwóch tuneli na połączenie (AWS wymaga tego dla pokrycia wysokiego SLA)
- Routing oparty na BGP automatycznie obsługuje failover między tunelami
Każdy tunel używa IPsec i zapewnia do 1.25 Gbps. Z dwoma tunelami w konfiguracji active/active otrzymujesz ~2.5 Gbps łącznej przepustowości. Dla wyższej przepustowości możesz utworzyć wiele połączeń VPN (do 4, dając ~10 Gbps teoretycznego maksimum).
Co wdrażaliśmy
Od 2020 roku to stało się naszym domyślnym podejściem dla produkcyjnych połączeń multi-cloud. Typowo wdrażaliśmy:
- 2x tunele VPN (AWS do GCP) dla HA
- BGP z dynamicznym routingiem dla automatycznego failover
- Prywatna adresacja IP z niepokrywającymi się blokami CIDR
- Alarmy CloudWatch + GCP Cloud Monitoring na status tuneli
Zalety
- Zarządzane przez dostawców chmury - żadnych VM do patchowania, żadnych kluczy do ręcznej rotacji
- Wbudowane HA - podwójne tunele z automatycznym failover
- Routing BGP - dynamiczna propagacja tras, bez ręcznych aktualizacji tabel routingu
- SLA - AWS VPN SLA pokrywa 99.95% uptime na tunel
- Szyfrowanie domyślnie - IPsec z AES-256-GCM
Wady
- 1.25 Gbps cap na tunel - jeśli potrzebujesz więcej, dodajesz równoległe połączenia, co zwiększa złożoność
- Narzut IPsec - ~10-15% redukcji przepustowości z szyfrowaniem/enkapsulacją
- Latency - dodaje ~2-5ms ponad bazową ścieżkę internetową z powodu narzutu szyfrowania
- Koszt rośnie z transferem danych - AWS pobiera $0.05/GB za dane wychodzące przez VPN; przy 10 TB/miesiąc to $500 samego egress
- Okazjonalne flappy tuneli - rekeying IKE może powodować krótkie przerwy zakłócające połączenia stanowe
Generacja 3: Managed Cross-Cloud Interconnect
W 2024-2025 zarówno AWS, jak i Google uruchomily usługi zarządzane specjalnie dla łączności multi-cloud na Layer 3:
- Google Cloud Cross-Cloud Interconnect - dedykowane połączenie z GCP do AWS (lub Azure/Oracle) z gwarantowaną przepustowością i SLA Google
- AWS Interconnect Multicloud - odpowiednik AWS, zapewniający dedykowaną łączność między AWS i innymi dostawcami chmury
Te usługi całkowicie eliminują IPsec. Ruch płynie po dedykowanej infrastrukturze zarządzanej przez dostawcę, szyfrowany na warstwie sieciowej, z gwarantowaną przepustowością do 100 Gbps.
Jak to działa
- Zamawiasz połączenie Cross-Cloud Interconnect (np. 10 Gbps) przez konsolę GCP lub AWS
- Dostawca provisionuje dedykowaną ścieżkę między swoją siecią a chmurą partnera
- BGP peering jest ustanawiany między routerami VPC po obu stronach
- Ruch płynie na Layer 3 bez enkapsulacji IPsec - połączenie samo w sobie jest fizycznie prywatne
Żadnych VM, żadnego narzutu IPsec, żadnego zarządzania tunelami. Dostajesz dedykowaną ścieżkę między VPC z gwarantowaną przepustowością.
Zalety
- Brak narzutu szyfrowania - ruch jest fizycznie izolowany, bez kosztu przetwarzania IPsec
- Gwarantowana przepustowość - 10 Gbps lub 100 Gbps dedykowanej pojemności
- Sub-milisekundowy dodatek latency - brak opóźnienia pochodzącego z szyfrowania/deszyfrowania
- SLA - 99.99% z podwójnymi połączeniami
- Zero zarządzania tunelami - brak rekeying, brak flapów tuneli, brak negocjacji IKE
- Ogromna skala - 100 Gbps pojedyncze połączenie vs. zarządzanie dziesięcioma tunelami VPN 1.25 Gbps
Wady
- Koszt - zaczyna się od ~$1,500-3,000/miesiąc za 10 Gbps (przed transferem danych)
- Ograniczenia lokalizacji - nie jest dostępne we wszystkich parach regionów
- Czas provisioningu - dni do tygodni, nie minuty jak VPN
- Nadmiarowe dla małych środowisk - jeśli transferujesz 100 GB/miesiąc, VPN jest dramatycznie tańszy
- Minimalne zobowiązanie - typowo wymaga rocznego commitment dla najlepszej ceny
Tabela porównawcza
| Aspekt | VPN na VM | Cloud-native Site-to-Site VPN | Managed Cross-Cloud Interconnect |
|---|---|---|---|
| Max przepustowość | 2-5 Gbps (limit VM) | 1.25 Gbps/tunel, ~10 Gbps z 4 połączeniami | 10-100 Gbps dedykowane |
| Narzut latency | ~0.5-1ms (WireGuard) | ~2-5ms (IPsec) | <0.5ms (brak przetwarzania szyfrowania) |
| Szyfrowanie | WireGuard/OpenVPN (Ty zarządzasz) | IPsec AES-256 (managed) | Fizyczna izolacja (IPsec niepotrzebny) |
| HA/failover | Ręczny (keepalived, skrypty) | Automatyczny (podwójne tunele, BGP) | Automatyczny (redundantne połączenia) |
| SLA | Brak | 99.95% na tunel | 99.99% z redundancją |
| Czas konfiguracji | Godziny | Minuty | Dni do tygodni |
| Koszt mies. (1 TB transfer) | ~$30-50 (koszt VM) | ~$216 | ~$1,700-3,200 |
| Koszt mies. (50 TB transfer) | ~$50 + egress | ~$2,700 | ~$2,000-3,500 |
| Obciążenie operacyjne | Wysokie (sam zarządzasz) | Niskie (dostawca zarządza tunelami) | Minimalne (w pełni managed) |
| Najlepsze dla | Dev/test, niski budżet | Produkcja <10 Gbps | Wysoka przepustowość, latency-sensitive |
Framework decyzyjny
Wybierz podejście do łączności na podstawie tych pytań:
Ile przepustowości faktycznie potrzebujesz?
- Poniżej 1 Gbps - Site-to-Site VPN jest wystarczający i ekonomiczny
- 1-10 Gbps - Site-to-Site VPN z wieloma połączeniami, lub rozważ interconnect jeśli latency ma znaczenie
- Powyżej 10 Gbps - Managed Cross-Cloud Interconnect to jedyna praktyczna opcja
Jaki jest Twój budżet na latency?
- Jeśli sub-5ms ma znaczenie (synchronizacja danych w czasie rzeczywistym, przetwarzanie transakcji) - Managed Interconnect
- Jeśli 5-15ms jest akceptowalne (przetwarzanie wsadowe, replikacja asynchroniczna) - Site-to-Site VPN
Jak długo połączenie będzie istnieć?
- Tymczasowe (migracja, 3-6 miesięcy) - Site-to-Site VPN; nie commituj się do interconnect na krótkie okresy czasu
- Stałe (architektura multi-cloud) - Managed Interconnect, długoterminowy koszt na GB jest niższy w dłuszym okresie
Jaka jest wydajność operacyjna Twojego zespołu?
- Niewielki zespół, brak specjalistów sieciowych - Managed Interconnect lub Site-to-Site VPN
- Dostępna ekspertyza sieciowa - VPN na VM jest sensowny jeśli budżet jest ograniczony
Nasze doświadczenie z trzema generacjami
W Devopsity wdrażaliśmy wszystkie trzy podejścia w produkcji:
VPN na VM (2018-2020): Tunele WireGuard łączące środowiska GCP z procesorami płatności hostowanymi na AWS. Tanie i efektywne dla budżetów startupowych, ale obciążenie operacyjne rosło wraz ze skalowaniem zespołu. Spędzaliśmy więcej czasu na debugowaniu problemów z tunelami niż na budowaniu produktu.
Site-to-Site VPN (2020-2024): Połączenia HA z podwójnymi tunelami między VPC AWS i VPC GCP dla klientów fintech z podzielonymi środowiskami. Niezawodne, zarządzalne, ale uderzyliśmy w sufit 1.25 Gbps podczas szczytowych okien replikacji danych. Rozwiązaniem było dodawanie równoległych połączeń - co działało, ale zwiększało złożoność routingu.
Managed Cross-Cloud Interconnect (2024-obecnie): Dla klientów z wymaganiami wysokiej przepustowości (replikacja baz danych, pipeline danych ML między chmurami), managed interconnect wyeliminował problem “ile tuneli VPN potrzebujemy?” całkowicie. Koszt jest wyższy, ale prostota operacyjna i gwarantowana przepustowość uzasadniają go dla ścieżek krytycznych dla produkcji.
Wzorzec, który obserwujemy: większość organizacji zaczyna od Site-to-Site VPN i przechodzi na Managed Interconnect, gdy ich ruch cross-cloud przekracza 5-10 Gbps konsekwentnie lub gdy potrzebują gwarancji latency dla środowisk real-time.
Planujesz łączność multi-cloud?
Umów darmową 30-minutową rozmowę. Omówimy Twoje wymagania przepustowości, ograniczenia latency i zarekomendujemy właściwe podejście dla Twojej architektury.
Najczęściej zadawane pytania
Czy mogę użyć Google Cross-Cloud Interconnect i AWS Site-to-Site VPN razem?
Tak. Popularny wzorzec to użycie Managed Interconnect jako głównej ścieżki o dużej przepustowości i utrzymywanie Site-to-Site VPN jako backup. Preferencje tras BGP obsługują failover automatycznie - ruch używa interconnect, gdy jest dostępny, i przechodzi na VPN, jeśli interconnect padnie.
Jak działa pricing transferu danych z Cross-Cloud Interconnect?
Płacisz za port interconnect (stała miesięczna opłata w zależności od pojemności) plus opłaty za transfer danych. Stawka za transfer danych jest typowo niższa niż egress internetowy. Przy dużych wolumenach (10+ TB/miesiąc) koszt per-GB jest znacząco niższy niż egress VPN.
Czy szyfrowanie IPsec jest nadal potrzebne z Managed Interconnect?
Nie ściśle, ponieważ połączenie jest fizycznie izolowane. Jednak niektóre frameworki compliance (PCI DSS, niektóre interpretacje HIPAA) wymagają szyfrowania niezależnie od fizycznej izolacji. Możesz dodać TLS na warstwie aplikacji bez pełnego narzutu tunelu IPsec.
Czy mogę połączyć AWS i GCP przez Azure?
Technicznie tak (Azure jako hub tranzytowy), ale to dodaje latency, koszt i złożoność. Bezpośrednie usługi interconnect AWS-GCP są stworzone specjalnie do tego. Używaj Azure jako tranzytu tylko jeśli masz już architekturę hub-and-spoke z Azure w centrum.
Co się dzieje z moim istniejącym VPN, gdy dodam Managed Interconnect?
Zachowaj go jako ścieżkę failover. Skonfiguruj preferencje tras BGP, aby ruch preferował interconnect (niższy MED lub wyższa local preference). Tunele VPN pozostają aktywne, ale nie przenoszą ruchu, chyba że interconnect padnie. To daje warstwę redundancji przy minimalnym dodatkowym koszcie.
