Domande frequenti su 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 Elastic Compute Cloud (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.

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 maggiori informazioni, consulta i Prezzi di Amazon SQS.

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

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.

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.

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. Nella pagina in Account Web Services, seleziona Attività account.

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 Applicazione di tag alle tue code Amazon SQS nella guida per sviluppatori di Amazon SQS. Per ulteriori informazioni sull'applicazione di tag per l'allocazione dei costi, consulta la sezione Tag di allocazione dei costi nel documento guida per l’utente Fatturazione e gestione costi AWS.

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.

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

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.

Per dettagli sulle operazioni sulle code, consulta la Documentazione di riferimento delle API di Amazon SQS.

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.

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

Amazon fornisce la libreria di messaggistica Amazon SQS Java, che implementa le specifiche di JMS 1.1 e utilizza Amazon SQS come provider JMS. Per maggiori informazioni, consulta Utilizzo di JMS con Amazon SQS nella Guida per gli sviluppatori di Amazon SQS.

Servizio messaggi Java (JMS)

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.

Per ulteriori informazioni, consulta la sezione Identificatori di code e messaggi nella Guida per gli sviluppatori di Amazon SQS.

In Amazon SQS, puoi usare l'API o la console per configurare code DLQ che ricevono messaggi provenienti da altre code di origine. Quando si configura una coda DLQ, è necessario impostare le autorizzazioni appropriate per il riorientamento della coda DLQ utilizzando RedriveAllowPolicy.

RedriveAllowPolicy include i parametri per l'autorizzazione di riorientamento della coda DLQ. Definisce quali code di origine possono specificare le code DLQ come oggetto JSON.

Una volta che crei una coda DLQ, questa riceve messaggi dopo che il numero massimo di tentativi di elaborazione non può essere completato. Puoi usare code DLQ per isolare i messaggi che non possono essere elaborati, in modo da analizzarli in un secondo momento.

Per maggiori informazioni, consulta la sezione Utilizzo delle code DLQ di Amazon SQS nella Guida per gli sviluppatori di Amazon SQS.

Il timeout visibilità è un intervallo di tempo durante il quale Amazon SQS impedisce ad altri componenti la ricezione e l'elaborazione di un messaggio. Per ulteriori informazioni, consulta la sezione Timeout della visibilità nella Guida per gli sviluppatori di Amazon SQS.

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 Utilizzo degli attributi di messaggi di Amazon SQS nella Guida per gli sviluppatori di Amazon SQS.

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.

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

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

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 Polling lungo di Amazon SQS nella Guida per gli sviluppatori di Amazon SQS.

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

In quasi tutti i casi, il polling lungo Amazon SQS è 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.

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.

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 Buffering lato client e inclusione in batch di richieste nella Guida per gli sviluppatori di Amazon SQS.

AmazonSQSBufferedAsyncClient fa parte dell’AWS SDK 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.

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 Sottoscrizione di una coda a un argomento di Amazon SNS nella Guida per gli sviluppatori di Amazon SQS.

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.

Per ulteriori informazioni, guarda questo tutorial: Ripulire messaggi da una coda di Amazon SQS.

Le code FIFO sono disponibili in tutte le regioni AWS in cui è disponibile Amazon SQS. Per dettagli sulla disponibilità di Amazon SQS, consulta questa pagina.

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).

Per ulteriori informazioni, consulta la sezione Elaborazione singola nella Guida per gli sviluppatori di Amazon SQS.

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.

No. Quando crei una coda, devi sceglierne il tipo. Tuttavia è possibile passare a una coda FIFO. Per ulteriori informazioni, consulta la sezione Passaggio da una coda standard a una FIFO nella Guida per gli sviluppatori di Amazon SQS.

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 Logica delle code FIFO nella Guida per gli sviluppatori 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à.

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 valori ID gruppo messaggi diversi possono essere inviati e ricevuti fuori ordine. Devi associare un ID gruppo di messaggi a un messaggio. 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.

Per maggiori informazioni, consulta la sezione Logica delle code FIFO nella Guida per gli sviluppatori di Amazon SQS.

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.

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.

