AWS Developer Associate

Ta strona to repetytorium do egzaminu AWS Certified Developer – Associate (DVA-C02). Każdy rozdział odpowiada konkretnym umiejętnościom (skill) z oficjalnego exam guide w wersji 2.1 — ich numery widzisz w znacznikach takich jak 1.2.3. Zamiast listy funkcji dostajesz mechanizmy: jak coś działa, dlaczego tak, i jak egzamin próbuje cię na tym złapać.

Format egzaminu

Domeny i ich waga

Jak czytać rozdziały

Strona ma trzy poziomy. Każdy blok nosi znacznik — L1 podstawy (model mentalny), L2 szczegóły na poziomie egzaminu, L3 rzadkie detale i przypadki brzegowe. Przełącznik głębokości jest w lewym dolnym rogu: głębokość 1 to szybka powtórka całości, głębokość 3 to wszystko.

Mapa kursu

Fakty sprawdzone w oficjalnym exam guide DVA-C02 (wersja 2.1) i dokumentacji AWS w październiku 2026. AWS zmienia limity i funkcje — przed egzaminem zerknij do What's New.

Wyobraź sobie pizzerię. Jeśli kelner stoi przy piecu i czeka, aż pizza się upiecze, zanim przyjmie następne zamówienie, to działa synchronicznie i ściśle powiązany (tight coupling) z kucharzem. Jeśli przypina kartkę z zamówieniem na tablicy i wraca do sali, to działa asynchronicznie, a tablica jest luźnym powiązaniem (loose coupling): kucharz może być wolniejszy, chory albo może ich być trzech — kelnera to nie obchodzi. W AWS tą tablicą jest kolejka (SQS), temat (SNS), szyna zdarzeń (EventBridge), strumień (Kinesis) albo przepływ (Step Functions).

Druga połowa rozdziału to odporność (resilience): co robi Twój kod, gdy usługa, którą woła (AWS albo zewnętrzne API płatności), odpowie błędem, przekroczy czas albo zacznie dławić (throttling). Odpowiedź egzaminu jest prawie zawsze ta sama: timeout + retry z exponential backoff i jitter + limit prób + idempotentność, a przy dłuższej awarii — circuit breaker.

Wzorce architektoniczne, które egzamin nazywa wprost

Retry, exponential backoff i jitter

Exponential backoff = każde kolejne ponowienie czeka dłużej (np. 1×, 2×, 4×, 8× bazowego opóźnienia), z górnym limitem. Jitter = losowy składnik opóźnienia. Bez jitter tysiąc klientów, którzy dostali błąd w tej samej chwili, ponowi w tej samej chwili — usługa dostaje falę („thundering herd”) i znowu pada. AWS SDK używa full jitter: opóźnienie losowane z całego przedziału od 0 do wyliczonej granicy. Najlepsze praktyki Well-Architected: backoff + jitter + maksymalna liczba ponowień, a w systemie wielowarstwowym ponawiaj w jednym miejscu, bo retry na każdej warstwie mnoży ruch.

# ~/.aws/config — dotyczy CLI i wszystkich SDK
[default]
retry_mode = standard
max_attempts = 5

# albo zmienne środowiskowe (mają pierwszeństwo przed plikiem)
export AWS_RETRY_MODE=adaptive
export AWS_MAX_ATTEMPTS=5

Własny kod (np. wywołanie zewnętrznego API płatności, którego SDK AWS nie obsługuje) piszesz według tego samego przepisu. Szkic w Pythonie — „full jitter” to po prostu random.uniform(0, granica):

import random, time

def call_with_retry(fn, max_attempts=5, base=0.1, cap=20.0):
    for attempt in range(max_attempts):
        try:
            return fn(timeout=2.0)                      # zawsze jawny timeout
        except TransientError:                          # 5xx, timeout, 429/throttling
            if attempt == max_attempts - 1:
                raise                                   # limit prób → oddaj błąd (albo DLQ)
            time.sleep(random.uniform(0, min(cap, base * 2 ** attempt)))  # backoff + full jitter
        # błędy 4xx (walidacja, brak uprawnień) NIE są łapane → bez retry

Idempotentność, timeouty i circuit breaker

Idempotentna operacja to taka, której wielokrotne wykonanie daje ten sam efekt co jedno. Analogia: przycisk windy — naciśnięcie go pięć razy nie przywoła pięciu wind. W systemach rozproszonych łatwo o „at most once” albo „at least once”, a „exactly once” robisz przez tokeny idempotencji: usługa pamięta token i na powtórzone żądanie zwraca poprzedni wynik zamiast wykonać akcję drugi raz. Przykłady w AWS: ClientToken w RunInstances (EC2), ClientRequestToken w TransactWriteItems (DynamoDB, token ważny 10 minut), narzędzie Idempotency z Powertools for AWS Lambda (stan trzyma w warstwie persystencji — najczęściej w tabeli DynamoDB, może też w Valkey/Redis). Kolejki standardowe SQS i strumienie dostarczają „at least once”, więc konsument też musi być idempotentny (SQS, Lambda).

Timeouty: ustawiaj jawnie timeout połączenia i żądania; nie polegaj na wartościach domyślnych, bo nie znają Twojego obciążenia. Za wysoki timeout wiąże zasoby (wątki, połączenia, czas Lambdy, za który płacisz), za niski generuje sztuczne błędy. Klasyk egzaminu: Lambda z timeoutem 15 min czeka na zawieszone API — ustaw krótszy timeout klienta HTTP niż timeout funkcji.

Circuit breaker (bezpiecznik): jeśli wywołania do zależności powtarzalnie kończą się błędem/timeoutem, wołający przestaje ją wołać na pewien czas (obwód otwarty — szybki błąd albo fallback), potem przepuszcza próbne wywołanie (half-open), a gdy się uda — wraca do normalnego stanu (zamknięty). Retry jest na krótkie, przejściowe błędy; circuit breaker — na dłuższą awarię, żeby nie dobijać leżącej usługi i nie marnować własnych zasobów. W AWS implementuje się go np. w Step Functions + stan obwodu w DynamoDB.

IAM działa jak ochrona w biurowcu. Masz identyfikator (principal: użytkownik IAM, rola, sesja roli, usługa AWS), a przy każdych drzwiach strażnik sprawdza listy: tę przypiętą do Ciebie (identity-based policy — „co ta osoba może”) i tę wiszącą na drzwiach (resource-based policy — „kto może tu wejść”). Domyślnie odpowiedź brzmi nie (implicit deny). Wystarczy jedno wyraźne „wolno” (Allow) na którejś liście, ale jedno wyraźne „zakaz” (explicit Deny) gdziekolwiek przekreśla wszystko.

Aplikacje nie powinny mieć „swoich” kluczy. Zamiast tego przyjmują rolę (assume role): dostają tymczasowe poświadczenia z STS na określony czas. Rola ma dwie polityki: trust policy (kto może ją przyjąć — np. lambda.amazonaws.com albo konto 222233334444) i permissions policy (co wolno po jej przyjęciu).

Typy polityk i jak się składają

// Trust policy roli dla zewnętrznej firmy (konto 999988887777)
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::999988887777:root" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "a1b2c3-unikalne-dla-klienta" } }
  }]
}

Elementy polityki, warunki i zmienne

Polityka to JSON z Version (zawsze "2012-10-17" — tylko ta wersja języka obsługuje policy variables) i listą Statement: Sid, Effect (Allow/Deny), Principal (tylko w resource-based), Action/NotAction, Resource/NotResource, Condition. NotAction dopasowuje wszystko oprócz wymienionych akcji — z Allow łatwo przyznać za dużo.

Operatory: StringEquals/StringLike (z * i ?), ArnLike, IpAddress, DateGreaterThan, Bool, NumericLessThan, Null (czy klucz istnieje). Sufiks …IfExists = „sprawdź, jeśli klucz jest w żądaniu”. Dla kluczy wielowartościowych: ForAllValues: (każda wartość z żądania musi pasować) i ForAnyValue: (co najmniej jedna). Jeśli klucza nie ma w kontekście żądania, warunek jest fałszywy (poza …IfExists i Null) — z wyjątkiem operatorów zaprzeczających (np. StringNotEquals, ArnNotLike), dla których brak klucza daje prawdę. Przykład 2.1.7: w DynamoDB ForAllValues:StringEquals na dynamodb:LeadingKeys = ${www.amazon.com:user_id} lub ${cognito-identity.amazonaws.com:sub} daje każdemu użytkownikowi dostęp tylko do jego partycji (DynamoDB, Cognito).

Role, sesje i dostęp między kontami

Czas sesji roli: DurationSeconds od 900 s (15 min) do ustawienia maximum session duration roli (1–12 h); bez parametru — 1 godzina. Tożsamość sesji widzisz jako arn:aws:sts::111122223333:assumed-role/NazwaRoli/NazwaSesji.

Narzędzia najmniejszych uprawnień

Każde wywołanie API AWS jest podpisane (Signature Version 4) kluczem, który należy do jakiejś tożsamości. Ani CLI, ani SDK nie zgadują — przeszukują po kolei listę miejsc, w których mogą leżeć poświadczenia, i biorą pierwsze znalezione. To credential provider chain. Analogia: szukasz kluczy do domu — najpierw w dłoni, potem w kieszeni, potem w torbie, na końcu na haczyku przy drzwiach. Jeśli w kieszeni leżą stare klucze od poprzedniego mieszkania, nigdy nie dojdziesz do haczyka.

Na egzaminie liczy się kolejność tego łańcucha, różnica między kluczami długoterminowymi (IAM user) i tymczasowymi (STS: rola, sesja), to, jak kod na EC2/Lambda/ECS dostaje rolę bez żadnych kluczy, oraz kilka praktycznych przełączników CLI.

Pliki konfiguracyjne, profile i zmienne środowiskowe

# ~/.aws/credentials — sekrety (aws configure)
[default]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

# ~/.aws/config — ustawienia; profile poza default mają prefiks "profile "
[default]
region = eu-central-1
output = json

[profile prod-admin]
role_arn = arn:aws:iam::123456789012:role/Admin
# skąd wziąć poświadczenia do AssumeRole
source_profile = default
# opcjonalnie: wymagaj kodu MFA
mfa_serial = arn:aws:iam::111122223333:mfa/jan

[profile ci-on-ec2]
role_arn = arn:aws:iam::123456789012:role/Deploy
# bazą jest instance profile
credential_source = Ec2InstanceMetadata

STS: tymczasowe poświadczenia

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/Admin \
    --role-session-name jan --serial-number arn:aws:iam::111122223333:mfa/jan --token-code 123456

aws sts decode-authorization-message --encoded-message <zakodowany-tekst> \
    --query DecodedMessage --output text

EC2: IMDSv2 i instance profile

Instance Metadata Service odpowiada pod 169.254.169.254; poświadczenia roli leżą pod /latest/meta-data/iam/security-credentials/<rola>. IMDSv2 jest sesyjny: token z PUT, ważny od 1 s do 6 h. HttpTokens = optional (v1 i v2) albo required (tylko v2). HttpPutResponseHopLimit (1–64) ogranicza, ile skoków sieciowych może przejść odpowiedź z tokenem — w kontenerach na EC2 z hop limit 1 wywołanie może nie dostać odpowiedzi; rozwiązaniem bywa hop limit 2. Ruch do IMDS nie jest filtrowany przez security groups.

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
          -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
     http://169.254.169.254/latest/meta-data/iam/security-credentials/

SigV4, paginacja, waitery, throttling

Przełączniki CLI, które pojawiają się w pytaniach

Dostęp deweloperów: IAM Identity Center i CloudShell

IAM Identity Center (dawniej AWS SSO) to zalecany sposób dawania ludziom dostępu do wielu kont: logowanie przez portal, permission sets mapowane na role w kontach. W CLI: aws configure sso (zapisuje sso_session, sso_start_url, sso_region w ~/.aws/config), potem aws sso login pobiera tymczasowe poświadczenia — zero kluczy w plikach. AWS CloudShell to powłoka w przeglądarce, z poświadczeniami zalogowanego użytkownika konsoli, preinstalowanym CLI, 1 GB trwałego miejsca na region (dane usuwane po 120 dniach bez sesji) i wygasaniem po 20–30 minutach bezczynności.

VPC to Twoje prywatne osiedle w regionie AWS. Podsieci (subnets) to ulice — każda w jednej strefie dostępności (AZ). Ulica jest publiczna, jeśli jej tablica tras (route table) prowadzi ruch 0.0.0.0/0 do Internet Gateway (IGW) — bramy osiedla. Ulica jest prywatna, jeśli takiej trasy nie ma. Mieszkańcy prywatnej ulicy mogą wychodzić „na miasto” tylko przez NAT gateway — portiernię, która stoi na ulicy publicznej, wypuszcza ruch wychodzący i wpuszcza wyłącznie odpowiedzi, nigdy nowe połączenia z zewnątrz.

Domyślnie Lambda działa poza Twoim VPC i ma dostęp do internetu. Gdy podłączysz ją do VPC (żeby sięgnąć do RDS, ElastiCache czy prywatnego API), widzi tylko to, co jest w VPC. Do internetu i publicznych endpointów AWS (S3, DynamoDB, SQS…) potrzebuje wtedy NAT gateway albo VPC endpointów.

Jak Lambda „wchodzi” do VPC: Hyperplane ENI

Lambda nie dostaje ENI na każde wywołanie (tak było dawno temu — stąd stara lore o „zimnych startach w VPC”). Obecnie tworzy Hyperplane ENI dla każdej kombinacji podsieć + security group, współdzielonej przez funkcje o tej samej konfiguracji; jedna obsługuje do 65 000 połączeń/portów, a przy większym ruchu Lambda dokłada kolejne. Nowa funkcja jest w stanie Pending, dopóki ENI nie jest gotowa (może to potrwać kilka minut). Po 14 dniach bezczynności Lambda odzyskuje ENI i funkcja przechodzi w Inactive — następne wywołanie się nie powiedzie, a funkcja wraca do Pending. Po odłączeniu od VPC usunięcie ENI trwa do 20 minut. Polityki IAM mogą wymuszać konfigurację VPC kluczami lambda:VpcIds, lambda:SubnetIds, lambda:SecurityGroupIds.

Security group vs Network ACL

VPC Flow Logs

Flow log można włączyć dla VPC, podsieci lub ENI. Rekord to m.in. adresy, porty, protokół, liczba bajtów/pakietów i action = ACCEPT/REJECT (odrzucenie przez SG lub NACL). Cel: CloudWatch Logs (dostarczenie zwykle ok. 5 min), S3 (ok. 10 min) lub Data Firehose. Nie zawierają treści pakietów i nie rejestrują m.in. ruchu do Amazon DNS ani do metadanych 169.254.169.254. Typowe pytanie: „połączenie z Lambdy do bazy się nie udaje — jak sprawdzić, czy ruch jest odrzucany?” → flow logs, szukaj REJECT.

Load balancer to recepcjonistka w przychodni: przyjmuje pacjentów pod jednym numerem i rozsyła ich do wolnych gabinetów. Co pół minuty puka do każdego gabinetu („zdrów?”) — to health check. Gabinet, który kilka razy z rzędu nie odpowie, przestaje dostawać pacjentów; gdy znów zacznie odpowiadać kilka razy z rzędu, wraca do grafiku. Auto Scaling to kierownik, który dostawia i zabiera gabinety zależnie od kolejki, a Route 53 to książka telefoniczna miasta, która może wskazywać różne przychodnie w zależności od tego, skąd dzwonisz i która przychodnia jest otwarta.

Rodzaje load balancerów: ALB (warstwa 7: HTTP/HTTPS/gRPC, routing po ścieżce, hoście, nagłówkach; cele: instancje, IP, Lambda), NLB (warstwa 4: TCP/UDP/TLS, ogromna przepustowość, statyczne IP / Elastic IP per AZ) i GWLB (warstwa 3: przepuszcza ruch przez wirtualne appliance’y — firewalle, IDS — z enkapsulacją GENEVE na porcie 6081). Classic Load Balancer to poprzednia generacja.

ALB vs NLB vs GWLB

Uwierzytelnianie na ALB (authenticate-cognito/authenticate-oidc) działa tylko na listenerze HTTPS — patrz Cognito. Lambda jako cel ALB dostaje zdarzenie z nagłówkami (opcjonalnie multiValueHeaders) i musi zwrócić obiekt ze statusCode.

Atrybuty target group, które warto znać

Kody błędów ALB (pytania troubleshootingowe)

Auto Scaling

ASG utrzymuje desired capacity między min a max i równoważy instancje między AZ (przy terminacji balans AZ ma pierwszeństwo). Konfiguracja instancji: launch template (wersjonowany). Stara lore: launch configuration — od 1 stycznia 2023 nie obsługuje nowych typów instancji, a konta utworzone od 1 października 2024 nie mogą tworzyć nowych launch configurations żadną metodą; w starszych testach wciąż występuje jako poprawna opcja.

Route 53: rekordy, alias, routing, health checks

Alias vs CNAME: alias to rozszerzenie Route 53 wskazujące zasoby AWS (ELB, CloudFront, API Gateway, S3 website, VPC endpoint, inny rekord w strefie); działa na zone apex (example.com), zapytania do zasobów AWS są bezpłatne, TTL ustala AWS. CNAME nie może być na zone apex i jest płatny. Rekordy: A (IPv4), AAAA (IPv6), CNAME, MX, TXT, NS, SOA… TTL to czas cache’owania odpowiedzi przez resolvery — krótki przed migracją. Private hosted zone odpowiada tylko w powiązanych VPC.

Health checks Route 53: monitorują endpoint (HTTP/HTTPS/TCP; HTTP/HTTPS zdrowy, gdy połączenie TCP nawiąże się w 4 s, a endpoint odpowie kodem 2xx/3xx w ciągu kolejnych 2 s; dla samego TCP wystarczy połączenie w 10 s; opcjonalnie szukany tekst w pierwszych 5 120 bajtach odpowiedzi), inny health check (calculated) albo alarm CloudWatch. Endpoint jest zdrowy, gdy > 18% checkerów raportuje „healthy”. Interwał 30 s albo 10 s (fast, dodatkowo płatny), plus failure threshold. Nie da się sprawdzić prywatnego IP — dla zasobów prywatnych użyj health checku na alarmie CloudWatch.

EC2 (Elastic Compute Cloud) to wirtualna maszyna, którą wynajmujesz na godziny albo sekundy. Wybierasz typ instancji (ile vCPU i pamięci), AMI (Amazon Machine Image, czyli obraz dysku z systemem), sieć (podsieć, security group) i dyski. Resztą, czyli systemem, łatkami i aplikacją, zajmujesz się sam. To najbardziej „ręczna” opcja compute w tej części.

Analogia: EC2 to wynajęte mieszkanie. Dostajesz klucze (key pair), umeblowanie wybierasz sam (AMI), a user data to kartka „co zrobić po wprowadzeniu się”, wykonywana przy pierwszym uruchomieniu. Dyski to trzy rodzaje szaf. EBS to szafa, którą zabierasz przy przeprowadzce. Instance store to szafa wbudowana w mieszkanie, która przepada, gdy się wyprowadzisz. EFS to wspólna piwnica dla całego bloku.

Instancja od środka: AMI, typ, user data, metadata

AMI to szablon dysku startowego i jest zasobem regionalnym. Żeby uruchomić tę samą konfigurację w innym regionie, kopiujesz AMI (CopyImage, „Copy AMI”). Własny AMI z zainstalowaną aplikacją („golden image”) skraca start instancji w Auto Scaling, bo nie trzeba niczego doinstalowywać w user data.

Key pair: AWS przechowuje klucz publiczny (trafia do ~/.ssh/authorized_keys), a klucz prywatny masz tylko Ty. Zgubisz go, to go nie odzyskasz.

# IMDSv2: token (TTL max 21600 s = 6 h), potem zapytanie
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

Szczegóły IMDS i user data

Storage: EBS, instance store, EFS

Stare pytania: do września 2025 gp3 miał limit 16 TiB, 16 000 IOPS i 1 000 MiB/s. W testach próbnych możesz spotkać „potrzebujesz ponad 16 000 IOPS, więc io2”. Dziś gp3 sięga 80 000 IOPS, ale io2 nadal jest odpowiedzią na „najniższa, stała latencja” i „Multi-Attach”.

Szyfrowanie EBS (KMS) obejmuje dane w spoczynku na wolumenie, ruch między wolumenem a instancją, snapshoty i wolumeny odtworzone ze snapshotów. Szyfrowania nie da się zdjąć. Klucza KMS istniejącego wolumenu nie zmienisz. Żeby zaszyfrować niezaszyfrowany wolumen lub zmienić klucz: snapshot, potem kopia snapshotu z szyfrowaniem, potem nowy wolumen. Możesz też włączyć „encryption by default” dla regionu.

Multi-Attach działa tylko dla io1/io2: do 16 instancji Nitro w tej samej AZ. Pytanie o wspólny dysk dla wielu AZ to zawsze EFS.

Monitorowanie i rozmiar instancji

Domyślnie (basic monitoring) EC2 wysyła metryki co 5 minut za darmo (status checks co minutę). Detailed monitoring daje okresy 1-minutowe za dodatkową opłatą. Metryki z hypervisora to m.in. CPUUtilization, ruch sieciowy i operacje dyskowe. Pamięć i wolne miejsce na dysku widzi tylko system operacyjny, więc zbiera je CloudWatch agent (metryki in-guest, logi, StatsD/collectd). Szczegóły w rozdziale o metrykach.

Instancje T (burstable) mają bazową wydajność CPU i zbierają kredyty CPU. W trybie standard po wyczerpaniu kredytów spadają do bazy, w trybie unlimited burstują dalej za dopłatą. Metryka CPUCreditBalance spada do zera, a aplikacja zwalnia? Typowe rozwiązania to unlimited albo zmiana typu (np. M).

Opcje zakupu: On-Demand (płatność za sekundę), Savings Plans i Reserved Instances (zobowiązanie na 1 lub 3 lata), Spot (wolne moce, duża zniżka, ostrzeżenie 2 minuty przed przerwaniem), Dedicated Hosts/Instances, Capacity Reservations (rezerwacja pojemności w AZ).

Elastic Beanstalk to „PaaS” zbudowany z klocków AWS. Wrzucasz paczkę z kodem (source bundle, np. ZIP), wybierasz platformę (Node.js, Python, Java, Docker…), a Beanstalk tworzy za Ciebie EC2, Auto Scaling group, load balancer, security groups, alarmy i logi. Same zasoby nadal należą do Ciebie i widzisz je w konsoli. Beanstalk tylko je orkiestruje (pod spodem przez CloudFormation).

Analogia: Beanstalk to firma przeprowadzkowa z ekipą. Mówisz „to jest mój dobytek (kod), mieszkanie ma mieć 2–6 pokoi (instancje)”, a oni wnoszą meble. Polityka wdrożenia mówi, jak wymieniają meble przy kolejnej dostawie: wszystko naraz (przez chwilę nie ma gdzie usiąść), pokój po pokoju, z dodatkowym pokojem na czas wymiany albo w zupełnie nowym mieszkaniu obok.

Słownik: aplikacja to kontener na wszystko. Wersja aplikacji (application version) to konkretna paczka kodu w S3. Środowisko (environment) to działający zestaw zasobów z jedną wersją. Środowisko ma tier: web server (HTTP za load balancerem) albo worker (czyta zadania z kolejki SQS). Tieru nie da się zmienić po utworzeniu środowiska.

Polityki wdrożeń: dokładne zachowanie

# .ebextensions/deploy.config
option_settings:
  aws:elasticbeanstalk:command:
    DeploymentPolicy: Rolling        # AllAtOnce | Rolling | RollingWithAdditionalBatch | Immutable | TrafficSplitting
    BatchSizeType: Percentage
    BatchSize: 25
  aws:elasticbeanstalk:trafficsplitting:   # tylko dla TrafficSplitting
    NewVersionPercent: "15"
    EvaluationTime: "10"

Ustawienia wdrożeń z namespace aws:elasticbeanstalk:command: Timeout (domyślnie 600 s; Beanstalk dolicza wewnętrznie 240 s), IgnoreHealthCheck (domyślnie false; true oznacza, że wdrożenie nie jest anulowane przez nieudane health checki), Healthy threshold (próg zdrowia; można go obniżyć np. do Warning). Uwaga: DeploymentPolicy ustawiona przez konsolę oraz BatchSize i BatchSizeType ustawione przez konsolę lub EB CLI przy tworzeniu środowiska nadpisują to, co jest w plikach konfiguracyjnych.

Rolling deployments (nowa wersja aplikacji) to co innego niż rolling updates, czyli zmiany konfiguracji wymagające wymiany instancji (np. typ instancji). Te drugie konfiguruje namespace aws:autoscaling:updatepolicy:rollingupdate, a mogą być też immutable. Immutable update wymaga enhanced health reporting.

Blue/green jest też wymagany przy przejściu na niekompatybilną wersję platformy (np. nowa gałąź). Środowiska nie mogą wtedy współdzielić bazy utworzonej przez Beanstalk, bo ta należy do jednego z nich.

Struktura paczki: .ebextensions, .platform, Procfile

my-app.zip
├── app.py / package.json / ...
├── Procfile                 # web: gunicorn app:app   (proces "web" dostaje ruch z proxy)
├── Buildfile                # krótkie komendy budujące
├── cron.yaml                # tylko worker: zadania okresowe
├── .ebextensions/
│   ├── 01-packages.config   # pliki wykonywane alfabetycznie
│   └── 02-options.config
└── .platform/
    ├── nginx/conf.d/my.conf # nadpisanie konfiguracji proxy
    ├── hooks/prebuild/      # skrypty (chmod +x) przy wdrożeniu aplikacji
    ├── hooks/predeploy/
    ├── hooks/postdeploy/
    └── confighooks/...      # te same etapy przy wdrożeniu samej konfiguracji

# .ebextensions/db-migrate.config
container_commands:
  01_migrate:
    command: "python manage.py migrate"
    leader_only: true
option_settings:
  aws:elasticbeanstalk:application:environment:
    DB_HOST: mydb.abc123.eu-central-1.rds.amazonaws.com

Duplikat klucza (np. dwa razy option_settings) w tym samym pliku spowoduje odrzucenie jednej sekcji. Pliki muszą mieć rozszerzenie .config i poprawny YAML (wcięcia spacjami).

Worker environment i cron.yaml

Analogia: worker to zaplecze restauracji. Kelner (web tier) wrzuca kartkę z zamówieniem do okienka (kolejka SQS), a kucharz (demon sqsd) zdejmuje kartkę i woła kucharza-aplikację: „POST, tu masz zamówienie”. Kiedy aplikacja odpowie 200 OK, kartka trafia do kosza (DeleteMessage). Jeśli nie odpowie, kartka wraca do okienka po czasie widoczności.

# cron.yaml (w katalogu głównym paczki workera)
version: 1
cron:
 - name: "backup-job"        # unikalna nazwa
   url: "/backup"            # ścieżka POST
   schedule: "0 */12 * * *"  # wyrażenie cron, UTC

Zadanie okresowe wrzuca do kolejki tylko lider wybierany przez zapis do tabeli DynamoDB, więc zadanie nie dubluje się na każdej instancji. Obsłużyć je może dowolna instancja. Przy istniejącej kolejce FIFO zadania okresowe nie są obsługiwane. Demon ustawia nagłówki X-Aws-Sqsd-Msgid, X-Aws-Sqsd-Queue, X-Aws-Sqsd-Receive-Count, X-Aws-Sqsd-Attr-*, a User-Agent to aws-sqsd. Przy autogenerowanej kolejce DLQ jest włączona domyślnie.

Konfiguracja, wersje, baza danych

Kolejność ważności (od najwyższej): ustawienia zastosowane bezpośrednio na środowisku (konsola, EB CLI, AWS CLI, SDK, w tym „recommended values” wstawiane przez konsolę), potem saved configuration, potem pliki .ebextensions (alfabetycznie), na końcu wartości domyślne. Dlatego „zmieniłem MinSize w .ebextensions i nic się nie stało” zwykle oznacza, że ktoś ustawił tę wartość w konsoli.

Saved configuration to zapis konfiguracji środowiska w S3 (YAML). Używasz go do tworzenia kolejnych środowisk z tymi samymi ustawieniami (eb config save zapisuje lokalnie do .elasticbeanstalk/saved_configs/). Plik env.yaml w paczce (environment manifest) może m.in. nadać nazwę środowisku i wskazać stos.

Lifecycle policy wersji: każde wdrożenie z konsoli lub EB CLI tworzy wersję w S3. Po przekroczeniu limitu (1 000 wersji w regionie) nie wdrożysz nowej. Polityka usuwa wersje według liczby (max count) albo wieku (max age), maksymalnie 100 przy jednym uruchomieniu. Nie usuwa wersji używanych przez środowiska. Opcjonalnie kasuje też source bundle z S3 (domyślnie paczka zostaje).

