Amazon DVA-C02: Messaggistica, Streaming e Architetture guidate dagli eventi (SNS, SQS, Kinesis, EventBridge, Step Functions) — Guida allo studio

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fa parte della AWS Developer Associate DVA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

EventBridge e Step Functions per il routing e l’orchestrazione

EventBridge eccelle nel routing di eventi basato su schemi e nelle integrazioni cross-account/con partner di eventi, utilizzando PutEvents per iniettare eventi e PutRule/PutTargets per instradarli verso SQS, Lambda, Kinesis, Step Functions o endpoint HTTP. EventBridge utilizza i pattern di eventi (event patterns) per il filtraggio e supporta l’archiviazione e il replay per ricostruire lo stato. Utilizzare le code dead-letter (DLQ) per le regole (Target con SqsParameters o DeadLetterConfig) e tenere presente che EventBridge fornisce tentativi di riesecuzione (retry) con backoff esponenziale, seguiti dall’invio alla DLQ in caso di fallimento. Per l’orchestrazione, scegliere Step Functions: macchine a stati Standard per flussi di lavoro durevoli e di lunga durata con cronologia delle esecuzioni e meccanismi di retry/Catch integrati, ed Express per flussi di lavoro di breve durata ad alto throughput con costi inferiori ed esecuzione best-effort. Utilizzare le integrazioni di tipo Task con le integrazioni di servizio (arn:aws:states:::lambda:invoke o arn:aws:states:::aws-sdk:apigateway:invoke) e i pattern di callback che usano “waitForTaskToken” per implementare approvazioni esterne asincrone. Implementare i meccanismi di retry e Catch con backoff esponenziale e utilizzare HeartbeatSeconds per i task di lunga durata. Utilizzare lo stato Map per parallelizzare l’elaborazione di grandi collezioni, ma prestare attenzione alla concorrenza e al throttling dei servizi a valle (downstream). Un errore comune è scegliere erroneamente la modalità Express per flussi di lavoro che richiedono una cronologia durevole con semantica exactly-once: scegliere la modalità Standard per garantire l’auditabilità. Inoltre, garantire l’idempotenza nei task invocati da Step Functions passando un token di idempotenza e facendo in modo che i servizi di destinazione applichino l’unicità al momento della scrittura.

Problema Pratico: Scenario d’Uso

Scenario: StreamlyGames gestisce un backend di gioco globale in un ambiente AWS multi-account. I giocatori caricano su S3 clip di gameplay da 10 MB; una pipeline di elaborazione deve transcodificare i video, eseguire analisi di ML e scrivere i risultati su Aurora Serverless con un’elaborazione ordinata, deduplicata e con consumer scalabili.

Sfida: Garantire che ogni file caricato attivi un’elaborazione exactly-once in ordine per ogni giocatore, gestire i picchi di traffico senza perdere eventi e scalare i consumer per l’inferenza ML prevenendo al contempo scritture duplicate nel database.

Approccio Raccomandato:

1. Creare una notifica di evento S3 per pubblicare gli eventi di creazione oggetto (object-created) su un bus personalizzato di EventBridge (PutEvents) e anche su una coda SQS FIFO (CreateQueue con FifoQueue=true), usando il PlayerID come MessageGroupId e un MessageDeduplicationId basato sull’ETag di S3.
2. Configurare un consumer Lambda con un event source mapping SQS (CreateEventSourceMapping) utilizzando BatchSize=1, FunctionResponseTypes=[“ReportBatchItemFailures”], e impostare un VisibilityTimeout maggiore del tempo massimo di elaborazione; utilizzare ChangeMessageVisibility quando si chiamano API ML di terze parti.
3. La funzione Lambda esegue scritture idempotenti sul DB Aurora utilizzando una chiave di idempotenza deterministica (INSERT … ON CONFLICT DO NOTHING o un vincolo di unicità) e salva i progressi (checkpoint); per chiamate ML di lunga durata, utilizzare Step Functions in modo asincrono con token di task (arn:aws:states:::lambda:invoke.waitForTaskToken) o Step Functions Express per un throughput elevato.
4. Per scalare l’inferenza, scrivere eventi intermedi su Kinesis Data Streams per shard per regione per consumer ad alto throughput e abilitare i consumer con enhanced fan-out (SubscribeToShard) per flotte di worker ML dedicate; monitorare IteratorAgeMilliseconds e usare UpdateShardCount per scalare.

Logica: Utilizzare SQS FIFO per garantire l’ordinamento per giocatore e la deduplicazione in fase di ingestion, scritture idempotenti sul DB per applicare la semantica exactly-once, e Kinesis con enhanced fan-out o Step Functions per gestire l’elaborazione ML ad alto throughput e con picchi di carico (bursty), mantenendo i consumer disaccoppiati e scalabili.

← Database e Caching (RDS · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →