Amazon SAA-C03: Applicatie-integratie, Messaging & Streaming — Studiegids

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

Onderdeel van de AWS SAA-C03 — Complete studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Amazon SQS: Ontkoppeling, Volgorde en Leveringssemantiek

Amazon SQS is een volledig beheerde, pull-gebaseerde berichtenwachtrij waarvan de primaire architecturale rol is om producers van consumers te ontkoppelen. Een synchrone aanroepketen koppelt de latency en beschikbaarheid van de producer aan elke downstream-afhankelijkheid; het invoegen van een SQS-wachtrij zet dit om in een asynchrone overdracht. Producers plaatsen berichten in de wachtrij met de snelheid waarmee het verkeer binnenkomt, en consumers halen berichten uit de wachtrij met de snelheid waarmee ze veilig kunnen verwerken. Dit is de canonische oplossing voor schrijfpieken die anders een RDS-instantie zouden overweldigen — de wachtrij absorbeert de piek, en een begrensde vloot van consumers verwerkt de wachtrij met een gecontroleerde concurrency, waardoor het aantal databaseverbindingen onder controle blijft.

Er bestaan twee typen wachtrijen, en de keuze bepaalt zowel de doorvoersnelheid als de leveringsgaranties.

Standard queues leveren minimaal eenmaal met slechts best-effort-volgorde. Duplicaten kunnen verschijnen wanneer een consumer een bericht niet verwijdert voordat de visibility timeout verloopt, of wanneer de gedistribueerde backend een bericht opnieuw afspeelt over verschillende shards. Zelfs als je tijdens het testen nooit een duplicaat ziet, is de service architectonisch toegestaan om opnieuw te leveren, vooral tijdens een broker-failover. Aannemen dat standaard wachtrijen ‘meestal’ eenmaal leveren is een ontwerpfout, geen operationeel risico — het is gegarandeerd dat duplicaten uiteindelijk op schaal zullen voorkomen. De logica van de consumer moet daarom idempotent zijn: een MessageId of business key bijhouden in DynamoDB met een conditionele schrijfoperatie, een idempotency key gebruiken bij downstream API-aanroepen, of vertrouwen op upsert-semantiek.

FIFO queues bieden strikte volgorde binnen een MessageGroupId en precies-eenmaal-verwerking via een MessageDeduplicationId (expliciet of een SHA-256 van de body) die duplicaten onderdrukt gedurende een venster van 5 minuten. De MessageGroupId is het centrale concept: alle berichten met dezelfde group ID worden strikt in volgorde aan één enkele consumer tegelijk geleverd, terwijl verschillende group ID’s parallel kunnen worden verwerkt. Voor een orderverwerkingssysteem waar de gebeurtenissen van elke klant sequentieel moeten zijn, maar verschillende klanten onafhankelijk zijn, gebruik je MessageGroupId = customerId. Het gebruik van één enkele group ID voor alles serialiseert de volledige workload en vernietigt de doorvoersnelheid. Deduplication ID’s zijn de juiste primitieve om dubbele ordercreatie te voorkomen wanneer een gebruiker een vastgelopen checkout opnieuw indient: de client genereert een deterministisch idempotency-token (een UUID gekoppeld aan de checkout-sessie) en SQS negeert alle dubbele inzendingen die binnen het venster arriveren.

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

Het selecteren van een standaard wachtrij wanneer de vereiste ‘volgorde’ of ‘geen duplicaten’ specificeert, is de klassieke fout. Geen enkele hoeveelheid applicatielogica kan de volgorde herstellen die de wachtrij nooit heeft behouden, omdat berichten van verschillende backend-hosts door elkaar binnenkomen. Kies FIFO wanneer de workload volgorde vereist (transactielogboeken, state-machine-transities) of precies-eenmaal-semantiek (betalingsverwerking, voorraadafname).

Visibility Timeout, Poison Messages en Payloadlimieten