RDS: baza dodana w konsoli Beanstalk jest częścią środowiska. Terminate środowiska = utrata bazy (chyba że zadziała deletion policy: Snapshot, Delete albo Retain). Na produkcji tworzysz RDS niezależnie i przekazujesz endpoint przez właściwości środowiska (option_settings lub konsola), a hasło najlepiej przez Secrets Manager. Beanstalk dla zintegrowanej bazy ustawia zmienne RDS_HOSTNAME, RDS_PORT, RDS_DB_NAME, RDS_USERNAME, RDS_PASSWORD.

EB CLI: eb init (projekt), eb create (środowisko), eb deploy (nowa wersja; --staged wdraża pliki z indeksu git, --label nadaje etykietę), eb swap (zamiana CNAME), eb config save. Docker: wystarczy Dockerfile albo Dockerrun.aws.json v1 (gotowy obraz z rejestru), a dla wielu kontenerów platforma „ECS managed Docker”. Rozmiar instancji (CPU, pamięć) zmieniasz typem instancji: opcja InstanceTypes w namespace aws:ec2:instances (starsza InstanceType w aws:autoscaling:launchconfiguration jest oznaczona jako przestarzała).

AWS Lambda uruchamia Twój kod (funkcję) w odpowiedzi na zdarzenie, bez serwerów do zarządzania. Płacisz za liczbę wywołań i czas trwania (w milisekundach, proporcjonalnie do skonfigurowanej pamięci). Funkcja ma handler, czyli punkt wejścia (np. app.lambda_handler), który dostaje dwa argumenty: event (dane zdarzenia, JSON) i context (informacje o wywołaniu i środowisku).

Analogia: Lambda to food truck na żądanie. Gdy przychodzi zamówienie, a żaden truck nie stoi pod ręką, trzeba go przywieźć, rozpalić grill i rozłożyć składniki. To cold start (faza INIT). Kolejne zamówienia obsługuje już rozgrzany truck (warm start). Rozłożone składniki, czyli wszystko, co zrobiłeś poza handlerem (klienci SDK, połączenia z bazą), zostają na kolejne zamówienia. Gdy zamówień przybywa szybciej, niż truck nadąża, AWS podstawia kolejne trucki: każdy obsługuje jedno zamówienie naraz, a liczba trucków w danej chwili to concurrency.

Typy wywołań i kto ich używa

# synchronicznie (CLI v2 wymaga --cli-binary-format dla surowego JSON)
aws lambda invoke --function-name my-fn \
  --cli-binary-format raw-in-base64-out \
  --payload '{"key":"value"}' response.json
# { "StatusCode": 200, "ExecutedVersion": "$LATEST" }

# asynchronicznie
aws lambda invoke --function-name my-fn --invocation-type Event \
  --cli-binary-format raw-in-base64-out --payload '{"key":"value"}' response.json
# { "StatusCode": 202 }

InvocationType przyjmuje RequestResponse, Event albo DryRun. DryRun tylko sprawdza parametry i uprawnienia, bez uruchamiania funkcji. --log-type Tail (tylko sync) zwraca w odpowiedzi ostatnie 4 KB logu zakodowane base64. Przy wywołaniu przez alias odpowiedź zawiera ExecutedVersion, czyli wersję, która faktycznie obsłużyła żądanie.

Cykl życia środowiska wykonawczego

Jeśli funkcja padnie lub przekroczy timeout w trakcie INVOKE, Lambda resetuje środowisko (zachowuje się to jak Shutdown), a kolejne wywołanie robi ponowny INIT („suppressed init”, doliczany do czasu wywołania). Reset nie czyści /tmp.

Rozliczanie INIT: od 1 sierpnia 2025 faza INIT jest rozliczana dla wszystkich konfiguracji, także dla funkcji ZIP na zarządzanych runtime'ach, gdzie wcześniej była darmowa. W starszych materiałach przeczytasz, że „cold start w ZIP jest za darmo”. Dziś to już nieaktualne.

import os, boto3
s3 = boto3.client("s3")              # INIT: raz na środowisko, potem reuse
TABLE = os.environ["TABLE_NAME"]     # konfiguracja ze zmiennych środowiskowych

def lambda_handler(event, context):  # INVOKE: przy każdym wywołaniu
    left = context.get_remaining_time_in_millis()
    print(context.aws_request_id, context.function_name, left)
    return {"statusCode": 200, "body": "ok"}

Limity, które musisz znać na pamięć

Stare limity w testach próbnych: async payload 256 KB (od października 2025 jest 1 MB), streaming 20 MB (od lipca 2025 jest 200 MB), storage kodu 75 GB (dziś 300 GB). Jeśli pytanie zakłada stary limit („plik 500 KB przez SNS do Lambdy”), wybierz rozwiązanie z S3 i przekazaniem klucza, bo nadal jest poprawne. Uwaga: sama wiadomość SNS wciąż ma limit 256 KB.

Uprawnienia: kto co może

# pozwól S3 (tylko z tego bucketu i konta) wywołać funkcję
aws lambda add-permission --function-name my-fn \
  --statement-id s3-invoke --action lambda:InvokeFunction \
  --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::my-bucket --source-account 111122223333

Zasada: przy push (S3, SNS, API Gateway wywołują funkcję) potrzebna jest resource-based policy funkcji. Przy pull (event source mapping czyta SQS lub Kinesis) potrzebna jest execution role z prawem odczytu źródła. Nie wywołuj ręcznie sts:AssumeRole na roli wykonawczej. Lambda przyjmuje ją sama, a klucze tymczasowe trafiają do zarezerwowanych zmiennych środowiskowych (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN), skąd SDK je odczytuje.

Błędy wywołania: co widzi klient

W Lambdzie ustawiasz kilka parametrów i one decydują o wszystkim. Pamięć to jedyne pokrętło mocy (CPU rośnie razem z nią). Timeout to bezpiecznik. Zmienne środowiskowe to konfiguracja. Warstwy i rozszerzenia to dodatki. Wersje i aliasy to bezpieczne wdrażanie. Concurrency to ile kopii funkcji może działać naraz.

Analogia do concurrency: konto ma parking na 1 000 miejsc wspólny dla wszystkich funkcji. Reserved concurrency to miejsca z tabliczką „tylko dla funkcji X”: nikt inny ich nie zajmie, ale X też nie zaparkuje więcej. Provisioned concurrency to samochody, które już stoją na tych miejscach z włączonym silnikiem (środowiska po INIT), więc ruszają natychmiast, bez cold startu. Płacisz za nie, nawet gdy stoją.

Pamięć, CPU, timeout, /tmp

Pamięć ustawiasz od 128 MB do 10 240 MB co 1 MB. CPU rośnie proporcjonalnie, a przy 1 769 MB funkcja ma równowartość jednego vCPU. Ponieważ płacisz za GB-sekundy, więcej pamięci często obniża koszt: funkcja kończy się szybciej. Optimum znajdziesz narzędziem Lambda Power Tuning (uruchamia funkcję z różnymi ustawieniami przez Step Functions) albo dzięki rekomendacjom Compute Optimizer (tylko x86_64). Metryka Max Memory Used w linii REPORT pokazuje, ile pamięci naprawdę zużyto.

Timeout: 1–900 s, domyślnie 3 s. Ephemeral storage /tmp: 512–10 240 MB, tymczasowy i unikalny dla każdego środowiska. Do współdzielenia plików między wywołaniami i funkcjami służy EFS.

Zmienne środowiskowe i szyfrowanie

Zmienne definiujesz na $LATEST. Przy publikacji wersji zostają w niej zamrożone. Klucze zaczynają się od litery i mają co najmniej 2 znaki. Łączny rozmiar to 4 KB. Lambda ustawia też zmienne zarezerwowane, których nie nadpiszesz, np. AWS_REGION, _HANDLER, AWS_LAMBDA_FUNCTION_NAME, AWS_LAMBDA_FUNCTION_MEMORY_SIZE, AWS_LAMBDA_INITIALIZATION_TYPE (on-demand, provisioned-concurrency, snap-start…) oraz poświadczenia roli AWS_ACCESS_KEY_ID/AWS_SESSION_TOKEN.

Warstwy, rozszerzenia, obrazy kontenerów

Layer to archiwum ZIP z bibliotekami, runtime'em lub danymi, rozpakowywane do /opt. Runtime'y mają już w ścieżkach odpowiednie katalogi: python/ (lub python/lib/python3.x/site-packages), nodejs/node_modules. Funkcja może mieć do 5 warstw, a łączny rozmiar po rozpakowaniu (funkcja + warstwy) to 250 MB. Wersje warstwy są niezmienne. Kolejność dodania warstw to kolejność, w jakiej Lambda scala ich zawartość (można ją zmienić: „Merge earlier/later”). Warstwy działają tylko z funkcjami ZIP. Udostępnienie innemu kontu: AddLayerVersionPermission (konsument potrzebuje lambda:GetLayerVersion).

Extensions to procesy działające obok funkcji w tym samym środowisku (np. agenci monitoringu, cache sekretów). Zewnętrzne są osobnymi procesami z /opt/extensions/, zwykle dostarczanymi jako warstwa, i mogą działać po zwróceniu odpowiedzi. Wewnętrzne działają w procesie runtime (wrapper scripts, JAVA_TOOL_OPTIONS). Współdzielą CPU, pamięć i timeout z funkcją. Ile dokładają, pokaże metryka PostRuntimeExtensionsDuration.

Obraz kontenera: budujesz obraz (do 10 GB) i wypychasz go do Amazon ECR. Obraz musi implementować Lambda Runtime API: AWS base images mają wbudowany runtime interface client (RIC), a do lokalnych testów runtime interface emulator (RIE). Obraz celuje w jedną architekturę (x86_64 albo arm64) i działa na systemie plików tylko do odczytu (poza /tmp). Warstw nie dodasz, wszystko pakujesz w obraz. Rola funkcji (lub polityka repozytorium) potrzebuje ecr:BatchGetImage i ecr:GetDownloadUrlForLayer.

Wersje i aliasy

Analogia: wersja to zdjęcie przepisu w danym dniu (już się nie zmieni), $LATEST to brudnopis, a alias prod to karteczka „gotujemy według zdjęcia nr 7”. Wdrożenie polega na przesunięciu karteczki, a rollback na przesunięciu jej z powrotem. Klienci (API Gateway, triggery) wskazują alias, więc niczego u nich nie zmieniasz.

Po opublikowaniu wersji jej kod, runtime, architektura, pamięć, warstwy i większość ustawień są niezmienne. Na wersji możesz nadal konfigurować m.in. triggery, destinations, provisioned concurrency i ustawienia async. Przy weighted alias metryki CloudWatch filtrujesz wymiarem ExecutedVersion, a w logach linia START pokazuje wersję. Ruch jest dzielony probabilistycznie, więc przy małym ruchu proporcje mogą odbiegać od ustawionych.

Concurrency: reserved, provisioned, limity konta

Wzór: concurrency = (żądania na sekundę) × (średni czas trwania w sekundach). 100 req/s × 0,5 s = 50 równoległych środowisk. 5 000 req/s × 0,2 s = 1 000.

• Zarezerwować możesz najwyżej pulę konta minus 100. Te 100 jednostek zawsze zostaje dla funkcji bez rezerwacji.
• Provisioned concurrency nie może przekroczyć reserved concurrency (jeśli obie są ustawione). Gdy suma provisioned na wersjach i aliasach równa się reserved, $LATEST zostanie wstrzymany (throttle).
• Tempo skalowania: każda funkcja może dokładać 1 000 środowisk co 10 sekund (albo 10 000 req/s co 10 s), aż do limitu konta.
• Throttling przy async nie gubi zdarzeń: wracają do kolejki i są ponawiane do 6 godzin. Przy sync klient dostaje 429 i sam musi ponowić.

SnapStart

Analogia: zamiast rano rozpalać grill od zera, robisz zdjęcie gotowej, rozgrzanej kuchni i przy kolejnych zamówieniach „teleportujesz” się do tego stanu. Przy publikacji wersji Lambda robi INIT, zapisuje snapshot pamięci i dysku, a nowe środowiska wznawia ze snapshotu (faza RESTORE).

Function URL i response streaming

Function URL to stały endpoint HTTPS https://<url-id>.lambda-url.<region>.on.aws przypięty do aliasu albo $LATEST (nie do numerowanej wersji). To najprostszy sposób na webhook czy proste API bez API Gateway. Nie daje jednak tego, co API Gateway: kluczy API z planami użycia, autoryzatorów Lambda i Cognito, walidacji i mapowania żądań, cache, kolejkowania i throttlingu żądań, WebSocketów. CORS konfigurujesz na samym URL.

Od października 2025 nowe Function URL wymagają obu akcji: lambda:InvokeFunctionUrl i lambda:InvokeFunction. Starsze materiały pokazują tylko InvokeFunctionUrl. Ograniczenie ruchu na URL ustawiasz przez reserved concurrency (maksymalne RPS = 10 × reserved). Przekroczenie daje HTTP 429.

Response streaming: funkcja wysyła odpowiedź kawałkami, co skraca time-to-first-byte i pozwala na odpowiedzi do 200 MB (pierwsze 6 MB bez limitu, potem 2 MBps). Działa przez Function URL z InvokeMode=RESPONSE_STREAM (domyślnie BUFFERED, max 6 MB) albo API InvokeWithResponseStream. Natywnie wspierają to runtime'y Node.js, a inne języki przez custom runtime lub Lambda Web Adapter. Function URL nie streamuje wewnątrz VPC. Płacisz za cały czas działania, nawet gdy klient się rozłączy.

VPC i EFS

Domyślnie funkcja ma dostęp do internetu i publicznych endpointów AWS, ale nie do prywatnych zasobów w Twoim VPC (RDS, ElastiCache). Po podpięciu do VPC (podsieci + security groups) Lambda tworzy Hyperplane ENI i funkcja widzi zasoby prywatne, ale traci internet. Przywraca go NAT gateway w podsieci publicznej (funkcja w podsieciach prywatnych), a ruch do AWS może iść przez VPC endpoints. Podpięcie funkcji do podsieci publicznej nie daje jej internetu. Rola potrzebuje ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces, ec2:DeleteNetworkInterface itd. (managed policy AWSLambdaVPCAccessExecutionRole). Szczegóły i animacja ścieżki pakietu: rozdział 4.

EFS: montujesz system plików pod ścieżką zaczynającą się od /mnt/ przez access point. Funkcja musi być w VPC z mount targetem w każdej używanej AZ. Rola potrzebuje elasticfilesystem:ClientMount (i ClientWrite do zapisu). Kiedy to wybrać: duże modele ML, pliki współdzielone między funkcjami, dane większe niż /tmp lub trwalsze od niego.

Runtime'y i paczki

