Amazon DOP-C02: Architetture Guidate dagli Eventi e Automazione — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Le architetture event-driven disaccoppiano i producer dai consumer, pongono l’accento sulla comunicazione asincrona e rendono i sistemi resilienti a picchi di carico e guasti. I principi fondamentali sono il disaccoppiamento debole tramite eventi/messaggi, la scalabilità guidata dai consumer, gli handler idempotenti e la gestione esplicita dei fallimenti con relativa osservabilità. AWS fornisce i componenti di base per code durevoli, pub/sub, bus di eventi, elaborazione di stream, orchestrazione e automazione operativa. Padroneggiare l’interazione tra Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, i mapping delle origini eventi di Lambda, AWS Systems Manager Automation e OpsCenter, oltre a Kinesis Data Streams e Firehose, consente di costruire pipeline di dati e automazioni scalabili, tolleranti ai guasti e auditabili.

Messaggistica e Ingestion: SQS, SNS, Kinesis e Firehose

Amazon SQS fornisce code durevoli e scalabili per il disaccoppiamento. Le code standard offrono una consegna at-least-once (almeno una volta) e un ordinamento best-effort, con un throughput virtualmente illimitato; sono adatte per worker paralleli che tollerano messaggi duplicati e fuori ordine tramite chiavi di idempotenza e scritture condizionali. Le code FIFO garantiscono la consegna ordinata per gruppo di messaggi e una semantica di elaborazione exactly-once (esattamente una volta) con de-duplicazione (in una finestra di cinque minuti). Garantiscono l’ordine e l’elaborazione singola, ma sacrificano il throughput assoluto: utilizzare più gruppi di messaggi per parallelizzare all’interno di una coda FIFO, o abilitare la modalità FIFO ad alto throughput per migliaia di messaggi al secondo. Configurare il visibility timeout per coda o per messaggio in modo che superi il tempo massimo di elaborazione; con i consumer Lambda, impostare il visibility timeout ad almeno sei volte il timeout della funzione per consentire i tentativi (retry) prima che un messaggio riappaia. Usare il long polling per ridurre le ricezioni vuote. Le code Dead-Letter (DLQ) catturano i messaggi “poison” (avvelenati) quando un messaggio supera il maxReceiveCount; è possibile in seguito eseguire il redrive dalla DLQ alla coda di origine per una rielaborazione con le dovute correzioni. Monitorare ApproximateAgeOfOldestMessage per rilevare accumuli (backlog) e guidare modifiche alla concorrenza/autoscaling.

Amazon SNS fornisce un servizio pub/sub gestito e ad alto throughput. I publisher inviano un messaggio una sola volta a un topic; SNS lo distribuisce (fan-out) a più sottoscrizioni (SQS, Lambda, HTTP/S, email, mobile). Le policy di filtro delle sottoscrizioni utilizzano gli attributi del messaggio per instradare solo le notifiche pertinenti a ciascun sottoscrittore, riducendo i costi e il carico a valle; è possibile esprimere predicati come corrispondenza esatta, prefisso, intervalli numerici, anything-but (tutto tranne) ed exists (esiste). Usare SNS per scenari di fan-out, notifiche disaccoppiate e notifiche push su dispositivi mobili. Abilitare i tentativi (retry) e considerare l’uso di DLQ per sottoscrizione per le consegne non andate a buon fine. Per requisiti di fan-out ordinato, i topic SNS FIFO con sottoscrizioni a code SQS FIFO garantiscono l’ordinamento e la de-duplicazione.

Kinesis Data Streams fornisce stream ordinati e a bassa latenza con parallelismo a livello di shard per l’analisi in tempo reale e l’elaborazione di eventi. I producer scrivono record con chiavi di partizione (partition key) negli shard; i consumer (Lambda, KCL, consumer Enhanced Fan-Out, Kinesis Data Analytics) leggono in ordine per shard con checkpointing. Usare la capacità on-demand per carichi imprevedibili o shard provisioned con resharding per un throughput prevedibile. Ottimizzare le chiavi di partizione per bilanciare gli shard sovraccarichi (hot shard) e monitorare IteratorAge per il ritardo dei consumer (lag). L’Enhanced Fan-Out offre un throughput dedicato di 2 MB/s per stream di consumer con push a bassa latenza su HTTP/2.

Kinesis Data Firehose è un servizio di consegna completamente gestito per l’ingestion quasi in tempo reale in S3, Amazon OpenSearch Service, Splunk o endpoint HTTP, con trasformazione opzionale tramite Lambda, buffering (per dimensione/tempo), compressione e crittografia. Acquisisce dati da chiamate dirette PutRecord/PutRecordBatch, da Kinesis Data Streams o da sottoscrizioni a CloudWatch Logs/Events. Usare Firehose quando si necessita di una consegna gestita con trasformazione e raggruppamento (batching) e non è necessario creare e gestire codice per i consumer. Il partizionamento dinamico consente di instradare i record verso prefissi S3 in base a delle chiavi, per un’elaborazione efficiente a valle.

