VPN w chmurze: AWS, Azure, GCP – Cloud VPN, Transit Gateway, HA

Zapewnienie bezpiecznej i niezawodnej łączności między środowiskami chmurowymi a infrastrukturą lokalną stało się kluczowe dla nowoczesnych przedsiębiorstw wdrażających strategie hybrydowe i multicloud. Wirtualne sieci prywatne (VPN) w chmurze zapewniają szyfrowane kanały komunikacyjne, które pozwalają organizacjom rozszerzać swoje sieci na wielu dostawców chmury i lokalizacje lokalne, przy zachowaniu bezpieczeństwa danych i zgodności z regulacjami.

Najwięksi dostawcy chmury — Amazon Web Services (AWS), Microsoft Azure i Google Cloud Platform (GCP) — oferują zaawansowane rozwiązania VPN zaprojektowane z myślą o różnych potrzebach, od podstawowej łączności site-to-site po wysoce dostępne architektury wieloregionowe. Niniejsza analiza omawia oferty VPN na tych trzech platformach, ze szczególnym uwzględnieniem funkcji Google Cloud HA VPN, integracji AWS Transit Gateway z VPN oraz hybrydowych opcji łączności w Azure, aby ułatwić świadome decyzje architektoniczne.

Wprowadzenie do wirtualnych sieci prywatnych w chmurze

Chmurowe wirtualne sieci prywatne stanowią fundamentalną zmianę w projektowaniu infrastruktury hybrydowej, zapewniając szyfrowane, bezpieczne ścieżki komunikacji przez sieci publiczne między zasobami w chmurze a lokalnymi centrami danych.

Znaczenia rozwiązań VPN we współczesnej chmurze nie można przecenić — umożliwiają one utrzymanie szyfrowanych połączeń przez potencjalnie niezaufane sieci przy jednoczesnym zachowaniu zgodności z wymogami bezpieczeństwa i rezydencji danych. VPN działają w warstwie sieciowej, używając protokołu IPsec do szyfrowania ruchu między punktami końcowymi, dzięki czemu wrażliwe dane pozostają chronione w drodze przez internet publiczny.

Różne organizacje mają odmienne wymagania w zakresie łączności chmurowej — od okazjonalnych transferów danych po krytyczne obciążenia produkcyjne wymagające gwarantowanej dostępności i wydajności. Krajobraz rozwiązań VPN w chmurze obejmuje IPsec VPN, łącza dedykowane i zaawansowane usługi tranzytowe — zrozumienie różnic i wzorców architektonicznych jest kluczowe dla optymalizacji wydajności i kosztów.

Rozwiązania VPN Google Cloud Platform i architektura wysokiej dostępności

Google Cloud Platform oferuje dwa typy bram VPN — HA VPN i Classic VPN — obsługujące różne scenariusze i zapewniające odmienne poziomy dostępności i wydajności. HA VPN to zalecane, nowoczesne podejście do łączności chmurowej z umową SLA na poziomie 99,99% (przy konfiguracji zgodnej z dobrymi praktykami), podczas gdy Classic VPN oferuje 99,9%.

Aby szybko uchwycić kluczowe cechy HA VPN i różnice względem Classic VPN, zwróć uwagę na poniższe punkty:

• 99,99% SLA — przy poprawnej topologii z redundancją po obu stronach połączenia,
• dwa interfejsy na bramie (dwa publiczne IP) umożliwiające układ active-active lub active-passive,
• wyłącznie dynamiczny routing BGP przez Cloud Router (brak tras statycznych),
• ECMP dla dystrybucji ruchu i zwiększenia łącznej przepustowości,
• pełny dual-stack IPv4/IPv6 oraz migracja do IPv6 bez utraty łączności IPv4.

Architektura i konfiguracja HA VPN

Architektura HA VPN w Google Cloud opiera się na redundancji na każdym poziomie stosu sieciowego. Tworząc bramę HA VPN, Google Cloud automatycznie przydziela dwa zewnętrzne adresy IP z różnych pul — po jednym dla każdego interfejsu.

Aby osiągnąć 99,99% SLA, należy zbudować topologię tuneli zapewniającą redundancję po obu stronach połączenia. Przy łączeniu z bramą peer mającą dwa interfejsy zaleca się tunele krzyżowe między interfejsami, tak aby utrata pojedynczego komponentu nie powodowała utraty łączności. Konfiguracja obsługuje ruch IPv4 i IPv6, a HA VPN zapewnia możliwości dual-stack.