Runtime'y mają daty wycofania (deprecation). Po tej dacie przez pewien czas można jeszcze tworzyć i aktualizować funkcje, potem jest to blokowane. Amazon Linux 2 kończy wsparcie 30 czerwca 2026, więc runtime'y na AL2 (np. Python 3.10/3.11, Java na AL2, provided.al2) warto przenieść na runtime'y oparte na Amazon Linux 2023. Paczkę ZIP do 50 MB wgrywasz bezpośrednio, większą przez S3 (do 250 MB po rozpakowaniu). Własny runtime to provided.al2023 z plikiem bootstrap.

Najczęstsze pytanie o Lambdę na egzaminie brzmi: co się stanie, gdy funkcja rzuci błąd? Odpowiedź zależy wyłącznie od sposobu wywołania. Przy wywołaniu synchronicznym błąd wraca do wywołującego i to on decyduje. Przy asynchronicznym Lambda ma własną kolejkę i sama ponawia. Przy event source mapping poller trzyma paczkę rekordów i ponawia według zasad źródła (kolejka albo strumień).

Analogia: wysyłasz list. Sync to rozmowa telefoniczna: jeśli rozmówca nie zrozumie, sam dzwonisz jeszcze raz. Async to skrzynka pocztowa z listonoszem: listonosz spróbuje doręczyć jeszcze dwa razy, a potem odda list na „poste restante” (DLQ albo on-failure destination). ESM to sekretarka, która bierze z tacy (kolejka) albo z taśmy (strumień) całą garść listów naraz. Z tacy niedoręczone listy wracają po chwili same. Z taśmy nie można wziąć następnego, dopóki obecny nie zostanie załatwiony, bo kolejność jest święta.

Kto ponawia: tabela decyzyjna

Async: konfiguracja błędów, DLQ i destinations

# ustawienia async na funkcji, wersji albo aliasie
aws lambda put-function-event-invoke-config --function-name my-fn \
  --maximum-retry-attempts 1 --maximum-event-age-in-seconds 3600
# destinations (update-* nie kasuje pozostałych ustawień; put-* nadpisuje całość)
aws lambda update-function-event-invoke-config --function-name my-fn \
  --destination-config '{"OnSuccess":{"Destination":"arn:aws:sqs:eu-central-1:111122223333:ok"},
                         "OnFailure":{"Destination":"arn:aws:events:eu-central-1:111122223333:event-bus/ops"}}'
# klasyczna DLQ (atrybut funkcji)
aws lambda update-function-configuration --function-name my-fn \
  --dead-letter-config TargetArn=arn:aws:sqs:eu-central-1:111122223333:my-dlq

Ustawienia async (retries, max age, destinations) konfigurujesz osobno na funkcji, wersji lub aliasie. Async może dostarczyć to samo zdarzenie więcej niż raz, nawet bez błędu (kolejka wewnętrzna jest eventually consistent), więc znowu: idempotencja. Jeśli funkcja nie nadąża, zdarzenia mogą się zestarzeć i zostać odrzucone. Odrzucone zdarzenia przechwycisz destination albo DLQ. Reserved concurrency = 0 przy async wysyła nowe zdarzenia od razu do DLQ lub destination, bez ponowień.

Event source mapping: wspólne zasady

Event source mapping (ESM) to zasób Lambdy (CreateEventSourceMapping), w którym pollery czytają źródło, składają paczkę i wywołują funkcję synchronicznie. Paczka jest wysyłana, gdy zajdzie pierwsze z trzech: skończy się okno batchowania (MaximumBatchingWindowInSeconds, 0–300 s), osiągnięty zostanie BatchSize albo payload dojdzie do 6 MB. ESM przetwarza każde zdarzenie co najmniej raz. Uprawnienia do czytania źródła ma rola wykonawcza funkcji.

SQS jako źródło

• Visibility timeout kolejki ≥ 6 × timeout funkcji (+ okno batchowania). Lambda nie pozwoli utworzyć ESM, jeśli timeout funkcji przekracza visibility timeout.
• Domyślnie błąd (wyjątek) = cała paczka wraca do kolejki, także wiadomości już przetworzone. Rozwiązanie: ReportBatchItemFailures i odpowiedź {"batchItemFailures":[{"itemIdentifier":"<messageId>"}]}.
• Pusta lub null lista batchItemFailures = sukces całej paczki. Wyjątek, niepoprawny JSON albo nieistniejące/puste itemIdentifier = porażka całej paczki. Przy FIFO zatrzymaj przetwarzanie na pierwszym błędzie i zwróć wszystkie pozostałe ID (kolejność).
• DLQ ustawiasz na kolejce źródłowej (maxReceiveCount ≥ 5), nie na funkcji. Wiadomości odfiltrowane przez FilterCriteria są usuwane z kolejki.
• Skalowanie (standard): start od 5 równoległych paczek, potem do +300 wywołań na minutę, domyślnie do 1 250 równoległych. FIFO: concurrency ≤ liczba grup wiadomości (MessageGroupId). Maximum concurrency (2–1 000) chroni downstream i nie pozwala jednej kolejce zjeść puli. Nie ustawiaj jej wyżej niż reserved concurrency funkcji.

def handler(event, context):
    failures = []
    for rec in event["Records"]:
        try:
            process(rec["body"])
        except Exception:
            failures.append({"itemIdentifier": rec["messageId"]})
    return {"batchItemFailures": failures}   # tylko te wrócą do kolejki

Kinesis i DynamoDB Streams jako źródło

Strumień to taśma z rekordami ułożonymi w kolejności w obrębie sharda. Lambda czyta każdy shard osobno i domyślnie przetwarza jedną paczkę na shard naraz (Kinesis standard iterator: odpytywanie raz na sekundę; DynamoDB Streams: 4 razy na sekundę). Concurrency ≈ liczba shardów × ParallelizationFactor. Więcej przepustowości uzyskasz, dodając shardy albo zwiększając ParallelizationFactor. Enhanced fan-out (Kinesis) daje konsumentowi dedykowane łącze do każdego sharda i niższą latencję.

Domyślnie błąd = ponawianie całej paczki aż do sukcesu albo wygaśnięcia rekordu, a shard stoi (metryka IteratorAge rośnie). Przy domyślnych ustawieniach jeden zły rekord może zablokować shard na cały okres retencji strumienia (Kinesis: domyślnie 24 h, do 365 dni; DynamoDB Streams: 24 h). Dlatego ustaw rozsądne MaximumRetryAttempts i/lub MaximumRecordAgeInSeconds, włącz BisectBatchOnFunctionError i dodaj on-failure destination. Przy ReportBatchItemFailures zwracasz numer sekwencyjny pierwszego nieudanego rekordu, a Lambda robi checkpoint i ponawia od najniższego zgłoszonego numeru.

Tumbling windows (Kinesis, DDB): okna do 900 s, w których funkcja przekazuje sobie state (do 1 MB na shard) między wywołaniami. Na koniec okna przychodzi isFinalInvokeForWindow: true. Odpowiedź bez pola state traktowana jest jako błąd. Zastosowanie: agregaty „na żywo” (sumy na minutę) bez zewnętrznej bazy. DynamoDB Streams: najwyżej 2 funkcje na shard tabeli jednoregionowej (1 przy global tables). LATEST przy tworzeniu mapowania może pominąć zdarzenia, a TRIM_HORIZON ich nie gubi.

Near real time (skill 1.2.7): Kinesis Data Streams + Lambda (ESM), DynamoDB Streams + Lambda (reakcja na zmiany w tabeli), Amazon Data Firehose z transformacją Lambda (wywołanie synchroniczne funkcji na buforze rekordów przed zapisem do S3 itp.), S3 event → Lambda (async). Więcej o samych strumieniach w rozdziale 22.

Filtrowanie zdarzeń

# tylko wiadomości SQS, w których body.type == "order" i amount > 100
aws lambda create-event-source-mapping --function-name my-fn \
  --event-source-arn arn:aws:sqs:eu-central-1:111122223333:orders \
  --filter-criteria '{"Filters":[{"Pattern":"{\"body\":{\"type\":[\"order\"],\"amount\":[{\"numeric\":[\">\",100]}]}}"}]}'

Klucz pola danych zależy od źródła: body (SQS), data (Kinesis, MQ), dynamodb (DynamoDB Streams). Rekordy niespełniające filtra: SQS je usuwa, Kinesis i DDB je pomijają (iterator idzie dalej), Kafka i MQ je odrzucają. DocumentDB nie obsługuje filtrów. Składnia jest taka sama jak we wzorcach EventBridge (rozdz. 21).

Idempotencja i pętle rekurencyjne

Idempotencja: przetworzenie tego samego zdarzenia drugi raz nie zmienia wyniku. Klasyczny wzorzec: zapis warunkowy w DynamoDB z kluczem idempotencji (np. messageId, ID zamówienia). Powertools for AWS Lambda ma gotowe narzędzie Idempotency: dekoratory @idempotent / @idempotent_function, warstwa persystencji DynamoDBPersistenceLayer, klucz wybierany wyrażeniem JMESPath (event_key_jmespath), wynik zapamiętywany domyślnie na 1 godzinę (expires_after_seconds). Równoległe wywołanie z tym samym kluczem dostaje IdempotencyAlreadyInProgressError.

Recursive loop detection: funkcja zapisuje do tej samej kolejki, tematu lub bucketu, który ją wywołuje, i powstaje nieskończona pętla. Lambda śledzi łańcuch po nagłówkach X-Ray (nie trzeba włączać active tracing) i po ~16 wywołaniach w jednym łańcuchu przerywa kolejne, wysyła zdarzenie do DLQ lub destination (jeśli są ustawione), zwiększa metrykę RecursiveInvocationsDropped i powiadamia. Działa dla pętli przez SQS, SNS, S3, niestandardowe event busy EventBridge i bezpośrednie wywołania Lambda–Lambda. Celową rekursję włączysz przez put-function-recursion-config --recursive-loop Allow. Pętla S3 → Lambda → ten sam bucket to klasyk: zapisuj wynik do innego bucketu lub prefiksu i filtruj powiadomienia.

Kontener to Twoja aplikacja zapakowana razem z zależnościami w obraz (Docker/OCI). AWS daje do tego trzy klocki. Amazon ECR to rejestr, w którym trzymasz obrazy. Amazon ECS to orkiestrator AWS (uruchamia, skaluje i podpina pod load balancer). Amazon EKS to zarządzany Kubernetes. ECS i EKS mogą uruchamiać kontenery na Twoich instancjach EC2 albo na AWS Fargate, czyli bez serwerów do zarządzania.

Analogia: ECR to magazyn gotowych dań w słoikach (obrazy). Task definition to przepis na zestaw: które słoiki, ile CPU i pamięci, jakie porty, jakie zmienne. Task to podany zestaw, czyli działająca kopia przepisu. Service to kierownik sali, który pilnuje, żeby zawsze stało N zestawów, i wymienia te, które się zepsuły. Cluster to sala. Na EC2 sam dostawiasz stoły (instancje), a na Fargate stoły pojawiają się same.

ECS od środka: task definition, task, service

{
  "family": "web",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512", "memory": "1024",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
  "taskRoleArn":      "arn:aws:iam::111122223333:role/web-app-role",
  "containerDefinitions": [{
    "name": "app",
    "image": "111122223333.dkr.ecr.eu-central-1.amazonaws.com/web:1.4.2",
    "portMappings": [{ "containerPort": 8080 }],
    "environment": [{ "name": "STAGE", "value": "prod" }],
    "secrets": [{ "name": "DB_PASSWORD",
                  "valueFrom": "arn:aws:secretsmanager:eu-central-1:111122223333:secret:db-pass" }],
    "logConfiguration": { "logDriver": "awslogs",
      "options": { "awslogs-group": "/ecs/web", "awslogs-region": "eu-central-1",
                   "awslogs-stream-prefix": "app" } }
  }]
}

Task role vs task execution role

Gdy task ma task role, SDK w kontenerze używa wyłącznie jej poświadczeń i nie dziedziczy uprawnień roli instancji EC2. Na Fargate profilu instancji w ogóle nie ma. Na EC2 z AMI innym niż ECS-optimized trzeba w agencie włączyć ECS_ENABLE_TASK_IAM_ROLE=true. Rola instancji (container instance role) służy tylko agentowi do rejestracji w klastrze. Ogranicz ją do AmazonEC2ContainerServiceforEC2Role, a uprawnień aplikacji tam nie dawaj.

Fargate vs EC2, sieć i porty

W trybie awsvpc podajesz tylko containerPort, bo hostPort jest ignorowany lub równy containerPort. W bridge pominięty hostPort oznacza, że Docker wybiera losowy wolny port, a ECS aktualizuje target group ALB (i AWS Cloud Map) o IP i port każdego taska. Minusem jest to, że security groups muszą otwierać szeroki zakres portów między ALB a instancjami.

Rozmieszczanie, skalowanie, wdrożenia

Kilka strategii można łączyć w kolejności, np. najpierw spread po AZ, potem binpack po pamięci. Dla zadań uruchamianych ręcznie (standalone) nie ma domyślnego ograniczenia rozmieszczenia. Do debugowania działającego kontenera służy ECS Exec (aws ecs execute-command, oparty na SSM Session Manager).

Amazon ECR

aws ecr create-repository --repository-name web --image-scanning-configuration scanOnPush=true
aws ecr get-login-password --region eu-central-1 \
  | docker login --username AWS --password-stdin 111122223333.dkr.ecr.eu-central-1.amazonaws.com
docker build -t web:1.4.2 .
docker tag web:1.4.2 111122223333.dkr.ecr.eu-central-1.amazonaws.com/web:1.4.2
docker push 111122223333.dkr.ecr.eu-central-1.amazonaws.com/web:1.4.2

Amazon EKS w pigułce

EKS to zarządzana płaszczyzna sterowania Kubernetes (control plane). Węzły to do wyboru: EKS Auto Mode (AWS zarządza węzłami), managed node groups, węzły self-managed albo Fargate (pod bez węzła). Wdrażasz manifestami Kubernetes (kubectl, Helm). Uprawnienia AWS dla podów nadajesz przez EKS Pod Identity (powiązanie roli IAM z kontem serwisowym w namespace) albo starszy mechanizm IRSA (OIDC). Na egzaminie EKS wybierasz, gdy pada słowo „Kubernetes”. W pozostałych przypadkach („najmniej pracy”, „natywnie AWS”) wygrywa zwykle ECS na Fargate.