Automazione delle Operazioni e Ripristino: Systems Manager Automation e OpsCenter

AWS Systems Manager Automation fornisce runbook (documenti di tipo Automation) scritti in JSON/YAML con passaggi come aws:runCommand, aws:executeScript, aws:invokeLambda, aws:approve, aws:createStack e aws:executeAutomation. Le automazioni accettano parametri, emettono output, sono versionate con una cronologia delle modifiche ed vengono eseguite con un ruolo dedicato AutomationAssumeRole per il principio del privilegio minimo (least privilege) e per operazioni tra account e Regioni diverse. È possibile controllare la concorrenza e le soglie di errore su intere flotte di risorse, richiedere approvazioni e finestre di Change Calendar e integrare le notifiche tramite SNS. Le automazioni possono essere invocate in base a una pianificazione, da regole di EventBridge (per il ripristino quasi in tempo reale su eventi di AWS Health, CloudWatch o API), da azioni di ripristino di AWS Config per applicare una policy (ad esempio, applicando tag predefiniti ai volumi EBS o associando un profilo di istanza predefinito alle istanze EC2) e da OpsCenter.

OpsCenter aggrega i problemi operativi in OpsItems a partire da allarmi di CloudWatch, eventi di AWS Config, Health o da origini personalizzate. Ogni OpsItem tiene traccia di stato, priorità, deduplicazione, risorse correlate e link ai runbook. È possibile associare runbook “one-click” per soluzioni standard e abilitare il ripristino automatico collegando regole di EventBridge o Config per avviare un’automazione specifica quando un OpsItem viene creato o aggiornato con una condizione corrispondente (ad esempio, un gruppo di sicurezza che consente l’accesso SSH da 0.0.0.0/0, una deviazione dalla conformità delle patch o backup falliti). Si può utilizzare Systems Manager Explorer per visualizzare lo stato di salute della flotta di risorse e gli OpsItems aperti tra più account e Regioni. Questa combinazione — OpsItems come registrazioni durevoli e runbook di automazione come soluzioni codificate — consente operazioni verificabili e coerenti su larga scala.

Linee guida operative e di progettazione

Progettare per l’idempotenza su tutti i consumer, poiché la consegna at-least-once (almeno una volta) è comune. Preferire il fan-out guidato dagli eventi tramite SNS o regole di EventBridge per reazioni parallele a bassa latenza; preferire SQS per mettere in buffer i carichi di lavoro e proteggere i producer dalla lentezza dei consumer; preferire Kinesis quando per l’analytics sono richiesti un ordinamento rigoroso per shard e stream riproducibili. Utilizzare EventBridge Pipes per un’integrazione leggera e gestita tra sorgenti e destinazioni quando un consumer su misura è eccessivo, e EventBridge Scheduler per trigger basati sul tempo senza dover mantenere un’infrastruttura cron.

Dimensionare correttamente timeout e tentativi. Per SQS, il timeout di visibilità deve superare il tempo massimo di elaborazione più i tentativi; per gli stream, limitare i tentativi e impostare MaximumRecordAgeInSeconds per evitare di riprodurre all’infinito record problematici. Utilizzare sistematicamente DLQ o destinazioni on-failure e aggiungere dashboard e allarmi su SQS ApproximateAgeOfOldestMessage, Lambda ConcurrentExecutions/Throttles/Errors, IteratorAge, Step Functions ExecutionFailed/TimedOut e EventBridge FailedInvocations. Quando un traffico con picchi è inevitabile ma gli SLA di latenza sono rigorosi, utilizzare la provisioned concurrency di Lambda per pre-riscaldare la capacità. Per la governance, preferire EventBridge con resource policy per il routing tra account e la funzionalità di archiviazione/riproduzione per supportare l’evoluzione dei consumer e il ripristino da incidenti.

Scenario pratico

Shopify ha bisogno di modernizzare l’elaborazione degli ordini per gli eventi di vendita flash, aggiungendo al contempo analytics in tempo reale e remediation automatizzata quando i servizi a valle rallentano o falliscono.

1. Ingestione e fan-out degli eventi d’ordine

• Utilizzare un topic SNS FIFO per pubblicare eventi OrderPlaced dal checkout, garantendo notifiche ordinate e deduplicate per OrderId. Le sottoscrizioni includono:
  • Coda SQS FIFO (Order-Workers) per l’evasione degli ordini, preservandone l’ordine.
  • Event bus personalizzato di EventBridge (CommerceBus) per la governance e l’instradamento aggiuntivo.
  • Delivery stream di Kinesis Data Firehose per la consegna quasi in tempo reale degli Ordini su S3 con compressione GZIP per l’analytics. Perché SNS FIFO: Fornisce una semantica ordinata ed exactly-once (esattamente una volta) con un fan-out scalabile verso più sottoscrittori senza accoppiare i publisher ai consumer.