HA VPN obsługuje wyłącznie routing dynamiczny przez BGP, co zapewnia automatyczne uczenie się tras i dynamiczny wybór ścieżek. Cloud Router zarządza sesjami BGP, umożliwiając tryb active-active (ECMP) lub active-passive.

Network Connectivity Center Google Cloud

Poza podstawowym HA VPN Google Cloud oferuje Network Connectivity Center (NCC), który zapewnia scentralizowany model hub-and-spoke do zarządzania złożonymi scenariuszami sieci hybrydowych i multicloud. NCC daje pojedynczy punkt orkiestracji i kontroli polityk dla wielu regionów, lokalizacji on‑premises i innych chmur.

Hub NCC jest zasobem globalnym, do którego można dołączać szprychy (VPC, tunele HA VPN, Cloud Interconnect, urządzenia routujące). Umożliwia to użycie Google Cloud jako firmowego kręgosłupa WAN i redukuje złożoność względem pełnej siatki.

Wydajność HA VPN i kwestie MTU

Google Cloud VPN ma parametry techniczne, które trzeba uwzględnić przy projektowaniu sieci. MTU usługi Cloud VPN wynosi 1460 bajtów z powodu narzutu IPsec (szyfrowanie i enkapsulacja). Należy zapewnić konfigurację peerów z pre-fragmentacją, aby uniknąć degradacji wydajności.

HA VPN obsługuje różne szyfry IPsec, w tym nowoczesne AEAD, co pozwala równoważyć wymagania bezpieczeństwa i wydajności.

Rozwiązania VPN i usługa Transit Gateway w Amazon Web Services

Amazon Web Services oferuje wiele opcji łączności VPN, a AWS Transit Gateway stanowi ewolucję architektury od prostych połączeń site-to-site do zaawansowanych hubów sieciowych w modelu hub-and-spoke. Transit Gateway to zarządzany, skalowalny regionalny węzeł tranzytowy, który łączy sieci VPC i sieci klientów z jednego punktu kontrolnego.

Integracja AWS Transit Gateway z VPN

Połączenie AWS Site-to-Site VPN z Transit Gateway konsoliduje wiele połączeń w jednym punkcie zarządzania i zapewnia zaawansowane możliwości routingu. Pojedynczy tunel osiąga do 1,25 Gb/s i 140 000 pakietów/s, a limit można obejść dzięki ECMP i wielu tunelom. Transit Gateway wspiera routing dynamiczny (BGP) i statyczny.

ECMP rozkłada ruch równomiernie na wiele tuneli VPN, pozwalając przekroczyć ograniczenia pojedynczego tunelu przy zachowaniu mechanizmów redundancji i failoveru.

Łączność HA VPN z AWS

Łącząc Google Cloud HA VPN z infrastrukturą AWS, zalecana topologia z dwoma połączeniami AWS Site-to-Site VPN (A i B) wymaga czterech tuneli i układu krzyżowego między interfejsami po obu stronach. Taki model spełnia 99,99% SLA po stronie Google Cloud.

Przy łączności Google Cloud–AWS znany jest problem z rekeyingiem VPN przy domyślnej konfiguracji AWS. Zalecane jest użycie IKEv2 i ograniczenie zestawów transformacji po stronie AWS do jednego algorytmu szyfrowania i integralności dla faz 1 i 2 oraz jednej grupy DH. Zapobiega to fragmentacji pakietów IKE, której Cloud VPN nie obsługuje. Sesje BGP należy skonfigurować z parametrami z plików konfiguracyjnych AWS.

Wydajność i skalowanie usługi Transit Gateway

AWS Transit Gateway oferuje mechanizmy uzyskiwania wysokiej przepustowości i redundancji. Tworząc wiele połączeń VPN do Transit Gateway i włączając BGP multipath po stronie urządzeń klienta, można osiągnąć łączną przepustowość na poziomie wielu gigabitów, choć pojedynczy przepływ nadal ogranicza przepustowość do limitu tunelu.

Transit Gateway wspiera także Accelerated VPN przez AWS Global Accelerator, co optymalizuje ścieżkę sieciową od bramy klienta do najbliższej lokalizacji brzegowej AWS i stabilizuje opóźnienia.

Usługa Microsoft Azure VPN Gateway i rozwiązania łączności hybrydowej

Microsoft Azure oferuje kompleksowe rozwiązania hybrydowe dzięki Azure VPN Gateway (site-to-site i point-to-site), w połączeniu z Azure ExpressRoute dla dedykowanych połączeń prywatnych. Azure VPN Gateway korzysta z protokołów szyfrowania IPsec/IKE, obsługując tryby active-standby i active-active.

