Amazon SOA-C02: Sieci i dostarczanie treści — Przewodnik do nauki

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Część AWS SysOps Administrator Associate SOA-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Sieci i dostarczanie treści obejmują fundamenty VPC, połączenia hybrydowe, DNS i globalny routing, buforowanie na brzegu sieci z CloudFront oraz cykl życia certyfikatów TLS — wszystkie te elementy są kluczowe dla dostępności, bezpieczeństwa i wydajności. Biegłość operacyjna zapewnia, że obciążenia robocze są osiągalne, odporne na awarie i bezpieczne zarówno w środowisku on-premise, jak i w chmurze. Ta sekcja koncentruje się na praktycznych wzorcach konfiguracji, przykładach z CLI/konsoli oraz kryteriach decyzyjnych, których będziesz używać jako administrator SysOps wspierający systemy produkcyjne.

Projektowanie VPC, podsieci, routing i łączność

Projektuj przestrzeń CIDR VPC z myślą o przyszłym wzroście: przydziel odpowiednio duży VPC (na przykład /16 lub /20 w zależności od skali) i podziel go na podsieci lokalne dla Strefy Dostępności (10.0.0.0/24, 10.0.1.0/24 na AZ), aby uniknąć zależności między strefami. Twórz jawne tablice routingu dla każdego typu podsieci: podsieci publiczne używają trasy do Internet Gateway (IGW) — np.

undefined

; podsieci prywatne kierują ruch 0.0.0.0/0 do NAT Gateway w tej samej Strefie Dostępności, aby uzyskać przewidywalne koszty ruchu wychodzącego i niższe opóźnienia.

Zrozum zachowanie NAT i niuanse routingu: NAT Gateway/Instance wykonuje translację adresów źródłowych (source NAT) dla wychodzących połączeń IPv4 i wymaga, aby ruch powrotny podążał zgodnie z tablicą routingu podsieci z powrotem przez NAT. Dla IPv6 użyj egress-only internet gateway. Użyj AWS CLI, aby utworzyć NAT Gateway i powiązać z nim Elastic IP:

undefined

. Używaj propagacji tras z Transit Gateway lub dołączonymi VPN, aby automatycznie zarządzać trasami dynamicznymi.

Przepływ ruchu i użycie grup zabezpieczeń w porównaniu z NACL musi być przemyślane: grupy zabezpieczeń są stanowe (zezwalasz na ruch przychodzący, a powrotny jest automatycznie dozwolony) i są dołączane do ENI; NACL są bezstanowe i oceniane na poziomie podsieci z uporządkowanymi regułami, więc musisz zezwolić zarówno na ruch przychodzący, jak i wychodzący na portach efemerycznych. Przykładowe polecenia:

undefined

;

undefined

. Kryteria decyzyjne: używaj grup zabezpieczeń do kontroli dostępu na poziomie instancji, a NACL do ochrony obwodowej, wysokowydajnego filtrowania i izolacji między kontami.

VPN, Direct Connect i sieci hybrydowe

Wybierz rodzaj łączności w oparciu o potrzeby dotyczące przepustowości, opóźnień i odporności. Site-to-Site VPN zapewnia szyfrowane tunele IPsec przez internet i jest szybki we wdrożeniu przy użyciu

undefined

. Skonfiguruj dwa tunele VPN dla wysokiej dostępności (HA); użyj BGP do dynamicznego routingu i propagacji tras przez Virtual Private Gateway lub Transit Gateway. Używaj AWS Managed VPN do szybkich wdrożeń oraz jako połączenie zapasowe (failover) dla Direct Connect.

Direct Connect zapewnia prywatną łączność o wysokiej przepustowości i niskich opóźnieniach. Zapewnij połączenie (lub LAG) za pomocą konsoli Direct Connect i utwórz prywatne interfejsy wirtualne (VIF) do VPC przez Direct Connect Gateway, aby uzyskać dostęp wieloregionowy. Użyj BGP z odpowiednim ASN i preferuj rozwiązanie hybrydowe DX + VPN: rozgłaszaj krytyczne prefiksy przez DX, z VPN jako automatycznym połączeniem zapasowym. Kryteria decyzyjne:

Używaj VPN do krótkoterminowych zastosowań, niskiej i średniej przepustowości lub jako szyfrowane połączenie zapasowe przez internet.
Używaj Direct Connect, gdy stała, wysoka przepustowość i przewidywalne opóźnienia uzasadniają koszty portu i połączeń krosowych (cross-connect).
Używaj Transit Gateway do centralizacji wielu połączeń VPC i on-premise, jeśli potrzebujesz skalowalności w modelu hub-and-spoke i uproszczonego zarządzania trasami.

Lista kontrolna operacji: potwierdź, że sesje BGP są aktywne, upewnij się, że trasy są propagowane (dla TGW użyj

undefined

), i przetestuj przełączanie awaryjne (failover), wyłączając jeden tunel lub zmieniając ścieżki BGP.

