Google PCA: Sieci, łączność hybrydowa i architektura ruchu sieciowego — Przewodnik do nauki

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Część Google Professional Cloud Architect — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Sieci, łączność hybrydowa i architektura ruchu w Google Cloud opierają się na bezpiecznym, skalowalnym projekcie Virtual Private Cloud (VPC); niezawodnych hybrydowych połączeniach międzysieciowych; inteligentnym zarządzaniu ruchem; oraz solidnej obserwowalności. Celem jest dostarczanie usług o niskim opóźnieniu i wysokiej odporności, z wyraźną segmentacją, kontrolowanym ruchem wychodzącym (egress) i przewidywalnymi trybami awarii. Ta sekcja przedstawia praktyczne wzorce projektowe, kompromisy i wskazówki operacyjne dotyczące podstawowych usług sieciowych Google Cloud.

Architektura i segmentacja VPC

• Planowanie adresacji i podsieci

  • Używaj VPC w trybie niestandardowym (custom-mode), aby kontrolować tworzenie podsieci i adresację IP. Unikaj domyślnych sieci VPC w środowiskach produkcyjnych.
  • Wcześnie alokuj niezachodzące na siebie bloki RFC1918. Weź pod uwagę przyszły wzrost, topologie o wysokiej dostępności i rozszerzenia hybrydowe. Zarezerwuj zakresy dla usług (np. dla punktów końcowych Private Service Connect) oraz dla peeringu/Interconnect.
  • Preferuj mniejsze podsieci per-funkcja lub per-środowisko zamiast dużych, płaskich sieci, aby zminimalizować promień rażenia awarii i uprościć konfigurację zapory sieciowej.

• Trasy (Routes)

  • Każda sieć VPC ma systemową tabelę tras; trasy są oceniane według dopasowania najdłuższego prefiksu, a następnie priorytetu. Trasy zarządzane przez Google obejmują domyślną trasę internetową (jeśli istnieją zewnętrzne adresy IP) oraz trasy podsieci. Trasy dynamiczne są wymieniane ze środowiskiem on-premises za pośrednictwem Cloud Router.
  • Używaj niestandardowych tras statycznych oszczędnie; w miarę możliwości polegaj na routingu dynamicznym dla zapewnienia odporności. Unikaj tras typu blackhole, chyba że jest to celowy mechanizm kontrolny.

• Reguły zapory sieciowej

  • Zapora sieciowa VPC jest stanowa (stateful), a reguły są przetwarzane według priorytetu, z niejawną regułą deny na końcu. Kieruj ruch na podstawie tagów sieciowych lub kont usług (service accounts); kierowanie na podstawie kont usług oferuje silniejsze gwarancje tożsamości niż tagi.
  • Oddzielaj reguły allow według przeznaczenia (sprawdzanie stanu, komunikacja wewnątrzwarstwowa, administracja) i ograniczaj ich zakres do źródłowych kont usług lub zakresów IP.
  • Rejestruj decyzje zapory sieciowej dla krytycznych reguł w Cloud Logging, aby wspomóc analizę śledczą i wydajnościową.

• Hierarchiczne zasady zapory sieciowej i zasady organizacji

  • Hierarchiczne zasady zapory sieciowej są stosowane na poziomie organizacji lub folderu i przetwarzane przed regułami na poziomie VPC. Używaj ich do ustawiania globalnych barier ochronnych (np. blokowanie SSH z 0.0.0.0/0), których projekty nie mogą nadpisać. Zasady pre i post zapewniają elastyczność, ale reguły deny na wyższych poziomach nie mogą zostać nadpisane.
  • Uzupełnij je o ograniczenia Organization Policy (np. ograniczenie tworzenia zewnętrznych adresów IP, zakaz tworzenia VPC peering przez projekty), aby egzekwować ład korporacyjny (governance).

• Shared VPC i segmentacja

  • Używaj Shared VPC, aby scentralizować zarządzanie siecią w projektach hosta (Host Projects), jednocześnie izolując obciążenia w projektach usługowych (Service Projects). Ten wzorzec redukuje zduplikowane ścieżki wyjściowe, standaryzuje mechanizmy kontroli i upraszcza tranzyt hybrydowy.
  • Izoluj środowiska (produkcyjne, nieprodukcyjne) w oddzielnych projektach hosta lub folderach; wymuszaj segmentację za pomocą hierarchicznych zasad i oddzielnych podsieci. Ogranicz uprawnienia IAM, aby tylko zespoły NetOps zarządzały zasobami projektu hosta.