Per impostazione predefinita, le code FIFO supportano fino a 3.000 messaggi al secondo con la divisione in batch o fino a 300 messaggi al secondo (300 operazioni di invio, ricezione o eliminazione al secondo) senza batch. Se si necessita di una velocità di trasmissione effettiva più elevata, è possibile abilitare la modalità di velocità di trasmissione effettiva elevata per FIFO nella console Amazon SQS, che supporterà fino a 70.000 messaggi al secondo senza batch e anche di più con i batch. Per un'analisi dettagliata delle quote della modalità FIFO di velocità di trasmissione effettiva elevata per regione, consultare la documentazione AWS.

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

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 la pagina Regioni e zone di disponibilità nella Guida per l'utente di Amazon Relational Database Service.

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 Esempi di policy di Amazon SQS nella Guida per gli sviluppatori di Amazon SQS.

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.

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 Timeout della visibilità nella Guida per gli sviluppatori di Amazon SQS.

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. 

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

La SSE consente di trasmettere dati sensibili in code crittografate. La SSE protegge il contenuto dei messaggi in code Amazon SQS utilizzando chiavi gestite in Sistema AWS di gestione delle chiavi (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.

Per ulteriori informazioni, consulta la sezione Protezione di dati con crittografia lato server (SSE) e AWS KMS nella guida per sviluppatori di Amazon SQS.

Sì. Per farlo è necessario abilitare la compatibilità tra i servizi AWS (ad esempio Amazon CloudWatch Events, Amazon S3 e Amazon SNS) e le code con SSE. Per informazioni dettagliate, consulta la sezione Compatibilità della Guida per gli sviluppatori di SQS.  

La crittografia sul lato server o SSE (Server-Side Encryption) per Amazon SQS è disponibile in tutte le regioni AWS in cui il servizio è disponibile. Per dettagli sulla disponibilità di Amazon SQS, consulta questa pagina.

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'operazione CreateQueue o SetQueueAttributes.

Per istruzioni dettagliate, consulta Creazione di una coda Amazon SQS con la crittografia lato server e Configurazione della crittografia lato server (SSE) per una coda Amazon SQS esistente nella Guida per gli sviluppatori di Amazon SQS.

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

Prima di poter utilizzare SSE, occorre configurare le policy 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 Chiavi master del cliente nella Guida per gli sviluppatori di AWS KMS.

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 l'autorizzazione kms:Decrypt per qualsiasi CMK utilizzata per crittografare il messaggio nella coda specificata.

Per ulteriori informazioni, consulta la sezione Quali permessi occorrono per utilizzare SSE? nella Guida per gli sviluppatori di 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 sezione relativa ai 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 le sezione Come calcolare i costi di utilizzo del mio AWS KMS nella Guida per gli sviluppatori di Amazon SQS.

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)
• Metadati 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 a busta e la decrittografia di messaggi per un periodo di tempo configurabile (da 1 minuto a 24 ore).

Per ulteriori informazioni, consulta la sezione Che cosa crittografa SSE per Amazon SQS? nella Guida per gli sviluppatori di Amazon SQS.

SSE usa l'algoritmo AES-GCM 256.

SSE non limita la velocità effettiva (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).
• La quota 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 che:

• Hai impostato il periodo di riutilizzo della chiave dati a 5 minuti (300 secondi).
• Il tuo account KMS ha una quota predefinita di TPS AWS KMS di 100 TPS.
• Usi una coda Amazon SQS senza un backlog e con 1 utente IAM per le operazioni 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

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 di dati (in secondi).

P è il numero di principali generatori che inviano alla coda Amazon SQS.

C è il numero di principali utilizzatori che ricevono dalla coda Amazon SQS.

Importante: in generale, i principali generatori costano il doppio dei principali utilizzatori. Per ulteriori informazioni, consulta la sezione Come funziona il periodo di riutilizzo delle chiavi di dati? nella Guida per gli sviluppatori di Amazon SQS.

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

