Amazon SAA-C03: Integracja aplikacji, przesyłanie komunikatów i przesyłanie strumieniowe — 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 SQS: Odsprzęganie, kolejność i semantyka dostarczania

Amazon SQS to w pełni zarządzana, oparta na modelu pull kolejka komunikatów, której główną rolą architektoniczną jest odsprzęgnięcie producentów od konsumentów. Synchroniczny łańcuch wywołań wiąże opóźnienie i dostępność producenta z każdą zależnością w dalszej części systemu; wstawienie kolejki SQS przekształca to w asynchroniczne przekazanie. Producenci kolejkują komunikaty w tempie, w jakim napływa ruch, a konsumenci pobierają je z kolejki w tempie, w jakim mogą je bezpiecznie przetwarzać. Jest to kanoniczne rozwiązanie problemu nagłych wzrostów zapisów, które w przeciwnym razie przeciążyłyby instancję RDS — kolejka absorbuje nagły wzrost, a ograniczona flota konsumentów opróżnia ją z kontrolowaną współbieżnością, utrzymując w ryzach liczbę połączeń z bazą danych.

Istnieją dwa typy kolejek, a wybór jednego z nich determinuje zarówno przepustowość, jak i gwarancje dostarczenia.

Kolejki standardowe dostarczają komunikaty co najmniej raz (at-least-once) z zachowaniem kolejności jedynie na zasadzie best-effort. Duplikaty mogą się pojawić, gdy konsument nie usunie komunikatu przed upływem limitu czasu widoczności (visibility timeout) lub gdy rozproszony backend ponownie odtworzy komunikat w różnych shardach. Nawet jeśli nigdy nie zobaczysz duplikatu podczas testów, usługa jest architektonicznie zaprojektowana tak, że może ponownie dostarczyć komunikat, zwłaszcza podczas awarii brokera. Założenie, że kolejki standardowe „zazwyczaj” dostarczą komunikat raz, jest błędem projektowym, a nie ryzykiem operacyjnym — przy dużej skali duplikaty z pewnością w końcu wystąpią. Logika konsumenta musi być zatem idempotentna: śledzić MessageId lub klucz biznesowy w DynamoDB za pomocą zapisu warunkowego, używać klucza idempotencji w wywołaniach API do systemów podrzędnych lub polegać na semantyce upsert.

Kolejki FIFO zapewniają ścisłą kolejność w ramach MessageGroupId oraz przetwarzanie dokładnie raz dzięki MessageDeduplicationId (jawnemu lub hashowi SHA-256 treści komunikatu), który eliminuje duplikaty w 5-minutowym oknie. MessageGroupId jest kluczową koncepcją: wszystkie komunikaty o tym samym ID grupy są dostarczane ściśle w kolejności do jednego konsumenta naraz, podczas gdy różne ID grup mogą być przetwarzane równolegle. W systemie przetwarzania zamówień, gdzie zdarzenia każdego klienta muszą być sekwencyjne, ale zdarzenia różnych klientów są niezależne, należy użyć MessageGroupId = customerId. Użycie jednego ID grupy dla wszystkiego serializuje całe obciążenie i niszczy przepustowość. Identyfikatory deduplikacji są właściwym mechanizmem do zapobiegania tworzeniu zduplikowanych zamówień, gdy użytkownik ponownie przesyła zawieszone zamówienie: klient generuje deterministyczny token idempotencji (UUID powiązany z sesją zakupową), a SQS odrzuca wszelkie zduplikowane zgłoszenia, które nadejdą w obrębie okna czasowego.

PaymentsQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: payments.fifo
    FifoQueue: true
    ContentBasedDeduplication: true
    DeduplicationScope: messageGroup
    FifoThroughputLimit: perMessageGroupId
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt PaymentsDLQ.Arn
      maxReceiveCount: 5

