Amazon SAA-C03: Integrazione di Applicazioni, Messaggistica e Streaming — Guida allo studio

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

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Amazon SQS: Disaccoppiamento, Ordinamento e Semantica di Consegna

Amazon SQS è una coda di messaggi pull-based completamente gestita, il cui ruolo architetturale primario è disaccoppiare i producer dai consumer. Una catena di chiamate sincrone lega la latenza e la disponibilità del producer a ogni dipendenza a valle; l’inserimento di una coda SQS trasforma questa interazione in un passaggio asincrono. I producer accodano i messaggi alla velocità con cui arriva il traffico, e i consumer li prelevano dalla coda alla velocità con cui possono elaborarli in sicurezza. Questa è la soluzione canonica per i picchi di scrittura che altrimenti sovraccaricherebbero un’istanza RDS: la coda assorbe il picco e una flotta limitata di consumer la svuota con una concorrenza controllata, tenendo sotto controllo il numero di connessioni al database.

Esistono due tipi di coda, e la scelta determina sia il throughput sia le garanzie di consegna.

Le code Standard offrono una consegna almeno una volta con un ordinamento solo best-effort. Possono verificarsi duplicati quando un consumer non riesce a eliminare un messaggio prima della scadenza del timeout di visibilità, o quando il backend distribuito riproduce un messaggio tra gli shard. Anche se non si vedono mai duplicati durante i test, il servizio è architetturalmente autorizzato a riconsegnare i messaggi, specialmente durante un failover del broker. Presumere che le code standard consegnino “solitamente” una sola volta è un difetto di progettazione, non un rischio operativo: è garantito che i duplicati si verifichino su larga scala. La logica del consumer deve quindi essere idempotente: tracciare un MessageId o una chiave di business in DynamoDB con una scrittura condizionale, usare una chiave di idempotenza nelle chiamate API a valle, o affidarsi a una semantica di tipo upsert.

Le code FIFO forniscono un ordinamento stretto all’interno di un MessageGroupId e un’elaborazione exactly-once tramite un MessageDeduplicationId (esplicito o un hash SHA-256 del body) che sopprime i duplicati per una finestra di 5 minuti. Il MessageGroupId è il concetto cardine: tutti i messaggi che condividono un ID di gruppo vengono consegnati in ordine stretto a un singolo consumer alla volta, mentre ID di gruppo diversi possono essere elaborati in parallelo. Per un sistema di elaborazione degli ordini in cui gli eventi di ogni cliente devono essere sequenziali ma clienti diversi sono indipendenti, si usa MessageGroupId = customerId. Usare un singolo ID di gruppo per tutto serializza l’intero carico di lavoro e distrugge il throughput. Gli ID di deduplicazione sono il primitivo corretto per prevenire la creazione di ordini duplicati quando un utente reinvia un checkout bloccato: il client genera un token di idempotenza deterministico (un UUID legato alla sessione di checkout) e SQS scarta qualsiasi invio duplicato che arriva entro la finestra temporale.

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

Scegliere una coda standard quando il requisito specifica “ordinamento” o “nessun duplicato” è l’errore classico. Nessuna logica applicativa può ripristinare un ordinamento che la coda non ha mai preservato, perché i messaggi provenienti da host di backend diversi arrivano intercalati. Scegliere FIFO ogni volta che il carico di lavoro richiede ordinamento (registri delle transazioni, transizioni di macchine a stati) o semantica exactly-once (acquisizione di pagamenti, decremento dell’inventario).

Timeout di Visibilità, Messaggi “Poison” e Limiti del Payload