• VPC Network Peering

  • Peering jest prywatny, skalowalny i o niskim opóźnieniu, ale nietranzytywny. Najlepiej nadaje się do łączenia autonomicznych sieci lub usług zarządzanych przez strony trzecie. Unikaj budowania hubów tranzytowych za pomocą peeringu; używaj Network Connectivity Center do tranzytu lub scentralizowanej sieci Shared VPC.
  • Ograniczenia: brak nakładających się adresów IP; pewne trasy (np. domyślna trasa internetowa) i niektóre usługi nie są propagowane. Podczas projektowania należy zrozumieć mechanizm importu/eksportu tras niestandardowych.

Kompromisy i tryby awarii:

• Nakładające się zakresy IP blokują peering i wymianę tras hybrydowych; problem można rozwiązać poprzez zmianę numeracji lub NAT.
• Zbyt liberalne reguły zapory sieciowej lub brakujące reguły sprawdzania stanu (health check) powodują awarie i trudne do zdiagnozowania zachowania.
• Trasy statyczne tworzą kruche zależności; preferuj Cloud Router do obsługi przełączania awaryjnego (failover).

Zarządzanie ruchem, DNS i bezpieczeństwo na brzegu sieci

• Wzorce Cloud Load Balancing

  • External HTTP(S) Load Balancer to globalny anycast z pojedynczym adresem VIP anycast, oferujący failover między regionami, routing oparty na ścieżce i hoście oraz integrację z CDN/Armor. Używaj go do obciążeń webowych i API wystawionych do internetu.
  • Internal HTTP(S) Load Balancer jest regionalny, przeznaczony do ruchu między usługami w ramach VPC lub przez Private Service Connect.
  • External/Internal TCP/UDP Network Load Balancer to regionalny L4; używaj go dla protokołów innych niż HTTP lub tam, gdzie wymagane jest zachowanie źródłowego adresu IP.
  • Usługi backendowe i Network Endpoint Groups (NEGs): używaj strefowych grup instancji jako backendów dla pul VM; używaj strefowych, regionalnych lub serwerowych NEG dla GKE, backendów hybrydowych lub Cloud Run. Twórz oddzielne usługi backendowe dla każdej klasy ruchu, profilu kondycji lub polityki pojemności. Przykład: obsługuj stare i nowe wersje API pod tą samą nazwą hosta, kierując ruch na podstawie ścieżki do oddzielnych usług backendowych, co pozwala na ich niezależne wdrażanie i skalowanie.

• Kontrole stanu i częste pułapki

  • Kontrole stanu muszą być dozwolone przez zaporę sieciową. Dla zewnętrznych kontroli stanu HTTP(S) zezwól na ruch z 130.211.0.0/22 i 35.191.0.0/16 do backendów. Brakująca reguła powoduje, że backendy są oznaczane jako niesprawne, a maszyny wirtualne są gwałtownie restartowane, jeśli autoskalowanie reaguje na sygnały z load balancera.
  • Dostosuj ścieżki i porty kontroli stanu do endpointów gotowości kontenera (readiness endpoints); ustaw limity czasu i progi, aby zrównoważyć szybki failover z fałszywymi alarmami (false positives).

• Architektura DNS

  • Używaj Cloud DNS dla stref autorytatywnych. Twórz strefy prywatne dla nazw wewnętrznych; twórz strefy publiczne dla nazw internetowych.
  • Split-horizon DNS: obsługuj różne odpowiedzi wewnętrznie i zewnętrznie, tworząc oddzielne strefy publiczne i prywatne o identycznych nazwach. Umożliwia to bezpieczną obsługę prywatnych nazw hostów usług i publicznie dostępnych rekordów.
  • Strefy przekierowujące (forwarding) i peeringowe: integruj z lokalnym DNS za pomocą polityk DNS i polityk serwera, aby przekierowywać zapytania dla określonych domen; używaj przekierowywania warunkowego, aby unikać pętli rekurencji.
  • Odnajdowanie usług (service discovery): przyjmij spójne konwencje nazewnictwa dla każdego środowiska i usługi. Dla GKE rozważ użycie usług typu headless z Cloud DNS lub mapowanie endpointów usług za pomocą Internal HTTP(S) Load Balancer i prywatnych nazw DNS.

