D: Cos'è Amazon SQS?

Amazon Simple Queue Service (Amazon SQS) è un servizio Web che permette di memorizzare i messaggi in attesa di invio tramite un sistema di accodamento. Con Amazon SQS, puoi creare con la massima rapidità applicazioni di accodamento di messaggi che possono essere eseguite su qualsiasi computer.

Amazon SQS offre un sistema di accodamento in hosting affidabile e scalabile per memorizzare i messaggi in transito tra computer. Con Amazon SQS, puoi trasferire dati tra diversi componenti distribuiti di applicazioni senza perdere messaggi e senza dover attendere che ciascuno dei componenti sia disponibile.

Amazon SQS può essere utile per creare applicazioni distribuite con componenti separati che funzionano con Amazon Elastic Compute Cloud (Amazon EC2) e altri servizi Web infrastrutturali di AWS.

D: Cosa è possibile fare con Amazon SQS?

Grazie alla scalabilità elevata di Amazon SQS, i prezzi sono calcolati solo in base all'uso effettivo. Si può cominciare su piccola scala ed espandere la propria applicazione in base alle esigenze aziendali, senza compromessi sulle prestazioni o sull'affidabilità. Con Amazon SQS non dovrai più preoccuparti di come i tuoi messaggi vengono memorizzati e gestiti; potrai concentrarti a creare applicazioni di invio di messaggi solide e sofisticate.

Ti offriamo qualche suggerimento:

  • Integra Amazon SQS con altri servizi Web di AWS per aumentare l'affidabilità e la flessibilità delle applicazioni.
  • Usa Amazon SQS per creare code in cui ogni messaggio è un'attività da completare da parte di un processo. Impiega uno o più computer per leggere le attività dalla coda di messaggi ed elaborarle.
  • Crea un'architettura di microservizi utilizzando le code di messaggi per connetterti ad essi.
  • Mantieni le notifiche degli eventi aziendali importanti in una coda Amazon SQS. Ad ogni evento può corrispondere un messaggio in una coda, così le applicazioni che devono rilevare l'evento possono individuarlo leggendo ed elaborando i messaggi.

D: Cosa occorre per cominciare a utilizzare Amazon SQS?

Completa il tutorial da 10 minuti Invio di messaggi tra applicazioni distribuite per iniziare subito a creare code di Amazon SQS e inviare messaggi.

Per ulteriori informazioni, consulta il documento Amazon SQS Developer Guide e il codice di esempio nel centro risorse.

D: Quali sono i vantaggi di Amazon SQS rispetto ai sistemi di accodamento di messaggi sviluppati internamente o in commercio?

Amazon SQS offre diversi vantaggi rispetto alla creazione di soluzioni aziendali o all'uso di sistemi di accodamento open source o in commercio, che richiedono, almeno all'inizio, notevoli sforzi di sviluppo e di configurazione.

Queste alternative richiedono manutenzione hardware continua e occupano risorse di amministrazione. La complessità di configurazione e gestione di questi sistemi è aggravata dalla necessità di prevedere storage ridondante che eviti la perdita di messaggi in caso di guasti hardware.

Al contrario, Amazon SQS richiede una configurazione minima senza sovraccarico amministrativo. Inoltre, Amazon SQS funziona su vasta scala ed è in grado di elaborare miliardi di messaggi al giorno. È possibile ridimensionare la quantità di traffico in Amazon SQS in qualsiasi momento e con qualsiasi configurazione. Infine, Amazon SQS fornisce una durabilità di messaggi molto elevata, offrendo una maggiore sicurezza a te e ai tuoi collaboratori.

D: Quali sono le differenze tra Amazon SQS e Amazon SNS?

Amazon Simple Queue Service (SQS) e Amazon SNS sono entrambi servizi di messaggistica disponibili in AWS in grado di offrire numerosi vantaggi agli sviluppatori. Amazon SNS consente alle applicazioni di inviare messaggi con vincoli tempistici specifici a più sottoscrittori grazie a un meccanismo "push" che elimina la necessità di controllare periodicamente (o "eseguire il polling") l'eventuale presenza di aggiornamenti. Amazon SQS è un servizio di accodamento dei messaggi utilizzato dalle applicazioni distribuite per scambiare messaggi mediante un modello di polling, che può essere impiegato per decuplicare i componenti di invio e ricezione. Amazon SQS offre elevati livelli di flessibilità ai componenti distribuiti delle applicazioni per quanto riguarda l'invio e la ricezione dei messaggi e non richiede la disponibilità simultanea di tutti i componenti.

Un caso d'uso comune è rappresentato dalla pubblicazione dei messaggi di SNS nelle code di messaggistica di Amazon SQS per inoltrarli a uno o più componenti in modo asincrono. Per ulteriori informazioni, consulta la pagina sulla messaggistica pub/sub.

D: Quali sono le differenze tra Amazon SQS e Amazon MQ?

Amazon MQ, Amazon SQS e Amazon SNS sono servizi di messaggistica adatti per ogni tipo di impresa. Se è in uso un'applicazione esistente e occorre trasferire la messaggistica nel cloud in modo semplice e veloce, si consiglia di utilizzare Amazon MQ. Supporta i protocolli e le API standard di settore e consente pertanto di passare da un qualsiasi broker di messaggi basato su standard al servizio senza dover ricompilare il codice dell'applicazione. Se è previsto lo sviluppo di una nuova applicazione nel cloud, si consiglia di utilizzare Amazon SQS e Amazon SNS. Amazon SQS ed SNS sono servizi di gestione di code di messaggi e argomenti completamente gestiti, che ricalibrano le risorse praticamente all'infinito e forniscono API intuitive. Questi due servizi possono essere usati per suddividere e ridimensionare microservizi, sistemi distribuiti e applicazioni serverless migliorandone l'affidabilità.

D: Amazon SQS fornisce l'ordine di messaggi?

Sì. Le code FIFO (first-in-first-out) conservano l'ordine esatto nel quale i messaggi vengono inviati e ricevuti. Se si utilizza una coda FIFO, non c'è bisogno di aggiungere informazioni di sequenziamento nei messaggi. Per maggiori informazioni, consulta la sezione FIFO Queue Logic nell'Amazon SQS Developer Guide.

Le code standard forniscono una funzionalità loose-FIFO che cerca di mantenere l'ordine dei messaggi. Tuttavia, poiché le code standard sono progettate per essere altamente scalabili utilizzando un'architettura estremamente distribuita, non è garantito che i messaggi ricevuti siano nello stesso esatto ordine nel quale sono stati inviati.

D: Amazon SQS garantisce la consegna dei messaggi?

Le code standard offrono una distribuzione di tipo at-least-once, ovvero ciascun messaggio viene distribuito almeno una volta.

Le code FIFO forniscono singole elaborazioni precise, ovvero ciascun messaggio viene distribuito una volta e rimane disponibile fino a che un consumer lo elabora e lo elimina. Non vengono introdotti duplicati introdotti nella coda.

 

D: Quali sono le differenze tra Amazon SQS e Amazon Kinesis Streams?