Wybranie kolejki standardowej, gdy wymaganie mówi o „kolejności” lub „braku duplikatów”, to klasyczny błąd. Żadna logika aplikacji nie jest w stanie przywrócić kolejności, której kolejka nigdy nie zachowała, ponieważ komunikaty z różnych hostów backendu docierają w sposób przemieszany. Wybierz FIFO zawsze, gdy obciążenie wymaga zachowania kolejności (rejestry transakcji, przejścia w maszynie stanów) lub semantyki „dokładnie raz” (przechwytywanie płatności, dekrementacja stanu magazynowego).

Visibility Timeout, trujące komunikaty i limity ładunku

Gdy konsument odbiera komunikat, SQS sprawia, że staje się on niewidoczny dla innych konsumentów na czas określony przez visibility timeout (domyślnie 30 sekund, maks. 12 godzin). Jeśli konsument usunie komunikat przed upływem tego czasu, komunikat znika na zawsze; jeśli nie — ponieważ konsument uległ awarii lub przetwarzanie po prostu trwało zbyt długo — komunikat pojawia się ponownie w kolejce i jest dostarczany raz jeszcze. Ustawienie visibility timeout na wartość krótszą niż rzeczywisty czas przetwarzania jest główną przyczyną zduplikowanego przetwarzania: funkcja Lambda, która wykonuje się 45 sekund, przy kolejce z domyślnym 30-sekundowym limitem czasu, będzie przetwarzać każdy komunikat co najmniej dwa razy. Ustaw limit czasu na co najmniej p99 czasu przetwarzania (zalecenie AWS dla kolejek obsługiwanych przez Lambda to co najmniej 6-krotność timeoutu funkcji), a dla zadań o nieprzewidywalnej długości dynamicznie przedłużaj limit czasu:

sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=handle,
    VisibilityTimeout=300  # extend by 5 minutes
)

Kolejki martwych listów (DLQ) przechwytują tzw. trujące komunikaty (poison-pill messages). RedrivePolicy na kolejce źródłowej określa maxReceiveCount (zazwyczaj 3–5); po przekroczeniu tej wartości SQS przenosi komunikat do DLQ w celu inspekcji offline. DLQ musi być tego samego typu co kolejka źródłowa (FIFO ↔ FIFO). Bez DLQ, źle sformatowane komunikaty krążą w pętli w nieskończoność, a w przypadku FIFO jest to szczególnie szkodliwe — zachowanie kolejności uniemożliwia dostarczenie kolejnych komunikatów w tej samej grupie, dopóki problematyczny komunikat nie zostanie obsłużony, więc jeden zły komunikat zatrzymuje całą grupę.

Komunikaty SQS mają limit rozmiaru 256 KB. W przypadku większych ładunków — na przykład zadania przenoszącego wyrenderowany dokument — należy użyć SQS Extended Client Library, która zapisuje ładunek do S3 i umieszcza w kolejce jedynie referencję w postaci nazwy bucketa i klucza. Biblioteka kliencka po stronie konsumenta transparentnie pobiera ładunek przy odbiorze. Nie dziel ładunków na wiele komunikatów (tracisz atomowość i kolejność) i nie koduj w base64 obiektu o rozmiarze 2 MB w nadziei, że się zmieści.

Autoskalowanie sterowane kolejką

Dla floty konsumentów na EC2 lub ECS za kolejką SQS, właściwym sygnałem do skalowania nie jest użycie CPU — jest nim backlog w kolejce. Użycie CPU jest opóźnione w stosunku do tempa napływu komunikatów i błędnie interpretuje nasyconego konsumenta jako „zajętego, ale dającego radę”. Kanoniczną metryką skalowania jest ApproximateNumberOfMessagesVisible, ale skalowanie bezpośrednio na podstawie surowej głębokości kolejki jest mało precyzyjne. Rekomendowanym podejściem jest niestandardowa metryka backlog-per-instance:

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Opublikuj tę metrykę w CloudWatch i użyj jej do sterowania polityką target-tracking w grupie Auto Scaling lub usłudze ECS, tak aby każdy worker utrzymywał ograniczony backlog (na przykład 10 komunikatów). Zapewnia to płynne skalowanie w górę podczas nagłych wzrostów i zapobiega oscylacjom, gdy głębokość kolejki jest mała, ale konsumenci są już nasyceni. Do skalowania w dół, połącz tę metrykę z ApproximateAgeOfOldestMessage, aby uniknąć zwalniania zasobów, gdy w kolejce wciąż znajdują się stare komunikaty.

