Amazon SAA-C03: Dostarczanie treści, Edge i optymalizacja wydajności — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Amazon CloudFront: Czym jest i dlaczego pomaga

Amazon CloudFront to globalnie rozproszona sieć dostarczania treści (CDN) oparta na ponad 600 punktach obecności (PoP). Jej zadaniem jest kończenie połączeń TLS od użytkownika w najbliższej lokalizacji brzegowej i natychmiastowe serwowanie odpowiedzi z pamięci podręcznej lub, w przypadku braku trafienia, przekierowywanie żądań przez prywatną sieć szkieletową AWS do źródła. Korzyść wydajnościowa jest dwojaka: trafienia w pamięci podręcznej redukują czas podróży w obie strony (RTT) do jednocyfrowych wartości milisekund i całkowicie odciążają serwer źródłowy, podczas gdy żądania nietrafione w cache’u wciąż zyskują dzięki zoptymalizowanemu kończeniu połączeń TLS/TCP na brzegu sieci, wsparciu dla HTTP/2 i HTTP/3, ponownemu wykorzystaniu połączeń keep-alive do źródła oraz tranzytowi przez sieć szkieletową, co pozwala ominąć zawodny publiczny internet.

Częstym błędem jest myślenie, że CloudFront przyspiesza tylko statyczne zasoby. Umieszczenie ALB za CloudFront z polityką CachingDisabled wciąż poprawia wydajność dynamicznego API, ponieważ uzgadnianie połączenia (handshake) z użytkownikiem kończy się w lokalnym PoP, zamiast przemierzać internet do regionu źródłowego. Jeśli połączymy to z mieszanym obciążeniem — na przykład /static/* serwowane z S3 i /api/* z ALB — jedna dystrybucja może obsłużyć oba przypadki:

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

Rekordy alias w Route 53 kierują następnie www.example.com na adres dystrybucji d123.cloudfront.net — rekordy alias są darmowe i rozwiązują się bezpośrednio na adresy IP anycast usługi CloudFront.

Certyfikaty muszą znajdować się w us-east-1

Dla każdej dystrybucji CloudFront obsługującej niestandardową domenę, certyfikat TLS widoczny dla użytkownika w AWS Certificate Manager musi być wystawiony w regionie us-east-1 (N. Virginia), niezależnie od tego, gdzie znajduje się źródłowy zasobnik, ALB czy użytkownicy. CloudFront to usługa globalna, której płaszczyzna sterowania jest zakotwiczona w us-east-1; lokalizacje brzegowe pobierają certyfikat z tego właśnie regionu. Proszenie o certyfikat ACM w eu-west-1, ponieważ akurat tam znajduje się zasobnik S3, jest błędnym wzorcem — dystrybucja nigdy go nie zobaczy.

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

Jeśli kończysz połączenie TLS po raz drugi, między CloudFront a źródłowym ALB, ten certyfikat (po stronie źródła) musi znajdować się w regionie, w którym działa ALB. Tylko certyfikat widoczny dla użytkownika jest przypisany do us-east-1. Ta sama zasada dotyczy niestandardowych domen dla API Gateway zoptymalizowanych brzegowo (które wewnętrznie używają zarządzanej przez AWS dystrybucji CloudFront): certyfikat musi znajdować się w us-east-1. W przeciwieństwie do tego, regionalne punkty końcowe API Gateway używają certyfikatu z regionu, w którym wdrożone jest API.

Origin Access Control dla źródeł S3

Używanie CloudFront przed zasobnikiem S3, który pozostaje publiczny, mija się z celem: użytkownicy omijają CloudFront, odwołując się bezpośrednio do punktu końcowego S3 REST, co pozwala im ominąć WAF, ograniczenia geograficzne, podpisane adresy URL i korzyści z buforowania — a także potencjalnie naraża dane.

Nowoczesnym rozwiązaniem jest Origin Access Control (OAC), które zastępuje przestarzałe Origin Access Identity (OAI). OAC używa podpisywania SigV4, wspiera SSE-KMS, działa w każdym regionie S3 (włączając te uruchomione po 2022 roku) i obsługuje dynamiczne żądania. Opcja Block Public Access pozostaje włączona, listy ACL nie są potrzebne, a polityka zasobnika nadaje uprawnienia do odczytu tylko głównemu podmiotowi usługi (service principal) CloudFront, z dodatkowym ograniczeniem do konkretnego ARN dystrybucji:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAI wciąż działa, ale powinno być traktowane jako rozwiązanie przestarzałe — do nowych wdrożeń zawsze wybieraj OAC.

Poprawność pamięci podręcznej

Skuteczność buforowania zależy od nagłówków Cache-Control i Expires zwracanych przez serwer źródłowy, w połączeniu z minimalnym, domyślnym i maksymalnym czasem życia (TTL) zdefiniowanym w polityce cache CloudFront. Niezmienne zasoby z unikalnym odciskiem (fingerprint) powinny być agresywnie buforowane; szablony HTML, które się do nich odwołują, powinny mieć krótki czas życia, aby zmiany wdrożeniowe mogły się propagować; uwierzytelnione odpowiedzi JSON nie powinny być w ogóle buforowane we współdzielonej sieci CDN:

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

Często spotyka się dwie symetryczne pułapki. Po pierwsze, jeśli serwer źródłowy nie wysyła żadnych nagłówków cache, CloudFront użyje domyślnego TTL dystrybucji i może po cichu buforować dynamiczne odpowiedzi przez wiele godzin. Po drugie, bezrefleksyjne stosowanie Cache-Control: no-cache na zasobach, które powinny być buforowane, zmusza do przesyłania każdego żądania z powrotem do źródła i niweczy cel istnienia CDN.

Najniebezpieczniejszą pułapką jest buforowanie spersonalizowanych odpowiedzi bez odpowiednich nagłówków. Jeśli ścieżka /account/dashboard zwraca HTML specyficzny dla użytkownika A, ale serwer źródłowy pomija nagłówek no-store, a polityka cache nie uwzględnia nagłówka autoryzacyjnego lub ciasteczka w kluczu pamięci podręcznej, lokalizacja brzegowa z radością zaserwuje stronę użytkownika A użytkownikowi B. Należy albo oznaczyć takie odpowiedzi jako private, no-store, albo dołączyć identyfikator sesji do klucza pamięci podręcznej i pogodzić się z niższym współczynnikiem trafień.

W scenariuszu optymalizacji kosztów, gdzie grupa Auto Scaling z instancjami EC2 On-Demand serwuje statyczną treść, prawidłowym przeprojektowaniem jest przeniesienie zasobów do S3, umieszczenie przed nimi CloudFront z OAC oraz eliminacja lub zmniejszenie grupy ASG. Przenosi to koszt z opłat za godzinę mocy obliczeniowej na opłaty za dostarczenie żądania, co jest o rzędy wielkości tańsze dla statycznych obciążeń.

Podpisane adresy URL, podpisane ciasteczka i ograniczenia geograficzne

CloudFront wspiera podpisane adresy URL (ograniczony czasowo, opcjonalnie z restrykcją IP, dostęp do pojedynczego obiektu — np. zakupiony plik wideo do pobrania, jednorazowy link do PDF) oraz podpisane ciasteczka (dostęp do wielu obiektów pasujących do wzorca ścieżki — np. uwierzytelniony subskrybent przeglądający katalog). Oba mechanizmy używają zaufanej grupy kluczy (trusted key group), której klucz publiczny jest wgrywany do CloudFront; klucz prywatny służy do podpisywania polityki określającej datę wygaśnięcia, zakres źródłowych adresów IP lub wzorzec URL.

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

Jest to mechanizm odrębny od S3 presigned URL, który omija CloudFront i udziela bezpośredniego dostępu do zasobnika. Połącz podpisane adresy URL CloudFront z OAC, a zasobnik pozostanie w pełni prywatny.

Ograniczenia geograficzne (Geo-restriction) wymuszają na poziomie dystrybucji listy dozwolonych lub zablokowanych krajów, zanim żądania trafią do pamięci podręcznej lub źródła. Wykorzystuje ono utrzymywaną przez CloudFront bazę danych GeoIP i jest tanim, odpornym na ominięcie pamięci podręcznej mechanizmem do egzekwowania embarg licencyjnych. Aby uzyskać bardziej szczegółową logikę (np. na poziomie stanu, kombinacji nagłówków), sięgnij po CloudFront Function lub Lambda@Edge; dla pełnego silnika reguł użyj WAF.

AWS Global Accelerator

Global Accelerator nie jest siecią CDN i nie buforuje treści. Udostępnia dwa statyczne adresy IPv4 anycast (lub BYOIP) rozgłaszane z globalnych lokalizacji brzegowych AWS. Połączenia TCP lub UDP klienta wchodzą do sieci szkieletowej AWS w najbliższej lokalizacji brzegowej i są kierowane przez prywatną sieć AWS do najzdrowszego punktu końcowego (ALB, NLB, EC2 lub Elastic IP) w jednym lub wielu Regionach, zgrupowanych w grupy punktów końcowych z regulatorami ruchu i wagami.

Statyczne adresy IP dają trzy konkretne korzyści: klienci i listy dozwolonych w zaporach sieciowych nigdy się nie zmieniają, nawet jeśli backend zostanie przebudowany; regionalne przełączanie awaryjne kończy się w kilka sekund dzięki przeniesieniu ruchu między grupami punktów końcowych w odpowiedzi na zmiany w sprawdzaniu kondycji, całkowicie omijając propagację DNS TTL; a TCP handshake jest kończony na brzegu sieci, podczas gdy transport na dużą odległość odbywa się w sieci szkieletowej AWS.

Wybierz Global Accelerator, gdy:

• Protokół nie jest protokołem HTTP: UDP dla gier lub VoIP, MQTT, SIP, SFTP, niestandardowy TCP.
• Potrzebujesz statycznych adresów IP dla firmowych list dozwolonych lub aplikacji mobilnych, które mają zaszyte adresy na stałe.
• Potrzebujesz regionalnego przełączania awaryjnego w czasie poniżej minuty dla wdrożeń stanowych w trybie active-active.
• Obciążenie jest dynamiczne i niebuforowalne, więc CDN oferuje niewielką wartość.

Wybierz CloudFront, gdy:

• Treść jest buforowalna (obrazy, segmenty wideo, statyczny HTML, odpowiedzi API z TTL).
• Chcesz wykorzystać przetwarzanie na brzegu sieci za pomocą Lambda@Edge lub CloudFront Functions.
• Potrzebujesz WAF, podpisanych adresów URL/ciasteczek lub szyfrowania na poziomie pola na brzegu sieci.

Dwie pułapki, których należy unikać. Wybór CloudFront, aby „przyspieszyć globalnie nasze serwery do gier”, jest błędem, ponieważ gry używają protokołu UDP i nie są buforowalne — wymagany jest Global Accelerator. I odwrotnie, wybór Global Accelerator dla statycznej strony internetowej jest drogi (stała opłata godzinowa plus opłata za GB) i rezygnuje z buforowania — CloudFront drastycznie obniżyłby koszty transferu wychodzącego z origin. Dla globalnie rozproszonego, ale działającego w jednym Regionie API HTTP, gdzie użytkownicy tolerują opóźnienia, zwykły routing oparty na opóźnieniach w Route 53 może być wystarczający i tańszy niż obie pozostałe opcje.

Polityki routingu Route 53 dla ruchu globalnego

Route 53 wybiera, do którego punktu końcowego resolver klienta ma się odwołać; następnie CloudFront lub Global Accelerator obsługują połączenie. Trzy polityki dominują w architekturach globalnych.

Routing oparty na opóźnieniach mierzy rzeczywiste opóźnienie sieciowe od lokalizacji resolvera do każdego Regionu i zwraca najszybszy. Używaj go dla identycznych stosów w wielu Regionach, gdy chcesz, aby użytkownicy byli kierowani do tego Regionu, który jest w danym momencie najszybszy.

Routing oparty na bliskości geograficznej jest oparty na współrzędnych, a nie na opóźnieniach: deklarujesz lokalizację (lub Region AWS) każdego punktu końcowego, a Route 53 kieruje użytkowników do geograficznie najbliższego. Jego charakterystyczną cechą jest wartość bias (od -99 do +99), która rozszerza lub zmniejsza efektywny obszar obsługi — przydatne do stopniowego przesuwania ruchu podczas uruchamiania nowego Regionu lub opróżniania Regionu w celu konserwacji. Routing oparty na bliskości geograficznej wymaga użycia Route 53 traffic flow (polityk ruchu) i jest zazwyczaj łączony z regionalnym NLB lub ALB w każdym Regionie.

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

Routing failover wykorzystuje parę podstawowy/zapasowy powiązaną ze sprawdzaniem kondycji. Jest to przełączanie awaryjne na poziomie DNS, podlegające TTL i buforowaniu przez resolvery, więc jest wolniejsze niż przełączanie awaryjne w warstwie danych w Global Accelerator — wybierz routing failover dla prostych konfiguracji active-passive, gdzie minuta propagacji DNS jest akceptowalna, a Global Accelerator, gdy potrzebujesz sekund.

Te polityki można łączyć. Powszechny wzorzec globalny: rekordy Route 53 oparte na opóźnieniach lub bliskości geograficznej wskazują na Global Accelerator (dla TCP/UDP) lub CloudFront (dla buforowalnego HTTPS), z rekordami failover sprawdzającymi kondycję poniżej jako siatką bezpieczeństwa. Warstwowość jest celowa: Route 53 wybiera Region, Global Accelerator lub CloudFront wybiera lokalizację brzegową i ścieżkę przez sieć szkieletową, a regionalny load balancer wybiera cel wewnątrz Regionu.

Typy punktów końcowych API Gateway i domeny niestandardowe

API Gateway oferuje trzy typy punktów końcowych o odrębnych topologiach:

Zoptymalizowane brzegowo punkty końcowe opakowują API w zarządzaną przez AWS dystrybucję CloudFront, której nie można bezpośrednio konfigurować. Jest to wygodne dla szybkiego globalnego zasięgu, ale ograniczające, gdy chcesz mieć własne zachowania buforowania, reguły WAF lub polityki żądań do origin. Idiomatycznym wzorcem zapewniającym maksymalną kontrolę jest regionalny punkt końcowy poprzedzony zarządzaną przez klienta dystrybucją CloudFront.

Umiejscowienie certyfikatu jest zgodne z zasadą CloudFront: niestandardowe domeny zoptymalizowane brzegowo wymagają certyfikatu ACM w regionie us-east-1; regionalne punkty końcowe wymagają certyfikatu w tym samym Regionie co API. HTTP API wymuszają minimum TLS 1.2; REST API obsługują polityki bezpieczeństwa do TLS 1.3.

Certyfikaty ACM: Wystawione, zweryfikowane, zaimportowane

ACM bezpłatnie wystawia i automatycznie odnawia publiczne certyfikaty TLS oraz integruje się bezpośrednio z CloudFront, API Gateway, ALB, NLB i innymi usługami AWS. Walidacja odbywa się poprzez walidację DNS (ACM dostarcza rekord CNAME do umieszczenia w Route 53 lub u dowolnego dostawcy DNS; dopóki rekord istnieje, ACM automatycznie odnawia certyfikat w nieskończoność) lub walidację e-mail (wymaga ręcznego kliknięcia przy każdym odnowieniu, co jest problematyczne w automatyzacji). Walidacja DNS jest właściwym domyślnym wyborem dla każdego środowiska produkcyjnego.

Certyfikatów wystawionych przez ACM nie można eksportować ani używać poza zintegrowanymi usługami AWS. Gdy wymogi regulacyjne lub biznesowe narzucają użycie konkretnego zewnętrznego urzędu certyfikacji (CA) — na przykład dla API REST, które musi być powiązane z określonym komercyjnym wystawcą i wymuszać TLS 1.3 — nie można użyć certyfikatu wystawionego przez ACM. Należy uzyskać certyfikat od wymaganego CA i zaimportować go do ACM, a następnie podłączyć do regionalnej domeny niestandardowej API Gateway z polityką bezpieczeństwa TLS 1.3.

Pułapka związana z importem jest dwojaka: zaimportowane certyfikaty nie odnawiają się automatycznie (trzeba je ponownie zaimportować przed wygaśnięciem, w przeciwnym razie punkt końcowy przestanie działać), a ACM nie weryfikuje łańcucha zaufania podczas importu — uszkodzony certyfikat pośredni zostanie wykryty dopiero podczas uzgadniania połączenia (handshake) przez rzeczywistych klientów. Przetestuj pełny łańcuch zaufania przy użyciu restrykcyjnego klienta przed wdrożeniem na produkcję.

S3 Transfer Acceleration vs. CloudFront

CloudFront optymalizuje pobieranie (download); S3 Transfer Acceleration optymalizuje wysyłanie (upload). Transfer Acceleration wykorzystuje tę samą sieć brzegową CloudFront w odwrotnym kierunku: żądania PUT trafiają do najbliższej lokalizacji brzegowej i podróżują siecią szkieletową AWS do regionu docelowego bucketu. Sprawdza się najlepiej, gdy globalnie rozproszeni użytkownicy wysyłają duże obiekty do bucketu w jednym regionie — na przykład inżynierowie terenowi z całego świata przesyłający wielogigabajtowe rysunki do us-east-1.

Obie funkcje mogą współistnieć na tym samym buckecie: włącz Transfer Acceleration i udostępnij dystrybucję CloudFront z OAC do pobierania plików. W przypadku małych obiektów lub klientów znajdujących się blisko regionu bucketu, Transfer Acceleration generuje dodatkowe koszty bez korzyści — użyj narzędzia S3 Transfer Acceleration speed comparison tool, aby zmierzyć wydajność przed podjęciem decyzji. Aby akceleracja zadziałała, klienci muszą używać punktu końcowego s3-accelerate.

AWS WAF dla ochrony warstwy 7

AWS WAF sprawdza żądania HTTP(S), zanim dotrą one do chronionego zasobu. Można go dołączyć do dystrybucji CloudFront, ALB, etapów (stages) API Gateway, API AppSync, pul użytkowników Cognito, usług App Runner i instancji Verified Access. Web ACL zawiera reguły, które dopasowują żądania na podstawie URI, nagłówków, query stringów, treści (body, domyślnie do 8 KB, z możliwością rozszerzenia do 64 KB dla ALB/API Gateway), zestawów IP i geolokalizacji.

Najczęstszymi elementami składowymi są AWS Managed Rules: AWSManagedRulesCommonRuleSet i AWSManagedRulesKnownBadInputsRuleSet chronią przed najpopularniejszymi exploitami z listy OWASP; AWSManagedRulesSQLiRuleSet i reguły dopasowania XSS (XSS match statements) obsługują ataki typu injection. Niestandardowe reguły dodają dopasowanie geograficzne (białe/czarne listy krajów dla zgodności z przepisami), dopasowanie do zestawów IP oraz reguły oparte na liczbie zapytań (rate-based) — zliczają one żądania z danego źródłowego adresu IP w pięciominutowym oknie i blokują go po przekroczeniu progu. Reguły rate-based to pierwsza linia obrony przed atakami typu HTTP flood i credential stuffing:

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

Zasady dotyczące regionów są ważne. Web ACL dla CloudFront są globalne i muszą być tworzone w regionie us-east-1. Web ACL dla zasobów regionalnych (ALB, API Gateway itp.) tworzy się w tym samym regionie, w którym znajduje się zasób.

Aby chronić statyczną stronę w S3, nie można dołączyć WAF do bucketu — S3 nie jest zasobem wspieranym przez WAF. Prawidłowym wzorcem jest użycie CloudFront z OAC przed bucketem i dołączenie web ACL do dystrybucji. Fakt, że do bucketu można dotrzeć tylko przez CloudFront, sprawia, że cała inspekcja ruchu jest skuteczna.

Firewall Manager dla zarządzania WAF w środowisku wielokontowym

Zarządzanie WAF na pojedynczych kontach nie skaluje się. W ramach organizacji zespół uruchamia nowy ALB bez dołączania firmowego standardu zabezpieczeń, co po cichu obniża poziom zgodności z politykami. AWS Firewall Manager rozwiązuje ten problem za pomocą polityk obejmujących całą organizację, egzekwowanych na kontach i zasobach objętych zakresem.

Wymagania wstępne: AWS Organizations z włączonymi wszystkimi funkcjami (all-features), wyznaczone konto administratora Firewall Manager oraz włączony AWS Config na każdym koncie członkowskim. Typy polityk obejmują AWS WAF, AWS Shield Advanced, grupy bezpieczeństwa (audyt i użycie), Network Firewall, Route 53 Resolver DNS Firewall oraz zapory sieciowe firm trzecich.

Polityka WAF może wymusić stosowanie “pierwszej” grupy reguł (przetwarzanej przed regułami zdefiniowanymi dla aplikacji), “ostatniej” grupy reguł (przetwarzanej po nich) lub całkowicie zastąpić istniejącą web ACL. Nowe ALB lub dystrybucje CloudFront pasujące do zakresu zasobów automatycznie otrzymują firmowy zestaw reguł, a zasoby niezgodne z polityką są oznaczane i — w zależności od ustawień naprawczych — automatycznie korygowane. Gdy w scenariuszu pojawiają się sformułowania “wiele kont”, “centralne zarządzanie” lub “spójne reguły WAF w całej organizacji”, odpowiedzią jest Firewall Manager, a nie zarządzanie WAF na każdym koncie z osobna.

Shield Standard a Shield Advanced

Zakładanie, że sam WAF zatrzyma ataki DDoS, jest poważnym błędem. WAF działa na żądaniach, które do niego docierają — jest doskonały przeciwko atakom typu flood na warstwę aplikacji, credential stuffing i znanym sygnaturom exploitów — ale duże ataki wolumetryczne na warstwach 3/4 (SYN floods, UDP reflection) są absorbowane przez AWS Shield.

Shield Standard jest domyślnie włączony bez dodatkowych kosztów. Automatycznie chroni przed powszechnymi atakami na warstwach L3/L4 i dotyczy usług CloudFront, Route 53 oraz Global Accelerator, z podstawową ochroną dla ELB, EC2 i innych zasobów. Nie zapewnia on jednak wglądu w szczegóły ataku, zaangażowania zespołu Shield Response Team ani ochrony kosztów.

Shield Advanced (3000 USD miesięcznie na organizację, z rocznym zobowiązaniem) dodaje:

Założenie, że Shield Standard jest wystarczający do ochrony przed „atakiem DDoS na dużą skalę z ochroną kosztów i reakcją ekspertów”, jest błędne właśnie dlatego, że w wersji Standard brakuje wglądu w atak, ochrony kosztów i dostępu do SRT. Gdy źródłem jest instancja EC2 za ELB, a DNS jest obsługiwany przez firmę trzecią (więc sztuczki z aliasami Route 53 nie wchodzą w grę), zalecanym wzorcem jest włączenie Shield Advanced na ELB i wystawienie aplikacji przez CloudFront (również chronionego przez Shield Advanced), aby przenieść obwód mitygacji na brzeg sieci (edge) i zmniejszyć powierzchnię ataku docierającą do Regionu.

Prawidłowa, warstwowa postawa obronna to: Shield do ataków wolumetrycznych na L3/L4, WAF do filtrowania na L7, CloudFront lub Global Accelerator jako brzegowy punkt wejścia, do którego podłączone są obie usługi, oraz Firewall Manager do egzekwowania polityki na wszystkich kontach.

← Sieci i łączność · Wszystkie domeny · Bazy danych i buforowanie →

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

Przeglądaj Amazon →