• Buforowanie na brzegu sieci i ochrona

  • Cloud CDN odciąża serwery źródłowe, buforując zawartość na brzegu sieci, co zmniejsza opóźnienia i koszty ruchu wychodzącego (egress). Uważnie konfiguruj klucze pamięci podręcznej, TTL i buforowanie negatywne (negative caching); omijaj buforowanie dla spersonalizowanych lub dynamicznych endpointów.
  • Cloud Armor zapewnia WAF, ograniczanie liczby zapytań (rate limiting) oraz kontrolę dostępu opartą na geolokalizacji/IP. Dołączaj polityki bezpieczeństwa do load balancerów; monitoruj logi trafień w reguły. Używaj prekonfigurowanych reguł dla popularnych CVE oraz niestandardowych sygnatur dla zagrożeń specyficznych dla aplikacji.
  • Terminacja TLS na load balancerze centralizuje zarządzanie certyfikatami; włącz automatyczne dostarczanie certyfikatów i zarządzane odnawianie tam, gdzie to możliwe.

Wskazówki operacyjne:

• Wersjonowane API: zaimplementuj routing oparty na ścieżce lub hoście do oddzielnych usług backendowych, aby każda wersja mogła być wdrażana niezależnie za pomocą wzorców blue-green lub canary.
• Używaj nagłówków żądań i plików cookie do testów A/B za pomocą polityk sterowania ruchem; zawsze sprawdzaj, czy logi i metryki korelują z tożsamością właściwego backendu.

Łączność hybrydowa, dostęp prywatny i tranzyt

• Cloud Router i BGP

  • Cloud Router dynamicznie wymienia trasy ze środowiskiem on-premises za pośrednictwem BGP dla tuneli Cloud VPN i połączeń Interconnect. Używaj trybu globalnego routingu dynamicznego w sieci VPC, gdy wymagana jest łączność z gałęziami (spoke) w wielu regionach.
  • Ogłaszaj tylko wymagane prefiksy; filtruj, aby zapobiegać wyciekom tras. Zrozum interakcje między atrybutem MED a priorytetami podczas projektowania ścieżek podstawowych i zapasowych.

• Cloud VPN, Dedicated i Partner Interconnect

  • HA VPN zapewnia redundantne tunele IPsec objęte umową SLA, obsługuje dynamiczny routing przez Cloud Router i jest odpowiedni do produkcyjnych środowisk hybrydowych o umiarkowanym zapotrzebowaniu na przepustowość.
  • Dedicated Interconnect zapewnia fizyczne łącza 10/100 Gbps w jednej lub więcej lokalizacjach; Partner Interconnect oferuje podobne rozwiązanie za pośrednictwem dostawcy usług. Używaj co najmniej dwóch zdywersyfikowanych połączeń Interconnect w oddzielnych lokalizacjach metropolitalnych lub oddzielnych strefach brzegowych, aby uzyskać wysoką dostępność.
  • Ścieżki redundantne i przełączanie awaryjne (failover): projektuj w trybie active/active z BGP na dwóch routerach Cloud Router na region i dwóch routerach on-premises; weryfikuj tolerancję na routing asymetryczny. Regularnie testuj przełączanie awaryjne; dostosuj liczniki czasu BFD i progi kondycji w celu uzyskania pożądanej zbieżności.
  • Tryby awarii: Niezgodność MTU powoduje fragmentację i spadki wydajności; zapewnij obsługę ramek jumbo (jumbo frames) na całej ścieżce dla Interconnect. Błędnie skonfigurowane filtry tras mogą powodować blackholing (utratę ruchu) dla całych podsieci. Obwody partnerskie z jednym punktem podłączenia (single-homed) są częstym pojedynczym punktem awarii.

• Cloud NAT, Private Google Access i Private Service Connect

  • Cloud NAT umożliwia ruch wychodzący (egress) do internetu dla prywatnych maszyn wirtualnych bez zewnętrznych adresów IP. Dobierz liczbę adresów IP NAT i alokację portów do szczytowego obciążenia, aby uniknąć wyczerpania portów; włącz logowanie w celach diagnostycznych.
  • Private Google Access pozwala prywatnym maszynom wirtualnym na dostęp do API Google przy użyciu wewnętrznych adresów IP; włącz na podsieciach dla dostępu maszyn wirtualnych i na węzłach GKE dla lokalnego dostępu do API z węzła. Dla klientów on-premises użyj Private Service Connect for Google APIs, aby udostępnić prywatne adresy VIP, które kierują ruch do API Google.
  • Private Service Connect dla usług producenta/konsumenta zapewnia prywatne, wewnętrzne punkty końcowe IP do publikowania usług między projektami lub organizacjami; połącz z prywatnym DNS, aby kierować ruchem bez ujawniania sieci.