Wyobraź sobie szatnię z setkami wieszaków. Numerek, który dostajesz (partition key), mówi szatniarzowi, przy którym wieszaku szukać — nie musi przeglądać całej sali. Jeśli na jednym wieszaku wisi kilka rzeczy, układa je w kolejności według drugiej etykiety (sort key). DynamoDB działa tak samo: haszuje klucz partycji, żeby trafić w konkretną partycję (fizyczny kawałek tabeli), a wewnątrz partycji trzyma elementy posortowane po kluczu sortowania.

Tabela (table) składa się z elementów (items), a element z atrybutów (attributes). Schemat jest elastyczny: wymagany jest tylko klucz główny (primary key). Klucz główny jest prosty (sam partition key) albo złożony (partition key + sort key) — wtedy unikalna musi być dopiero para tych wartości.

Pojemność (throughput) liczysz w jednostkach: RCU (read capacity unit) i WCU (write capacity unit). Jedno RCU to jeden silnie spójny odczyt na sekundę elementu do 4 KB (albo dwa odczyty ostatecznie spójne). Jedno WCU to jeden zapis na sekundę elementu do 1 KB. Cała reszta tego rozdziału to konsekwencje tych dwóch zdań.

Rachunek RCU/WCU — reguły i przykłady

Algorytm egzaminacyjny jest zawsze ten sam: (1) zaokrąglij rozmiar elementu w górę (odczyt do wielokrotności 4 KB, zapis do 1 KB), (2) podziel przez 4 KB albo 1 KB, (3) pomnóż przez liczbę operacji na sekundę, (4) dla eventual podziel przez 2, dla transakcji pomnóż przez 2. Zaokrąglasz rozmiar elementu, a nie wynik końcowy — 10 elementów po 1 KB czytanych osobno (GetItem) to 10 × 1 RCU, nie 3 RCU.

• Query i Scan liczą się inaczej niż GetItem: DynamoDB sumuje rozmiar wszystkich przeczytanych elementów i dopiero tę sumę zaokrągla do 4 KB. Dlatego Query po wielu małych elementach jest dużo tańszy niż tyle samo GetItem.
• BatchGetItem i BatchWriteItem liczą każdy element osobno, tak jakby był pojedynczym GetItem/PutItem.
• UpdateItem zużywa WCU według większego z rozmiarów „przed” i „po” — nawet jeśli zmieniasz jeden atrybut dużego elementu.
• Odczyt elementu, który nie istnieje, też zużywa RCU. Nieudany zapis warunkowy (ConditionExpression = false) też zużywa WCU.
• Ile faktycznie zużyło żądanie? Parametr ReturnConsumedCapacity = TOTAL (suma) albo INDEXES (z rozbiciem na tabelę i indeksy).

Spójność odczytu

On-demand czy provisioned

Zmiana trybu: z provisioned na on-demand możesz przełączyć tabelę do czterech razy w 24-godzinnym oknie, a z on-demand na provisioned — w dowolnym momencie. W starszych testach próbnych spotkasz regułę „przełączenie raz na 24 godziny” — dziś obowiązuje limit z dokumentacji. Pojemność provisioned podnosisz dowolnie często (UpdateTable), ale zmniejszenia są limitowane: na początku doby UTC masz 4, potem przybywa jedno na godzinę (do 27 na dobę).

Domyślne limity przepustowości: 40 000 RCU i 40 000 WCU na tabelę (w on-demand: 40 000 read/write request units) oraz 80 000 RCU/WCU na konto w trybie provisioned; do 2 500 tabel na region. Wszystkie te limity da się podnieść przez Service Quotas.

Partycje, gorące klucze i throttling

Każda partycja ma twardy sufit: 3 000 RCU i 1 000 WCU. Jeśli wszystkie zapisy idą na jeden klucz (np. status = "NEW" albo dzisiejsza data), cała tabela może mieć 10 000 WCU, a i tak dostaniesz throttling na jednej partycji. Dwa mechanizmy łagodzą problem automatycznie:

• Burst capacity — DynamoDB odkłada do 300 sekund niewykorzystanej pojemności i zużywa ją przy krótkim skoku.
• Adaptive capacity — włączone zawsze, bez opłat; przesuwa pojemność do gorących partycji, a bardzo gorący element potrafi odizolować w osobnej partycji (wciąż do limitu 3 000 RCU / 1 000 WCU).

Gdy to nie wystarcza, projektujesz klucz: write sharding — dodajesz sufiks losowy (np. 2024-07-09.1 … .200) albo wyliczany z innego atrybutu (wtedy wiesz, gdzie szukać przy odczycie). Ceną jest odczyt: żeby zebrać dzień, musisz odpytać wszystkie sufiksy i scalić wyniki. Gorące klucze znajdziesz w CloudWatch Contributor Insights for DynamoDB (najczęściej używane i najczęściej dławione klucze), a samo dławienie w metrykach ReadThrottleEvents, WriteThrottleEvents i ThrottledRequests.

Elementy, typy i serializacja

Typy skalarne: S (string), N (number), B (binary), BOOL, NULL; dokumentowe: M (map), L (list); zbiory: SS, NS, BS. Klucz partycji ma od 1 do 2048 bajtów, klucz sortowania od 1 do 1024 bajtów, zagnieżdżenie do 32 poziomów. Niskopoziomowe API mówi „DynamoDB JSON”, w którym każda wartość niesie typ:

{ "pk": {"S": "USER#42"}, "sk": {"S": "ORDER#2024-07-09"},
  "total": {"N": "129.90"}, "tags": {"SS": ["gift","express"]},
  "address": {"M": {"city": {"S": "Kraków"}}} }

Serializację (umiejętność 1.3.5) robią za ciebie warstwy wyżej: w JavaScript DynamoDBDocumentClient (marshall/unmarshall), w Pythonie zasób boto3.resource('dynamodb') albo TypeSerializer, w Javie Enhanced Client (dawniej DynamoDBMapper). Przy serializacji uważaj na rozmiar: nazwy atrybutów też wchodzą do limitu 400 KB, więc krótkie nazwy oszczędzają WCU. Duże obiekty (zdjęcia, PDF) kładziesz do S3, a w DynamoDB trzymasz klucz obiektu.

Wróć do szatni. Query to podejście do jednego wieszaka (jedna wartość partition key) i zdjęcie kurtek z zakresu numerków (warunek na sort key). Scan to obejście całej sali i obejrzenie każdego wieszaka. Filtr (FilterExpression) nie skraca spaceru — szatniarz i tak ogląda każdą kurtkę, tylko część odkłada z powrotem. Dlatego płacisz za to, co przeczytano, a nie za to, co zwrócono.

Podstawowe operacje na pojedynczym elemencie to GetItem, PutItem (tworzy albo zastępuje cały element), UpdateItem (zmienia wybrane atrybuty, a gdy elementu nie ma — tworzy go, czyli upsert) i DeleteItem. Do tego operacje wsadowe (BatchGetItem, BatchWriteItem), transakcje (TransactGetItems, TransactWriteItems) i PartiQL — SQL-owa nakładka na to samo API.

Warunki i zmiany opisujesz wyrażeniami (expressions): KeyConditionExpression (który klucz), FilterExpression (co odrzucić po odczycie), ProjectionExpression (które atrybuty zwrócić), ConditionExpression (kiedy zapis ma się udać) i UpdateExpression (co zmienić). Nazwy i wartości podstawiasz przez ExpressionAttributeNames (#n, np. dla słów zastrzeżonych jak status) i ExpressionAttributeValues (:v).

Query i Scan w szczegółach

W Query filtr nie może dotyczyć atrybutów klucza (od tego jest KeyConditionExpression). Select=COUNT zwraca tylko liczbę elementów — przydatne, ale RCU są takie same. SDK mają paginatory (np. get_paginator('query') w boto3), które same przekazują LastEvaluatedKey; więcej o stronicowaniu w rozdziale o SDK.

# boto3 — Query z ręcznym stronicowaniem
kwargs = dict(TableName="Orders",
    KeyConditionExpression="pk = :u AND begins_with(sk, :p)",
    FilterExpression="#s = :st",                    # status to słowo zastrzeżone
    ExpressionAttributeNames={"#s": "status"},
    ExpressionAttributeValues={":u": {"S": "USER#2"}, ":p": {"S": "ORDER#"},
                               ":st": {"S": "SHIPPED"}},
    ProjectionExpression="sk, total")
while True:
    page = ddb.query(**kwargs)
    handle(page["Items"])
    if "LastEvaluatedKey" not in page: break
    kwargs["ExclusiveStartKey"] = page["LastEvaluatedKey"]

Parallel scan: każdy wątek/worker wywołuje Scan z tym samym TotalSegments i innym Segment (0 … N−1). Skraca czas, ale zjada pojemność szybciej — przy dużym Scanie na produkcyjnej tabeli rozważ mniejszy Limit, osobną tabelę/indeks albo eksport do S3 (bez zużycia RCU, rozdział 14).

Zapisy warunkowe, optimistic locking i liczniki

# Optimistic locking ręcznie (AWS CLI)
aws dynamodb update-item --table-name Docs \
  --key '{"pk":{"S":"DOC#7"}}' \
  --update-expression "SET body = :b, version = version + :one" \
  --condition-expression "version = :expected" \
  --expression-attribute-values '{":b":{"S":"nowa treść"},":one":{"N":"1"},":expected":{"N":"3"}}' \
  --return-values UPDATED_NEW

UpdateExpression ma cztery klauzule: SET (ustaw/zwiększ, list_append, if_not_exists), REMOVE (usuń atrybut), ADD (dodaj do liczby lub zbioru), DELETE (usuń wartości ze zbioru).

Gdy zapis warunkowy się nie uda, ReturnValuesOnConditionCheckFailure=ALL_OLD zwraca aktualny element w wyjątku — bez dodatkowego GetItem.

Operacje wsadowe i transakcje

UnprocessedItems/UnprocessedKeys ponawiasz z exponential backoff — natychmiastowe ponowienie zwykle znowu trafi w throttling. W starszych pytaniach spotkasz limit transakcji 25 elementów; obecnie dokumentacja podaje 100 unikalnych elementów i 4 MB. Transakcja nie może dwa razy dotknąć tego samego elementu, a w global tables gwarancje ACID obowiązują tylko w regionie, w którym nastąpił zapis.

Idempotencja transakcji: ClientRequestToken sprawia, że powtórzone TransactWriteItems (np. po timeoutcie sieci) nie wykona się drugi raz. Token jest ważny 10 minut; ten sam token z innymi parametrami daje IdempotentParameterMismatch.

{ "TransactItems": [
    { "Update": { "TableName": "Accounts", "Key": {"pk": {"S": "ACC#1"}},
        "UpdateExpression": "SET balance = balance - :a",
        "ConditionExpression": "balance >= :a",
        "ExpressionAttributeValues": {":a": {"N": "100"}} } },
    { "Update": { "TableName": "Accounts", "Key": {"pk": {"S": "ACC#2"}},
        "UpdateExpression": "SET balance = balance + :a",
        "ExpressionAttributeValues": {":a": {"N": "100"}} } } ],
  "ClientRequestToken": "transfer-2024-07-09-0001" }

PartiQL

PartiQL to SQL-owa składnia do DynamoDB: ExecuteStatement (jedno polecenie), BatchExecuteStatement (wsad) i ExecuteTransaction (transakcja). Pod spodem działa to samo API, z tymi samymi kosztami. SELECT bez warunku równości (lub IN) na partition key w WHERE zamienia się w pełny Scan; politykę IAM można ustawić tak, żeby takie zapytania były zabronione.

SELECT sk, total FROM "Orders" WHERE pk = 'USER#2' AND begins_with(sk, 'ORDER#')   -- Query
SELECT * FROM "Orders" WHERE total > 100                                            -- pełny Scan!

Książka ma jeden spis treści (klucz główny tabeli). Gdy chcesz szukać po nazwiskach bohaterów, potrzebujesz indeksu na końcu książki. LSI (local secondary index) to dodatkowy porządek wewnątrz tego samego rozdziału: ten sam partition key, inny sort key. GSI (global secondary index) to zupełnie nowy spis: dowolny partition key i sort key, przez całą tabelę — w praktyce kopia wybranych atrybutów w osobnej „tabeli”, aktualizowana asynchronicznie.

DynamoDB Streams to dziennik zmian: każdy Put, Update i Delete zostawia rekord, który może przeczytać np. Lambda (wyzwalacz, trigger). TTL to data przydatności: wpisujesz czas wygaśnięcia, a DynamoDB sam usuwa przeterminowane elementy, bez zużycia WCU. DAX to pamięć podręczna w pamięci RAM przed tabelą (mikrosekundy zamiast milisekund). Global tables to ta sama tabela w kilku regionach z zapisem w każdym z nich.

LSI kontra GSI

Projekcje (ProjectionType): KEYS_ONLY (klucze tabeli i indeksu — najmniejszy, najtańszy), INCLUDE (klucze + wskazane atrybuty; łącznie najwyżej 100 takich atrybutów we wszystkich indeksach tabeli), ALL (całe elementy — największa elastyczność, największy koszt zapisu i składowania). Rzutuj to, czego zapytanie potrzebuje: w GSI brakującego atrybutu nie dociągniesz.

Indeks rzadki (sparse index): GSI zawiera tylko elementy, które mają atrybut(y) klucza indeksu. Jeśli atrybut isOpen mają tylko otwarte zgłoszenia, GSI na nim to tania lista „otwartych” bez Scanu. Nowość: klucze GSI mogą być złożone z wielu atrybutów (do czterech w partition key i do czterech w sort key), zamiast ręcznie sklejanych kluczy typu TOURNAMENT#WINTER#REGION#EU.

Back-pressure GSI: indeksy aktualizują się asynchronicznie, ale jeśli GSI nie nadąża (za mało WCU, gorąca partycja indeksu — np. GSI po status z trzema wartościami), DynamoDB dławi zapisy do tabeli bazowej. Wyjątek wskazuje GSI (powód np. IndexWriteProvisionedThroughputExceeded), choć ty piszesz do tabeli. Reguła: WCU każdego GSI co najmniej takie jak zapisy, które do niego trafiają, i klucz GSI o wysokiej kardynalności.

DynamoDB Streams i Kinesis Data Streams

• Rekordy żyją 24 godziny; każdy rekord pojawia się w strumieniu dokładnie raz, w kolejności zmian danego elementu. Strumień dzieli się na shardy; na jeden shard projektuj najwyżej dwóch równoczesnych czytelników (w tabeli nie-globalnej).
• Lambda czyta strumień przez event source mapping (batch, ponowienia, bisekcja, ReportBatchItemFailures, filtry zdarzeń) — szczegóły w rozdziale 10.
• Alternatywa: Kinesis Data Streams for DynamoDB — retencja do 1 roku, więcej konsumentów (enhanced fan-out), Firehose do S3; gdy 24 h i dwóch czytelników to za mało (Kinesis).

TTL: automatyczne wygasanie

Włączasz TTL na tabeli i wskazujesz atrybut (np. expireAt) typu Number z czasem w sekundach epoch (np. 1767225600). Inny format (ISO-string, milisekundy) jest ignorowany; wartość starsza niż 5 lat w przeszłości też. Usuwanie działa w tle, zwykle w ciągu kilku dni po wygaśnięciu, i nie zużywa WCU. W starszych materiałach spotkasz „w ciągu 48 godzin” — dokumentacja mówi dziś o kilku dniach.

• Wygasłe, ale jeszcze nieusunięte elementy wciąż zwracają Get/Query/Scan i liczą się do składowania — odfiltruj je (FilterExpression: expireAt > :now).
• Usunięcie przez TTL trafia do Streams jako usunięcie serwisowe: userIdentity.type = "Service", principalId = "dynamodb.amazonaws.com" — tak odróżnisz je od skasowania przez użytkownika (np. archiwizacja przez Lambdę do S3).
• Element znika też z LSI i GSI, jak przy zwykłym Delete.

DAX kontra ElastiCache

DAX (DynamoDB Accelerator) to klaster cache w twoim VPC, zgodny z API DynamoDB: podmieniasz klienta SDK na klienta DAX i reszta kodu zostaje. Ma dwa niezależne bufory: item cache (wyniki GetItem/BatchGetItem, domyślny TTL 5 minut) i query cache (wyniki Query/Scan według parametrów). Zapisy przechodzą przez DAX do tabeli (write-through) i aktualizują item cache, ale nie unieważniają query cache.

Global tables, kopie zapasowe, eksport

• Global tables (wersja 2019.11.21, Current): repliki w wielu regionach, zapis w każdym (active-active). Domyślnie MREC (multi-Region eventual consistency): replikacja asynchroniczna, zwykle w ciągu sekundy, konflikty rozstrzyga last writer wins. Opcjonalnie MRSC (multi-Region strong consistency) — silnie spójne odczyty między regionami; równoległy zapis tego samego elementu w innym regionie kończy się ReplicatedWriteConflictException (można ponowić). Transakcje są ACID tylko w regionie zapisu.
• On-demand backup: pełna kopia na żądanie (DynamoDB albo AWS Backup), bez wpływu na wydajność i dostępność tabeli.
• PITR (point-in-time recovery): ciągłe kopie, odtworzenie do dowolnej sekundy z okresu 1–35 dni (domyślnie 35); odtwarzasz zawsze do nowej tabeli (także w innym regionie).
• Export to S3: z dowolnego momentu w oknie PITR (więc PITR musi być włączony), pełny lub przyrostowy, format DynamoDB JSON lub Amazon Ion, bez zużycia RCU — potem Athena po stronie S3.
• Import from S3: CSV, DynamoDB JSON lub Ion (także GZIP/ZSTD) do nowej tabeli, bez zużycia WCU.

Dostęp na poziomie elementów i atrybutów

Polityka IAM może ograniczyć użytkownika do elementów, których partition key równa się jego identyfikatorowi: warunek dynamodb:LeadingKeys (z modyfikatorem ForAllValues) i zmienna polityki, np. ${cognito-identity.amazonaws.com:sub} dla tożsamości z Cognito identity pool. dynamodb:Attributes ogranicza widoczne atrybuty (najwyższego poziomu), a dynamodb:Select i dynamodb:ReturnValues domykają furtki (odczyt bez projekcji zwróciłby wszystko). Pełny wzorzec multi-tenant: rozdział 31, tożsamości: Cognito.

{ "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem"],
  "Resource": "arn:aws:dynamodb:*:*:table/GameScores",
  "Condition": { "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"] } } }