Wanneer een consumer een bericht ontvangt, maakt SQS het onzichtbaar voor andere consumers gedurende de visibility timeout (standaard 30 seconden, max 12 uur). Als de consumer het bericht verwijdert voordat de timeout verloopt, is het weg; zo niet — omdat de consumer is gecrasht, of de verwerking simpelweg te lang duurde — verschijnt het bericht opnieuw en wordt het opnieuw geleverd. Het instellen van de visibility timeout korter dan de daadwerkelijke verwerkingstijd is een hoofdoorzaak van dubbele verwerking: een Lambda die 45 seconden nodig heeft voor een wachtrij met de standaard 30-seconden timeout zal elk bericht minstens twee keer opnieuw verwerken. Stel de timeout in op ten minste de p99-verwerkingstijd (de richtlijn van AWS voor door Lambda aangestuurde wachtrijen is minstens 6× de functie-timeout), en voor taken van onvoorspelbare lengte, verleng de timeout dynamisch:

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

Dead-letter queues (DLQ’s) vangen ‘poison-pill’-berichten op. Een RedrivePolicy op de bronwachtrij specificeert een maxReceiveCount (meestal 3–5); zodra dit wordt overschreden, verplaatst SQS het bericht naar de DLQ voor offline inspectie. De DLQ moet van hetzelfde type zijn als de bronwachtrij (FIFO ↔ FIFO). Zonder een DLQ blijven misvormde berichten oneindig circuleren, en bij FIFO is dit bijzonder schadelijk — de volgorde voorkomt dat volgende berichten in dezelfde groep worden geleverd totdat de boosdoener is afgehandeld, dus één slecht bericht stopt een hele groep.

SQS-berichten hebben een limiet van 256 KB. Voor grotere payloads — bijvoorbeeld een taak met een gerenderd document — gebruik je de SQS Extended Client Library, die de payload naar S3 schrijft en alleen een bucket/key-referentie in de wachtrij plaatst. De consumer-library haalt deze transparant op bij ontvangst. Splits payloads niet over meerdere berichten (je verliest atomiciteit en volgorde) en probeer geen 2 MB blob te base64-encoderen in de hoop dat het past.

Wachtrij-gestuurde Autoscaling

Voor een consumer-vloot op EC2 of ECS achter een SQS-wachtrij is het juiste schaal-signaal niet CPU — het is de backlog van de wachtrij. CPU loopt achter op de aankomstsnelheid en interpreteert een verzadigde consumer verkeerd als ‘druk maar redt het wel’. De canonische schaalmetriek is ApproximateNumberOfMessagesVisible, maar direct schalen op de ruwe wachtrijdiepte is grof. De aanbevolen aanpak is de backlog-per-instantie custom metric:

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Publiceer dit naar CloudWatch en stuur een target-tracking-beleid aan op een Auto Scaling-groep of ECS-service, zodat elke worker een begrensde backlog behoudt (bijvoorbeeld 10 berichten). Dit zorgt voor een soepele scale-out tijdens pieken en voorkomt oscillatie wanneer de wachtrijdiepte klein is maar de consumers al verzadigd zijn. Voor scale-in, koppel dit met ApproximateAgeOfOldestMessage om te voorkomen dat capaciteit wordt beëindigd terwijl er nog oude berichten in de wachtrij staan.

Amazon SNS: Fan-Out, Filtering en Cross-Account Delivery

SNS is een push-gebaseerde publish/subscribe-dienst. Publishers schrijven naar een topic; SNS pusht naar elke subscription: SQS-wachtrijen, Lambda-functies, HTTP(S)-endpoints, e-mail, sms, Kinesis Data Firehose of mobile push. Het dominante patroon voor duurzaamheid is SNS → SQS fan-out: één topic waarop meerdere SQS-wachtrijen zijn geabonneerd, zodat elke downstream-dienst zijn eigen duurzame buffer, retry-beleid en DLQ heeft, terwijl de publisher alleen het topic kent. Als een consumer-dienst urenlang uitvalt, verzamelt de wachtrij berichten en verwerkt deze bij herstel — SNS alleen mist die buffering en zal zijn retry-beleid uitputten.

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