Quando un consumer riceve un messaggio, SQS lo rende invisibile agli altri consumer per la durata del timeout di visibilità (predefinito 30 secondi, massimo 12 ore). Se il consumer elimina il messaggio prima della scadenza del timeout, questo viene rimosso definitivamente; in caso contrario — perché il consumer si è arrestato in modo anomalo o l’elaborazione ha semplicemente richiesto troppo tempo — il messaggio riappare e viene consegnato di nuovo. Impostare il timeout di visibilità su un valore inferiore al tempo di elaborazione effettivo è una delle cause principali dell’elaborazione duplicata: una funzione Lambda che impiega 45 secondi su una coda con il timeout predefinito di 30 secondi rielaborerà ogni messaggio almeno due volte. Impostare il timeout ad almeno il tempo di elaborazione p99 (la guida di AWS per le code gestite da Lambda è di almeno 6 volte il timeout della funzione), e per processi di durata imprevedibile, estendere il timeout dinamicamente:

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

Le code di messaggi non recapitabili (DLQ) catturano i messaggi “poison pill”. Una RedrivePolicy sulla coda di origine specifica un maxReceiveCount (tipicamente 3–5); una volta superato, SQS sposta il messaggio nella DLQ per un’ispezione offline. La DLQ deve corrispondere al tipo della coda di origine (FIFO ↔ FIFO). Senza una DLQ, i messaggi malformati girano in loop all’infinito, e nelle code FIFO questo è particolarmente dannoso: l’ordinamento impedisce che i messaggi successivi nello stesso gruppo vengano consegnati finché non viene gestito il messaggio problematico, quindi un singolo messaggio errato blocca un intero gruppo.

I messaggi SQS sono limitati a 256 KB. Per payload più grandi — ad esempio, un processo che trasporta un documento renderizzato — si usa la SQS Extended Client Library, che scrive il payload su S3 e accoda solo un riferimento a bucket/chiave. La libreria del consumer lo recupera in modo trasparente alla ricezione. Non dividere i payload su più messaggi (si perdono atomicità e ordinamento) e non codificare in base64 un blob da 2 MB sperando che rientri nei limiti.

Scalabilità Guidata dalla Coda

Per una flotta di consumer su EC2 o ECS dietro una coda SQS, il segnale di scalabilità corretto non è la CPU, ma il backlog della coda. La CPU è in ritardo rispetto alla velocità di arrivo dei messaggi e interpreta erroneamente un consumer saturo come “occupato ma in grado di gestire il carico”. La metrica di scalabilità canonica è ApproximateNumberOfMessagesVisible, ma scalare direttamente sulla profondità grezza della coda è impreciso. L’approccio consigliato è la metrica personalizzata di backlog per istanza:

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Pubblicare questo valore su CloudWatch e usarlo per guidare una policy di target tracking su un Auto Scaling group o un servizio ECS, in modo che ogni worker mantenga un backlog limitato (ad esempio, 10 messaggi). Questo produce uno scale-out fluido durante i picchi e previene le oscillazioni quando la profondità della coda è ridotta ma i consumer sono già saturi. Per lo scale-in, abbinarlo a ApproximateAgeOfOldestMessage per evitare di terminare capacità mentre permangono messaggi vecchi.

Amazon SNS: Fan-Out, Filtraggio e Consegna Cross-Account

SNS è un servizio di tipo publish/subscribe basato su push. I publisher scrivono su un topic; SNS invia un push a ogni sottoscrizione: code SQS, funzioni Lambda, endpoint HTTP(S), email, SMS, Kinesis Data Firehose o notifiche push su dispositivi mobili. Il pattern di durabilità predominante è il fan-out SNS → SQS: un topic con più code SQS sottoscritte, in modo che ogni servizio a valle abbia il proprio buffer durevole, la propria policy di tentativi (retry) e la propria DLQ, mentre il publisher conosce solo il topic. Se un servizio consumer rimane inattivo per ore, la sua coda accumula messaggi e li elabora al ripristino — SNS da solo non dispone di tale buffering ed esaurirà la sua policy di tentativi.

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

Il filtraggio dei messaggi (message filtering) consente a ogni sottoscrizione di dichiarare una filter policy JSON in modo che SNS consegni solo i messaggi corrispondenti, evitando l’anti-pattern in cui ogni consumer riceve tutti i messaggi e li filtra lato client:

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