Amazon SQS offre code in hosting affidabili e a scalabilità elevata per memorizzare i messaggi durante il trasferimento fra applicazioni o microservizi. Trasferisce dati fra i componenti di applicazioni distribuite e consente di disaccoppiare questi componenti. Amazon SQS fornisce costrutti di middleware comuni quali code DLQ e gestione a pillola di veleno. Inoltre fornisce un'API web service generica ed è accessibile con qualsiasi linguaggio di programmazione supportato dall'SDK AWS. Amazon SQS supporta sia le code standard sia le code FIFO.

Amazon SQS va utilizzato quando ciascun messaggio deve essere consumato solo una volta e nei seguenti casi:

  • Disaccoppiamento dei componenti di un'applicazione: hai una coda di elementi di lavoro e vuoi tenere traccia del completamento corretto di ogni elemento in modo indipendente. I risultati dell'ack/fail vengono monitorati da Amazon SQS, così l'applicazione non dovrà mantenere checkpoint o cursori persistenti. Dopo un timeout visibilità configurato, Amazon SQS elimina i messaggi la cui ricezione è confermata e recapita nuovamente i messaggi non completati.
  • Configurazione di intervalli fra singoli messaggi: hai una coda di processi e devi programmare degli intervalli fra i singoli processi. Con Amazon SQS, puoi prorogare singoli messaggi fino a 15 minuti.
  • Aumento dinamico dell'esecuzione simultanea o throughput in tempo di lettura: hai una coda di lavoro e vuoi aggiungere lettori supplementari finché il backlog non è stato smaltito. Con Amazon Kinesis Streams, è possibile ridimensionare le risorse fino al numero di shard necessari (anche se sarà necessario pianificare in anticipo il provisioning di un numero consono di shard). Amazon SQS non necessita pre-provisioning.
  • Dimensionamento trasparente: le richieste vengono memorizzate nel buffer e il carico cambia in seguito ai picchi di carico occasionali o alla progressiva crescita aziendale. Poiché Amazon SQS può elaborare indipendentemente ciascuna richiesta memorizzata nel buffer, può ricalibrare in modo trasparente per gestire il carico senza istruzioni di provisioning da parte tua.

Amazon Kinesis Streams permette l'elaborazione in tempo reale di streaming di big data e la capacità di leggere e riprodurre i record su più applicazioni Amazon Kinesis. L'Amazon Kinesis Client Library (KCL) distribuisce tutti i record per una determinata chiave di partizione allo stesso processore, facilitando la creazione di più applicazioni in grado di leggere dallo stesso flusso di Amazon Kinesis (ad esempio, per l'applicazione di conteggi, aggregazioni o filtri).

Amazon Kinesis Streams va utilizzato per consentire a più consumer di elaborare ciascun record, oltre ai casi d'uso seguenti:

  • Instradamento di record correlati allo stesso processore: trasmetti in streaming MapReduce. Ad esempio, conteggio e aggregazione sono più semplici quando tutti i record per una determinata chiave sono instradati allo stesso processore di record.
  • Utilizzo simultaneo di un flusso da parte di più applicazioni: un'applicazione aggiorna un pannello di controllo in tempo reale e un'altra archivia dati in Amazon Redshift. Entrambe le applicazioni devono poter acquisire dati dallo stesso flusso in modo simultaneo e indipendente.

D: Amazon utilizza Amazon SQS per le sue applicazioni?

Sì. Gli sviluppatori di Amazon usano Amazon SQS per diverse applicazioni che elaborano un elevato numero di messaggi al giorno. I processi più importanti di Amazon.com e di Amazon Web Services impiegano Amazon SQS.


D: Quanto costa Amazon SQS?

I prezzi sono calcolati solo in base all'uso effettivo, senza tariffe minime.

Il costo di Amazon SQS viene calcolato in base alle richieste, a cui si aggiungono i costi di trasferimento dei dati da Amazon SQS (a meno che i dati non vengano trasferiti in istanze Amazon EC2 o funzioni AWS Lambda nella stessa regione). Per i dettagli sui prezzi per tipo di coda e per regione, consulta i Prezzi di Amazon SQS.

D: Cosa prevede il piano gratuito di Amazon SQS?

Il piano gratuito di Amazon SQS offre 1 milione di richieste al mese senza alcun costo.

Molte applicazioni di piccole dimensioni possono operare interamente nell'ambito del piano gratuito. Saranno tuttavia applicati i costi di trasferimento dei dati. Per ulteriori informazioni, consulta la pagina dei prezzi di Amazon SQS.

Il piano gratuito è un'offerta mensile. L'uso gratuito non viene accumulato di mese in mese.

D: Vengono addebitati i costi di tutte le richieste Amazon SQS?

Sì, per ogni richiesta che va oltre il piano gratuito. Tutte le richieste di Amazon SQS sono soggette a costi e vengono fatturate alla stessa tariffa.

D: Le operazioni in batch di Amazon SQS costano più delle altre richieste?

No. Le operazioni in batch (SendMessageBatch, DeleteMessageBatch e ChangeMessageVisibilityBatch) hanno lo stesso costo delle altre richieste Amazon SQS. Raggruppando le richieste in batch, potrai ridurre i costi correlati ad Amazon SQS.

D: Come viene addebitato e fatturato l'utilizzo di Amazon SQS?

Non sono previsti costi di avvio per iniziare a usare Amazon SQS. Alla fine del mese, verrà addebitato sulla carta di credito il costo delle risorse utilizzate in quel mese.

Puoi visualizzare in qualsiasi momento i costi relativi al periodo di fatturazione corrente sul sito Web di AWS:

  1. Accedi al tuo account AWS.
  2. In Your Web Services Account, seleziona Account Activity.

D: In che modo è possibile tenere traccia e gestire i costi associati alle code Amazon SQS?

Per monitorare le code per determinate risorse e calcolarne i costi, puoi utilizzare i tag per l'allocazione dei costi. Un tag è un'etichetta di metadati che include una coppia chiave-valore. Ad esempio, è possibile contrassegnare con dei tag le code in base al centro di costo, per poi suddividere le spese in categorie separate.

Per ulteriori informazioni, consulta la sezione Tagging Your Amazon SQS Queues nel documento Amazon SQS Developer Guide. Per ulteriori informazioni sull'applicazione di tag per l'allocazione dei costi, consulta la sezione Using Cost Allocation Tags nel documento AWS Billing and Cost Management User Guide.

D: I prezzi includono le tasse?

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite.

Per i clienti con indirizzo di fatturazione in Giappone, l'utilizzo di AWS (in qualunque area geografica) è soggetto all'imposta sul consumo giapponese. Per ulteriori informazioni, consulta la pagina Domande frequenti sull'imposta sul consumo per Amazon Web Services.


D: È possibile usare Amazon SQS con altri servizi AWS?

Sì. Puoi rendere le applicazioni più flessibili e scalabili utilizzando Amazon SQS con servizi di elaborazione quali Amazon EC2, Amazon EC2 Container Service (Amazon ECS) e AWS Lambda, oppure con servizi di storage e di database quali Amazon Simple Storage Service (Amazon S3) e Amazon DynamoDB.

Un caso di utilizzo comune è un'applicazione separata distribuita in cui diversi componenti o moduli devono comunicare fra di loro ma non possono tutti sostenere la stessa quantità di lavoro simultaneamente. In questo caso, le code di Amazon SQS trasportano i messaggi per l'elaborazione nell'applicazione in esecuzione sulle Istanze di Amazon EC2.

Le istanze di Amazon EC2 possono leggere i messaggi nella coda, elaborare il processo e poi pubblicare i risultati come messaggi su un'altra coda Amazon SQS (ad esempio per avviare ulteriori fasi di elaborazione in un'altra applicazione). Poiché con Amazon EC2 le applicazioni possono ricalibrare le risorse in modo dinamico, gli sviluppatori delle applicazioni possono modificare il numero delle istanze di calcolo sulla base della quantità di messaggi nelle code SQS, per garantire che i processi vengano eseguiti rapidamente.