• Network Connectivity Center (NCC) i tranzyt

  • NCC umożliwia topologie hub-and-spoke, gdzie gałęziami (spokes) są sieci VPC, tunele HA VPN lub połączenia Interconnect. Użyj centralnego huba, aby uprościć dystrybucję tras i tranzyt między wieloma sieciami VPC, zwłaszcza między projektami lub organizacjami.
  • Preferuj Shared VPC dla tranzytu wewnątrzorganizacyjnego, jeśli pozwalają na to zasady ładu korporacyjnego; użyj NCC, gdy potrzebujesz elastycznego tranzytu międzydomenowego lub integracji z SD-WAN.
  • Pamiętaj, że VPC Peering nie jest przechodni (non-transitive); nie polegaj na nim w celu zapewnienia tranzytu. NCC lub scentralizowana sieć VPC z firewallem/load balancerem tworzy rdzeń tranzytowy.

Wybory wieloregionowe, opóźnienia i koszty ruchu wychodzącego (egress):

• Umieszczaj zasoby obliczeniowe blisko użytkowników i blisko stanowych backendów, aby zminimalizować RTT. External HTTP(S) Load Balancing zapewnia globalny ruch przychodzący (ingress) z inteligentnym routingiem, ale opóźnienia w replikacji bazy danych i spójność pozostają ograniczeniami na poziomie aplikacji.
• Ruch między strefami w obrębie regionu generuje koszty; replikacja międzyregionalna dodaje opłaty za ruch wychodzący (egress) i opóźnienia. Używaj Cloud CDN, aby zmniejszyć ruch wychodzący do internetu i obciążenie serwerów źródłowych, a usługi intensywnie komunikujące się ze sobą utrzymuj w tej samej lokalizacji.
• W przypadku odtwarzania po awarii (disaster recovery), rozważ korzyści z utrzymywania rezerwowego środowiska (warm standby) w innym regionie w stosunku do kosztów ruchu wychodzącego i złożoności operacyjnej. Używaj globalnego load balancingu z politykami przełączania awaryjnego i kontrolami kondycji obejmującymi wiele regionów tylko wtedy, gdy płaszczyzna danych i płaszczyzna sterowania mogą tolerować izolację regionalną.

Obserwowalność, operacje na rzecz niezawodności i kontrole

• Obserwowalność sieci

  • VPC Flow Logs: włącz na poziomie podsieci i dostosuj opcje próbkowania oraz metadanych. Używaj do ustalania punktu odniesienia dla ruchu (baselining), analizy ruchu wychodzącego (egress) i polowania na zagrożenia (threat hunting). Eksportuj do BigQuery w celu długoterminowej analityki.
  • Logowanie reguł zapory sieciowej: włącz dla krytycznych reguł, aby przechwytywać ruch dozwolony i odrzucony; koreluj z logami przepływu w celu wykrywania błędnych konfiguracji.
  • Connectivity Tests: modeluj ścieżki od źródła do celu, aby weryfikować osiągalność, wybór trasy i ocenę reguł zapory. Integruj z CI/CD, aby wykrywać dryf konfiguracji przed wdrożeniem.
  • Pulpity nawigacyjne stanu: monitoruj stan backendów load balancera, wykorzystanie portów Cloud NAT, status sesji BGP w Cloud Router oraz wykorzystanie Interconnect. Ustawiaj alerty na odchylenia.

• Wzorce niezawodności i typowe tryby awarii

  • Odporność na poziomie strefy (zonal resilience): rozmieszczaj backendy w co najmniej dwóch strefach; używaj zarządzanych grup instancji (managed instance groups) lub wielostrefowych pul węzłów GKE. Sprawdzaj, czy sprawdzanie stanu (health checks) i tagi zapory sieciowej mają zastosowanie do wszystkich stref.
  • Odporność routingu: używaj globalnego routingu dynamicznego i wielu Cloud Routerów dla łączności obejmującej cały region. Testuj scenariusze typu blackhole i upewnij się, że monitorowanie obejmuje wycofywanie tras.
  • Odporność DNS: domyślnie wdrażaj wiele serwerów nazw z Cloud DNS; w przypadku rozwiązań hybrydowych upewnij się, że serwery przekazujące (forwarders) są redundantne i unikaj pojedynczych punktów awarii w resolverach on-premise. Zapobiegaj błędnym konfiguracjom typu split-horizon, które zwracają nierutowalne odpowiedzi z niewłaściwej strony.
  • Bezpieczeństwo na brzegu sieci (at the edge): stosuj limity zapytań (rate limits) w Cloud Armor, aby chronić origin przed atakami typu flood; zaniechanie tego może wywołać burze autoskalowania i nagłe wzrosty kosztów.