Per ulteriori informazioni, consulta le sezione Come calcolare i costi di utilizzo del mio AWS KMS nella guida per sviluppatori di Amazon SQS.

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

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 libreria client ampia di Amazon SQS per Java (Amazon S3 è un servizio conforme agli standard HIPAA, fatta eccezione per Amazon S3 Transfer Acceleration). Per maggiori informazioni, consulta la sezione Utilizzo della libreria client ampia di Amazon SQS per Java nella Guida per gli sviluppatori di 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 la quota di retention viene raggiunta, i messaggi vengono automaticamente eliminati.

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 la Documentazione di riferimento delle API di 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 numero di byte che può contenere un messaggio Amazon SQS. Imposta questo attributo con un valore compreso tra 1.024 byte (1 KB) e 262.144 byte (256 KB). Per maggiori informazioni, consulta Utilizzo degli attributi di messaggi di Amazon SQS nella Guida per gli sviluppatori di Amazon SQS.

Per inviare messaggi che superano i 256 KB, usa la libreria client ampia di Amazon SQS per 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.

I messaggi Amazon SQS possono contenere fino a 256 KB di dati di testo, incluso testo 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 la specifica XML 1.0.

Una singola coda di messaggi Amazon SQS può contenere un numero illimitato di messaggi. Tuttavia c'è una quota di 120.000 messaggi in volo per una coda standard e di 120.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.

Puoi creare un numero illimitato di code di messaggi.

I nomi di coda sono limitati a 80 caratteri.

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

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.

È 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 la Documentazione di riferimento delle API di Amazon SQS.

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

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

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.

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

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.

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 Esempi di policy di Amazon SQS nella Guida per gli sviluppatori di Amazon SQS.

Per informazioni sulla disponibilità dei servizi, consulta la tabella delle regioni per l'infrastruttura globale AWS.

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

I prezzi di Amazon SQS sono gli stessi in tutte le regioni, tranne nella regione Cina (Pechino). Per maggiori informazioni, visita prezzi Amazon SQS.

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 maggiori informazioni, visita prezzi Amazon SQS.

Una coda di messaggi non recapitabili è una coda di Amazon SQS alla quale una coda fonte può inviare messaggi se la coda fonte dell'applicazione del cliente non è in grado di elaborare i messaggi con successo. Le code di messaggi non recapitabili ti aiutano a gestire la mancata elaborazione dei messaggi e il ciclo di vita dei messaggi non elaborati. Puoi configurare un allarme per ogni messaggio inviato a una coda di messaggi non recapitabili, verificare se nei registri sono presenti eccezioni che potrebbero avere causato l'invio alla coda, e analizzare i contenuti dei messaggi per rilevare problemi di elaborazione da parte dell'applicazione del cliente. Dopo avere ripristinato l'applicazione del tuo cliente, puoi reindirizzare i messaggi dalla coda di messaggi non recapitabili alla coda fonte.

Quando crei la tua coda fonte, Amazon SQS ti permette di specificare una coda di messaggi non recapitabili (DLQ) e in quale condizione SQS deve spostare i messaggi nella DLQ. La condizione corrisponde al numero di volte che un cliente può ricevere un messaggio dalla coda, definito con maxReceiveCount. Questa configurazione di una coda di messaggi non recapitabili con una coda fonte e maxReceiveCount è nota come policy di reindirizzamento. Amazon SQS è impostato per spostare il messaggio a una coda di messaggi non recapitabili (con il suo ID messaggio originale) quando il valore ReceiveCount di un messaggio supera il valore maxReceiveCount per una coda. Per esempio, se la coda fonte ha come policy di reindirizzamento un valore di maxReceiveCount impostato su cinque, e il cliente della coda fonte riceve un messaggio per sei volte senza elaborarlo con successo, SQS sposta il messaggio nella coda di messaggi non recapitabili.

La policy di reindirizzamento gestisce la prima metà del ciclo di vita dei messaggi non elaborati spostandoli da una coda fonte a una coda di messaggi non recapitabili. Il reindirizzamento alla coda di messaggi non recapitabili completa in modo efficace il ciclo riportando quei messaggi alla loro coda fonte, come mostrato di seguito.

Innanzitutto, ti consente di ispezionare a campione i messaggi presenti nella coda di messaggi non recapitabili, mostrando gli attributi dei messaggi e i relativi metadati. In seguito, dopo avere ispezionato i messaggi, puoi riportarli nella/e loro coda/e fonte. Inoltre puoi scegliere la velocità di reindirizzamento per configurare il ritmo con cui Amazon SQS sposterà i messaggi dalla coda di messaggi non recapitabili alla coda fonte.

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.)