Amazon SNS: Fan-Out, filtrowanie i dostarczanie międzykontowe

SNS to usługa typu publish/subscribe oparta na mechanizmie push. Wydawcy (publishers) publikują wiadomości w temacie (topic); SNS wysyła je do każdej subskrypcji: kolejek SQS, funkcji Lambda, punktów końcowych HTTP(S), e-maili, SMS-ów, Kinesis Data Firehose czy powiadomień mobilnych. Dominującym wzorcem zapewniającym trwałość jest fan-out z SNS do SQS: jeden temat z subskrypcją w postaci wielu kolejek SQS, dzięki czemu każda usługa docelowa ma swój własny, trwały bufor, politykę ponowień i kolejkę DLQ, podczas gdy wydawca wie tylko o istnieniu tematu. Jeśli usługa konsumencka przestanie działać na wiele godzin, jej kolejka będzie gromadzić wiadomości, a po przywróceniu działania zostaną one przetworzone — sam SNS nie ma takiej możliwości buforowania i wyczerpałby swoją politykę ponowień.

Producer ──▶ SNS topic ──┬──▶ SQS Queue A ──▶ Service A
                         ├──▶ SQS Queue B ──▶ Service B
                         └──▶ SQS Queue C ──▶ Service C

Filtrowanie wiadomości pozwala każdej subskrypcji zadeklarować politykę filtrowania w formacie JSON, dzięki czemu SNS dostarcza tylko pasujące wiadomości, co pozwala uniknąć antywzorca, w którym każdy konsument otrzymuje wszystkie wiadomości i filtruje je po swojej stronie:

{
  "eventType": ["order_placed", "order_cancelled"],
  "region": ["us-east-1", "us-west-2"]
}

Istotne są dwie właściwości behawioralne. Po pierwsze, standardowe tematy SNS nie gwarantują kolejności wiadomości — ponieważ liczniki ponowień dla każdego subskrybenta i niezależne ścieżki sieciowe sprawiają, że zmiana kolejności jest zjawiskiem normalnym. Jeśli kolejność ma znaczenie, należy użyć tematu SNS FIFO z subskrypcją w postaci kolejek SQS FIFO; wtedy ID grupy wiadomości (message group ID) jest propagowane na całej ścieżce. W przeciwnym razie subskrybenci muszą być idempotentni i odporni na zmianę kolejności. Po drugie, subskrypcje HTTP(S) ponawiają próby zgodnie z polityką dostarczania (domyślnie: trzy natychmiastowe próby, następnie wykładniczy backoff do jednej godziny, a potem odrzucenie). Subskrybenci muszą odpowiedzieć kodem 2xx w ciągu 15 sekund, zweryfikować sygnaturę x-amz-sns-message-type i — w przypadku zawodnych punktów końcowych — zawsze mieć skonfigurowaną kolejkę DLQ dla SNS (z przekierowaniem do SQS), aby niedostarczone wiadomości były przechwytywane, a nie cicho odrzucane.

Wywołania międzykontowe to częsta pułapka. Gdy Konto A publikuje wiadomość do tematu, który w ramach fan-out wywołuje funkcję Lambda na Koncie B, wymagane są dwie polityki: polityka tematu SNS (lub kierunek subskrypcji) musi zezwalać na subskrypcję, a polityka zasobowa (resource-based policy) funkcji Lambda musi zezwalać na akcję lambda:InvokeFunction z sns.amazonaws.com z warunkiem SourceArn pasującym do tematu. Brak polityki zasobowej Lambda jest najczęstszą przyczyną awarii — subskrypcja wydaje się być w dobrej kondycji, ale wywołania są odrzucane z błędem 403. Jeśli temat jest szyfrowany kluczem KMS zarządzanym przez klienta, polityka klucza musi również przyznawać uprawnienia kms:Decrypt i kms:GenerateDataKey dla podmiotu publikującego (publishing principal) oraz dla sns.amazonaws.com.