Berichtfiltering stelt elke subscription in staat een JSON-filterbeleid te declareren, zodat SNS alleen overeenkomende berichten aflevert. Dit voorkomt het anti-patroon waarbij elke consumer elk bericht ontvangt en client-side filtert:

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

Twee gedragseigenschappen zijn van belang. Ten eerste, standaard SNS-topics garanderen geen volgorde tussen berichten — per-subscriber retry-timers en onafhankelijke netwerkpaden maken herordening routine. Als volgorde belangrijk is, gebruik dan een SNS FIFO-topic geabonneerd op SQS FIFO-wachtrijen; de message group ID wordt end-to-end doorgegeven. Anders moeten subscribers idempotent zijn en tolerant voor herordening. Ten tweede, HTTP(S)-subscriptions proberen het opnieuw volgens een afleveringsbeleid (standaard: drie onmiddellijke retries, dan exponentiële backoff tot een uur, daarna weggooien). Subscribers moeten binnen 15 seconden met 2xx reageren, de x-amz-sns-message-type-handtekening valideren en — voor onbetrouwbare endpoints — altijd een SNS DLQ hebben (doorgestuurd naar SQS), zodat niet-afgeleverde berichten worden opgevangen in plaats van stilzwijgend te worden verwijderd.

Cross-account aanroepen is een veelvoorkomende valkuil. Wanneer Account A publiceert naar een topic dat via fan-out naar een Lambda in Account B gaat, zijn twee policies vereist: de SNS topic policy (of de subscription-richting) moet de subscription toestaan, en de Lambda resource-based policy moet lambda:InvokeFunction toestaan vanaf sns.amazonaws.com met een SourceArn-conditie die overeenkomt met het topic. Het ontbreken van de Lambda resource policy is de meest voorkomende faalmodus — de subscription lijkt in orde, maar aanroepen worden afgewezen met een 403-fout. Als het topic is versleuteld met een door de klant beheerde KMS-sleutel, moet de key policy ook kms:Decrypt en kms:GenerateDataKey toekennen aan de publicerende principal en aan sns.amazonaws.com.

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

Amazon EventBridge: Gerouteerde Eventbussen

EventBridge (voorheen CloudWatch Events) breidt pub/sub uit met op inhoud gebaseerde routering, schema-ontdekking, SaaS-partner eventbronnen en archiveren/afspelen. Events stromen door eventbussen (default, custom of partner) en worden gematcht met rules waarvan de eventpatronen filteren op JSON-structuur. Rules kunnen payloads transformeren via inputpaden en inputtemplates, dead-letter doelen toevoegen en afleveren bij meer dan 20 native doelen, waaronder Lambda, Step Functions, ECS-taken, SQS, SNS, Kinesis en API-destinations.

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

Het onderscheid met SNS is architectonisch. SNS is geoptimaliseerd voor broadcast met hoge doorvoer naar homogene abonnees met eenvoudige attribuutfiltering en lagere latentie. EventBridge is geoptimaliseerd voor heterogene event-driven architecturen: veel producers zenden verschillende eventschema’s uit, en consumers abonneren zich op basis van een patroon in plaats van een topic. Voor een monoliet die wordt opgesplitst in microservices — vooral wanneer producers SaaS-partners of AWS-diensten (Config, GuardDuty, CodePipeline, CloudTrail) omvatten die native events uitzenden — is EventBridge doorgaans de juiste keuze. Voor fan-out met extreem hoog volume en lage latentie naar identieke abonnees, wint SNS nog steeds omdat EventBridge een iets hogere latentie per event heeft en een lager standaard doorvoerplafond.

Amazon MQ: Brokered Messaging voor Bestaande Protocollen

