Amazon SOA-C02: Serverless e integrazione di applicazioni — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Il serverless e l’integrazione di applicazioni coprono l’esecuzione di applicazioni basate su eventi senza gestire server e la connessione affidabile tra i servizi. L’importanza operativa risiede nella gestione della scalabilità, della latenza, delle modalità di fallimento e dell’accesso con privilegi minimi, mantenendo al contempo i costi prevedibili. Questo dominio si concentra sul comportamento di Lambda (cold start, concorrenza), sulla consegna affidabile degli eventi (EventBridge, SNS, SQS), sui controlli di sicurezza (ruoli di esecuzione e permessi) e sull’osservabilità per i flussi asincroni.

Aspetti operativi e concorrenza di AWS Lambda

Le prestazioni e la disponibilità di Lambda dipendono dai cold start, dai limiti di concorrenza e dai controlli di throttling. I cold start si verificano quando Lambda deve inizializzare un nuovo ambiente di esecuzione; per ridurne l’impatto, si usa la concorrenza allocata (provisioned concurrency) (

undefined

) per i percorsi critici in termini di latenza e si preferiscono runtime più leggeri o un lavoro di inizializzazione ridotto. Si riserva e si limita la concorrenza con la concorrenza riservata (reserved concurrency) (

undefined

) per proteggere i servizi a valle e applicare quote per funzione; si monitorano le metriche CloudWatch ConcurrentExecutions e Throttles.

I modelli di retry e di invocazione differiscono in base alla modalità: le invocazioni sincrone (API Gateway, Invoke diretto) restituiscono immediatamente gli errori; le invocazioni asincrone (EventBridge, SNS, notifiche asincrone S3) utilizzano la policy di retry asincrona di Lambda (due tentativi con backoff) e possono usare DLQ o destinazioni. Per i mapping delle origini eventi (stream SQS, Kinesis, DynamoDB), il poller di Lambda effettua tentativi finché il messaggio non scade o la policy di redrive dell’origine evento non attiva un messaggio non recapitabile. Configurare timeout e memoria in modo conservativo (

undefined

) e impostare il timeout di visibilità di SQS > timeout della funzione (si raccomanda visibilità >= timeout della funzione * 2) per ridurre l’elaborazione duplicata.

Architetture event-driven con EventBridge

EventBridge fornisce un event bus gestito con routing flessibile, registro degli schemi, consegna cross-account e impostazioni di retry/DLQ. Utilizzare event bus personalizzati per la separazione dei domini e event bus dei partner per le integrazioni SaaS; creare regole con pattern (

undefined

) e collegare target con configurazione di dead-letter e retry (il JSON dei target supporta DeadLetterConfig e RetryPolicy). Usare il registro degli schemi per individuare e applicare la struttura degli eventi; registrare gli schemi quando i producer sono ben definiti e usare i Code Bindings per generare modelli tipizzati dove utile.

Scegliere EventBridge quando si necessita di:

• Routing e filtraggio complessi con pattern di eventi ricchi o isolamento cross-account/event-bus
• Supporto nativo per più target (Lambda, Step Functions, Kinesis, SQS, SNS)
• Individuazione e governance degli schemi tra i team

Scegliere SNS/SQS diretti quando si necessita di un fan-out più semplice o di una semantica di coda garantita:

• SNS per il fan-out verso molti sottoscrittori e semantica push
• SQS per l’elaborazione durevole basata su pull con timeout di visibilità e policy di redrive

Messaggistica con SNS e SQS (DLQ, timeout di visibilità)

SNS è un servizio push pub/sub; SQS è una coda durevole con semantica pull. Per un’elaborazione ad alta affidabilità, preferire i pattern SNS -> SQS -> Lambda per disaccoppiare l’ingestion dall’elaborazione e ottenere controllo su retry e visibilità. Configurare la policy di redrive di SQS (

undefined

) per spostare i messaggi in una DLQ dopo un maxReceiveCount e assicurarsi che il timeout di visibilità sia sufficientemente lungo da evitare una riconsegna prematura (si raccomanda visibilità >= timeout della funzione * 2). Per esigenze FIFO, usare SQS FIFO o SNS FIFO con ID del gruppo di messaggi per preservare l’ordine e ID di deduplicazione per evitare duplicati.

Opzioni di gestione dei messaggi non recapitabili e dove usarle:

• Invocazioni asincrone di Lambda: configurare DeadLetterConfig o Destinations (AsyncEventInvokeConfig) per inviare i fallimenti a SQS/SNS o invocare un’altra Lambda.
• SQS: configurare la policy di redrive verso una DLQ SQS per i messaggi “poison” e impostare un maxReceiveCount appropriato.
• EventBridge: impostare DeadLetterConfig e RetryPolicy sui target della regola per catturare gli eventi non recapitabili.

L’idempotenza è essenziale: implementare handler idempotenti usando scritture condizionali di DynamoDB (PutItem con ConditionExpression attribute_not_exists(pk)), token di idempotenza memorizzati con TTL o la deduplicazione di SQS FIFO per una semantica exactly-once.

Permessi delle funzioni, ruoli e principio del privilegio minimo