S3 to przechowalnia bagażu bez limitu miejsca. Zasobnik (bucket) to przechowalnia o globalnie unikalnej nazwie w jednym regionie, obiekt (object) to walizka, a klucz (key), np. photos/2024/cat.jpg, to numer na kwicie. „Foldery” są tylko prefiksami w nazwie klucza. Każda walizka ma metadane (systemowe, jak Content-Type, i własne x-amz-meta-*) oraz opcjonalne tagi.

Od strony dewelopera S3 to API HTTP: PutObject, GetObject, HeadObject, DeleteObject, ListObjectsV2, CopyObject i multipart upload. Odczyt po zapisie jest silnie spójny (strong read-after-write consistency) we wszystkich regionach: po udanym PUT lub DELETE kolejny GET i LIST widzą zmianę.

Cała reszta rozdziału to pokrętła wokół tej przechowalni: klasy (jak szybko i jak tanio), lifecycle (automatyczne przenoszenie i kasowanie), wersjonowanie i replikacja (ochrona przed pomyłką i awarią regionu), zdarzenia (reakcja na nowe pliki), presigned URL i multipart (bezpieczny i szybki upload z klienta), wydajność, CORS i hosting stron. Bezpieczeństwo i szyfrowanie: następny rozdział.

Spójność

PUT nowego obiektu, nadpisanie i DELETE są silnie spójne — także LIST. Dwa równoczesne PUT pod ten sam klucz: wygrywa żądanie z najnowszym znacznikiem czasu; S3 nie daje blokad obiektów dla współbieżnych zapisów (jeśli to problem, zbuduj blokadę w aplikacji, np. w DynamoDB, albo użyj zapisów warunkowych). Konfiguracje zasobnika (np. włączenie wersjonowania, polityki) są ostatecznie spójne — chwilę po zmianie stara konfiguracja może jeszcze działać. W starszych materiałach spotkasz „eventual consistency dla nadpisań i DELETE” — to już nieaktualne.

Klasy składowania

Wszystkie obecne klasy (poza przestarzałym Reduced Redundancy Storage, 99,99%) są projektowane na 11 dziewiątek trwałości (99,999999999%); różnią się dostępnością, kosztem i czasem dostępu. Obiekt z Glacier Flexible/Deep Archive trzeba najpierw przywrócić (RestoreObject) — powstaje tymczasowa kopia. Usunięcie lub przeniesienie obiektu przed minimalnym okresem = opłata za resztę tego okresu.

Lifecycle: przenoszenie i wygasanie

Reguły filtrujesz prefiksem, tagami i rozmiarem obiektu (ObjectSizeGreaterThan/ObjectSizeLessThan). Od września 2024 domyślnie obiekty mniejsze niż 128 KB nie są przenoszone do żadnej klasy (opłata za przejście byłaby większa niż oszczędność) — chyba że dodasz filtr rozmiaru.

Wersjonowanie i delete markers

• Stany zasobnika: bez wersjonowania → włączone → zawieszone (suspended). Po włączeniu nie wrócisz do „bez wersjonowania”, możesz tylko zawiesić.
• Obiekty sprzed włączenia mają wersję null. Nadpisanie tworzy nową wersję; stare zostają (i kosztują).
• DELETE bez versionId nie kasuje danych — dodaje delete marker; zwykły GET zwraca wtedy 404. Odzyskanie pliku = usunięcie delete markera. Trwałe usunięcie = DELETE z konkretnym versionId (opcjonalnie chronione przez MFA Delete, rozdział 16).

Replikacja

• Wymagania: wersjonowanie w źródle i celu, rola IAM, przez którą S3 replikuje, przy innym koncie — polityka zasobnika docelowego; jeśli źródło ma Object Lock, cel też musi go mieć.
• Domyślnie (konfiguracja z Filter) delete markery nie są replikowane — można włączyć delete marker replication. Usunięcia konkretnej wersji nigdy nie są replikowane (ochrona przed złośliwym kasowaniem).
• Brak replikacji łańcuchowej: obiekty, które same są replikami z innej reguły, nie są dalej replikowane (A → B → C nie działa; do tego Batch Replication). Konfiguracje zasobnika (lifecycle, powiadomienia) też się nie replikują.
• Replikowane są obiekty zaszyfrowane SSE-S3, SSE-KMS (z dodatkową konfiguracją kluczy) i SSE-C.

Zdarzenia: S3 Event Notifications kontra EventBridge

Powiadomienia są dostarczane co najmniej raz (at least once), zwykle w sekundach, czasem po minucie lub dłużej — konsument musi być idempotentny. Uwaga na pętlę: Lambda wyzwalana przez upload do zasobnika X, która zapisuje wynik do tego samego zasobnika, wywoła samą siebie. Rozwiązanie: osobny zasobnik wynikowy albo prefiks wyjściowy poza filtrem. Do wysyłania jednego zdarzenia do wielu kolejek: S3 → SNS → wiele SQS (fan-out) albo EventBridge.

Presigned URL

Presigned URL to bilet do szatni podpisany przez ciebie: każdy, kto go ma, może do czasu wygaśnięcia wykonać tę jedną operację (GET albo PUT) na tym jednym kluczu z twoimi uprawnieniami. Klient nie potrzebuje poświadczeń AWS. Typowy wzorzec: backend (Lambda) generuje URL do PUT, przeglądarka wysyła plik prosto do S3 — bez przepychania pliku przez API Gateway (limity rozmiaru) i bez obciążania serwera.

# CLI — link do pobrania ważny 1 godzinę
aws s3 presign s3://reports/2024/q2.pdf --expires-in 3600

# Python — link do wysłania pliku (PUT)
url = s3.generate_presigned_url("put_object",
        Params={"Bucket": "uploads", "Key": "u/42/avatar.png", "ContentType": "image/png"},
        ExpiresIn=300)

URL przestaje działać także wtedy, gdy poświadczenia, którymi go podpisano, zostaną unieważnione lub wygasną. Jeśli podpisujący nie ma uprawnienia s3:GetObject/s3:PutObject, URL wygeneruje się bez błędu, ale żądanie dostanie 403. Wiek podpisu możesz ograniczyć w polityce zasobnika warunkiem s3:signatureAge.

Multipart, Transfer Acceleration, byte-range i prefiksy

• Multipart upload: CreateMultipartUpload → UploadPart (części 1–10 000, równolegle, w dowolnej kolejności) → CompleteMultipartUpload (albo AbortMultipartUpload). Zalety: przepustowość (równoległość), odporność (ponawiasz tylko nieudaną część), pauza i wznowienie. Pojedynczy PUT: do 5 GB; multipart: obiekt do ok. 50 TB (48,8 TiB). Konsola wgra plik do 160 GB. Wysokopoziomowe aws s3 cp i Transfer Manager w SDK robią multipart automatycznie.
• Niedokończony upload nie wygasa sam — jego części leżą i kosztują, a nie widać ich w zwykłym listingu. Lekarstwo: reguła lifecycle AbortIncompleteMultipartUpload.
• Transfer Acceleration: upload/download przez najbliższą lokalizację brzegową CloudFront i sieć AWS; endpoint <bucket>.s3-accelerate.amazonaws.com; nazwa zasobnika bez kropek; dodatkowa opłata. Odpowiedź na „użytkownicy z innego kontynentu wysyłają duże pliki wolno”.
• Byte-range fetches: nagłówek Range w GET pobiera fragment obiektu — równoległe pobieranie dużych plików, ponowienie tylko fragmentu, odczyt nagłówka pliku bez pobierania całości.
• Prefiksy: co najmniej 3 500 PUT/COPY/POST/DELETE i 5 500 GET/HEAD na sekundę na prefiks, bez limitu liczby prefiksów. Przy przekroczeniu dostajesz 503 Slow Down — rozłóż klucze na więcej prefiksów i ponawiaj z backoffem. Dla treści czytanych masowo: CloudFront.

CORS i hosting statycznej strony

Strona z https://app.example.com pobiera skryptem pliki z https://assets.s3.amazonaws.com — to inny origin, więc przeglądarka wymaga nagłówków CORS. Konfigurację CORS ustawiasz na zasobniku, z którego pobierasz (docelowym), nie na tym, który hostuje stronę. Bez niej w konsoli przeglądarki widzisz błąd CORS, choć sam obiekt jest dostępny.