D: È disponibile un caso d'uso di esempio di Amazon SQS?

Un sito Web di transcodifica video utilizza Amazon EC2, Amazon SQS, Amazon S3 e Amazon DynamoDB insieme:

  1. Gli utenti finali inviano i video da transcodificare al sito Web.
  2. I video vengono memorizzati in Amazon S3 e viene inviato un messaggio di richiesta nella coda in arrivo di Amazon SQS con un puntatore al video e al formato di destinazione del video nel messaggio.
  3. Il motore di transcodifica, eseguito su un gruppo di istanze di Amazon EC2, legge il messaggio di richiesta dalla coda in arrivo, recupera il video da Amazon S3 utilizzando il puntatore e transcodifica il video nel formato di destinazione.
  4. Il video convertito viene copiato su Amazon S3 e un messaggio di risposta viene inviato nella coda in uscita di Amazon SQS con un puntatore al video convertito.
  5. Nello stesso momento, i metadati del video (formato, data di creazione, durata e così via) vengono indicizzati in Amazon DynamoDB a scopo di query.

Durante l'esecuzione di questo flusso di lavoro, un'istanza dedicata di AutoScaling monitora costantemente la coda in arrivo. A seconda del numero di messaggi in coda, l'istanza AutoScaling ottimizza dinamicamente il numero di istanze Amazon EC2 per la transcodifica, permettendo ai clienti del sito Web i ottenere sempre tempi di risposta adeguati.

D: Come si interagisce con Amazon SQS?

Puoi accedere ad Amazon SQS utilizzando la Console di gestione AWS, che consente di creare code di Amazon SQS e inviare messaggi facilmente.

Amazon SQS fornisce anche un'API web service. Inoltre è integrato con gli SDK AWS, che consentono di lavorare nel linguaggio di programmazione di tua scelta.

D: Quali sono le operazioni disponibili per le code di messaggi?

Per dettagli sulle operazioni sulle code, consulta la pagina dei Dettagli di Amazon SQS.

D: Chi può effettuare operazioni su una coda di messaggi?

Solo il proprietario dell'account AWS (o di un account a cui il proprietario ne abbia delegato i diritti) può effettuare operazioni su una coda di messaggi Amazon SQS.

D: È possibile utilizzare Java Message Service (JMS) con Amazon SQS?

Sì. Puoi sfruttare scalabilità, costi ridotti e disponibilità elevata di Amazon SQS senza dover gestire un cluster JMS.

Amazon fornisce la Amazon SQS Java Messaging Library, che implementa le specifiche di JMS 1.1 e utilizza Amazon SQS come provider JMS. Per maggiori informazioni, consulta la sezione Using JMS with Amazon SQS nell'Amazon SQS Developer Guide.

D: Come fa Amazon SQS a identificare i messaggi?

Tutti i messaggi hanno un ID univoco globale che Amazon SQS restituisce quando il messaggio viene consegnato nella coda. L'ID non è necessario per eseguire ulteriori operazioni sul messaggio, ma è utile per monitorare la corretta ricezione di un determinato messaggio in una coda.

Quando ricevi un messaggio dalla coda, la risposta include un handle di ricezione, che devi fornire quando elimini un messaggio.

D: Come fa Amazon SQS a gestire i messaggi che risultano in errore?

In Amazon SQS, puoi usare l'API o la console per configurare code DLQ, ovvero code configurate per la ricezione di messaggi provenienti da altre code di origine.

Se trasformi la coda in una coda DLQ, questa riceve messaggi dopo che il numero massimo di tentativi di elaborazione è stato completato. Puoi usare code DLQ per isolare i messaggi che non possono essere elaborati, in modo da analizzarli in un secondo momento.

Per ulteriori informazioni, consulta la domanda "Posso utilizzare una coda DLQ con code FIFO?" su questa pagina e la sezione Using Amazon SQS Dead Letter Queues nell'Amazon SQS Developer Guide.

D: Cos'è il timeout visibilità?

Il timeout visibilità è un intervallo di tempo durante il quale Amazon SQS impedisci ad altri componenti la ricezione e l'elaborazione di un messaggio. Per ulteriori informazioni, consulta la sezione Visibility Timeout nell'Amazon SQS Developer Guide.

D: Come fa Amazon SQS a permettere a più lettori di accedere alla stessa coda di messaggi senza perdere messaggi o elaborarli più volte?

Ogni coda Amazon SQS ha un timeout visibilità configurabile. Un messaggio non è visibile per nessun altro lettore per un determinato intervallo di tempo, quando viene letto in una coda. Se il tempo impiegato per elaborare il messaggio è minore del timeout visibilità, ogni messaggio sarà elaborato ed eliminato.

Se il componente non è disponibile oppure non riesce a terminarne l'elaborazione, allo scadere del timeout visibilità il messaggio ritorna a essere visibile per ogni componente in lettura della coda. In questo modo diversi componenti possono leggere il messaggio dalla stessa coda, ognuno elaborando messaggi differenti.

D: Qual è il limite massimo della visibilità di un messaggio?

Il valore massimo del timeout visibilità per un messaggio Amazon SQS è 12 ore.

D: Amazon SQS supporta i metadati nei messaggi?

Sì. Un messaggio Amazon SQS può contenere fino a 10 attributi di metadati. Puoi usare tali attributi per separare il corpo del messaggio dai metadati che lo descrivono. In questo modo è più semplice elaborare e memorizzare le informazioni più rapidamente e in modo più intelligente, perché le applicazioni non devono analizzare l'intero messaggio prima di apprendere come elaborarlo.

Gli attributi di messaggio Amazon SQS hanno la forma del gruppo nome-tipo-valore. I tipi supportati includono stringhe, valori binari e numeri (numeri interi, a virgola mobile e a doppia precisione). Per maggiori informazioni, consulta la sezione Using Amazon SQS Message Attributes nell'Amazon SQS Developer Guide.

D: In che modo è possibile determinare il valore del tempo in coda?

Per determinare il valore del tempo in coda, è possibile richiedere l'attributo SentTimestamp al momento della ricezione del messaggio. Sottraendo quel valore dall'ora attuale si ottiene il valore del tempo in coda.

D: Qual è, in genere, la latenza di Amazon SQS?

In genere, la latenza per le richieste API SendMessage, ReceiveMessage e DeleteMessage è quantificabile nell'ordine di qualche decina o poche centinaia di millisecondi.

D: Per l'accesso in forma anonima, qual è il valore dell'attributo SenderID per un messaggio?

Quando l'ID account AWS non è disponibile (ad esempio quando invia un messaggio un utente anonimo), Amazon SQS fornisce un indirizzo IP.