Tryby konfiguracji Azure VPN Gateway

Azure VPN Gateway można skonfigurować w dwóch trybach: active-standby i active-active. W trybie active-standby brama ma dwie instancje, z których tylko jedna obsługuje ruch, a druga czeka w gotowości. Przy pracach planowych łączność zwykle wraca w 10–15 s, a przy awariach nieplanowych w 1–3 min.

Tryb active-active zestawia aktywne tunele IPsec z obu instancji bramy równocześnie do urządzenia VPN on‑premises. Każda instancja Azure ma unikalny publiczny adres IP i tworzy osobny tunel. Dla pojedynczego przepływu TCP/UDP Azure stara się używać tego samego tunelu dla spójności.

Wdrożenie active-active wymaga użycia SKU innego niż Basic, wariantu route-based oraz dwóch publicznych adresów IP w SKU Standard i w trybie Static. Koszt bramy active-active jest taki sam jak active-standby; dodatkowe koszty wynikają z dwóch adresów publicznych.

Projekt active-active z podwójną redundancją

Dla maksymalnej niezawodności Azure rekomenduje architekturę z podwójną redundancją, łączącą bramy active-active po stronie Azure i on‑premises. Powstaje pełna siatka z czterema aktywnymi tunelami IPsec między siecią wirtualną Azure a siecią lokalną. Wynikiem jest w pełni redundantna sieć, w której ruch rozkłada się na wszystkie tunele, a każdy przepływ TCP/UDP podąża tą samą ścieżką.

Taki projekt chroni przed wieloma scenariuszami awarii: awaria jednego urządzenia on‑premises pozostawia trzy działające tunele; awaria lub serwis jednej instancji bramy Azure nie przerywa przetwarzania ruchu przez drugą. Największą korzyścią jest eliminacja krótkich przerw łączności podczas prac serwisowych lub awarii.

Azure ExpressRoute i łączność prywatna

Choć VPN Gateway zapewnia szyfrowanie przez internet publiczny, Azure ExpressRoute oferuje dedykowaną łączność prywatną z pominięciem internetu — o wyższej niezawodności, niższych i bardziej stabilnych opóźnieniach oraz większej przepustowości. Połączenia ExpressRoute działają w warstwie 3 z routingiem dynamicznym BGP, dostępne z przepustowościami od 50 Mb/s do 100 Gb/s.

Strategia hybrydowa Azure oferuje wiele opcji w zależności od wymagań. Przy surowych wymogach zgodności, wrażliwych danych lub konieczności stałej wysokiej wydajności zalecany jest ExpressRoute. Przy ograniczonym budżecie, sezonowych obciążeniach lub niekrytycznych aplikacjach lepszym wyborem może być VPN Gateway. Maksymalną odporność zapewnia podejście łączone — ExpressRoute + VPN jako automatyczny failover.

Wzorce architektury sieciowej wysokiej dostępności

Projektowanie wysoce dostępnej infrastruktury sieciowej w chmurze wymaga zrozumienia wzorców architektonicznych i konkretnych konfiguracji, by osiągnąć docelowe poziomy dostępności. Wysoka dostępność oznacza eliminację pojedynczych punktów awarii oraz aktywne ścieżki podczas prac planowych i zdarzeń nieplanowych.

Topologia sieci hub-and-spoke

Topologia hub-and-spoke stała się standardem dla organizacji zarządzających łącznością hybrydową w wielu regionach chmury, centrach danych on‑premises i różnych chmurach. Model hub-and-spoke upraszcza polityki routingu i bezpieczeństwa, umożliwia routing tranzytywny oraz redukuje liczbę wymaganych połączeń względem pełnej siatki.

Wysoka dostępność między regionami

Przy wdrożeniach wieloregionowych (DR, równoważenie obciążenia, dystrybucja geograficzna) łączność sieciowa staje się krytyczna. Architektury HA między regionami muszą utrzymać łączność nawet przy niedostępności całych regionów lub ścieżek międzyregionalnych.

W Google Cloud bramy HA VPN są zasobami regionalnymi, więc w każdym regionie wymagającym łączności trzeba wdrożyć osobną bramę. Aby połączyć sieci VPC w różnych regionach z wykorzystaniem HA VPN, zestawia się cztery tunele między bramami (po dwa z każdego interfejsu), aby spełnić wymagania 99,99% SLA. Można też zastosować routing tranzytywny z siecią hub VPC i indywidualnymi połączeniami HA VPN do sieci spoke.