• Kontrola kosztów

  • Minimalizuj wywołania międzyregionalne, preferuj wewnętrzny load balancing dla ruchu wewnątrz VPC i rozważ użycie PSC dla ruchu producent-konsument, aby uniknąć kosztów wyjścia przez NAT (NAT egress).
  • Używaj Cloud CDN dla zasobów statycznych i półstatycznych; dostosuj możliwość buforowania (cacheability). Dobierz przepustowość Interconnect, aby uniknąć przepłacania za niewykorzystany zapas; użyj danych o ruchu, aby dopasować zobowiązania (commits).

Fragmenty operacyjne:

• Zezwól na sprawdzanie stanu (health checks) przez load balancer do prywatnych backendów:

undefined

• Włącz Private Google Access w podsieci:

undefined

• Utwórz Cloud Router dla HA VPN:

undefined

Praktyczny scenariusz problemowy

Contoso Retail planuje uruchomić globalne API e-commerce z wersjonowaniem bez przestojów, ścisłą prywatną łącznością z systemami back-office i brakiem publicznych adresów IP na maszynach wirtualnych aplikacji. Rozwiązanie musi zapewniać ochronę przed atakami DDoS, buforowanie na brzegu sieci (edge caching) i niezawodny dostęp hybrydowy z dwóch centrów danych.

Podejście:

1. Zaprojektuj VPC i segmentację

• Utwórz projekt hosta Shared VPC w trybie custom-mode z dedykowanymi podsieciami dla każdej warstwy (web, api, data) w dwóch regionach. Uzasadnienie: Shared VPC centralizuje kontrolę, podczas gdy projekty usługowe izolują zespoły. Podsieci per warstwa umożliwiają stosowanie zapory sieciowej z zasadą najmniejszych uprawnień i tworzą mniejsze domeny awarii.
• Zastosuj hierarchiczne polityki zapory sieciowej na poziomie organizacji, aby zablokować przychodzący ruch SSH z internetu i ograniczyć ruch wychodzący do dozwolonych miejsc docelowych. Uzasadnienie: Globalne zabezpieczenia (guardrails) zmniejszają ryzyko błędnej konfiguracji w projektach.

2. Zaimplementuj globalny ruch przychodzący (ingress) oparty na ścieżce i wersjonowanie API