D: Cos'è il polling lungo in Amazon SQS?

Il polling lungo in Amazon SQS è un modo per recuperare messaggi dalle code Amazon SQS. Mentre il comune polling breve restituisce i messaggi immediatamente, anche quando la coda interrogata è vuota, il polling lungo non restituisce la risposta finché il messaggio non arriva nella coda o il polling lungo scade.

Con il polling lungo, recuperare i messaggi dalla coda Amazon SQS non appena sono disponibili è facile e poco costoso. Il polling lungo può ridurre il costo di utilizzo di SQS, poiché riduce il numero di ricezioni a vuoto. Per maggiori informazioni, consulta la sezione Amazon SQS Long Polling nell'Amazon SQS Developer Guide.

D: Il polling lungo di Amazon SQS comporta costi aggiuntivi?

No. Le chiamate ReceiveMessage associate al polling lungo vengono fatturate esattamente come le altre chiamate ReceiveMessage.

D: In quali casi è più utile usare il polling lungo di Amazon SQS e in quali casi il polling breve?

In quasi tutti i casi, il polling lungo è preferibile al polling breve. Le richieste a polling lungo consentono la ricezione dei messaggi non appena raggiungono la coda, riducendo il numero di istanze ReceiveMessageResponse restituite vuote.

Il polling lungo di Amazon SQS ha prestazioni più elevate e un costo ridotto nella maggior parte dei casi d'uso. Tuttavia, se un'applicazione è stata progettata per ricevere una risposta immediata da una chiamata ReceiveMessage, sarà necessario apportare alcune modifiche per poter approfittare dei vantaggi del polling lungo.

Per esempio, se la tua applicazione impiega un thread singolo per interrogare più code, potrebbe non essere possibile passare dal polling breve a quello lungo, perché il thread singolo attenderà il timeout del polling lungo sulle code vuote, ritardando l'elaborazione delle code che possono contenere messaggi.

In applicazioni di questo genere, consigliamo di usare un thread singolo per elaborare una sola coda, consentendo all'applicazione di sfruttare i vantaggi del polling lungo di Amazon SQS.

D: Quale valore è consigliabile usare per il timeout del polling lungo?

In generale, il timeout di un polling lungo dovrebbe essere al massimo di 20 secondi. Poiché valori di timeout più elevati riducono il numero di istanze ReceiveMessageResponse restituite vuote, prova a impostare un timeout il più elevato possibile.

Se il limite di 20 secondi non è adatto per l'applicazione in uso (come nell'esempio della domanda precedente), imposta un timeout di durata inferiore, fino a 1 secondo.

Tutti i kit SDK AWS sono impostati con polling lunghi di 20 secondi come valore predefinito. Se non usi un kit SDK AWS per accedere ad Amazon SQS, oppure se lo hai configurato con un timeout più breve, potresti dover modificare il client Amazon SQS perché accetti richieste con termini più lunghi o utilizzare un timeout con polling breve.

D: Cos'è AmazonSQSBufferedAsyncClient per Java?

AmazonSQSBufferedAsyncClient per Java fornisce un'implementazione dell'interfaccia AmazonSQSAsyncClient e aggiunge diverse importanti caratteristiche:

  • L'inclusione automatica in batch di più richieste SendMessage, DeleteMessage o ChangeMessageVisibility senza dover modificare l'applicazione
  • Prelettura dei messaggi in un buffer locale per consentire all'applicazione di elaborare immediatamente i messaggi da Amazon SQS senza attenderne il recupero

La combinazione di queste due caratteristiche (la creazione automatica di batch e la prelettura) permette di migliorare il throughput e ridurre la latenza delle applicazioni, contenendo al contempo i costi grazie alla diminuzione del numero di richieste Amazon SQS. Per maggiori informazioni, consulta la sezione Client-Side Buffering and Request Batching nell'Amazon SQS Developer Guide.

Amazon SQS Buffered Asynchronous Client al momento non supporta le code FIFO.

D: Dove è possibile scaricare AmazonSQSBufferedAsyncClient per Java?

AmazonSQSBufferedAsyncClient fa parte del kit SDK AWS per Java.

D: È necessario riscrivere un'applicazione per poter utilizzare AmazonSQSBufferedAsyncClient per Java?

No. AmazonSQSBufferedAsyncClient per Java viene implementata come una sostituzione nel codice per le istanze esistenti di AmazonSQSAsyncClient.

Se aggiorni un'applicazione per consentire l'utilizzo del kit SDK AWS più recente e modifichi il client perché utilizzi AmazonSQSBufferedAsyncClient per Java invece di AmazonSQSAsyncClient, l'applicazione potrà beneficiare del batching automatico e della prelettura.

D: In che modo è possibile abbonarsi alle code di messaggi Amazon SQS per ricevere le notifiche dagli argomenti Amazon SNS?

  1. Nella console di Amazon SQS, seleziona una coda di messaggi standard.
  2. In Queue Actions, seleziona Subscribe Queue to SNS Topic dall'elenco a discesa.
  3. Nella finestra di dialogo, seleziona l'argomento desiderato nell'elenco a discesa Choose a Topic e fai clic su Subscribe.

Per maggiori informazioni, consulta la sezione Subscribing a Queue to an Amazon SNS Topic nell'Amazon SQS Developer Guide.

D: In che modo è possibile effettuare il fan-out di messaggi identici su più code Amazon SQS?

  1. Crea un argomento con Amazon SNS.
  2. Crea e sottoscrivi più di una coda di messaggi di Amazon SQS all'argomento Amazon SNS.
  3. Quando un messaggio viene inviato all'argomento Amazon SNS, viene inviato collettivamente alle code di messaggi Amazon SQS.

Amazon SNS consegna il messaggio in tutte le code di messaggi Amazon SQS abbonate all'argomento.

D: Amazon SNS fornisce la consegna di messaggi di tipo at-least-once a code di Amazon SQS?

Amazon SNS è stato progettato in modo da consegnare ciascun messaggio alle code standard di Amazon SQS almeno una volta.

D: È possibile eliminare tutti i messaggi in una coda senza eliminare la coda?

Sì. Puoi eliminare tutti i messaggi in una coda Amazon SQS tramite l'operazione PurgeQueue.

Quando si ripulisce una coda, tutti i messaggi precedentemente inviati a quella coda vengono eliminati. Poiché la coda e i relativi attributi non vengono cancellati, non è necessario riconfigurarla, ma è possibile continuare a utilizzarla.

Per cancellare solo messaggi specifici, usa le chiamate DeleteMessage e DeleteMessageBatch.


D: Quali sono le differenze fra una coda standard e una coda FIFO?

Code standard