Due proprietà comportamentali sono importanti. Primo, i topic SNS standard non garantiscono l’ordinamento tra i messaggi — i timer di retry per singolo sottoscrittore e i percorsi di rete indipendenti rendono il riordino un evento di routine. Se l’ordinamento è importante, si utilizza un topic SNS FIFO sottoscritto da code SQS FIFO; il message group ID si propaga end-to-end. Altrimenti, i sottoscrittori devono essere idempotenti e tolleranti al riordino. Secondo, le sottoscrizioni HTTP(S) effettuano tentativi secondo una delivery policy (default: tre tentativi immediati, poi backoff esponenziale fino a un’ora, quindi scarto). I sottoscrittori devono rispondere con un codice 2xx entro 15 secondi, convalidare la firma x-amz-sns-message-type e — per gli endpoint inaffidabili — avere sempre una DLQ SNS (reindirizzata a SQS) in modo che i messaggi non recapitati vengano catturati anziché essere scartati silenziosamente.

L’invocazione cross-account è una trappola frequente. Quando l’Account A pubblica su un topic che distribuisce (fan-out) a una Lambda nell’Account B, sono necessarie due policy: la topic policy di SNS (o la direzione della sottoscrizione) deve consentire la sottoscrizione, e la resource-based policy della Lambda deve permettere l’azione lambda:InvokeFunction da sns.amazonaws.com con una condizione SourceArn che corrisponda al topic. La mancanza della resource policy della Lambda è la modalità di fallimento più comune — la sottoscrizione appare funzionante, ma le invocazioni vengono respinte con un errore 403. Se il topic è crittografato con una chiave KMS gestita dal cliente (customer-managed key), la key policy deve anche concedere le autorizzazioni kms:Decrypt e kms:GenerateDataKey al principal che pubblica e a 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: Event Bus con Routing

EventBridge (precedentemente CloudWatch Events) estende il modello pub/sub con routing basato sul contenuto, scoperta degli schemi (schema discovery), sorgenti di eventi da partner SaaS e archiviazione/replay. Gli eventi fluiscono attraverso event bus (default, personalizzati o di partner) e vengono confrontati con regole (rules) i cui event pattern filtrano sulla base della struttura JSON. Le regole possono trasformare i payload tramite input path e input template, associare destinazioni dead-letter e consegnare a più di 20 target nativi, tra cui Lambda, Step Functions, task ECS, SQS, SNS, Kinesis e API destination.

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

La distinzione da SNS è di natura architetturale. SNS è ottimizzato per la trasmissione (broadcast) ad alto throughput verso sottoscrittori omogenei, con un semplice filtraggio basato su attributi e una latenza inferiore. EventBridge è ottimizzato per architetture event-driven eterogenee: molti producer emettono schemi di eventi diversi e i consumer si sottoscrivono tramite pattern anziché per topic. Per un monolito in fase di scomposizione in microservizi — specialmente quando i producer includono partner SaaS o servizi AWS (Config, GuardDuty, CodePipeline, CloudTrail) che emettono eventi nativamente — EventBridge è tipicamente la scelta giusta. Per un fan-out a volume estremamente elevato e bassa latenza verso sottoscrittori identici, SNS è ancora la scelta vincente perché EventBridge ha una latenza per evento leggermente superiore e un limite di throughput predefinito più basso.

Amazon MQ: Messaggistica con Broker per Protocolli Esistenti

Amazon MQ è un broker gestito che esegue ActiveMQ o RabbitMQ. Esiste per migrare carichi di lavoro on-premise che dipendono da AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire o JMS senza dover riscrivere l’applicazione. Se un sistema di pagamento utilizza un broker JMS di terze parti con semantica transazionale “exactly-once”, migrarlo su Amazon MQ preserva il protocollo di comunicazione (wire protocol) e le garanzie di consegna, eliminando al contempo la gestione dell’infrastruttura. Scegliere SQS/SNS/EventBridge per progetti greenfield nativi su AWS; scegliere Amazon MQ solo quando la compatibilità del protocollo è il vincolo principale.