Route 53 DNS, sprawdzanie stanu (health checks) i polityki routingu

Route 53 jest zarówno autorytatywnym serwerem DNS, jak i płaszczyzną sterowania routingiem. Wdróż mechanizmy sprawdzania stanu (health checks) dla punktów końcowych (HTTP/HTTPS/TCP) i połącz je z rekordami typu failover lub weighted. Przykład: utwórz rekord typu failover z rekordami primary/secondary w konsoli Route 53 lub użyj

undefined

z polityką routingu Failover i identyfikatorem HealthCheckId. Dostosuj wartość TTL w oparciu o oczekiwane SLA przełączania awaryjnego — niskie TTL (30-60s) dla aktywnego failover, dłuższe (300s+) dla stabilnych punktów końcowych.

Wybierz politykę routingu zgodnie z zamierzonym celem:

Simple: zwraca pojedynczą wartość; używaj dla niekrytycznych lub pojedynczych punktów końcowych.
Failover: primary/secondary ze sprawdzaniem stanu do obsługi awarii.
Weighted: stopniowe przenoszenie ruchu dla wdrożeń typu blue/green lub canary.
Latency-based: kieruje użytkowników do regionu o najniższym opóźnieniu.
Geolocation/geoproximity: zapewnia zgodność z wymogami dotyczącymi rezydencji danych lub dostarcza ukierunkowane treści.

Kryteria decyzyjne:

