Amazon SOA-C02: Serverless i integracja aplikacji — 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.

Architektury bezserwerowe i integracja aplikacji obejmują uruchamianie aplikacji sterowanych zdarzeniami bez zarządzania serwerami oraz niezawodne łączenie usług. Znaczenie operacyjne polega na zarządzaniu skalą, opóźnieniami, trybami awarii i dostępem z najniższymi uprawnieniami, przy jednoczesnym utrzymaniu przewidywalnych kosztów. Ten obszar koncentruje się na zachowaniu Lambda (zimne starty, współbieżność), niezawodnym dostarczaniu zdarzeń (EventBridge, SNS, SQS), mechanizmach kontroli bezpieczeństwa (role wykonawcze i uprawnienia) oraz obserwowalności dla przepływów asynchronicznych.

Aspekty operacyjne i współbieżność w AWS Lambda

Wydajność i dostępność Lambda zależą od zimnych startów, limitów współbieżności i mechanizmów kontroli dławienia (throttling). Zimne starty występują, gdy Lambda musi zainicjować nowe środowisko wykonawcze; zmniejsz ich wpływ, używając provisioned concurrency (aws lambda put-provisioned-concurrency-config –function-name MyFn –qualifier 1 –provisioned-concurrent-executions 10) dla ścieżek krytycznych pod względem opóźnień, oraz preferuj lżejsze środowiska uruchomieniowe lub mniejszy zakres prac inicjalizacyjnych. Rezerwuj i ograniczaj współbieżność za pomocą reserved concurrency (aws lambda put-function-concurrency –function-name MyFn –reserved-concurrent-executions 50), aby chronić usługi podrzędne i egzekwować limity na poziomie funkcji; monitoruj metryki CloudWatch ConcurrentExecutions i Throttles.

Modele ponowień i wywołań różnią się w zależności od trybu: wywołania synchroniczne (API Gateway, bezpośrednie wywołanie Invoke) zwracają błędy natychmiast; wywołania asynchroniczne (EventBridge, SNS, asynchroniczne powiadomienia S3) korzystają z polityki ponowień asynchronicznych Lambda (dwa ponowienia z backoffem) i mogą używać DLQ lub miejsc docelowych (destinations). W przypadku mapowań źródeł zdarzeń (SQS, Kinesis, DynamoDB streams), poller Lambda ponawia próby, aż wiadomość wygaśnie lub polityka redrive źródła zdarzeń uruchomi przeniesienie do kolejki DLQ. Konfiguruj timeout i pamięć konserwatywnie (aws lambda update-function-configuration –function-name MyFn –timeout 30 –memory-size 1024) i ustaw visibility timeout SQS > timeout funkcji (zalecane visibility >= timeout funkcji * 2), aby zmniejszyć ryzyko podwójnego przetwarzania.

Architektury sterowane zdarzeniami z EventBridge