Applicare il principio del privilegio minimo ai ruoli di esecuzione di Lambda e alle policy basate sulle risorse della funzione. Iniziare con AWSLambdaBasicExecutionRole per i log di CloudWatch, poi concedere ARN espliciti delle risorse per i servizi (es. dynamodb:PutItem su arn:aws:dynamodb:region:acct:table/MyTable). Evitare i caratteri jolly come Resource: "*" quando sono possibili ARN specifici. Usare policy gestite o personalizzate limitate per azione e risorsa, e includere condizioni (aws:SourceAccount, aws:SourceArn) quando si aggiungono permessi di invocazione per i servizi:

• Aggiungere il permesso di invocazione per EventBridge:

undefined

• Per SNS: usare la condizione source-arn per limitare quale topic può invocare la funzione

Criteri decisionali:

• Usare policy basate sulle risorse della funzione per consentire le invocazioni da parte dei servizi (EventBridge, SNS, CloudWatch Events)
• Usare il ruolo di esecuzione IAM per i permessi a runtime (DynamoDB, S3, Secrets Manager)
• Preferire permessi a livello di risorsa e vincoli condizionali per ridurre il raggio d’impatto

Osservabilità e troubleshooting per il serverless

L’osservabilità deve coprire metriche, log, tracce e lo stato della consegna asincrona. Metriche chiave di CloudWatch: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (per trigger da stream e SQS). Per la visibilità sui fallimenti asincroni, monitorare le metriche “AsyncEventInvoke” e impostare allarmi CloudWatch su DeadLetterErrors e Throttles. Abilitare il tracciamento X-Ray (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active) per ottenere tracce end-to-end tra i servizi e visualizzare cold-start, latenze downstream ed eccezioni.

Utilizzare log JSON strutturati e query di CloudWatch Logs Insights per trovare rapidamente pattern di errore; strumentare controlli di idempotenza e registrare i correlation ID nei log. Per il tracciamento distribuito, propagare esplicitamente i trace ID nei payload degli eventi per i flussi EventBridge/SNS se il contesto automatico viene perso. Per gli event-source mapping di SQS, monitorare ApproximateAgeOfOldestMessage e impostare allarmi se cresce, indicando contropressione (backpressure) o throttling. Catturare e generare allarmi sulla metrica Throttles di Lambda, e tracciare i compromessi tra utilizzo e costo della concorrenza fornita (provisioned concurrency).

Errori Comuni e Criteri Decisionali

• Non configurare DLQ o affidarsi solo ai tentativi di default: configurare DLQ o Destinations per le Lambda asincrone e la policy di redrive di SQS per le code per catturare i “poison message” per l’ispezione manuale.
• Timeout di visibilità errato su SQS che porta a elaborazioni duplicate: impostare il timeout di visibilità >= timeout della funzione * 2 e tenere conto dei tentativi e delle chiamate downstream per evitare duplicati.
• Ruoli di esecuzione Lambda eccessivamente permissivi: evitare Resource: "*" e aggiungere condizioni sul servizio/sorgente (aws:SourceArn, aws:SourceAccount) alle policy di invocazione e di risorsa.
• Ignorare i limiti di concorrenza causando throttling: usare la concorrenza riservata (reserved concurrency) per limitare le funzioni, la concorrenza fornita (provisioned concurrency) per funzioni sensibili alla latenza, e monitorare ConcurrentExecutions/Throttles.
• Mancanza di tracciamento attraverso i confini asincroni: aggiungere correlation ID agli eventi e abilitare X-Ray o propagare gli header di traccia per ricostruire i flussi.
• Uso improprio di SNS diretto a Lambda per esigenze di durabilità: preferire SNS->SQS->Lambda quando si necessita di buffering durevole, controllo della visibilità e una gestione più semplice delle DLQ.

Problema Pratico: Scenario d’Uso

AcmePayments riceve un alto volume di eventi di pagamento tramite EventBridge e riscontra throttling intermittente delle Lambda ed elaborazioni duplicate durante i picchi. Hanno bisogno di un’elaborazione affidabile, nessuna perdita di dati e un carico limitato sul sistema downstream DynamoDB.

1. Creare un bus di eventi personalizzato su EventBridge e una regola per intercettare gli eventi di pagamento; aggiungere una coda SQS FIFO come target durevole con DeadLetterConfig e RetryPolicy nella configurazione del target.
2. Configurare Lambda per leggere dalla coda SQS (event source mapping) con una dimensione del batch (batch size) ottimizzata per la capacità del sistema downstream e un timeout di visibilità impostato a >= timeout della funzione * 2.
3. Riservare la concorrenza per la Lambda (aws lambda put-function-concurrency …) per limitare i picchi di scrittura su DynamoDB; implementare la concorrenza fornita (provisioned concurrency) per un piccolo pool se è richiesta bassa latenza.
4. Implementare l’idempotenza usando scritture condizionali su DynamoDB basate sul payment-id e salvare i record di idempotenza con un TTL per la pulizia.
5. Abilitare il tracciamento X-Ray e i log strutturati con un correlation ID nell’evento per tracciare l’elaborazione; impostare allarmi CloudWatch su ApproximateAgeOfOldestMessage, Throttles e sulle metriche della DLQ.

Razionale: Il disaccoppiamento da EventBridge a SQS fornisce buffering durevole e semantiche di retry; la concorrenza riservata protegge il sistema downstream DynamoDB dai picchi, l’idempotenza previene i duplicati, e il tracciamento/allarmi forniscono visibilità operativa sulle modalità di fallimento.

← Database e caching · Tutti i domini · Gestione dei costi e tagging delle risorse →

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

Sfoglia Amazon →