Dla globalnej aplikacji z regionami w trybie active-active i ELB: używaj rekordów Alias wskazujących na ALB/ELB, aby uniknąć dodatkowych opłat i wykorzystać sprawdzanie stanu punktów końcowych.
Dla planowanych migracji lub kształtowania ruchu: używaj rekordów Weighted i zmieniaj wagi przyrostowo za pomocą CLI (

undefined

Dla szybkiego odzyskiwania po awariach centrum danych: używaj routingu Failover z niskimi wartościami TTL i solidnymi mechanizmami sprawdzania stanu.

CloudFront CDN, strategie buforowania i unieważnianie

CloudFront przyspiesza dostarczanie treści poprzez buforowanie w lokalizacjach brzegowych (edge locations) i zmniejszanie obciążenia serwera źródłowego (origin). Skonfiguruj zachowania pamięci podręcznej (Cache Behaviors) dla poszczególnych wzorców ścieżek; kontroluj buforowanie za pomocą nagłówków Cache-Control i Expires z serwera źródłowego lub nadpisuj je za pomocą Forwarded Values oraz Minimum/Maximum TTL w ustawieniach dystrybucji. Użyj Origin Shield, aby zmniejszyć obciążenie serwera źródłowego pochodzące z wielu lokalizacji brzegowych.

Kluczowe strategie buforowania:

Zasoby statyczne: długie wartości TTL, używaj fingerprintingu (wersjonowania obiektów), aby unieważnianie (invalidation) nie było konieczne.
Treści dynamiczne: ustaw Cache-Control: no-cache lub minimalny TTL i użyj Lambda@Edge lub Cache Policy do selektywnego buforowania na podstawie nagłówków/ciasteczek.
API: rozważ regionalną pamięć podręczną (API Gateway + CloudFront) z krótkimi wartościami TTL.

Wzorce unieważniania i zarządzania:

Użyj

undefined

do natychmiastowego usunięcia; pamiętaj o kosztach unieważniania dla dużych wzorców.

Preferuj wersjonowanie obiektów (zmiana nazwy pliku lub wersjonowanie w query string), aby unikać częstych unieważnień.
Zapewnij poprawną konfigurację serwera źródłowego: źródło S3 powinno być zabezpieczone za pomocą Origin Access Control (OAC) lub OAI, aby tylko CloudFront mógł odczytywać dane; dla źródła ALB upewnij się, że kontrole stanu (health checks) i ustawienia sesji przylepnych (stickiness) są zgodne z zachowaniem CloudFront.

Certyfikaty TLS, ACM i cykl życia certyfikatu

Użyj AWS Certificate Manager (ACM) do udostępniania certyfikatów dla ELB, CloudFront i API Gateway. Zamów publiczne certyfikaty za pomocą

undefined

dla walidacji DNS, co pozwala na automatyczne odnawianie. Ważne: CloudFront wymaga certyfikatów ACM w regionie us-east-1; usługi regionalne (ALB, regionalny API Gateway) wymagają certyfikatów w regionie docelowym.

Wzorce walidacji i rotacji:

Walidacja DNS automatyzuje odnawianie i jest preferowaną metodą w środowiskach produkcyjnych; utwórz rekordy CNAME w Route 53 przez konsolę lub za pomocą

undefined

Dla certyfikatów manualnych lub importowanych użyj

undefined

i śledź datę wygaśnięcia za pomocą

undefined

Rotuj certyfikaty, wdrażając nowy certyfikat obok starego (dodaj go do ALB lub dystrybucji CloudFront), zweryfikuj ruch, a następnie usuń stary certyfikat przed jego wygaśnięciem.

Kryteria decyzyjne: używaj ACM dla publicznych certyfikatów podłączonych do punktów końcowych zarządzanych przez AWS. Używaj importowanych certyfikatów tylko wtedy, gdy wymagane są prywatne urzędy certyfikacji (CA) lub zewnętrzne kotwice zaufania (trust anchors).

Częste pułapki i kryteria decyzyjne

Nieprawidłowe reguły grup bezpieczeństwa (security group) lub tablic routingu (route table) powodujące niedostępność instancji — zweryfikuj reguły przychodzące i wychodzące grup bezpieczeństwa oraz wpisy 0.0.0.0/0 w tablicy routingu; pamiętaj, że grupy bezpieczeństwa są stanowe (stateful), a NACL są bezstanowe (stateless) i wymagają jawnego zezwolenia na porty efemeryczne.
Błędnie skonfigurowane wartości TTL w DNS powodujące nieaktualny routing po przełączeniu awaryjnym (failover) — ustawiaj TTL na podstawie okien czasowych przełączania (krótkie TTL dla aktywnego failover) i testuj przełączanie z włączonymi kontrolami stanu (health checks).
Pominięcie konfiguracji źródła (origin) CloudFront i OAC/OAI — zabezpiecz źródła S3, aby buckety nie były publiczne, i upewnij się, że tożsamość źródła CloudFront ma uprawnienia do odczytu obiektów.
Poleganie na Direct Connect bez zapasowego połączenia VPN — zawsze projektuj hybrydę DX + VPN dla odporności na awarie i weryfikuj zachowanie BGP podczas przełączania awaryjnego.
Umieszczanie bram NAT (NAT Gateways) tylko w jednej strefie dostępności (AZ) — twórz bramy NAT w każdej AZ, aby unikać ścieżek danych między strefami i awarii wyjścia w pojedynczej strefie.
Zapominanie o zasadach regionalności ACM dla CloudFront — zamawiaj publiczne certyfikaty w us-east-1 dla CloudFront; usługi sfederowane lub regionalne wymagają certyfikatów regionalnych.

Problem praktyczny: Scenariusz użycia

Firma AcmePayments obsługuje globalną aplikację płatniczą z regionalnymi ALB, statyczną stroną opartą na S3 oraz lokalnym centrum danych wymagającym połączeń rozliczeniowych o wysokiej przepustowości. Potrzebują przewidywalnych opóźnień, bezpiecznej dystrybucji treści statycznych i szybkiego przełączania awaryjnego (failover) w przypadku degradacji wydajności regionu.

Zaprojektuj VPC z publicznymi i prywatnymi podsieciami lokalnymi dla każdej strefy dostępności (AZ); wdróż bramy NAT (NAT Gateways) w każdej AZ i skonfiguruj tablice routingu tak, aby ruch wychodzący z prywatnych podsieci przechodził przez lokalną bramę NAT.
Uruchom Direct Connect z prywatnym VIF do najbliższego regionu i skonfiguruj redundantne połączenie Site-to-Site VPN jako automatyczne przełączanie awaryjne (failover) przy użyciu BGP z odpowiednią propagacją tras do Transit Gateway.
Użyj routingu opartego na opóźnieniach (latency-based routing) w Route 53 dla ALB z kontrolami stanu (health checks) i niskimi wartościami TTL dla krytycznych punktów końcowych; zaimplementuj rekordy ważone (weighted records) do testowania przełączania awaryjnego etapami.
Wdróż CloudFront dla strony statycznej ze źródłem S3 zabezpieczonym przez Origin Access Control i ustaw długie wartości TTL oraz wersjonowanie obiektów, aby unikać unieważniania; użyj Lambda@Edge do wymaganej manipulacji nagłówkami.
Zamów certyfikaty ACM poprzez walidację DNS (w us-east-1 dla CloudFront) i wdrażaj nowe certyfikaty obok istniejących w ramach rotacji blue/green, a następnie usuń stare przed ich wygaśnięciem.

Uzasadnienie: te kroki izolują domeny awarii, zapewniają globalny routing o niskich opóźnieniach, zabezpieczają i buforują zasoby statyczne na brzegu sieci oraz zapewniają, że cykl życia certyfikatów jest zautomatyzowany i niezakłócający działania — co jest zgodne z najlepszymi praktykami w zakresie dostępności operacyjnej i bezpieczeństwa.

← Bezpieczeństwo · Wszystkie domeny · Pamięć masowa i zarządzanie danymi →

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