[ { "AllowedOrigins": ["https://app.example.com"],
    "AllowedMethods": ["GET", "PUT"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000 } ]

Static website hosting: włączasz na zasobniku, ustawiasz index document i error document; strona jest pod endpointem http://<bucket>.s3-website-<region>.amazonaws.com (albo s3-website.<region>). Endpoint strony nie obsługuje HTTPS — HTTPS i własna domena: CloudFront (z OAC, rozdział 27) albo Amplify Hosting. Publiczna strona wymaga zdjęcia Block Public Access i polityki zezwalającej na s3:GetObject; przy SSE-KMS potrzebujesz CloudFront.

Zapytania do danych w S3: S3 Select, Object Lambda, Athena

Szyfrowanie to sejf, a pytanie egzaminacyjne brzmi prawie zawsze: kto trzyma klucz? Przy SSE-S3 klucze ma i obraca AWS — wygodnie i za darmo. Przy SSE-KMS kluczem jest klucz KMS: AWS szyfruje za ciebie, ale ty kontrolujesz politykę klucza, rotację i widzisz każde użycie w CloudTrail. Przy SSE-C przynosisz własny klucz w każdym żądaniu, a S3 go nie przechowuje. Przy szyfrowaniu po stronie klienta (client-side encryption) S3 dostaje już zaszyfrowane bajty i nigdy nie widzi klucza ani danych jawnych.

Szyfrowanie w spoczynku (at rest) chroni dane na dyskach, szyfrowanie w tranzycie (in transit) — po drodze (TLS/HTTPS). Od 5 stycznia 2023 każdy nowy obiekt w S3 jest szyfrowany co najmniej SSE-S3, bez dopłat; TLS wymuszasz polityką zasobnika z warunkiem aws:SecureTransport.

Drzwi do zasobnika pilnują: polityka zasobnika (bucket policy, polityka zasobu), polityki IAM tożsamości, Block Public Access (bezpiecznik nad wszystkim, co publiczne), Object Ownership (wyłączone ACL), access points (osobne „wejścia” z własnymi politykami) oraz Object Lock i MFA Delete przeciw kasowaniu. Logika oceny polityk (explicit deny wygrywa) jest w rozdziale o IAM.

Opcje szyfrowania w spoczynku

• Default encryption zasobnika ustawiasz na SSE-S3, SSE-KMS lub DSSE-KMS. Zmiana domyślnego szyfrowania nie zmienia istniejących obiektów — trzeba je skopiować (np. CopyObject lub S3 Batch Operations).
• S3 Bucket Keys: S3 pobiera z KMS krótkotrwały klucz na poziomie zasobnika i z niego wyprowadza klucze danych — mniej wywołań GenerateDataKey/Decrypt, koszt KMS niższy nawet o 99%. Kontekst szyfrowania staje się ARN-em zasobnika, nie obiektu — polityki oparte na ARN obiektu w kontekście przestają działać.
• Limity KMS: operacje kryptograficzne na kluczach symetrycznych mają wspólny limit na konto i region — 10 000, 20 000 albo 100 000 żądań/s zależnie od regionu. Przy przekroczeniu S3 zwraca błąd throttlingu z KMS. Rozwiązania: Bucket Keys, podniesienie limitu (Service Quotas), backoff. W starszych testach spotkasz niższe wartości tych limitów — limity KMS rosły; zasady KMS: rozdział 29.
• Klucz aws/s3 (AWS managed) nie pozwala udostępnić obiektów innemu kontu — do cross-account potrzebny customer managed key z odpowiednią polityką klucza.
• SSE szyfruje dane obiektu, nie metadane — nie wkładaj sekretów do x-amz-meta-*.

SSE-C od kwietnia 2026: w nowych zasobnikach (i istniejących na kontach bez obiektów SSE-C) SSE-C jest domyślnie zablokowane. Aby go używać, ustawiasz w konfiguracji szyfrowania zasobnika BlockedEncryptionTypes na NONE (PutBucketEncryption). Starsze pytania zakładają, że SSE-C działa od ręki — w odpowiedziach nadal liczy się zasada „klucz klienta w nagłówkach, HTTPS, S3 nie przechowuje klucza”.

Polityki wymuszające TLS i szyfrowanie

{ "Version": "2012-10-17",
  "Statement": [
    { "Sid": "DenyInsecureTransport", "Effect": "Deny", "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } } },
    { "Sid": "DenyNotSSEKMS", "Effect": "Deny", "Principal": "*",
      "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } } ] }

Druga instrukcja to klasyczny wzorzec „wymuś SSE-KMS”. Pułapka: odrzuca każde PutObject bez nagłówka — także od klientów, którzy polegają na domyślnym szyfrowaniu SSE-KMS zasobnika. Dziś prościej ustawić default encryption na SSE-KMS (i ewentualnie wymusić konkretny klucz warunkiem na s3:x-amz-server-side-encryption-aws-kms-key-id). Wariant z "Null": {"s3:x-amz-server-side-encryption-aws-kms-key-id": "true"} odrzuca żądania, które nie wskazują klucza KMS.

Dostęp publiczny, ACL i access points

• Nowe zasobniki, access pointy i obiekty domyślnie nie pozwalają na dostęp publiczny. BPA ustawisz na poziomie konta, zasobnika, access pointa i AWS Organizations; ustawienie bardziej restrykcyjne wygrywa. Publiczna strona WWW wymaga świadomego wyłączenia BPA (albo lepiej: CloudFront + OAC, zasobnik prywatny — rozdział 27).
• Object Ownership = Bucket owner enforced (domyślnie): ACL wyłączone, właściciel zasobnika jest właścicielem każdego obiektu, także wgranego przez inne konto. Dostęp dajesz politykami. Pozostałe tryby (Bucket owner preferred, Object writer) włączają ACL — tylko gdy naprawdę potrzebujesz uprawnień per obiekt.
• Access points: nazwane punkty dostępu do jednego zasobnika, każdy z własną polityką i ustawieniem sieci (Internet albo tylko z określonego VPC — wybierane przy tworzeniu, potem niezmienne). Upraszczają jedną gigantyczną politykę zasobnika na wiele małych (np. per zespół lub aplikacja); polityka zasobnika może delegować kontrolę dostępu do access pointów.
• Dostęp między kontami do obiektów: polityka zasobnika (zasób) zezwala kontu B, a polityka IAM w koncie B zezwala użytkownikowi — potrzebne obie. Przy SSE-KMS dochodzi polityka klucza KMS.

Object Lock i MFA Delete

Object Lock działa tylko z włączonym wersjonowaniem i blokuje konkretne wersje obiektu.

Restauracja ma jednego szefa kuchni (instancję główną, primary). Multi-AZ to zastępca stojący w drugiej kuchni (inna strefa dostępności), który robi dokładnie to samo co szef w tej samej chwili (replikacja synchroniczna) — ale nie wydaje dań gościom. Gdy szef zasłabnie, zastępca przejmuje kuchnię. Read replica to dodatkowe okienka wydawania: obsługują tylko odczyty, dostają zamówienia z lekkim opóźnieniem (replikacja asynchroniczna) i nie przejmą kuchni same.

Amazon RDS to zarządzane bazy MySQL, PostgreSQL, MariaDB, Oracle, SQL Server i Db2: AWS robi kopie zapasowe, łatki, failover. Aurora to silnik AWS zgodny z MySQL i PostgreSQL, z rozproszoną warstwą składowania (kopie danych w trzech AZ) i do 15 replik czytających z tego samego wolumenu. Aurora Serverless (dawniej „v2”) skaluje moc w jednostkach ACU w locie, nawet do zera.

Z perspektywy dewelopera najważniejsze są trzy rzeczy: jak się połączyć (endpointy), jak się uwierzytelnić bez haseł w kodzie (IAM DB auth, Secrets Manager) i jak nie zatopić bazy połączeniami z setek Lambd (RDS Proxy).

Multi-AZ, Multi-AZ DB cluster i read replicas

Aplikacja używa jednego endpointu bazy — po failoverze nazwa zostaje, zmienia się adres za nią. Dlatego klient z długim cache DNS (np. JVM) może łączyć się ze starym adresem; ustaw krótki TTL DNS. Odczyty z repliki mogą być nieaktualne (replica lag) — „read-after-write” kieruj na primary.

Aurora

• Wolumen klastra (cluster volume) trzyma kopie danych w trzech AZ i rośnie automatycznie (do 256 TiB w nowszych wersjach). Repliki Aurora (do 15) czytają ten sam wolumen; opóźnienie zwykle znacznie poniżej 100 ms.
• Gdy writer pada, Aurora promuje jedną z replik (failover) — repliki są jednocześnie skalowaniem odczytów i zapasem.
• Endpointy: cluster (writer) endpoint — zapisy, DDL; reader endpoint — odczyty, Aurora rozkłada połączenia między repliki; custom endpoint — wybrany podzbiór instancji (np. większe repliki dla raportów); instance endpoint — konkretna instancja (diagnostyka, strojenie).
• Aurora Serverless: pojemność w ACU (ok. 2 GiB RAM + CPU + sieć), zakres od 0 do 256 ACU, skok co 0,5 ACU; przy minimum 0 ACU instancja automatycznie się pauzuje bez połączeń. Dla zmiennego lub nieznanego ruchu, środowisk dev/test, wielu najemców. W starszych pytaniach spotkasz „Aurora Serverless v1” (skalowanie skokowe, pauza) — dokumentacja mówi dziś po prostu o Aurora serverless (dawne v2).

Uwierzytelnianie: IAM DB auth i Secrets Manager

IAM database authentication (MariaDB, MySQL, PostgreSQL): aplikacja z rolą IAM generuje token uwierzytelniający podpisany SigV4 (ważny 15 minut) i używa go zamiast hasła; ruch musi być szyfrowany SSL/TLS. Rola potrzebuje akcji rds-db:connect na zasobie użytkownika bazy. Zalety: brak haseł w kodzie, centralne zarządzanie w IAM.

TOKEN=$(aws rds generate-db-auth-token --hostname mydb.xxxx.eu-central-1.rds.amazonaws.com \
        --port 3306 --username app_user --region eu-central-1)
mysql --host=mydb.xxxx.eu-central-1.rds.amazonaws.com --user=app_user \
      --password="$TOKEN" --ssl-ca=global-bundle.pem --enable-cleartext-plugin

Secrets Manager: RDS może sam zarządzać hasłem głównego użytkownika w Secrets Manager (--manage-master-user-password) i rotować je co 7 dni domyślnie, bez zmian w aplikacji, o ile ta pobiera sekret w runtime (np. przez Lambda extension z cache). Porównanie z Parameter Store i rotacja: rozdział 30.

RDS Proxy i Lambda

Każde środowisko wykonawcze Lambdy otwiera własne połączenie. Przy skoku ruchu setki środowisk = setki połączeń i „too many connections”. RDS Proxy trzyma pulę połączeń do bazy i dzieli ją między klientów, kolejkuje lub dławi nadmiar zamiast przewracać bazę, a przy failoverze sam łączy się ze standby — aplikacja widzi krótszą przerwę.

• Proxy działa w tym samym VPC co baza i nie jest publicznie dostępny; Lambda musi być w VPC (VPC, konfiguracja Lambdy).
• Klienci uwierzytelniają się do proxy przez IAM albo poświadczenia z Secrets Manager (do 200 sekretów na proxy); proxy łączy się z bazą poświadczeniami z Secrets Manager (lub IAM).
• Wzorzec w Lambdzie: połączenie (do proxy) tworzone poza handlerem, żeby kolejne wywołania w tym samym środowisku je reużywały (model wykonania).

Cache to ściągawka w kieszeni. Zamiast za każdym razem iść do biblioteki (bazy danych), zaglądasz do kieszeni — milisekunda zamiast spaceru. Kłopoty są dwa: ściągawka może być nieaktualna (ktoś zmienił książkę), a kieszeń ma ograniczone miejsce. Strategie cache to różne odpowiedzi na pytanie, kiedy przepisywać do ściągawki.

Lazy loading (cache-aside): najpierw zaglądasz do cache; jeśli nie ma (cache miss), czytasz z bazy i dopisujesz do cache. Write-through: przy każdym zapisie do bazy od razu aktualizujesz cache. TTL (time to live) to data ważności wpisu — po niej klucz znika i kolejny odczyt pobierze świeżą wartość.

Amazon ElastiCache to zarządzany cache w pamięci z silnikami Valkey, Redis OSS i Memcached, w wersji serverless albo jako klaster węzłów. Obok niego egzamin pyta o magazyny „do konkretnego wzorca dostępu”: OpenSearch Service (wyszukiwanie pełnotekstowe, analiza logów) i Athena (SQL na plikach w S3). Cache dla DynamoDB to DAX, cache na brzegu — CloudFront, cache odpowiedzi API — API Gateway.

Strategie cache

# lazy loading + write-through + TTL (Python, Valkey/Redis OSS)
def get_user(uid):
    v = cache.get(f"user:{uid}")
    if v is not None:
        return json.loads(v)                                   # hit
    row = db.query("SELECT * FROM users WHERE id=%s", uid)     # miss → baza
    cache.setex(f"user:{uid}", 300, json.dumps(row))           # TTL 300 s
    return row

def update_user(uid, data):
    db.update("users", uid, data)
    cache.setex(f"user:{uid}", 300, json.dumps(data))          # write-through

Gdzie cache'ować (umiejętność 4.3.6)? Warstwy od klienta do bazy: przeglądarka (nagłówki Cache-Control), CloudFront (treść statyczna i odpowiedzi na brzegu), cache stage'u API Gateway (odpowiedzi REST API, TTL), pamięć procesu (zmienne poza handlerem Lambdy), ElastiCache (współdzielony cache aplikacji), DAX (przed DynamoDB). Im bliżej klienta, tym taniej i szybciej, ale trudniej unieważnić.

ElastiCache: silniki i tryby

• ElastiCache Serverless: cache gotowy w niecałą minutę, bez planowania pojemności — skaluje się sam według pamięci, CPU i sieci. Klaster węzłów (node-based): sam wybierasz typy i liczbę węzłów.
• Nazewnictwo: dokumentacja mówi dziś „ElastiCache (Redis OSS)” i „ElastiCache for Valkey” (otwartoźródłowy Valkey pod Linux Foundation, węzły ok. 20% tańsze niż Redis OSS); w starszych pytaniach zobaczysz „ElastiCache for Redis” — to ten sam typ odpowiedzi.
• ElastiCache działa zwykle w twoim VPC (Serverless może też mieć publiczny endpoint z IAM i TLS); dostęp kontrolujesz grupami bezpieczeństwa (VPC). Lambda łącząca się przez prywatny endpoint musi być w tym VPC.

Sesje i inne wzorce

Gdy aplikacja działa na wielu instancjach za load balancerem (albo w Lambdzie), stan sesji nie może żyć w pamięci jednej instancji. Trzymasz go w ElastiCache (szybko, TTL = czas sesji) albo w DynamoDB (trwale, TTL tabeli). Sticky sessions na ALB (rozdział 5) to obejście, które psuje rozkład obciążenia i gubi sesję przy awarii instancji. Inne klasyki: sorted set jako ranking graczy w czasie rzeczywistym, liczniki (INCR), limiter żądań, pub/sub.

Magazyny do wzorców dostępu: OpenSearch i Athena

Typowe połączenie: DynamoDB jako źródło prawdy + wyszukiwanie pełnotekstowe w OpenSearch. Dane przenosisz zero-ETL (DynamoDB plugin dla OpenSearch Ingestion) albo samodzielnie przez DynamoDB Streams + Lambda. Pytanie „wyszukaj produkty po fragmencie opisu” to nie Scan z contains() — to OpenSearch.

Wyobraź sobie szatnię w teatrze. Oddajesz płaszcz (producer wysyła wiadomość), szatniarz wiesza go na wieszaku (kolejka), a ktoś później go odbiera (consumer). Szatniarz nie musi wiedzieć, kto przyjdzie po płaszcz ani kiedy. Na tym polega decoupling: producent i konsument nie muszą działać w tym samym czasie ani w tym samym tempie.

Amazon SQS (Simple Queue Service) to w pełni zarządzana kolejka typu pull. Konsument sam pyta kolejkę o wiadomości (ReceiveMessage), przetwarza je i musi je jawnie skasować (DeleteMessage). SQS nie wie, czy przetwarzanie się udało. Jeśli konsument nie skasuje wiadomości, ta po pewnym czasie wróci do kolejki i ktoś odbierze ją ponownie.

Ten „pewien czas” to visibility timeout. Po odebraniu wiadomość nie znika, tylko staje się na chwilę niewidoczna dla innych konsumentów (jest „in flight”). Domyślnie trwa to 30 sekund, maksymalnie 12 godzin. Jeśli konsument w tym czasie nie zdąży jej skasować, wiadomość znów jest widoczna i trafia do kogoś innego. Dlatego SQS standard daje at-least-once delivery: ta sama wiadomość może przyjść więcej niż raz, więc przetwarzanie powinno być idempotentne.

Standard kontra FIFO

Deduplikacja w FIFO. Jeśli wyślesz wiadomość z tym samym MessageDeduplicationId w ciągu 5 minut, SQS przyjmie wywołanie, ale nie doda duplikatu. Zamiast podawać ID ręcznie, możesz włączyć content-based deduplication (ContentBasedDeduplication=true). Wtedy SQS liczy SHA-256 z treści (body) wiadomości, bez atrybutów. Dwie wiadomości o tej samej treści, ale różnych atrybutach, zostaną uznane za duplikat.

Grupy wiadomości. MessageGroupId działa jak osobny pas na autostradzie. Wewnątrz pasa obowiązuje kolejność, a różne pasy (np. jeden na klienta albo zamówienie) są przetwarzane równolegle przez różnych konsumentów. Jedna grupa = jeden konsument naraz, więc jeśli wszystko wyślesz z jednym ID grupy, nie zrównoleglisz przetwarzania.

High throughput FIFO włączasz atrybutami DeduplicationScope=messageGroup i FifoThroughputLimit=perMessageGroupId. Limit dotyczy wtedy grupy, nie całej kolejki, więc potrzebujesz wielu różnych MessageGroupId.

Atrybuty kolejki, które warto znać

Kod: wysyłka, long polling, kasowanie

# Python (boto3)
sqs = boto3.client("sqs")
sqs.send_message(QueueUrl=url, MessageBody=json.dumps(order),
                 DelaySeconds=0,                       # message timer (tylko standard)
                 MessageAttributes={"type": {"DataType": "String", "StringValue": "order"}})
# FIFO: dodaj MessageGroupId (obowiązkowe) i MessageDeduplicationId (albo content-based dedup)
sqs.send_message(QueueUrl=fifo_url, MessageBody=body,
                 MessageGroupId="customer-42", MessageDeduplicationId="order-1001")

resp = sqs.receive_message(QueueUrl=url, MaxNumberOfMessages=10,   # max 10 na wywołanie
                           WaitTimeSeconds=20,                     # long polling, max 20 s
                           VisibilityTimeout=60)                   # nadpisuje VT kolejki dla tych wiadomości
for m in resp.get("Messages", []):
    process(m)
    sqs.delete_message(QueueUrl=url, ReceiptHandle=m["ReceiptHandle"])  # bez tego wiadomość wróci

DeleteMessage i ChangeMessageVisibility przyjmują receipt handle z ostatniego odbioru, a nie MessageId. Każdy odbiór daje nowy receipt handle.

Visibility timeout w szczegółach

• ChangeMessageVisibility ustawia nowy timeout liczony od chwili wywołania, nie od odbioru. Łączny limit to 12 h od pierwszego odbioru.
• ChangeMessageVisibility z VisibilityTimeout=0 natychmiast oddaje wiadomość innym konsumentom („nie dam rady, weź ktoś inny”).
• Zmiana dotyczy tylko tego odbioru. Przy następnym odbiorze wiadomość znów dostaje timeout kolejki.
• Wiadomości „in flight” (odebrane, nieskasowane): w kolejce standard ok. 120 000. Po przekroczeniu short polling zwraca błąd OverLimit, a long polling po prostu nic nie zwraca. Kolejka FIFO też ma limit 120 000 (w starszych materiałach: 20 000).

Dead-letter queue i redrive

DLQ to zwykła kolejka, którą wskazujesz w redrive policy kolejki źródłowej. Każdy odbiór zwiększa licznik ApproximateReceiveCount. Gdy wiadomość została odebrana maxReceiveCount razy i nadal nie jest skasowana, SQS przenosi ją do DLQ. Zbyt niskie maxReceiveCount (np. 1) wyśle do DLQ wiadomości, które padły na chwilowym błędzie.

• DLQ musi być w tym samym koncie i regionie i tego samego typu (DLQ kolejki FIFO jest FIFO, DLQ standard jest standard).
• Retencja: w kolejce standard wiadomość zachowuje pierwotny znacznik czasu dodania, więc w DLQ żyje krócej. Ustaw retencję DLQ dłuższą niż kolejki źródłowej. W FIFO znacznik zeruje się przy przeniesieniu.
• DLQ redrive (konsola albo API StartMessageMoveTask, ListMessageMoveTasks, CancelMessageMoveTask) przenosi wiadomości z DLQ z powrotem do kolejki źródłowej lub innej kolejki tego samego typu, gdy naprawisz błąd.
• Alarm CloudWatch na ApproximateNumberOfMessagesVisible kolejki DLQ > 0 to klasyczny sposób, by dowiedzieć się o porażkach.

Duże wiadomości, batching, purge, bezpieczeństwo

• Extended Client Library (Java, Python) zapisuje ładunek w S3 (do 2 GB) i wysyła do kolejki referencję. To typowa odpowiedź na „wiadomość większa niż limit SQS”.
• Batch: do 10 wiadomości w SendMessageBatch / DeleteMessageBatch / ChangeMessageVisibilityBatch; ReceiveMessage zwraca max 10 (MaxNumberOfMessages). Odpowiedź batch może być częściowo udana, więc sprawdzaj listę Failed. Łączny rozmiar paczki też nie może przekroczyć limitu rozmiaru wiadomości.
• Atrybuty wiadomości: do 10 na wiadomość (metadane obok treści).
• PurgeQueue kasuje wszystkie wiadomości bez możliwości odzyskania. Trwa do 60 s, a kolejne wywołanie w tym czasie zwraca PurgeQueueInProgress.
• Szyfrowanie: w tranzycie HTTPS. At rest SSE-SQS (klucze zarządzane przez SQS, domyślnie włączone dla nowych kolejek) albo SSE-KMS (klucz AWS managed aws/sqs lub customer managed). Producent do kolejki SSE-KMS potrzebuje kms:GenerateDataKey i kms:Decrypt, konsument kms:Decrypt. Żeby usługi AWS wysyłające do kolejki (np. SNS, EventBridge, powiadomienia S3) działały z zaszyfrowaną kolejką, utwórz customer managed key i dodaj w jego key policy uprawnienia dla principala tej usługi.
• Access policy (resource-based policy kolejki): dostęp innego konta albo usługi, np. sqs:SendMessage dla sns.amazonaws.com z warunkiem aws:SourceArn (fan-out). Wymuszenie TLS: Deny przy aws:SecureTransport=false.

Skalowanie konsumentów

Flota EC2 czytająca z kolejki skaluje się w Auto Scaling group na podstawie długości kolejki. AWS zaleca metrykę backlog per instance (ApproximateNumberOfMessages / liczba instancji InService) z target tracking, a nie surowe ApproximateNumberOfMessagesVisible. Liczbę oczekujących wiadomości możesz policzyć metric math, bez publikowania własnej metryki. W pytaniach często wystarczy jednak odpowiedź „alarm/target tracking na ApproximateNumberOfMessagesVisible”. Elastic Beanstalk ma do tego gotowy worker environment. Lambda skaluje pollery sama (ESM).

Metryki: ApproximateNumberOfMessagesVisible (czeka), ApproximateNumberOfMessagesNotVisible (in flight), ApproximateAgeOfOldestMessage (konsumenci nie nadążają), NumberOfEmptyReceives (warto włączyć long polling).

SQS przypomina szatnię, a SNS megafon na dworcu. Mówisz raz („pociąg do Krakowa opóźniony”) i słyszy to każdy, kto stoi na peronie. Nie wiesz, kto słucha, a nikt nie musi Cię o nic pytać. To pub/sub: wydawca (publisher) wysyła wiadomość do tematu (topic), a SNS wypycha (push) kopię do każdej subskrypcji.

Subskrybentem może być kolejka SQS, funkcja Lambda, endpoint HTTP/S, e-mail, SMS, aplikacja mobilna (push) albo strumień Amazon Data Firehose. SNS nie przechowuje wiadomości do późniejszego odczytu. Jeśli dostarczenie się nie uda, SNS ponawia próby według delivery policy, a potem wiadomość przepada, chyba że subskrypcja ma DLQ.

Najważniejszy wzorzec egzaminacyjny to fan-out SNS → SQS. Zamówienie trafia do tematu, temat do kilku kolejek (fakturowanie, wysyłka, analityka), a każda kolejka ma własnych konsumentów, którzy pracują w swoim tempie i nie gubią wiadomości, gdy są wyłączeni. Filter policy na subskrypcji sprawia, że kolejka dostaje tylko to, co ją interesuje.

Protokoły subskrypcji

Subskrypcje HTTP/S, e-mail i zasobów z innych kont trzeba potwierdzić, zanim zaczną dostawać wiadomości. Subskrypcja SQS lub Lambdy w tym samym koncie działa od razu.

Filter policies (skill 4.3.4)

Polityka to JSON: nazwy właściwości i listy dopuszczalnych wartości. Między różnymi kluczami działa AND, a w obrębie listy wartości OR. SNS ignoruje właściwości wiadomości, których polityka nie wymienia. Jeśli wiadomość nie ma atrybutu, którego wymaga polityka, nie zostanie dostarczona do tej subskrypcji.

// FilterPolicyScope = MessageAttributes (domyślnie) — dopasowanie do atrybutów wiadomości
{ "region": ["eu"], "type": ["order", "preorder"] }

// FilterPolicyScope = MessageBody — dopasowanie do pól w treści JSON (także zagnieżdżonych)
{ "order": { "amount": [ { "numeric": [">=", 1000] } ],
             "country": [ { "anything-but": ["US"] } ] } }

• Operatory: dokładne dopasowanie (domyślnie, wielkość liter ma znaczenie), prefix, suffix, anything-but, numeric (zakresy), exists, equals-ignore-case, cidr (adresy IP), a także $or.
• Ograniczenia: max 5 kluczy na politykę, łączna liczba kombinacji wartości ≤ 150, do 200 polityk na temat. Zmiana polityki działa po maksymalnie 15 minutach (eventual consistency).
• Filtrowanie po treści wymaga poprawnego JSON-a w body. Atrybuty mają typy String, String.Array, Number, Binary. Wiadomość SQS ma do 10 atrybutów. Gdy SNS przekazuje wiadomość do SQS z raw message delivery, atrybuty SNS stają się atrybutami SQS.

aws sns subscribe --topic-arn arn:aws:sns:eu-central-1:111122223333:orders \
  --protocol sqs --notification-endpoint arn:aws:sqs:eu-central-1:111122223333:eu-shipping \
  --attributes '{"FilterPolicy":"{\"region\":[\"eu\"]}","FilterPolicyScope":"MessageAttributes","RawMessageDelivery":"true"}'

Fan-out SNS → SQS krok po kroku

{ "Effect": "Allow",
  "Principal": { "Service": "sns.amazonaws.com" },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:eu-central-1:111122223333:eu-shipping",
  "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:sns:eu-central-1:111122223333:orders" } } }

Klasyczny przypadek: S3 event notifications nie pozwalają na dwie reguły z nakładającymi się prefiksami lub sufiksami dla tego samego typu zdarzenia. Żeby to samo zdarzenie trafiło do kilku konsumentów, wyślij je do SNS (albo EventBridge) i zrób fan-out.

FIFO topics

• Nazwa kończy się .fifo. Publish wymaga MessageGroupId i MessageDeduplicationId (albo content-based deduplication). Duplikat w ciągu 5 minut jest przyjmowany, ale nie dostarczany.
• Subskrybenci: tylko kolejki SQS (FIFO dla ścisłej kolejności, standard, gdy wystarczy best-effort i liczy się koszt). Do Lambdy dostarczysz przez kolejkę SQS i jej event source mapping.
• Limity: do 1 000 tematów FIFO na konto i 100 subskrypcji na temat FIFO (standard: 100 000 tematów, 12,5 mln subskrypcji na temat).

Dostarczanie, ponowienia, DLQ

Błędy client-side (usunięty endpoint, polityka blokuje SNS) nie są ponawiane. Błędy server-side (endpoint niedostępny) są ponawiane według polityki. W obu przypadkach, po porażce, wiadomość trafia do DLQ subskrypcji (atrybut RedrivePolicy subskrypcji, kolejka SQS w tym samym koncie i regionie co subskrypcja; dla subskrypcji tematu FIFO DLQ jest kolejką FIFO), a bez DLQ przepada.

Inne funkcje: Publish z MessageStructure=json wysyła inną treść każdemu protokołowi. PublishBatch to do 10 wiadomości. SSE przez KMS (KmsMasterKeyId). Delivery status logging do CloudWatch Logs pokazuje sukcesy i porażki dostarczeń (np. do Lambdy, SQS, HTTP). Message data protection (data protection policies) audytuje, maskuje, redaguje lub blokuje dane wrażliwe (PII).

Mobile push: tworzysz platform application (dane uwierzytelniające APNs/FCM), dla każdego urządzenia token urządzenia zamieniasz na platform endpoint (CreatePlatformEndpoint → EndpointArn) i publikujesz do endpointu (TargetArn) albo do tematu, który endpointy subskrybują. Logowanie użytkowników aplikacji to rola Cognito, nie SNS.

Pomyśl o sortowni poczty. Listy (zdarzenia, events) wpadają na taśmę (event bus). Przy taśmie stoją sortownicy (reguły, rules). Każdy ma kartkę z opisem: „biorę listy z Krakowa powyżej 1 kg” (event pattern). Gdy list pasuje, sortownik wkłada kopię do worka (target). Jeden list może pasować do wielu reguł, a każda reguła może mieć kilka worków.

EventBridge to serwerless router zdarzeń. Zdarzenia przychodzą od usług AWS (np. zmiana stanu EC2, wywołanie API zapisane w CloudTrail), z Twojego kodu (PutEvents) albo od partnerów SaaS. Reguły filtrują je wzorcami i wysyłają do celów: Lambda, SQS, SNS, Step Functions, Kinesis, API Gateway, inna szyna, dowolne API HTTP (API destinations) i wiele innych.

W porównaniu z SNS EventBridge filtruje po dowolnym polu w treści zdarzenia bogatszymi operatorami, potrafi przekształcić zdarzenie przed wysłaniem, archiwizować i odtwarzać zdarzenia, uruchamiać coś według harmonogramu i odbierać zdarzenia z aplikacji SaaS. SNS wygrywa przy bardzo dużej liczbie subskrybentów, w kanałach dla ludzi (SMS, e-mail, push) i przy FIFO.

Zdarzenie i wzorzec

// zdarzenie (envelope + detail)
{ "version": "0", "id": "…", "detail-type": "OrderPlaced", "source": "com.shop.orders",
  "account": "111122223333", "time": "2026-10-04T10:00:00Z", "region": "eu-central-1",
  "resources": [], "detail": { "amount": 1500, "country": "PL" } }

// wzorzec reguły: wszystkie podane pola muszą pasować (AND), w tablicy wystarczy jedna wartość (OR)
{ "source": ["com.shop.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": { "amount": [ { "numeric": [">=", 1000] } ],
              "country": [ { "anything-but": ["US", "CA"] } ] } }