EventBridge dostarcza zarządzaną magistralę zdarzeń z elastycznym routingiem, rejestrem schematów, dostarczaniem międzykontowym oraz ustawieniami ponowień/DLQ. Używaj niestandardowych magistral zdarzeń do separacji domen, a partnerskich magistral zdarzeń do integracji z SaaS; twórz reguły ze wzorcami (aws events put-rule –name orderEvents –event-pattern file://order-pattern.json –event-bus-name customBus) i dołączaj cele z konfiguracją dead-letter i ponowień (JSON dla celów wspiera DeadLetterConfig i RetryPolicy). Używaj rejestru schematów do odkrywania i egzekwowania struktury zdarzeń; rejestruj schematy, gdy producenci są dobrze zdefiniowani, i używaj Code Bindings do generowania typowanych modeli, gdy jest to pomocne.

Wybierz EventBridge, gdy potrzebujesz:

• Złożonego routingu i filtrowania z bogatymi wzorcami zdarzeń lub izolacji między kontami/magistralami zdarzeń
• Natywnego wsparcia dla wielu celów (Lambda, Step Functions, Kinesis, SQS, SNS)
• Odkrywania schematów i zarządzania nimi w różnych zespołach

Wybierz bezpośrednie połączenie z SNS/SQS, gdy potrzebujesz prostszego fan-outu lub gwarantowanej semantyki kolejki:

• SNS do fan-outu do wielu subskrybentów i semantyki push
• SQS do trwałego przetwarzania opartego na modelu pull z visibility timeout i politykami redrive

Przesyłanie wiadomości za pomocą SNS i SQS (DLQ, visibility timeout)

SNS to usługa pub/sub działająca w modelu push; SQS to trwała kolejka z semantyką pull. Dla przetwarzania o wysokiej niezawodności preferuj wzorzec SNS -> SQS -> Lambda, aby oddzielić przyjmowanie danych od ich przetwarzania i uzyskać kontrolę nad ponowieniami i widocznością. Skonfiguruj politykę redrive SQS (aws sqs set-queue-attributes –queue-url URL –attributes file://redrive.json), aby przenosić wiadomości do DLQ po przekroczeniu maxReceiveCount, i upewnij się, że visibility timeout jest wystarczająco długi, aby uniknąć przedwczesnego ponownego dostarczenia (zalecane visibility >= timeout funkcji * 2). Dla potrzeb FIFO użyj SQS FIFO lub SNS FIFO z ID grup wiadomości (message group ID), aby zachować kolejność, oraz ID deduplikacji (deduplication ID), aby unikać duplikatów.

Opcje obsługi dead-letter i gdzie ich używać:

• Asynchroniczne wywołania Lambda: skonfiguruj DeadLetterConfig lub Destinations (AsyncEventInvokeConfig), aby wysyłać niepowodzenia do SQS/SNS lub wywoływać inną funkcję Lambda.
• SQS: skonfiguruj politykę redrive do kolejki SQS DLQ dla tzw. poison messages i ustaw odpowiedni maxReceiveCount.
• EventBridge: ustaw DeadLetterConfig i RetryPolicy na celach reguł, aby przechwytywać niedostarczalne zdarzenia.

Idempotentność jest kluczowa: implementuj idempotentne handlery, używając zapisów warunkowych w DynamoDB (PutItem z ConditionExpression attribute_not_exists(pk)), tokenów idempotentności przechowywanych z TTL, lub deduplikacji SQS FIFO dla semantyki exactly-once (dokładnie raz).

Uprawnienia funkcji, role i zasada najniższych uprawnień

Stosuj zasadę najniższych uprawnień do ról wykonawczych Lambda i polityk zasobów funkcji. Zacznij od AWSLambdaBasicExecutionRole dla logów CloudWatch, a następnie przyznawaj jawne uprawnienia do ARN-ów zasobów dla usług (np. dynamodb:PutItem na arn:aws:dynamodb:region:acct:table/MyTable). Unikaj symboli wieloznacznych, takich jak Resource: “*”, gdy możliwe jest użycie konkretnych ARN-ów. Używaj zarządzanych lub niestandardowych polityk ograniczonych do akcji i zasobu, i dołączaj warunki (aws:SourceAccount, aws:SourceArn) podczas dodawania uprawnień do wywoływania przez usługi:

• Dodaj uprawnienie do wywołania przez EventBridge: aws lambda add-permission –function-name MyFn –principal events.amazonaws.com –statement-id ev1 –action lambda:InvokeFunction –source-arn arn:aws:events:region:acct:rule/MyRule
• Dla SNS: użyj warunku source-arn, aby ograniczyć, który temat może wywołać funkcję

Kryteria decyzyjne:

• Używaj polityk opartych na zasobach funkcji, aby zezwolić na wywołania przez usługi (EventBridge, SNS, CloudWatch Events)
• Używaj roli wykonawczej IAM do nadawania uprawnień w czasie działania (DynamoDB, S3, Secrets Manager)
• Preferuj uprawnienia na poziomie zasobów i ograniczenia warunkowe, aby zmniejszyć promień rażenia (blast radius)

Obserwowalność i rozwiązywanie problemów w architekturze bezserwerowej

Obserwowalność musi obejmować metryki, logi, ślady (traces) i status dostarczania asynchronicznego. Kluczowe metryki CloudWatch: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (dla wyzwalaczy strumieniowych i SQS). Aby uzyskać wgląd w awarie asynchroniczne, monitoruj metryki “AsyncEventInvoke” i skonfiguruj alarmy CloudWatch dla DeadLetterErrors i Throttles. Włącz śledzenie X-Ray (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active), aby uzyskać kompleksowe ślady (end-to-end traces) między usługami i wizualizować zimne starty, opóźnienia w usługach podrzędnych i wyjątki.

Używaj ustrukturyzowanych logów JSON i zapytań CloudWatch Logs Insights, aby szybko znajdować wzorce błędów; instrumentuj sprawdzanie idempotentności i zapisuj w logach identyfikatory korelacji. W przypadku śledzenia rozproszonego, propaguj jawnie identyfikatory śledzenia w ładunkach zdarzeń dla przepływów EventBridge/SNS, jeśli automatyczny kontekst zostanie utracony. Dla mapowań źródeł zdarzeń SQS monitoruj metrykę ApproximateAgeOfOldestMessage i ustawiaj alarmy, jeśli jej wartość rośnie, co wskazuje na ciśnienie zwrotne (backpressure) lub dławienie (throttling). Przechwytuj i alarmuj na podstawie metryki Lambda Throttles oraz śledź kompromis między wykorzystaniem a kosztem alokowanej współbieżności (provisioned concurrency).

Częste pułapki i kryteria decyzyjne

• Brak konfiguracji kolejek DLQ lub poleganie wyłącznie na domyślnych ponowieniach: skonfiguruj kolejki DLQ lub Destinations dla asynchronicznych funkcji Lambda oraz politykę ponownego dostarczania (redrive) dla kolejek SQS, aby przechwytywać komunikaty zatrute (poison messages) do ręcznej inspekcji.
• Nieprawidłowy limit czasu widoczności (visibility timeout) w SQS prowadzący do zduplikowanego przetwarzania: ustaw limit czasu widoczności na wartość >= 2 * limit czasu wykonania funkcji i uwzględnij ponowienia oraz wywołania usług podrzędnych, aby uniknąć duplikatów.
• Zbyt liberalne role wykonawcze Lambda: unikaj Resource: "*" i dodawaj warunki dotyczące usługi/źródła (aws:SourceArn, aws:SourceAccount) do polityk wywołań i zasobów.
• Ignorowanie limitów współbieżności powodujące dławienie: używaj zarezerwowanej współbieżności (reserved concurrency) do ograniczania funkcji, alokowanej współbieżności (provisioned concurrency) dla funkcji wrażliwych na opóźnienia i monitoruj metryki ConcurrentExecutions/Throttles.
• Brak śledzenia przez granice asynchroniczne: dodawaj identyfikatory korelacji do zdarzeń i włącz X-Ray lub propaguj nagłówki śledzenia, aby zrekonstruować przepływy.
• Niewłaściwe użycie bezpośrednich wywołań SNS do Lambda dla potrzeb trwałości: preferuj architekturę SNS->SQS->Lambda, gdy potrzebujesz trwałego buforowania, kontroli widoczności i łatwiejszej obsługi DLQ.

Problem praktyczny: Scenariusz użycia

Firma AcmePayments otrzymuje dużą liczbę zdarzeń płatniczych przez EventBridge i doświadcza okresowego dławienia funkcji Lambda oraz zduplikowanego przetwarzania w godzinach szczytu. Potrzebują niezawodnego przetwarzania, braku utraty danych i ograniczonego obciążenia podrzędnej bazy danych DynamoDB.

1. Utwórz niestandardową magistralę (bus) EventBridge i regułę dopasowującą zdarzenia płatnicze; dodaj kolejkę SQS FIFO jako trwały cel (target) z DeadLetterConfig i RetryPolicy w konfiguracji celu.
2. Skonfiguruj funkcję Lambda do odpytywania kolejki SQS (mapowanie źródła zdarzeń) z rozmiarem partii (batch size) dostosowanym do przepustowości usług podrzędnych i limitem czasu widoczności (visibility timeout) ustawionym na wartość >= 2 * limit czasu wykonania funkcji.
3. Zarezerwuj współbieżność dla funkcji Lambda (aws lambda put-function-concurrency …), aby ograniczyć gwałtowne wzrosty zapisów do DynamoDB; zaimplementuj alokowaną współbieżność (provisioned concurrency) dla małej puli, jeśli wymagane są niskie opóźnienia.
4. Zaimplementuj idempotentność przy użyciu zapisów warunkowych DynamoDB kluczowanych przez payment-id i przechowuj rekordy idempotentności z TTL w celu ich automatycznego usuwania.
5. Włącz śledzenie X-Ray i ustrukturyzowane logi z identyfikatorem korelacji w zdarzeniu, aby śledzić przetwarzanie; ustaw alarmy CloudWatch na metryki ApproximateAgeOfOldestMessage, Throttles i metryki DLQ.

Uzasadnienie: Oddzielenie EventBridge od SQS zapewnia trwałe buforowanie i semantykę ponowień; zarezerwowana współbieżność chroni podrzędną bazę DynamoDB przed gwałtownymi wzrostami obciążenia, idempotentność zapobiega duplikatom, a śledzenie i alarmy zapewniają widoczność operacyjną trybów awarii.

← Bazy danych i buforowanie · Wszystkie domeny · Zarządzanie kosztami i tagowanie zasobów →

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

Przeglądaj Amazon →