Kinesis Data Streams

Kinesis Data Streams (KDS) è un log durevole, ordinato e partizionato per l’ingestione di flussi di dati (streaming) ad alto throughput — clickstream, telemetria IoT, aggregazione di log. I record vengono inseriti negli shard in base alla PartitionKey; l’ordinamento è garantito all’interno di uno shard, non attraverso l’intero stream. Ogni shard supporta 1 MB/s o 1.000 record/s in scrittura e 2 MB/s in lettura (o valori superiori con Enhanced Fan-Out). I record vengono conservati per 24 ore per impostazione predefinita, estendibili fino a 365 giorni, in modo che più consumer indipendenti possano riprodurre (replay) la stessa cronologia — cosa che SQS non può fare, poiché SQS elimina i messaggi dopo l’ack.

La modalità on-demand elimina la necessità di calcolare il numero di shard, scalando automaticamente fino a 200 MiB/s in scrittura per stream, ideale per traffico imprevedibile. La modalità provisioned è più economica in condizioni di stato stazionario (steady state) in cui la capacità è nota.

Scegliere KDS al posto di SQS FIFO quando il carico di lavoro richiede un’ingestione ordinata e riproducibile (replayable) a throughput che FIFO non può sostenere (FIFO raggiunge il suo limite ben al di sotto dei milioni di record al secondo gestiti da KDS), quando più consumer indipendenti devono leggere lo stesso stream, o quando la dicitura “preservare l’ordine originale durante tutta l’elaborazione” è associata a volumi elevati.

Kinesis Data Firehose

Kinesis Data Firehose è un servizio di consegna completamente gestito. Legge da uno stream Kinesis o tramite PUT diretti, bufferizza per dimensione (1–128 MB) o per tempo (60–900 secondi, a seconda di quale condizione si verifica per prima), invoca opzionalmente una funzione Lambda per la trasformazione di ogni singolo record (pulizia di PII, normalizzazione del formato), può convertire JSON in Parquet o ORC al volo utilizzando uno schema Glue, crittografa con KMS e consegna i dati a S3, Redshift, OpenSearch o Splunk. Non ha shard, né consumer da eseguire, e il prezzo è basato sui GB elaborati (pay-per-GB).

Il pattern canonico per l’ingestione scalabile in un data lake abbina Data Streams (in modalità on-demand) come buffer durevole con Firehose per la consegna a S3:

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

Per l’ingestione di milioni di eventi da dispositivi mobili, la loro crittografia e il loro salvataggio in S3 come file Parquet, la risposta corretta è Firehose con la conversione in Parquet e una chiave KMS — non KDS più un consumer personalizzato più un writer Parquet scritto a mano, che richiederebbe una quantità di codice e infrastruttura notevolmente maggiore. Firehose è near-real-time e non supporta il replay lato consumer; quando è richiesto il replay, è necessario mantenere KDS nel percorso dei dati.

Kinesis Data Analytics (ora Managed Service for Apache Flink) esegue job SQL o Flink su uno stream per effettuare aggregazioni a finestra (windowed aggregations).

Integrazione con Lambda e semantica dei tentativi di riesecuzione

Lambda si integra con questi servizi con comportamenti di tentativi di riesecuzione (retry) sostanzialmente diversi:

Per SQS, mantenere il timeout della funzione Lambda ≤ al visibility timeout della coda, e impostare il visibility timeout ad almeno 6 volte il timeout della funzione. Per Kinesis, abilitare BisectBatchOnFunctionError e configurare una destinazione OnFailure (SQS o SNS) in modo che un singolo “poison record” non blocchi l’intero shard a tempo indeterminato.

Tabella decisionale per la selezione

← Analytics · Tutti i domini · Sicurezza →

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

Sfoglia Amazon →