2. Mettere in buffer ed elaborare l’evasione degli ordini

• Lambda consuma dalla coda SQS FIFO tramite un event source mapping con una dimensione del batch di 10, risposta parziale del batch abilitata e concorrenza massima limitata per proteggere le API del magazzino a valle. Il timeout di visibilità della coda è impostato a sei volte il timeout della Lambda per gestire i tentativi. Una DLQ cattura i poison message con maxReceiveCount=3; un workflow di redrive rielabora in seguito i messaggi corretti. Perché SQS FIFO + Lambda ESM: Garantisce il sequenziamento per singolo ordine, isola la lentezza dei servizi a valle tramite buffering e offre una gestione degli errori a grana fine.

3. Orchestrare una saga multi-step

• Un workflow Standard di Step Functions orchestra l’acquisizione del pagamento, la prenotazione dell’inventario, il controllo frodi e la prenotazione della spedizione, con tentativi, timeout e task di compensazione (rimborso, riassortimento) sui percorsi di fallimento. Il primo Task è attivato da una Lambda invocata dal consumer SQS. Perché Standard: Progressione di stato a lunga esecuzione, auditabile ed exactly-once attraverso sistemi esterni, con una ricca gestione degli errori.

4. Instradare gli eventi di dominio verso le funzionalità

• Il CommerceBus riceve eventi Order* tramite PutEvents dai servizi producer e dalla sottoscrizione SNS. Regole di EventBridge:
  • Corrispondenza con OrderPlaced per notificare il Marketing (Lambda) e creare un caso di supporto (integrazione API AWS Support) quando ordinano clienti di alto valore.
  • Inoltro di OrderFailed all’event bus di un account operativo centrale utilizzando una resource policy per la governance tra account. Perché EventBridge: Instradamento centralizzato, filtraggio, consegna tra account e la capacità di aggiungere nuovi consumer senza modificare i producer.

5. Collegare tramite Pipe il feed di un partner per l’arricchimento

• EventBridge Pipes collega la coda SQS Standard di un partner (SKU in arretrato) a un workflow Express di Step Functions che arricchisce gli articoli tramite una funzione Lambda e invia i risultati a una coda SQS interna per il riassortimento. Perché Pipes + Express: Integrazione gestita a basso overhead con arricchimento leggero, ad alto throughput e a basso costo.

6. Analytics e ricerca in tempo reale

• Un Kinesis Data Stream raccoglie eventi di clickstream e operativi. Lambda (consumer Enhanced Fan-Out) esegue la sessionizzazione e Kinesis Data Analytics aggrega i KPI. Firehose consegna gli ordini trasformati e i dati di analytics a un data lake S3 e ad Amazon OpenSearch Service con partizionamento dinamico per data/mercato per query efficienti. Perché Streams + Firehose: Elaborazione ordinata e a bassa latenza per l’analytics, con consegna e trasformazione gestite verso lo storage e la ricerca.

7. Automazione basata sul tempo

• EventBridge Scheduler esegue un cron ogni minuto per pubblicare InventorySnapshotRequested su CommerceBus, attivando un workflow Express di Step Functions che compila snapshot da tutti i magazzini per un’accuratezza dello stock quasi in tempo reale. Perché Scheduler: Cron nativo e resiliente senza infrastruttura personalizzata.

8. Remediation e operazioni automatizzate

• Le regole di AWS Config rilevano SSH aperto o ACL S3 pubbliche nei VPC di evasione ordini. Le Managed remediation invocano i runbook di Systems Manager Automation per correggere il drift. Gli allarmi di CloudWatch su SQS ApproximateAgeOfOldestMessage e Lambda IteratorAge creano OpsItem in OpsCenter; i runbook associati scalano la provisioned concurrency su Lambda specifiche, aumentano la capacità riservata di Step Functions o allargano temporaneamente le finestre di batch. Una regola di EventBridge sugli eventi di manutenzione EC2 di AWS Health si rivolge a un documento SSM Automation per riavviare in modo controllato le istanze interessate durante le finestre di manutenzione. Perché OpsCenter + Automation: Tracciamento dei problemi centralizzato e auditabile con remediation con un clic o automatiche, basate sul principio del privilegio minimo (least-privilege), che vengono eseguite in sicurezza tra account e regioni.

Questo design sostiene i picchi delle vendite flash attraverso il buffering e il fan-out, preserva gli invarianti di business tramite l’orchestrazione, fornisce analytics in pochi secondi e chiude il cerchio con una remediation automatizzata e guidata da policy.

← Alta Affidabilità · Tutti i domini · Storage →

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

Sfoglia Amazon →