Routing active-active vs. active-passive

Przy architekturach HA VPN trzeba wybrać między trybami active-active i active-passive, co wpływa na wydajność, dystrybucję obciążenia i zachowanie w razie awarii. W konfiguracji active-active w Google Cloud HA VPN oba tunele aktywnie przekazują ruch, a Cloud Router używa ECMP do dystrybucji. Zapewnia to najwyższą łączną przepustowość, ale przy awarii jednego tunelu ruch musi zostać przeplanowany (ok. 40 s).

W trybie active-passive peer ogłasza trasy z różnymi kosztami (MED), dając pierwszeństwo jednemu tunelowi. Active-passive oferuje mniejszą łączną przepustowość, ale stabilniejsze opóźnienia, i jest zalecany, gdy przepustowość w normalnym trybie ma odpowiadać przepustowości podczas failoveru.

Analiza porównawcza rozwiązań VPN w chmurze

Poniższa tabela podsumowuje kluczowe różnice między rozwiązaniami GCP, AWS i Azure w obszarach SLA, routingu, obsługi IPv6 i limitów przepustowości na tunel:

Usługa	SLA	Routing	Obsługa IPv6	Maks. przepustowość na tunel
Google Cloud HA VPN	99,99% (przy poprawnej konfiguracji)	Tylko BGP (Cloud Router)	Dual-stack IPv4/IPv6 (IKEv2)	Do 3 Gb/s (sumarycznie RX+TX)
AWS Site-to-Site VPN (z Transit Gateway)	Brak oficjalnego SLA (projektowana HA)	BGP lub statyczny	IPv4/IPv6 wewnątrz tunelu	1,25 Gb/s
Azure VPN Gateway	99,95% (non‑Basic), 99,9% (Basic)	Policy‑based (statyczny) lub route‑based (BGP)	IPv6 wewnątrz tunelu	Zależna od SKU

Możliwości routingu

Google Cloud HA VPN obsługuje wyłącznie dynamiczny routing przez BGP, eliminując trasy statyczne. AWS Transit Gateway obsługuje BGP i routing statyczny. Azure VPN Gateway obsługuje routing politykowy i trasowy, przy czym rekomendowany jest route‑based z BGP.

Routing dynamiczny automatycznie wykrywa dostępne ścieżki i przełącza się przy awarii, redukując konieczność ręcznych zmian. Routing statyczny bywa prostszy, ale gorzej skaluje się w środowiskach HA.

Obsługa IPv6

Google Cloud HA VPN zapewnia pełne wsparcie IPv6 (dual‑stack i tryb tylko IPv6). Azure VPN Gateway obsługuje adresy IPv6 wewnątrz tunelu (zewnętrzne IP pozostają IPv4). AWS Transit Gateway wspiera IPv4/IPv6 wewnątrz tunelu przy zewnętrznych adresach IPv4.

Wydajność, ceny i aspekty operacyjne

Przepustowość bram VPN i wydajność

Google Cloud HA VPN: do 3 Gb/s łącznie (wejście+wyjście) na tunel. AWS Site-to-Site VPN: 1,25 Gb/s na tunel, skalowalne przez ECMP i wiele tuneli. Azure VPN Gateway: parametry zależą od SKU.

Aby przezwyciężyć ograniczenia pojedynczego tunelu, stosuje się równoległe tunele z ECMP. Pamiętaj: pojedynczy przepływ pozostaje ograniczony pojemnością jednego tunelu, dlatego zyski pojawiają się przy wielu równoległych przepływach.

Modele cenowe i optymalizacja kosztów

Poniżej zebrano najważniejsze dźwignie kosztowe, które warto uwzględnić przy planowaniu budżetu:

• opłaty godzinowe za bramy/tunele — np. w GCP ~0,05 USD/godz. za tunel, w AWS ~0,05 USD/godz. za połączenie Site‑to‑Site,
• koszty transferu danych — zależne od regionów źródła i celu, modelu rozliczeń oraz kierunku (egress/ingress),
• adresy publiczne i usługi dodatkowe — nieużywane IP, AWS Global Accelerator dla Accelerated VPN,
• łącza dedykowane — ExpressRoute/Direct Connect mają wyższy koszt stały, ale obniżają koszt transferu przy dużym wolumenie.

Złożoność operacyjna i zarządzanie

Google Cloud HA VPN automatyzuje failover i adresację IP (niższy narzut operacyjny, wymóg BGP). Azure VPN Gateway zapewnia automatyczny failover w active‑standby, a active‑active wymaga dodatkowej konfiguracji. AWS Transit Gateway upraszcza łączność multi‑VPC, ale wymaga zarządzania bramą klienta i sesjami BGP po stronie klienta.