Amazon MQ is een beheerde broker die ActiveMQ of RabbitMQ draait. Het is bedoeld om on-premises workloads te migreren die afhankelijk zijn van AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire, of JMS zonder de applicatie te herschrijven. Als een betalingssysteem een externe JMS-broker gebruikt met transactionele ’exactly-once’-semantiek, behoudt een migratie naar Amazon MQ het wire-protocol en de leveringsgaranties, terwijl het infrastructuurbeheer wordt geëlimineerd. Kies SQS/SNS/EventBridge voor greenfield AWS-native ontwerpen; kies Amazon MQ alleen wanneer protocolcompatibiliteit de beperking is.

Kinesis Data Streams

Kinesis Data Streams (KDS) is een duurzaam, geordend, gepartitioneerd log voor streaming ingest met hoge doorvoer — clickstreams, IoT-telemetrie, log-aggregatie. Records worden in shards geplaatst op basis van de PartitionKey; de volgorde wordt gegarandeerd binnen een shard, niet over de hele stream. Elke shard ondersteunt 1 MB/s of 1.000 records/s schrijven en 2 MB/s lezen (of hoger met Enhanced Fan-Out). Records worden standaard 24 uur bewaard, uitbreidbaar tot 365 dagen, zodat meerdere onafhankelijke consumers dezelfde geschiedenis opnieuw kunnen afspelen — iets wat SQS niet kan, omdat SQS verwijdert na een ‘ack’.

On-demand modus elimineert het rekenwerk met shards door automatisch op te schalen tot 200 MiB/s schrijven per stream, ideaal voor onvoorspelbaar verkeer. Provisioned modus is goedkoper in een stabiele toestand waar de capaciteit bekend is.

Kies KDS boven SQS FIFO wanneer de workload een geordende, herhaalbare ingest vereist met doorvoersnelheden die FIFO niet aankan (FIFO piekt ver onder de miljoenen records/seconde die KDS aankan), wanneer meerdere onafhankelijke consumers dezelfde stream moeten lezen, of wanneer de formulering “oorspronkelijke volgorde tijdens de verwerking behouden” wordt gecombineerd met een hoog volume.

Kinesis Data Firehose

Kinesis Data Firehose is een volledig beheerde delivery-service. Het leest data uit een Kinesis-stream of via directe PUT-requests, buffert op basis van grootte (1–128 MB) of tijd (60–900 seconden, wat het eerst wordt bereikt), kan optioneel een Lambda aanroepen voor transformatie per record (opschonen van PII, normalisatie van formaten), kan direct JSON converteren naar Parquet of ORC met behulp van een Glue-schema, versleutelt met KMS en levert af aan S3, Redshift, OpenSearch of Splunk. Het heeft geen shards, geen consumers om te beheren en een prijsmodel op basis van betalen per GB.

Het canonieke patroon voor schaalbare opname (ingestion) in een data lake combineert Data Streams (on-demand) als de duurzame buffer met Firehose voor de aflevering aan S3:

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

Voor het opnemen van miljoenen mobiele events, het versleutelen ervan en het opslaan in S3 als Parquet, is het juiste antwoord Firehose met Parquet-conversie en een KMS-sleutel — niet KDS plus een custom consumer plus een handgeschreven Parquet-writer, wat aanzienlijk meer code en infrastructuur vereist. Firehose is near-real-time en ondersteunt geen replay aan de consumer-zijde; wanneer replay vereist is, behoud dan KDS in het traject.

Kinesis Data Analytics (nu Managed Service for Apache Flink) voert SQL- of Flink-jobs uit op een stream voor windowed aggregations.

Lambda-integratie en Retry-semantiek

Lambda integreert met deze services met wezenlijk verschillend gedrag bij het opnieuw proberen (retry):

Voor SQS, zorg dat de Lambda-functie-timeout ≤ de visibility timeout van de wachtrij is, en stel de visibility timeout in op minstens 6× de functie-timeout. Voor Kinesis, schakel BisectBatchOnFunctionError in en configureer een OnFailure-bestemming (SQS of SNS) zodat één enkel ‘poison record’ niet de hele shard voor onbepaalde tijd blokkeert.

Keuzetabel

← Analytics · Alle domeinen · Beveiliging →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Amazon →