Il tipo di coda predefinito di Amazon SQS è quello standard. Una coda standard consente di aver un numero quasi illimitato di transazioni al secondo. Le code standard garantiscono che un messaggio venga consegnato almeno una volta. Tuttavia, di tanto in tanto (a causa dell'architettura estremamente distribuita che consente un throughput elevato), potrebbe essere consegnata più di una copia di un messaggio. Le code standard assicurano il miglior ordine possibile, ovvero i messaggi vengono generalmente consegnati nello stesso ordine di invio.

sqs-what-is-sqs-standard-queue-diagram

Puoi utilizzare code standard di messaggi in molti scenari, se la tua applicazione può elaborare i messaggi che arrivano più di una volta e nell'ordine sbagliato. Per esempio:

  • Separa le richieste degli utenti attivi dal lavoro intenso in background: consenti agli utenti di caricare contenuti multimediali mentre li ridimensionano o li codificano.
  • Assegna le attività a più nodi dei lavoratori: elabora un numero elevato di richieste di convalida delle carte di credito.
  • Elabora in batch i messaggi per l’elaborazione futura: pianifica più voci da aggiungere a un database.

Code FIFO

Le caratteristiche più importanti di questo tipo di coda sono la consegna FIFO (First-In-First-Out) e la singola elaborazione: viene mantenuto l'ordine esatto in cui i messaggi vengono inviati e ricevuti e i messaggi vengono consegnati una volta e i messaggi vengono consegnati una volta e rimangono disponibili finché un consumer non li elabora e cancella.; nella coda non vengono introdotti duplicati. Le code FIFO supportano inoltre più gruppi di messaggi ordinati all'interno di un'unica coda. Le code FIFO prevedono una limitazione di 300 transazioni al secondo per operazione API, ma offrono tutte le funzionalità delle code standard.

sqs-what-is-sqs-fifo-queue-diagram



Le code FIFO sono progettate per ottimizzare la messaggistica fra applicazioni quando l'ordine delle operazioni e degli eventi è fondamentale o quando i duplicati non possono essere tollerati. Per esempio:

  • Assicura che i comandi immessi dagli utenti siano eseguiti nel giusto ordine.
  • Visualizza il prezzo corretto del prodotto inviando modifiche sui prezzi nel giusto ordine.
  • Impedisci a uno studente di iscriversi a un corso prima di aver creato un account.

D: In quali regioni sono disponibili le code FIFO?

Le code FIFO sono al momento disponibili nelle regioni Stati Uniti occidentali (Oregon), Stati Uniti orientali (Virginia settentrionale) e UE (Irlanda). La caratteristica sarà resa disponibile in altre regioni nei prossimi mesi.

D: Quante copie di un messaggio si ricevono?

Le code FIFO sono progettate per non introdurre mai messaggi duplicati. Tuttavia, in alcuni casi, il produttore di messaggi può introdurre duplicati: per esempio, se il produttore invia un messaggio, non riceve una risposta e allora rimanda lo stesso messaggio. Le API di Amazon SQS forniscono una funzionalità di disaccoppiamento che impedisce al produttore del messaggio di inviare duplicati. I duplicati introdotti dal produttore del messaggio vengono eliminati entro un intervallo di disaccoppiamento di 5 minuti.

Con le code standard, è possibile che si riceva occasionalmente il duplicato di un messaggio (consegna almeno una volta). Se si usa una coda standard, le applicazioni devono essere idempotenti (ovvero non devono essere influenzate nel momento in cui un messaggio viene elaborato più di una volta).

D: Le code Amazon SQS che ho usato precedentemente cambiano le code FIFO?

No. Le code standard di Amazon SQS (il nuovo nome delle code esistenti) non cambiano e si possono ancora creare code standard. Queste code continuano a fornire la scalabilità e il throughput più elevati, tuttavia l'ordine non è garantito e possono esserci duplicati.

Le code standard sono adatta a più scenari, come ad esempio la distribuzione di lavoro con più consumer idempotenti.

D: Possono convertire una coda standard esistente in una coda FIFO?

No. Quando crei una coda, devi sceglierne il tipo. Tuttavia è possibile passare a una coda FIFO. Per maggiori informazioni, consulta la sezione Moving From a Standard Queue to a FIFO Queue nell'Amazon SQS Developer Guide.

D: Le code FIFO di Amazon SQS sono compatibili con versioni precedenti?

Per utilizzare la funzionalità di coda FIFO si deve usare l'SDK AWS più recente.

Le code FIFO utilizzano le stesse azioni API delle code standard e i meccanismi di ricezione ed eliminazione dei messaggi e di modifica del timeout visibilità sono gli stessi. Tuttavia, quando si inviano messaggi, si deve specificare un ID di gruppo di messaggi. Per maggiori informazioni, consulta la sezione FIFO Queue Logic nell'Amazon SQS Developer Guide.

Importante: non è possibile convertire una coda standard esistente in una coda FIFO. Per cambiare, devi creare una nuova coda FIFO per la tua applicazione o eliminare la coda standard esistente e ricrearla come coda FIFO. Per maggiori informazioni, consulta la sezione Moving From a Standard Queue to a FIFO Queue nell'Amazon SQS Developer Guide.

D: con quali servizi (AWS o esterni) sono compatibili le code FIFO di Amazon SQS?

Alcuni servizi AWS o esterni per l'invio di notifiche ad Amazon SQS potrebbero non essere compatibili con le code FIFO, anche se consentono di impostare una coda FIFO come destinazione.

Le seguenti caratteristiche dei servizi AWS non sono attualmente compatibili con le code FIFO:

Per informazioni sulla compatibilità di altri servizi con le code FIFO, vedere la documentazione dei rispettivi servizi.

D: Le code FIFO di Amazon SQS sono compatibili con Amazon SQS Buffered Asynchronous Client, la libreria Extended Client di Amazon SQS per Java o Amazon SQS Java Message Service (JMS) Client?

Le code FIFO non sono attualmente compatibili con Amazon SQS Buffered Asynchronous Client.

Sono invece compatibili con la libreria Extended Client di Amazon SQS per Java e Amazon SQS Java Message Service (JMS) Client.

D: Quali parametri di CloudWatch AWS supportano le code FIFO di Amazon SQS?

Le code FIFO supportano tutti i parametri supportati dalle code standard. Per le code FIFO, tutti i parametri approssimativi restituiscono conteggi accurati. Per esempio, sono supportati i seguenti parametri di CloudWatch AWS:

  • ApproximateNumberOfMessagesDelayed – Il numero dei messaggi nella coda che vengono differiti e non sono disponibili per la lettura immediata.
  • ApproximateNumberOfMessagesVisible – Il numero dei messaggi disponibili per il recupero dalla coda.
  • ApproximateNumberOfMessagesNotVisible – Il numero dei messaggi in volo, ovvero inviati a un client ma che non sono ancora stati eliminati e che non hanno ancora raggiunto il limite della finestra di visibilità.

D: Cosa sono i gruppi di messaggi?

I messaggi sono raggruppati in "pacchetti" distinti e ordinati in una coda FIFO. Per ogni ID di gruppo di messaggi, tutti i messaggi vengono inviati e ricevuti nell'ordine esatto. Tuttavia, i messaggi con ID di gruppo di messaggi diversi possono essere inviati e ricevuti non nell'ordine esatto. Ogni messaggio deve essere associato un ID di gruppo di messaggi. Se non si fornisce un ID di gruppo di messaggi, l'azione non viene completata.

Se più host (o diversi thread sullo stesso host) inviano messaggi con lo stesso ID di gruppo di messaggi a una coda FIFO, Amazon SQS li consegna nell'ordine in cui sono arrivati per l'elaborazione. Per garantire che Amazon SQS conservi l'ordine nel quale i messaggi vengono inviati e ricevuti, i mittenti devono inviare ciascun messaggio con un ID di gruppo di messaggi univoco.  

D: Le code FIFO di Amazon SQS supportano più produttori?

Sì. Uno o più produttori possono inviare messaggi a una coda FIFO. I messaggi vengono memorizzati nell'ordine in cui sono ricevuti correttamente da Amazon SQS.

Se più produttori inviano messaggi in parallelo senza attendere la risposta di esito positivo delle azioni SendMessage o SendMessageBatch, l'ordine fra i produttori può non essere rispettato. La risposta delle azioni SendMessage or SendMessageBatch contiene la sequenza d'ordine finale utilizzata dalle code FIFO per collocare i messaggi nella coda in modo che il codice di più produttori in parallelo possa determinare l'ordine finale dei messaggi nella coda.

D: Le code FIFO di Amazon SQS supportano più consumer?

Le code FIFO di Amazon SQS non distribuiscono messaggi da uno stesso gruppo di messaggi a più di un consumer alla volta. Tuttavia, se la coda FIFO dispone di più gruppi di messaggi, è possibile sfruttare i consumer in parallelo, consentendo ad Amazon SQS di distribuire messaggi da gruppi di messaggi diversi a consumer differenti.

D: Posso utilizzare una coda DLQ con code FIFO?

Sì. Tuttavia, una coda DLQ FIFO va utilizzata con una coda FIFO. (Analogamente, una coda DLQ standard può essere utilizzata solo con una coda standard.)

D: Qual è il limite di throughput per una coda FIFO di Amazon SQS?

Senza divisione in batch, le code FIFO supportano fino a 300 messaggi al secondo (300 operazioni SendMessage, ReceiveMessage o DeleteMessage al secondo). Sfruttando la divisione in batching massima di 10 messaggi per operazione, le code FIFO supportano fino a 3.000 messaggi al secondo. Le code standard di Amazon SQS dispongono di un throughput limitato.

D: Sono previste limitazioni specifiche per gli attributi delle code FIFO?

Il nome di una coda FIFO deve terminare con il suffisso .fifo. Il suffisso viene conteggiato nel limite del nome della coda di 80 caratteri. Per determinare se una coda è FIFO, verifica che il suo nome termini con tale suffisso.


D: Qual è il livello di affidabilità dello storage dei dati in Amazon SQS?

Amazon SQS memorizza tutte le code di messaggi e i messaggi all'interno di una singola regione AWS ad elevata disponibilità, su diverse zone di disponibilità; in questo modo il messaggio può essere reperibile anche se in un computer, una rete o una zona di disponibilità dovessero verificarsi guasti. Per ulteriori informazioni, consulta Regions and Availability Zones nella Guida per l'utente di Amazon Relational Database Service.

D: In che modo è possibile proteggere i messaggi nelle code?

Sono disponibili meccanismi di autenticazione per accertare che i messaggi memorizzati nelle code di Amazon SQS siano protetti da accessi non autorizzati. Puoi controllare chi può inviare messaggi a una coda e chi può riceverne da una coda. Per maggiore sicurezza, puoi creare un'applicazione in modo che crittografi i messaggi prima che vengono messi nella coda.

Amazon SQS dispone di un proprio sistema di autorizzazioni basato sulle risorse, che impiega policy scritte con la stessa sintassi delle policy di AWS Identity and Access Management (IAM); come in IAM, ad esempio, è possibile usare variabili. Per maggiori informazioni, consulta la sezione Amazon SQS Policy Examples nell'Amazon SQS Developer Guide.

Amazon SQS supporta i protocolli HTTP over SSL (HTTPS) e Transport Layer Security (TLS). La maggior parte dei client sono in grado di utilizzare le versioni più recenti di TLS senza modificare il codice o la configurazione. Amazon SQS supporta le versioni 1.0, 1.1 e 1.2 del protocollo Transport Layer Security (TLS) in tutte le regioni.

D: Perché esistono le operazioni separate ReceiveMessage e DeleteMessage?

Quando Amazon SQS ti restituisce un messaggio, quel messaggio resta nella coda, che tu l'abbia ricevuto o no. Sei tu a decidere se vuoi eliminare il messaggio e la richiesta di eliminazione conferma che hai terminato l'elaborazione del messaggio.

Se non elimini il messaggio, Amazon SQS lo consegnerà di nuovo nel momento in cui giunge un'altra richiesta di ricezione. Per ulteriori informazioni, consulta la sezione Visibility Timeout nell'Amazon SQS Developer Guide.

D: Un messaggio eliminato può essere ricevuto di nuovo?

No. Le code FIFO non introducono mai messaggi duplicati.

Per le code standard, in casi particolari, è possibile che un messaggio precedentemente eliminato venga ricevuto una seconda volta. Questo può accadere nei rari casi in cui l'operazione DeleteMessage non elimina tutte le copie di un messaggio perché uno dei server del sistema distribuito Amazon SQS non è disponibile al momento dell'eliminazione. In quel caso, la copia del messaggio può essere consegnata di nuovo. Per evitare questo comportamento, progetta l'applicazione in modo che sia idempotente, in modo tale che non si verifichino errori o incoerenze se ricevi di nuovo un messaggio eliminato.

D: Cosa succede se viene inoltrata una richiesta DeleteMessage su un messaggio già eliminato?

Quando inoltri una richiesta DeleteMessage su un messaggio già eliminato, Amazon SQS restituisce una risposta di operazione riuscita.


D: Quali sono i vantaggi della crittografia lato server (SSE) per Amazon SQS?

La crittografia lato server (SSE) consente di trasmettere dati sensibili in code crittografate. SSE protegge il contenuto dei messaggi in code Amazon SQS utilizzando chiavi gestite in AWS Key Management Service (AWS KMS). SSE crittografa i messaggi non appena Amazon SQS li riceve. I messaggi sono archiviati in forma crittografata e Amazon SQS li decrittografa solo quando vengono inviati a un consumer autorizzato.

AWS KMS combina hardware e software sicuri ad alta disponibilità per fornire un sistema di gestione di chiavi dimensionato per il cloud.

I vantaggi dell'uso di AWS KMS sono i seguenti:

  • Puoi creare e gestire autonomamente le chiavi master del cliente (CMK).
  • Puoi anche utilizzare le CMK gestite da AWS per Amazon SQS, che sono univoche per ogni account e regione. 
  • Gli standard di sicurezza di AWS KMS ti consentono di soddisfare i requisiti di conformità relativi alla crittografia.

Per ulteriori informazioni, consulta le risorse seguenti:

D: In quali regioni sono disponibili code con SSE?

SSE per Amazon SQS è disponibile nelle regioni Stati Uniti orientali (Virginia settentrionale, Ohio) e Stati Uniti occidentali (Oregon). Questa caratteristica sarà resa disponibile in altre regioni nei prossimi mesi.

D: Come si abilita SSE per una coda Amazon SQS nuova o esistente?

Per abilitare SSE per una coda nuova o esistente con l'API Amazon SQS, bisogna specificare l'ID della chiave master del cliente (CMK): l'alias, l'ARN dell'alias, l'ID della chiave o l'ARN della chiave di una CMK gestita da AWS o di una CMK personalizzata impostando l'attributo KmsMasterKeyId dell'azione CreateQueue o SetQueueAttributes.

Per istruzioni dettagliate, consulta le sezioni Creating an Amazon SQS Queue with Server-Side Encryption e Configuring Server-Side Encryption (SSE) for an Existing Amazon SQS Queue nell'Amazon SQS Developer Guide.

D: Quali tipi di code Amazon SQS possono usare SSE?

SSE è supportato sia dalle code standard sia dalle code FIFO.

D: Quali permessi servono per utilizzare SSE con Amazon SQS?

Prima di poter utilizzare SSE, occorre configurare le policy di chiave AWS KMS per permettere la crittografia delle code e la crittografia e decrittografia dei messaggi.

Per abilitare SSE per una coda, si può utilizzare la chiave master del cliente (CMK) per Amazon SQS gestita da AWS o una CMK personalizzata. Per ulteriori informazioni, consulta la sezione Customer Master Keys nell'AWS KMS Developer Guide.

Per inviare messaggi a una coda crittografata, il produttore deve avere i permessi kms:GenerateDataKey e kms:Decrypt per la CMK.

Per ricevere messaggi da una coda crittografata, il consumer deve avere il permesso kms:Decrypt per qualsiasi CMK utilizzata per crittografare il messaggio nella coda specificata. Se la coda agisce come una coda DLQ, il consumer deve avere il permesso kms:Decrypt per qualsiasi CMK utilizzata per crittografare il messaggio nella coda specificata.

Per ulteriori informazioni, consulta la sezione What Permissions Do I Need to Use SSE? nell'Amazon SQS Developer Guide.

D: Ci sono costi relativi all'utilizzo di SSE con Amazon SQS?

Non ci sono costi supplementari di Amazon SQS. Tuttavia ci sono costi associati alle chiamate da Amazon SQS ad AWS KMS. Per ulteriori informazioni, consulta la pagina dei prezzi di AWS Key Management Service.

I costi di utilizzo di AWS KMS dipendono dal periodo di riutilizzo della chiave dati configurata per le tue code. Per ulteriori informazioni, consulta la sezione How Do I Estimate My AWS KMS Usage Costs? nell'Amazon SQS Developer Guide.

D: Che cosa crittografa SSE per Amazon SQS e in che modo?

SSE crittografa il corpo di un messaggio in una coda Amazon SQS.

SSE non crittografa gli elementi seguenti:

  • Metadata della coda (nome e attributo della coda)
  • Metadata del messaggio (ID messaggio, time stamp e attributo)
  • Parametri della coda

Amazon SQS genera chiavi dati basate sulla chiave master del cliente (CMK) per Amazon SQS gestita da AWS o una CMK personalizzata per fornire una crittografia della busta e la decrittografia di messaggi per un periodo di tempo configurabile (da 1 minuto a 24 ore).

D: Quali algoritmi utilizza SSE per Amazon SQS per crittografare i messaggi?

SSE usa l'algoritmo AES-GCM 256.

D: SSE interferisce con il funzionamento di Amazon SQS?

La crittografia di un messaggio ne rende il contenuto non disponibile a utenti non autorizzati o anonimi. La crittografia di un messaggio non influenza il normale funzionamento di Amazon SQS:

  • un messaggio è crittografato solo se viene inviato dopo l'abilitazione della crittografia di una coda. Amazon SQS non crittografa messaggi nel backlog.
  • Tutti i messaggi crittografati rimangono tali anche se la crittografia della loro coda viene disabilitata.

D: Come coesistono le code crittografate di Amazon SQS con le code non crittografate e le code DLQ?

Spostare un messaggio su una coda DLQ non ne influenza la crittografia:

  • Se si sposta un messaggio da una coda di origine crittografata a una coda DLQ non crittografata, il messaggio rimane crittografato.
  • Se si sposta un messaggio da una coda di origine non crittografata a una coda DLQ crittografata, il messaggio rimane non crittografato.

D: SSE limita le transazioni al secondo (TPS) o il numero di code che possono essere create con Amazon SQS?

SSE non limita il throughput (TPS) di Amazon SQS. Il numero di code SSE che possono essere create è limitato dagli elementi seguenti:

  • Il periodo di riutilizzo della chiave dati (da 1 minuto a 24 ore).
  • Il limite per account di AWS KMS (100 TPS per impostazione predefinita).
  • Il numero di utenti o account IAM che accedono alle code.
  • L'esistenza di un backlog di grandi dimensioni (un backlog importante richiede più chiamate AWS KMS).

Per esempio, supponiamo i limiti seguenti:

  • Hai impostato il periodo di riutilizzo della chiave dati a 5 minuti (300 secondi).
  • Il tuo account KMS ha un limite predefinito di 100 TPS.
  • Usi una coda Amazon SQS senza un backlog e con 1 utente IAM per le azioni SendMessage o ReceiveMessage su tutte le code.

In questo caso puoi calcolare il numero massimo teorico di code Amazon SQS con SSE come segue:

300 secondi × 100 TPS/1 utente IAM = 30.000 code

D: Come si stimano i costi di utilizzo di AWS KMS?

Per prevedere i costi e capire meglio la tua fattura AWS, è necessario sapere con quale frequenza Amazon SQS utilizza la tua CMK.

Nota: sebbene la formula seguente possa fornire un'idea molto precisa dei costi previsti, i costi effettivi possono essere più elevati a causa della distribuzione che caratterizza Amazon SQS.

Per calcolare il numero di richieste API per coda (R), usa la formula seguente:

R = B / D * (2 * P + C)

B è il periodo di fatturazione (in secondi)

D è il periodo di riutilizzo della chiave dati (in secondi)

P è il numero di entità generatrici che inviano alla coda Amazon SQS.

C è il numero di entità utilizzatrici che ricevono dalla coda Amazon SQS.

Importante: in generale, le entità generatrici costano il doppio delle entità utilizzatrici. Per ulteriori informazioni, consulta la sezione How Does the Data Key Reuse Period Work? nell'Amazon SQS Developer Guide.

Se il produttore e l'utilizzatore hanno utenti IAM diversi, il costo aumenta.

Per esempi di calcolo, consulta la sezione How Do I Estimate My Customer Master Key (CMK) Usage Costs? nell'Amazon SQS Developer Guide. Per informazioni esatte sui prezzi, consulta la pagina dei prezzi di AWS KMS Service.


D: Amazon SQS è certificato PCI DSS?

Sì. Amazon SQS è certificato PCI DSS livello 1. Per ulteriori informazioni, consulta la pagina Conformità PCI DSS.

D: Amazon SQS è conforme agli standard HIPAA?

Sì, AWS ha esteso il proprio programma di conformità agli standard HIPAA in modo da includere Amazon SQS. Se disponi di un contratto di società in affari o BAA (Business Associate Agreement) con AWS, puoi utilizzare Amazon SQS per creare applicazioni conformi allo standard HIPAA, memorizzare messaggi in transito e trasmettere messaggi, inclusi messaggi contenenti informazioni sanitarie protette.

Se disponi di un BAA con AWS, puoi iniziare subito a utilizzare Amazon SQS. In caso contrario, oppure se hai domande sull'utilizzo di AWS con applicazioni conformi agli standard HIPAA, contattaci.

Nota: se preferisci non trasferire informazioni sanitarie protette tramite Amazon SQS (oppure se le dimensioni dei messaggi sono superiori a 256 KB), puoi inviare payload di messaggi Amazon SQS tramite Amazon S3 utilizzando la Amazon SQS Extended Client Library for Java (Amazon S3 è un servizio conforme agli standard HIPAA, fatta eccezione per Amazon S3 Transfer Acceleration). Per maggiori informazioni, consulta la sezione Using the Amazon SQS Extended Client Library for Java nella Amazon SQS Developer Guide.


D: Per quanto tempo è possibile conservare i messaggi nelle code Amazon SQS?

Una retention dei messaggi maggiore offre più flessibilità permettendo intervalli più lunghi fra la produzione e il consumo dei messaggi.

Il periodo di retention dei messaggi di Amazon SQS può essere configurato tra 1 minuto e 14 giorni. L'impostazione di default è 4 giorni. Quando il periodo di retention viene raggiunto, i messaggi vengono automaticamente eliminati.

D: Come si configura un periodo di retention dei messaggi maggiore in Amazon SQS?

Per modificare il periodo di retention dei messaggi, configura l'attributo MessageRetentionPeriod tramite la console o usando il metodo Distributiveness. Tramite questo attributo, puoi specificare il numero di secondi di retention di un messaggio in Amazon SQS.

Puoi usare l'attributo MessageRetentionPeriod per impostare il periodo di retention tra 60 secondi (1 minuto) e 1.209.600 secondi (14 giorni). Per ulteriori informazioni su come utilizzare questo attributo di messaggio, consulta il documento Amazon SQS API Reference.

D: Come si configurano le dimensioni massime dei messaggi per Amazon SQS?

Per configurare le dimensioni massime dei messaggi, usa la console o il metodo SetQueueAttributes per impostare l'attributo MaximumMessageSize. Questo attributo specifica il limite del numero di byte che può contenere un messaggio Amazon SQS. Imposta questo limite con un valore compreso tra 1.024 byte (1 KB) e 262.144 byte (256 KB). Per maggiori informazioni, consulta la sezione Using Amazon SQS Message Attributes nell'Amazon SQS Developer Guide.

Per inviare messaggi che superano i 256 KB, usa la Amazon SQS Extended Client Library for Java. Questa libreria permette di inviare messaggi Amazon SQS che contengono riferimenti a un payload di messaggio in Amazon S3, con dimensioni massime di 2 GB. 

D: Quali tipi di dati possono essere inclusi in un messaggio?

I messaggi Amazon SQS possono contenere fino a 256 KB di dati di testo, incluso XML, JSON e testo non formattato. Sono accettati i seguenti caratteri Unicode:

#x9 | #xA | #xD | [#x20 – #xD7FF] | [#xE000 – #xFFFD] | [#x10000 – #x10FFFF]

Per ulteriori informazioni, consulta XML 1.0 Specification.

D: Quali sono le dimensioni massime possibili per le code di messaggi Amazon SQS?

Una singola coda di messaggi Amazon SQS può contenere un numero illimitato di messaggi. Tuttavia c'è un limite di 120.000 messaggi in volo per una coda standard e di 20.000 per una coda FIFO. I messaggi sono in fase di consegna dopo la ricezione di una coda da un componente di consumo, ma non sono ancora stati cancellati da essa.

D: Quante code di messaggi è possibile creare?

Puoi creare un numero illimitato di code di messaggi.

D: C'è un limite alla lunghezza del nome delle code di messaggi Amazon SQS?

I nomi di coda sono limitati a 80 caratteri.

D: Sono previste restrizioni sui nomi delle code di messaggi Amazon SQS?

I nomi possono contenere caratteri alfanumerici, trattini (-) e trattini bassi (_).

D: È possibile utilizzare più di una volta il nome di una coda di messaggi?

Il nome delle code di messaggi deve essere univoco all'interno dell'account AWS e della regione. Puoi usare nuovamente un nome se elimini la relativa coda di messaggi.


D: Come si condivide una coda di messaggi?

È possibile associare un'istruzione di policy di accesso (e specificarne le autorizzazioni) con la coda di messaggi da condividere. Amazon SQS fornisce le API per creare e gestire le istruzioni di policy di accesso:

  • AddPermission
  • RemovePermission
  • SetQueueAttributes
  • GetQueueAttributes

Per ulteriori informazioni, consulta il documento Amazon SQS API Reference.

D: Chi paga l'accesso a una coda condivisa?

L'accesso a una coda condivisa viene addebitato al proprietario della coda.

D: In che modo di identifica l'utente AWS con cui condividere una coda di messaggi?

L'API Amazon SQS utilizza il numero di account AWS per identificare gli utenti AWS.

D: Quali informazioni è necessario fornire a un utente AWS per condividere con lui una coda di messaggi?

Per condividere una coda di messaggi, devi fornire all'utente AWS l'URL completo della coda da condividere. Le operazioni CreateQueue e ListQueues restituiscono questo URL nella risposta.

D: Amazon SQS supporta l'accesso anonimo?

Sì. Puoi configurare una policy di accesso che consente agli utenti anonimi di accedere a una coda di messaggi.

D: In quali casi è consigliato utilizzare l'API Permissions?

L'API Permissions fornisce un'interfaccia per la condivisione dell'accesso a una coda di messaggi per sviluppatori. Può tuttavia concedere privilegi di accesso condizionale o altri casi d'uso avanzati.

D: In quali casi è consigliato usare l'operazione SetQueueAttributes con gli oggetti JSON?

L'operazione SetQueueAttributes supporta la sintassi di policy di accesso completa. Ad esempio, puoi usare la sintassi di policy per limitare l'accesso a una coda di messaggi per indirizzo IP e ora del giorno. Per maggiori informazioni, consulta la sezione Amazon SQS Policy Examples nell'Amazon SQS Developer Guide.


D: In quali regioni è disponibile Amazon SQS?

Per informazioni sulla disponibilità dei servizi, consulta la tabella delle regioni per l'infrastruttura globale AWS.
Note: Le code FIFO al momento sono disponibili solo nelle regioni Stati Uniti occidentali (Oregon), Stati Uniti orientali (Virginia settentrionale) e UE (Irlanda). La caratteristica sarà resa disponibile in altre regioni nei prossimi mesi.

D: È possibile condividere messaggi tra code in regioni diverse?

No. Ogni coda di messaggi Amazon SQS è indipendente in ciascuna regione.

D: C'è una differenza di prezzo fra le regioni?

I prezzi di Amazon SQS sono gli stessi in tutte le regioni, tranne nella regione Cina (Pechino). Per ulteriori informazioni, consulta la pagina dei prezzi di Amazon SQS.

D: Qual è la struttura dei prezzi fra più regioni?

Puoi trasferire dati tra Amazon SQS e Amazon EC2 o AWS Lambda all'interno di una stessa regione senza alcun costo.

Quando trasferisci dati tra Amazon SQS e Amazon EC2 o AWS Lambda in regioni diverse, viene addebitata la tariffa standard per il trasferimento di dati. Per ulteriori informazioni, consulta la pagina dei prezzi di Amazon SQS.