• Wdróż zewnętrzny HTTP(S) Load Balancer z pojedynczym adresem IP anycast i terminacją HTTPS. Skonfiguruj mapy URL do kierowania ruchu /v1/* i /v2/* do oddzielnych usług backendowych opartych na regionalnych, strefowych grupach NEGs. Uzasadnienie: Oddzielne usługi backendowe pozwalają na niezależne wdrażanie i wycofywanie każdej wersji API pod jedną nazwą hosta i certyfikatem TLS.
• Dołącz Cloud Armor WAF i limity zapytań (rate limits); włącz Cloud CDN dla punktów końcowych z zawartością możliwą do buforowania (np. zdjęcia produktów). Uzasadnienie: Chroni origin oraz zmniejsza opóźnienia i koszty ruchu wychodzącego (egress).

3. Zapewnij osiągalność i stan backendów

• Utwórz regułę zapory sieciowej, aby zezwolić na sprawdzanie stanu (health checks) przez load balancer do grup instancji API na oczekiwanych portach. Uzasadnienie: Bez tego sprawdzanie stanu kończy się niepowodzeniem, a autoskalery mogą działać niestabilnie (thrash), gdy instancje są uznawane za niesprawne.
• Rozmieść instancje w dwóch strefach w każdym regionie; ustaw progi sprawdzania stanu (health check) konserwatywnie, aby uniknąć niestabilności (flapping). Uzasadnienie: Różnorodność strefowa i stabilne polityki sprawdzania stanu poprawiają dostępność.

4. Zbuduj DNS z mechanizmem split-horizon i odnajdywaniem usług (service discovery)

• Utwórz publiczną strefę Cloud DNS dla contoso.com i prywatną strefę o tej samej nazwie dla rekordów wyłącznie wewnętrznych (np. db.internal.contoso.com). Uzasadnienie: Split-horizon zapobiega wyciekowi nazw wewnętrznych, zachowując spójne nazewnictwo.
• Skonfiguruj polityki DNS, aby przekazywać zapytania on-premises dla corp.local do firmowego serwera DNS i importować strefy prywatne do projektów aplikacji. Uzasadnienie: Płynne rozwiązywanie nazw ponad granicami hybrydowymi bez pętli rekursji.

5. Ustanów łączność hybrydową z redundancją

• W każdym regionie utwórz dwa tunele HA VPN do każdego centrum danych, każda para na oddzielnych Cloud Routerach z BGP. Jeśli wymagania dotyczące przepustowości i SLA to uzasadniają, dodaj Partner Interconnect z redundantnymi załącznikami (attachments) w oddzielnych strefach brzegowych (edge zones). Uzasadnienie: Wiele zróżnicowanych ścieżek zapewnia przełączanie awaryjne (failover); BGP umożliwia szybką zbieżność i dynamiczną wymianę tras.
• Użyj globalnego routingu dynamicznego w Shared VPC i zastosuj filtry tras, aby zapobiec propagacji niechcianych prefiksów z lokalizacji on-premises. Uzasadnienie: Spójny routing w różnych regionach przy jednoczesnym zmniejszeniu ryzyka wycieków tras.

6. Zapewnij prywatny dostęp do interfejsów API Google i internetu wychodzącego

• Włącz Private Google Access w podsieciach aplikacji i skonfiguruj punkty końcowe Private Service Connect dla interfejsów API Google używanych przez zadania wsadowe. Użyj Cloud NAT dla ruchu wychodzącego niezwiązanego z API, tam gdzie jest to potrzebne. Uzasadnienie: Backendy nie posiadają publicznych adresów IP, ale nadal mają dostęp do niezbędnych usług; PSC upraszcza rozwiązywanie nazw za pomocą prywatnego DNS.

7. Scentralizuj tranzyt i łączność z podmiotami trzecimi

• Utwórz hub Network Connectivity Center w projekcie hosta; dołącz tunele HA VPN, załączniki Interconnect i wszelkie szprychy SD-WAN (spokes). Uzasadnienie: Tranzyt w modelu hub-and-spoke upraszcza dystrybucję tras między wieloma sieciami VPC i sieciami zewnętrznymi w porównaniu do siatek peeringu (peering meshes).

8. Wdróż obserwowalność i zabezpieczenia (guardrails)

• Włącz VPC Flow Logs we wszystkich podsieciach z odpowiednim próbkowaniem; włącz logi zapory sieciowej dla krytycznych reguł; eksportuj do BigQuery. Używaj Connectivity Tests w CI/CD przed promowaniem nowych zmian w zaporze sieciowej lub trasach. Uzasadnienie: Głęboka widoczność wspiera rozwiązywanie problemów, planowanie pojemności i audytowalność.
• Ustaw alerty na zerwanie sesji BGP w Cloud Router, wyczerpanie portów Cloud NAT, spadki stanu backendów i zadziałanie reguł Cloud Armor. Uzasadnienie: Wczesne wykrywanie awarii i ataków skraca MTTR.

9. Optymalizuj pod kątem wydajności i kosztów

• Umieszczaj usługi stanowe (stateful) razem z zasobami obliczeniowymi w tym samym regionie; buforuj zawartość statyczną na brzegu sieci za pomocą Cloud CDN. Uzasadnienie: Minimalizuje RTT i koszty ruchu wychodzącego między regionami.
• Okresowo przeglądaj logi przepływu (flow logs), aby zidentyfikować ruch między strefami (cross-zone chatter) i dostosować rozmieszczenie lub granice usług. Uzasadnienie: Redukuje niepotrzebny ruch wychodzący (egress) i opóźnienia.

Ten projekt zapewnia globalny, bezpieczny ruch przychodzący (ingress) z wersjonowanym routingiem, odporną łączność hybrydową z dynamicznym przełączaniem awaryjnym (failover), prywatny dostęp do wymaganych usług oraz kompleksową obserwowalność, jednocześnie kontrolując opóźnienia i koszty ruchu wychodzącego (egress).

← Przechowywanie danych · Wszystkie domeny · Bezpieczeństwo →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Google →