{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:222222222222:function:ProcessOrder",
  "Condition": {"ArnLike": {"AWS:SourceArn": "arn:aws:sns:us-east-1:111111111111:orders"}}
}

Amazon EventBridge: Routing na szynach zdarzeń

EventBridge (wcześniej CloudWatch Events) rozszerza model pub/sub o routing oparty na treści, wykrywanie schematów, źródła zdarzeń od partnerów SaaS oraz archiwizację i odtwarzanie. Zdarzenia przepływają przez szyny zdarzeń (event buses) (domyślną, niestandardową lub partnerską) i są dopasowywane do reguł (rules), których wzorce zdarzeń (event patterns) filtrują na podstawie struktury JSON. Reguły mogą transformować dane (payloads) za pomocą ścieżek wejściowych (input paths) i szablonów wejściowych (input templates), dołączać cele typu dead-letter i dostarczać zdarzenia do ponad 20 natywnych celów, w tym Lambda, Step Functions, zadań ECS, SQS, SNS, Kinesis i API destinations.

{
  "source": ["com.acme.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {"amount": [{"numeric": [">", 500]}]}
}

Różnica w stosunku do SNS ma charakter architektoniczny. SNS jest zoptymalizowany pod kątem masowego rozgłaszania (broadcast) o wysokiej przepustowości do jednorodnych subskrybentów, z prostym filtrowaniem atrybutów i niższym opóźnieniem. EventBridge jest zoptymalizowany dla heterogenicznych architektur sterowanych zdarzeniami: wielu producentów emituje zdarzenia o różnych schematach, a konsumenci subskrybują je na podstawie wzorca, a nie tematu. W przypadku monolitu dekomponowanego na mikrousługi — zwłaszcza gdy producenci zdarzeń obejmują partnerów SaaS lub usługi AWS (Config, GuardDuty, CodePipeline, CloudTrail), które natywnie emitują zdarzenia — EventBridge jest zazwyczaj właściwym wyborem. Dla fan-outu o ekstremalnie dużej objętości i niskim opóźnieniu do identycznych subskrybentów, SNS wciąż wygrywa, ponieważ EventBridge ma nieco wyższe opóźnienie na zdarzenie i niższy domyślny próg przepustowości.

Amazon MQ: Broker wiadomości dla istniejących protokołów

Amazon MQ to zarządzany broker oparty na ActiveMQ lub RabbitMQ. Jego celem jest migracja obciążeń on-premises, które zależą od protokołów AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire lub JMS, bez konieczności przepisywania aplikacji. Jeśli system płatności używa zewnętrznego brokera JMS z transakcyjną semantyką “dokładnie raz” (exactly-once), przeniesienie go do Amazon MQ pozwala zachować protokół komunikacyjny (wire protocol) i gwarancje dostarczenia, eliminując jednocześnie zarządzanie infrastrukturą. Wybierz SQS/SNS/EventBridge dla nowych, natywnych projektów w AWS (greenfield); wybierz Amazon MQ tylko wtedy, gdy ograniczeniem jest kompatybilność protokołów.

Kinesis Data Streams

Kinesis Data Streams (KDS) to trwały, uporządkowany i partycjonowany log do przyjmowania danych strumieniowych (ingest) o wysokiej przepustowości — np. clickstreamów, telemetrii IoT, agregacji logów. Rekordy są umieszczane w fragmentach (shards) na podstawie klucza partycjonowania (PartitionKey); kolejność jest gwarantowana w obrębie jednego fragmentu, ale nie w całym strumieniu. Każdy fragment obsługuje zapis 1 MB/s lub 1000 rekordów/s oraz odczyt 2 MB/s (lub więcej dzięki Enhanced Fan-Out). Rekordy są domyślnie przechowywane przez 24 godziny, z możliwością rozszerzenia do 365 dni, dzięki czemu wielu niezależnych konsumentów może odtwarzać tę samą historię — czego nie potrafi SQS, ponieważ usuwa wiadomości po potwierdzeniu (ack).

Tryb na żądanie (on-demand) eliminuje potrzebę obliczania liczby fragmentów, automatycznie skalując zapis do 200 MiB/s na strumień, co jest idealne dla nieprzewidywalnego ruchu. Tryb aprowizowany (provisioned) jest tańszy przy stałym obciążeniu, gdy pojemność jest znana.

Wybierz KDS zamiast SQS FIFO, gdy obciążenie wymaga uporządkowanego, odtwarzalnego przyjmowania danych z przepustowością, której FIFO nie jest w stanie obsłużyć (FIFO osiąga maksymalnie znacznie niższe wartości niż miliony rekordów na sekundę obsługiwane przez KDS), gdy wielu niezależnych konsumentów musi odczytywać ten sam strumień, lub gdy w wymaganiach pojawia się sformułowanie “zachowaj oryginalną kolejność podczas całego przetwarzania” w połączeniu z dużą objętością danych.

Kinesis Data Firehose

Kinesis Data Firehose to w pełni zarządzana usługa do dostarczania danych. Odczytuje dane ze strumienia Kinesis lub bezpośrednio przez PUT, buforuje je według rozmiaru (1–128 MB) lub czasu (60–900 sekund, w zależności od tego, co nastąpi pierwsze), opcjonalnie wywołuje funkcję Lambda do transformacji poszczególnych rekordów (np. czyszczenie PII, normalizacja formatu), może w locie konwertować format JSON na Parquet lub ORC przy użyciu schematu Glue, szyfruje za pomocą KMS i dostarcza do S3, Redshift, OpenSearch lub Splunk. Nie ma shardów, nie wymaga uruchamiania konsumentów i oferuje model cenowy pay-per-GB.

Kanoniczny wzorzec skalowalnego pozyskiwania danych do data lake łączy Data Streams (w trybie on-demand) jako trwały bufor z Firehose do dostarczania danych do S3:

Producers → Kinesis Data Streams (on-demand) → Firehose (60s buffer, Parquet) → S3 → Athena/Glue

Do pozyskiwania milionów zdarzeń z urządzeń mobilnych, ich szyfrowania i zapisywania w S3 w formacie Parquet, poprawną odpowiedzią jest Firehose z konwersją do Parquet i kluczem KMS — a nie KDS plus niestandardowy konsument plus własnoręcznie napisany writer Parquet, co wymaga znacznie więcej kodu i infrastruktury. Firehose działa w czasie zbliżonym do rzeczywistego i nie obsługuje ponownego odtwarzania danych po stronie konsumenta; gdy ponowne odtwarzanie jest wymagane, należy pozostawić KDS w architekturze.

Kinesis Data Analytics (obecnie Managed Service for Apache Flink) uruchamia zadania SQL lub Flink na strumieniu w celu wykonywania agregacji w oknach czasowych.

Integracja z Lambda i semantyka ponawiania prób

Lambda integruje się z tymi usługami, ale mechanizmy ponawiania prób (retry) znacznie się różnią:

Dla SQS, timeout funkcji Lambda powinien być ≤ visibility timeout kolejki, a visibility timeout powinien być ustawiony na co najmniej 6-krotność timeoutu funkcji. Dla Kinesis, włącz BisectBatchOnFunctionError i skonfiguruj miejsce docelowe OnFailure (SQS lub SNS), aby pojedynczy wadliwy rekord (poison record) nie blokował całego sharda na czas nieokreślony.

Tabela decyzyjna wyboru usługi

← Analityka · Wszystkie domeny · Bezpieczeństwo →

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

Przeglądaj Amazon →