Wzorce łączności między chmurami i w multicloud

Wraz z upowszechnieniem strategii multicloud rośnie znaczenie łączności między chmurami i on‑premises. Najczęściej stosowane są trzy podejścia:

• site‑to‑site VPN przez internet — szybkie wdrożenie i niski koszt, bez gwarancji opóźnień/przepustowości,
• łącza dedykowane — AWS Direct Connect i Azure ExpressRoute dla przewidywalnej wydajności i SLA,
• dostawcy łączności multicloud — np. Equinix, Megaport, którzy upraszczają peering i routing.

Bezpośrednia łączność AWS i Azure

Najprostszym sposobem połączenia AWS i Azure jest AWS Site-to-Site VPN od Transit Gateway do Azure VPN Gateway z szyfrowaniem IPsec przez internet publiczny. Dla wyższej przewidywalności i wydajności łączy się AWS Direct Connect z Azure ExpressRoute, samodzielnie lub przez operatora multicloud.

Łączność Google Cloud z AWS

Aby ułatwić wdrożenie 99,99% SLA dla łączności Google Cloud–AWS, zastosuj poniższe kroki:

1. Utwórz w AWS Transit Gateway oraz dwie Customer Gateway reprezentujące interfejsy bramy HA VPN w Google Cloud.
2. Skonfiguruj dwa połączenia AWS Site-to-Site VPN (A i B), uzyskując cztery publiczne IP endpointów (A1, A2, B1, B2).
3. W Google Cloud utwórz Zewnętrzną bramę VPN z czterema adresami IP peer i zestaw cztery tunele w układzie krzyżowym.
4. Skonfiguruj Cloud Router (BGP) i IKEv2 z ograniczonym zestawem transformacji, aby uniknąć fragmentacji IKE po stronie AWS.

Najlepsze praktyki i kwestie bezpieczeństwa

Najlepsze praktyki konfiguracji wysokiej dostępności

Wdrażając HA w środowiskach hybrydowych, kieruj się następującymi zasadami:

• wdrażaj bramy w trybie active‑active po obu stronach, aby wyeliminować pojedyncze punkty awarii,
• stosuj routing dynamiczny (BGP) zamiast statycznego, by automatycznie dostosowywać się do zmian topologii,
• zabezpiecz wiele łączy ISP po stronie on‑premises, aby niezawodność VPN nie zależała od jednego operatora,
• testuj regularnie procedury failover (planowe i nieplanowe), aby potwierdzić skuteczność odzyskiwania.

Segmentacja sieci i egzekwowanie polityk bezpieczeństwa

Połączenia VPN powinny funkcjonować w ramach spójnej architektury bezpieczeństwa. Warto wdrożyć następujące mechanizmy kontroli:

• polityka najmniejszych uprawnień — domyślnie blokuj, jawnie zezwalaj tylko na niezbędny ruch,
• mikrosegmentacja — podziel sieć na mniejsze strefy z odrębnymi politykami, ograniczając ruch boczny,
• service mesh w środowiskach kontenerowych — kontrola i szyfrowanie komunikacji usług,
• zasady zero trust — silne uwierzytelnianie, ciągła weryfikacja tożsamości i stanu urządzeń, pełne szyfrowanie ruchu.

Szyfrowanie i konfiguracja szyfrów

Dobór szyfrów wpływa na bezpieczeństwo i wydajność. Rekomendacje:

• unikaj słabych szyfrów (DES, 3DES) i krótkich kluczy,
• preferuj AES‑256 oraz AEAD (np. AES‑GCM) tam, gdzie to możliwe,
• u standaryzuj zestawy transformacji po obu stronach tunelu, aby zminimalizować negocjacje i błędy,
• dla Google Cloud–AWS ogranicz liczbę transformacji, by zapobiec fragmentacji pakietów IKE.

Uwagi dotyczące MTU i fragmentacji pakietów

MTU ma krytyczne znaczenie dla wydajności i niezawodności VPN. Poniższe zalecenia pomagają uniknąć strat:

• ustaw MTU z uwzględnieniem narzutu IPsec — w Cloud VPN to 1460 bajtów,
• włącz pre‑fragmentację po stronie źródła przed szyfrowaniem,
• unikaj fragmentacji po szyfrowaniu, która degraduje wydajność,
• uwzględnij wpływ NAT na MTU i przetestuj konfigurację z realnymi wzorcami ruchu.