Amazon SQS – Häufig gestellte Fragen

Sie zahlen nur für das, was Sie auch tatsächlich nutzen. Dabei fallen keine Mindestgebühren an.

Die Kosten für Amazon SQS werden aus den Kosten pro Anforderung plus den Datenübertragungskosten für die aus Amazon SQS ausgelesenen Daten berechnet (ausgenommen Daten werden an Amazon Elastic Compute Cloud (EC2)-Instances oder an AWS Lambda-Funktionen in derselben Region übertragen). Weitere Informationen zur genauen Kostenaufschlüsselung des jeweiligen Warteschlangentyps und der Region finden Sie unter Preise zu Amazon SQS.

Im kostenlosen Kontingent für Amazon SQS sind 1 Mio. Anforderungen pro Monat kostenlos enthalten.

Zahlreiche kleinere Anwendungen können vollständig innerhalb der Grenzen dieses kostenlosen Kontingents betrieben werden. Allerdings fallen möglicherweise weiterhin Datenübertragungsgebühren an. Weitere Informationen finden Sie unter Amazon SQS – Preise.

Das kostenlose Kontingent ist ein monatliches Angebot. Das nicht in Anspruch genommene Kontingent bei einer kostenlosen Nutzung kann nicht auf den nächsten Monat übertragen werden.

Ja, für alle Anforderungen, die über das kostenlose Kontingent hinausgehen. Alle Amazon SQS-Anforderungen verursachen Kosten und werden zu derselben Gebühr verrechnet.

Nein. Stapelvorgänge (SendMessageBatch, DeleteMessageBatch und ChangeMessageVisibilityBatch) kosten genauso viel wie andere Amazon SQS-Anforderungen. Durch die Gruppierung von Nachrichten in Stapel können Sie Ihre Kosten senken.

Es gibt keine Einrichtungsgebühren für die Nutzung von Amazon SQS. Nach Ende eines Monats wird Ihre Kreditkarte automatisch mit den Nutzungsgebühren für den betreffenden Monat belastet.

Sie können die Gebühren für den aktuellen Abrechnungszeitraum jederzeit auf der AWS-Website anzeigen:

1. Melden Sie sich bei Ihrem AWS-Konto an.
2. Wählen Sie unter Mein Web Services-Konto die Option Kontoaktivität.

Sie können Ihre Warteschlangen für Ressourcen- und Kostenverwaltung mithilfe von Kostenzuordnungstags markieren und nachverfolgen. Ein Tag ist eine Metadatenbezeichnung, die aus einem Schlüssel-Wert-Paar besteht. Sie können Ihre Warteschlangen beispielsweise nach Kostenstelle mit Tags versehen und dann Ihre Kosten basierend auf diesen Kostenstellen kategorisieren und nachverfolgen.

Weitere Informationen finden Sie im Thema zum Markieren Ihrer Amazon SQS-Warteschlangen im Amazon SQS-Entwicklerhandbuch. Weitere Informationen zu Kostenzuordnungstags für AWS-Ressourcen finden Sie unter Verwendung von Kostenzuordnungstags im Benutzerhandbuch zu AWS-Fakturierung und Kostenmanagement.

Falls nicht anders angegeben, gelten unsere Preise zuzüglich geltender Steuern und Abgaben, darunter MwSt. und Umsatzsteuer.

Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS in jeder Region der japanischen Verbrauchssteuer. Weitere Informationen finden Sie in den häufig gestellten Fragen zu Verbrauchssteuern in Amazon Web Services.

Ja. Sie können Ihre Anwendungen flexibler und skalierbarer machen, indem Sie Amazon SQS mit Datenverarbeitungsdiensten wie Amazon EC2, Amazon Elastic Container Service (ECS) und AWS Lambda sowie mit Speicher- und Datenbankdiensten wie Amazon Simple Storage Service (Amazon S3) und Amazon DynamoDB nutzen.

Sie können Amazon SQS mithilfe der AWS-Managementkonsole aufrufen, über die Sie mühelos Amazon-SQS-Warteschlangen erstellen und Nachrichten senden können.

Amazon SQS stellt auch eine Web-Services-API bereit. Diese ist auch in die AWS SDKs integriert, wodurch Sie in Ihrer gewünschten Programmiersprache arbeiten können.

Informationen zu Nachrichtenwarteschlangen-Vorgängen finden Sie in der Amazon-SQS-API-Referenz.

Vorgänge in einer Amazon SQS-Nachrichtenwarteschlange können nur vom AWS-Kontoinhaber oder einem AWS-Konto ausgeführt werden, an das der Inhaber die Aufgabe delegiert hat.

Ja. Sie können die Vorteile der Skalierbarkeit, der niedrigen Kosten und der hohen Verfügbarkeit von Amazon SQS nutzen und müssen sich keine Sorgen um den aufwendigen Betrieb eines eigenen JMS-Clusters machen. 

Amazon bietet eine Amazon SQS Java Messaging Library, die die Implementierung der JMS 1.1-Spezifikationen unterstützt und Amazon SQS als JMS-Anbieter verwendet. Weitere Informationen finden Sie unter Verwenden von JMS mit Amazon SQS im Amazon-SQS-Entwicklerhandbuch.

Java Message Service (JMS)

Alle Nachrichten verfügen über eine global eindeutige ID, die Amazon SQS zurückgibt, wenn die Nachricht an die Nachrichtenwarteschlange geliefert wird. Die ID ist für keine weiteren Vorgänge mit der Nachricht notwendig, aber sie ist nützlich, um herauszufinden, ob eine bestimmte Nachricht in der Warteschlange empfangen wurde.

Wenn Sie eine Mitteilung aus der Nachrichtenwarteschlange empfangen, enthält die Antwort eine Empfangs-Mitteilung, die für die Löschung der Mitteilung benötigt wird.

Weitere Informationen finden Sie unter Warteschlangen- und Nachrichtenkennungen im Amazon-SQS-Entwicklerhandbuch.

In Amazon SQS können Sie die API oder die Konsole verwenden, um Warteschlangen für unzustellbare Nachrichten zu konfigurieren. Das sind Warteschlangen, die Nachrichten aus anderen Quell-Warteschlangen empfangen. Beim Konfigurieren einer Warteschlange für unzustellbare Nachrichten müssen Sie die entsprechenden Redrive-Berechtigungen für die Warteschlange für unzustellbarer Nachrichten mit RedriveAllowPolicy benutzen.

RedriveAllowPolicy enthält darunter auch die Parameter für die Redrive-Berechtigung für unzustellbare Nachrichten in der Warteschlange. Sie definiert, welche Quell-Warteschlangen eine Warteschlange für unzustellbare Nachrichten als JSON-Objekt angeben können.

Wenn Sie eine Warteschlange für unzustellbare Nachrichten einrichten, erhält sie Nachrichten, die nach einer maximalen Anzahl von Verarbeitungsversuchen nicht abgeschlossen werden können. Sie können Warteschlangen für unzustellbare Nachrichten benutzen, um Nachrichten, die nicht verarbeitet werden können, für eine spätere Analyse zu isolieren.

Weitere Informationen finden Sie unter Verwenden von Amazon-SQS-Warteschlangen für unzustellbare Nachrichten im Amazon-SQS-Entwicklerhandbuch.

Die Zeitbeschränkung für die Sichtbarkeit ist eine Zeitspanne, während derer Amazon SQS andere Verbraucherkomponenten daran hindert, eine Nachricht zu empfangen oder zu verarbeiten. Weitere Informationen finden Sie unter Zeitbeschränkung für die Sichtbarkeit im Amazon-SQS-Entwicklerhandbuch.

Ja. Eine Amazon SQS-Nachricht kann bis zu 10 Metadatenattribute enthalten. Sie können Nachrichtenattribute verwenden, um den Haupttext einer Nachricht von den Metadaten zu trennen, die ihn beschreiben. Dadurch können Sie Informationen schneller und effizienter verarbeiten und speichern, da Ihre Anwendungen nicht mehr die gesamte Nachricht untersuchen müssen, um die erforderlichen Verarbeitungsschritte zu bestimmen.

Amazon SQS-Nachrichtenattribute haben das Format "Name-Typ-Wert". Unterstützte Typen sind u. a.: String, Binary und Number (einschließlich Integer, Floating Point und Double). Weitere Informationen finden Sie unter Verwenden von Amazon SQS-Nachrichtenattributen im Amazon-SQS-Entwicklerhandbuch.

Um den Wert der Wartezeit zu bestimmen, können Sie das Attribut "SentTimestamp" anfordern, wenn Sie eine Nachricht erhalten. Die Subtraktion dieses Wertes von der aktuellen Zeit ergibt den Wert der Wartezeit.

Die typischen Latenzen für SendMessage-, ReceiveMessage- und DeleteMessage-API-Anforderungen liegen im Zehner- oder unteren Hunderterbereich von Millisekunden.

Wenn die AWS-Konto-ID nicht sichtbar ist, beispielsweise, wenn ein anonymer Benutzer eine Nachricht sendet, übergibt Amazon SQS die IP-Adresse.

Die Amazon SQS-Langabfrage ist eine Möglichkeit zum Abrufen von Nachrichten aus Ihren Amazon SQS-Warteschlangen. Während die normale Kurzabfrage sofort eine Rückgabe liefert, auch wenn die abgefragte Nachrichtenwarteschlange leer ist, gibt die Langabfrage erst dann eine Antwort zurück, wenn eine Nachricht in die Nachrichtenwarteschlange eingeht oder die Zeitbeschränkung der Langabfrage überschritten wird.

Die Langabfrage ermöglicht das kostengünstige Abrufen von Nachrichten aus Ihrer Amazon SQS-Warteschlange, sobald diese verfügbar sind. Die Verwendung von Langabfragen kann zur Reduzierung der SQS-Kosten beitragen, da Sie damit die Anzahl der leeren Empfangsvorgänge minimieren können. Weitere Informationen finden Sie unter Amazon-SQS-Langabfragen im Amazon-SQS-Entwicklerhandbuch.

Nein. ReceiveMessage-Langabfragen werden genauso in Rechnung gestellt wie ReceiveMessage-Kurzabfragen.

In den meisten Fällen ist die Amazon SQS-Langabfrage im Vergleich zur Kurzabfrage die bessere Wahl. Bei Anforderungen von Langabfragen erhalten Warteschlangennutzer Nachrichten, sobald diese in Ihre Warteschlange eingehen, wobei die Anzahl leerer "ReceiveMessageResponses"-Instances verringert wird.

Die Amazon SQS-Langabfrage führt in den meisten Anwendungsfällen zu einer höheren Leistung bei geringeren Kosten. Wenn Ihre Anwendung jedoch so codiert ist, dass eine sofortige Antwort auf einen Aufruf von "ReceiveMessage" erwartet wird, können Sie ggf. nicht mit der Langabfrage arbeiten, ohne zuvor die Anwendung zu ändern.

Wenn Ihre Anwendung beispielsweise über einen einzelnen Thread zum Abfragen mehrerer Warteschlangen verfügt, funktioniert der Wechsel von der Kurz- zur Langabfrage ggf. nicht. Der Grund ist, dass der einzelne Thread bei leeren Warteschlangen die Zeitbeschränkung der Langabfrage abwartet, wodurch die Verarbeitung von Warteschlangen verzögert wird, die ggf. Nachrichten enthalten.

Bei einer solchen Anwendung hat sich bewährt, dass ein einzelner Thread nur eine Warteschlange verarbeitet, damit die Anwendung in den Genuss der Vorteile von Amazon SQS-Langabfragen kommen kann.

Im Allgemeinen sollten Sie maximal 20 Sekunden für eine Zeitüberschreitung bei langen Abfragen verwenden. Durch höhere Zeitbeschränkungswerte für die Langabfrage wird die Anzahl zurückgegebener leerer "ReceiveMessageResponses"-Instances verringert. Legen Sie deshalb den Zeitbeschränkungswert für die Langabfrage so hoch wie möglich fest.

Wenn der Maximalwert von 20 Sekunden für Ihre Anwendung geeignet ist (siehe das Beispiel in der vorigen Frage), können Sie einen kürzeren Zeitbeschränkungswert für die Langabfrage wählen (der Mindestwert ist 1 Sekunde).

Alle AWS SDKs arbeiten standardmäßig mit 20-sekündigen Langabfragen. Wenn Sie AWS SDK für den Zugriff auf Amazon SQS verwenden oder Ihr AWS SDK mit einem kürzeren Zeitbeschränkungswert konfiguriert haben, müssen Sie ggf. den Amazon SQS-Client so ändern, dass längere Anforderungen zulässig sind, oder einen kürzeren Zeitbeschränkungswert für die Langabfrage wählen.

Der AmazonSQSBufferedAsyncClient for Java bietet eine Implementierung der AmazonSQSAsyncClient-Schnittstelle, die mehrere wichtige Funktionen hinzufügt:

• Automatische Stapelverarbeitung mehrerer Anforderungen von Typ "SendMessage", "DeleteMessage" oder "ChangeMessageVisibility" in Stapeln des jeweiligen Typs, ohne dass die Anwendung geändert werden muss
• Vorabruf von Nachrichten in einen lokalen Puffer, was Ihrer Anwendung die sofortige Verarbeitung von Nachrichten aus Amazon SQS ermöglicht, ohne deren Abruf abwarten zu müssen.

Durch die Kombination aus automatischer Stapelverarbeitung und Vorabruf werden der Durchsatz gesteigert und die Latenz Ihrer Anwendung verkürzt und durch das Stellen weniger Amazon SQS-Anforderungen die Kosten gesenkt. Weitere Informationen finden Sie unter Clientseitige Pufferung und Batch-Verarbeitung von Anforderungen im Amazon-SQS-Entwicklerhandbuch.

Sie laden den AmazonSQSBufferedAsyncClient mit dem AWS SDK für Java herunter.

Nein. Der AmazonSQSBufferedAsyncClient wird im Austausch für den vorhandenen AmazonSQSAsyncClient implementiert.

Sie können Ihre Anwendung so ändern, dass das neueste AWS SDK verwendet wird, und die Clientkonfiguration so ändern, dass der AmazonSQSBufferedAsyncClient anstelle von AmazonSQSAsyncClient verwendet wird, damit Ihre Anwendung in den Genuss von automatischer Stapelverarbeitung und Vorabruf kommt.

1. Wählen Sie in der Amazon SQS-Konsole eine Amazon SQS-Standardwarteschlange aus.
2. Wählen Sie unter Queue Actions in der Dropdown-Liste Subscribe Queue to SNS Topic aus.
3. Wählen Sie im Dialogfeld das Thema in der Dropdown-Liste Choose a Topic aus und klicken Sie auf Subscribe.

Weitere Informationen finden Sie unter Abonnieren einer Warteschlange für ein Amazon-SNS-Thema im Amazon-SQS-Entwicklerhandbuch.

Ja. Mit der Aktion PurgeQueue können alle Nachrichten in einer Amazon SQS-Nachrichtenwarteschlange gelöscht werden.

Wenn Sie eine Nachrichtenwarteschlange leeren, werden alle bis dahin an die Nachrichtenwarteschlange gesendeten Nachrichten gelöscht. Da die Nachrichtenwarteschlange selbst mit ihren Attributen bestehen bleibt, ist es nicht nötig, sie für die Weiterverwendung erneut zu konfigurieren.

Wenn Sie bestimmte Nachrichten löschen müssen, verwenden Sie die Aktionen DeleteMessage oder DeleteMessageBatch.

Weitere Informationen finden Sie im Tutorial Löschen von Nachrichten aus Amazon-SQS-Warteschlangen.

FIFO-Warteschlangen sind in allen AWS-Regionen verfügbar, in denen Amazon SQS angeboten wird. Weitere Informationen zur regionalen Verfügbarkeit von Amazon SQS finden Sie hier.

FIFO-Warteschlangen sind darauf ausgelegt, niemals Duplikate von Nachrichten aufzunehmen. Dennoch kann der Produzent Ihrer Nachricht das Aufnehmen von Duplikaten in bestimmten Szenarien herbeiführen: Wenn der Produzent beispielsweise eine Nachricht sendet, keine Antwort erhält, und dieselbe Nachricht erneut sendet. APIs von Amazon SQS bieten eine Deduplizierungsfunktion, die das Senden von Duplikaten beim Produzenten Ihrer Nachricht verhindern. Alle Duplikate, die vom Produzenten der Nachricht eingebracht wurden, werden innerhalb eines 5-minütigen Deduplizierungsintervalls entfernt.

Bei Standardwarteschlangen kann es gelegentlich vorkommen, dass Sie eine doppelte Kopie einer Nachricht erhalten (mindestens einmal erfolgende Zustellung). Wenn Sie eine Standardwarteschlange verwenden, müssen Ihre Anwendungen idempotent sein (d. h. die mehrmalige Verarbeitung derselben Nachricht darf die Anwendung nicht nachteilig beeinflussen).

Weitere Informationen finden Sie unter Garantierte einmalige Verarbeitung im Amazon-SQS-Entwicklerhandbuch.

Nein. Amazon-SQS-Standardwarteschlangen (dies ist der neue Name für bestehende Warteschlangen) bleiben unverändert und Sie können weiterhin neue Standardwarteschlangen erstellen. Diese Warteschlangen bieten weiterhin die höchste Skalierbarkeit und den höchsten Durchsatz; jedoch haben Sie hier keine Zustellungsgarantien und es können Duplikate vorkommen.

Standardwarteschlangen sind für viele Bereiche geeignet, wie etwa für die Aufgabenverteilung bei mehreren idempotenten Konsumenten.

Nein. Sie müssen den Warteschlangentyp auswählen, wenn Sie die Warteschlange erstellen. Dennoch ist es möglich, die Warteschlange in eine FIFO-Warteschlange zu verschieben. Weitere Informationen finden Sie unter Verschieben aus einer Standardwarteschlange in eine FIFO-Warteschlange im Amazon-SQS-Entwicklerhandbuch.

Um die Funktionen der FIFO-Warteschlange nutzen zu können, müssen Sie die neuste AWS SDK verwenden.

FIFO-Warteschlangen verwenden die gleichen API-Aktionen wie Standardwarteschlangen; die Mechanismen für den Empfang und das Löschen von Nachrichten sowie für das Ändern der Zeitbeschränkung für die Sichtbarkeit sind dieselben. Jedoch müssen Sie beim Senden von Nachrichten eine Nachrichtengruppen-ID angeben. Weitere Informationen finden Sie unter FIFO-Warteschlangenlogik im Amazon-SQS-Entwicklerhandbuch.

Manche AWS-Services oder externe Services, die Benachrichtigungen an Amazon SQS senden, sind möglicherweise nicht mit FIFO-Warteschlangen kompatibel, obwohl Sie eine FIFO-Warteschlange als Ziel festlegen können.

Die folgenden Funktionen der AWS-Services sind derzeit nicht mit FIFO-Warteschlangen kompatibel:

• Auto Scaling von Lebenszyklus-Hooks
• AWS-IoT-Regelaktionen
• AWS-Lambda-Warteschlangen für unzustellbare Nachrichten

In der Servicedokumentation finden Sie Informationen zur Kompatibilität von sonstigen Services mit FIFO-Warteschlangen.

FIFO-Warteschlangen sind derzeit nicht mit dem Amazon SQS Buffered Asynchronous Client kompatibel.

FIFO-Warteschlangen sind mit der Amazon SQS Extended Client Library for Java und dem Amazon SQS Java Message Service (JMS)-Client kompatibel.

FIFO-Warteschlangen unterstützen alle Metriken, die von Standardwarteschlangen unterstützt werden. Bei FIFO-Warteschlangen liefern alle approximativen Metriken genaue Zählungen. Beispielsweise werden folgende Metriken von AWS CloudWatch unterstützt:

• ApproximateNumberOfMessagesDelayed – Die Anzahl der Nachrichten in der Warteschlange, die verzögert und zum Lesen nicht sofort verfügbar sind.
• ApproximateNumberOfMessagesVisible – Die Anzahl der Nachrichten, die für das Abrufen aus der Warteschlange verfügbar sind.
• ApproximateNumberOfMessagesNotVisible – Die Anzahl der Nachrichten, die sich in der Übertragung befinden (Nachrichten, die an einen Client gesendet, aber noch nicht gelöscht wurden, oder das Ende des Zeitfensters für die Sichtbarkeit noch nicht erreicht haben).

Nachrichten werden innerhalb einer FIFO-Warteschlange in getrennten, sortierten „Paketen“ gruppiert. Für jede Nachrichtengruppen-ID werden alle Nachrichten in einer strikten Reihenfolge gesendet und empfangen. Nachrichten mit anderen Werten der Nachrichtengruppen-ID werden jedoch möglicherweise nicht der Reihenfolge nach gesendet und empfangen. Sie müssen die Nachrichtengruppen-ID einer Nachricht zuordnen. Wenn Sie keine Nachrichtengruppen-ID angeben, schlägt die Aktion fehl.

Wenn mehrere Hosts (oder verschiedene Threads auf dem gleichen Host) Nachrichten mit der gleichen Nachrichtengruppen-ID an eine FIFO-Warteschlange senden, stellt Amazon SQS die Nachrichten in der Reihenfolge zu, in der sie für die Verarbeitung eingehen. Um sicherzustellen, dass Amazon SQS die Reihenfolge einhält, in der die Nachrichten gesendet und empfangen werden, muss darauf geachtet werden, dass mehrere Sender jede getrennte Nachricht mit einer individuellen Nachrichtengruppen-ID versenden.

Weitere Informationen finden Sie unter FIFO-Warteschlangenlogik im Amazon-SQS-Entwicklerhandbuch.

Ja. Ein oder mehrere Produzenten können Nachrichten an eine FIFO-Warteschlange senden. Nachrichten werden in der Reihenfolge gespeichert, in der sie von Amazon SQS erfolgreich empfangen wurden.

Wenn mehrere Produzenten Nachrichten parallel senden, ohne auf die Erfolgsmeldung der Aktionen "SendMessage" oder "SendMessageBatch" zu warten, wird die Reihenfolge zwischen den Produzenten möglicherweise nicht eingehalten. Die Meldung der Aktionen "SendMessage" oder "SendMessageBatch" enthält die endgültige Sortierungsreihenfolge, die FIFO-Warteschlangen verwenden, um die Nachrichten in die Warteschlange aufzunehmen; somit kann die endgültige Reihenfolge der Nachrichten in der Warteschlange mithilfe Ihres Multiple-Parallel-Producer-Codes bestimmt werden.

Standardmäßig stellen Amazon SQS FIFO-Warteschlangen Nachrichten aus derselben Nachrichtengruppe nicht mehreren Empfängern gleichzeitig zu. Falls Ihre FIFO-Warteschlange jedoch mehrere Nachrichtengruppen bedient, können Sie den Vorteil paralleler Konsumenten nutzen, so dass Amazon SQS Nachrichten aus verschiedenen Nachrichtengruppen verschiedenen Empfängern zustellt.

FIFO-Warteschlagen unterstützen standardmäßig bis zu 3 000 Nachrichten pro Sekunde mit Stapelverarbeitung oder bis zu 300 Nachrichten pro Sekunde (300 Vorgänge zum Senden, Empfangen oder Löschen pro Sekunde) ohne Stapelverarbeitung. Wenn Sie einen höheren Durchsatz benötigen, können Sie den Hochdurchsatzmodus für FIFO auf der Amazon-SQS-Konsole aktivieren. Dieser unterstützt bis zu 70 000 Nachrichten pro Sekunde ohne Stapelverarbeitung und sogar noch mehr mit Stapelverarbeitung. Eine detaillierte Aufschlüsselung der FIFO-Kontingente für den Hochdurchsatzmodus pro Region finden Sie in der AWS-Dokumentation.

Der Name einer FIFO-Warteschlange muss mit dem Suffix ".fifo" enden. Der Suffix ist Teil des 80-Zeichen-Limits für Warteschlangennamen. Um herauszufinden, ob eine Warteschlange FIFO ist, können Sie überprüfen, ob der Warteschlangennamen mit dem Suffix endet.

Amazon SQS speichert alle Nachrichtenwarteschlangen in einer einzelnen, hochverfügbaren AWS-Region mit mehreren redundanten Availability Zones (AZ), sodass ein Ausfall eines einzelnen Computers, eines Netzwerks oder einer AZ nicht zu einer Nichtverfügbarkeit der Nachrichten führt. Weitere Informationen finden Sie unter Regionen und Availability Zones im Benutzerhandbuch zu Amazon Relational Database Service.

Authentifizierungsmechanismen sorgen dafür, dass in Amazon SQS-Nachrichtenwarteschlangen gespeicherte Nachrichten vor unautorisiertem Zugriff geschützt sind. Sie können steuern, wer Nachrichten an eine Nachrichtenwarteschlange senden und Nachrichten von einer Nachrichtenwarteschlange empfangen darf. Für zusätzliche Sicherheit können Sie Ihre Anwendung so konzipieren, dass sie Nachrichten verschlüsselt, bevor diese in der Nachrichtenwarteschlange platziert werden.

Amazon SQS verfügt über ein eigenes ressourcenbasiertes Berechtigungssystem. Dieses verwendet Richtlinien, die in derselben Sprache wie Richtlinien von AWS Identity and Access Management (IAM) geschrieben sind. So können Sie beispielsweise wie in IAM-Richtlinien auch Variablen verwenden. Weitere Informationen finden Sie unter Amazon-SQS-Richtlinienbeispiele im Amazon-SQS-Entwicklerhandbuch.

Amazon SQS unterstützt die Protokolle HTTP over SSL (HTTPS) und Transport Layer Security (TLS). Die meisten Clients können sich automatisch abstimmen, um neuere Versionen von TLS zu verwenden, ohne dass Änderungen im Programmcode oder in der Konfiguration notwendig sind. Amazon SQS unterstützt die Versionen 1.0, 1.1 und 1.2 des Protokolls Transport Layer Security (TLS) in allen Regionen.

Wenn Amazon SQS eine Nachricht an Sie zurücksendet, bleibt diese Nachricht in der Nachrichtenwarteschlange, ganz gleich, ob Sie diese Nachricht erhalten haben oder nicht. Sie sind dafür verantwortlich, die Nachricht zu löschen. Durch die Löschanforderung bestätigen Sie, dass Sie mit der Verarbeitung der Nachricht fertig sind.

Wenn Sie die Nachricht nicht löschen, sendet sie Amazon SQS bei der nächsten Anforderung erneut. Weitere Informationen finden Sie unter Zeitbeschränkung für die Sichtbarkeit im Amazon-SQS-Entwicklerhandbuch.

Nein. FIFO-Warteschlangen nehmen nie doppelte Nachrichten auf.

In seltenen Fällen erhalten Sie bei Standardwarteschlangen möglicherweise eine vorher gelöschte Nachricht erneut. 

Wenn Sie eine DeleteMessage-Anforderung für eine bereits gelöschte Nachricht stellen, gibt Amazon SQS eine success-Antwort zurück.

Mit SSE können Sie vertrauliche Daten in verschlüsselten Warteschlangen übermitteln. SSE schützt die Nachrichteninhalte in Amazon-SQS-Warteschlangen und verwendet dabei Schlüssel, die im AWS Key Management Service (AWS KMS) verwaltet werden. Die Nachrichten werden direkt beim Eingang in Amazon SQS verschlüsselt. Sie werden verschlüsselt gespeichert. Amazon SQS entschlüsselt Nachrichten nur, wenn sie an den autorisierten Kunden gesendet werden.

Weitere Informationen finden Sie unter Datenschutz mit serverseitiger Verschlüsselung (SSE) und AWS KMS im Amazon SQS-Entwicklerhandbuch.

Ja. Dazu müssen Sie die Kompatibilität zwischen AWS Services (z. B. Amazon CloudWatch Events, Amazon S3 und Amazon SNS) und Warteschlangen mit SSE ermöglichen. Detaillierte Anweisungen finden Sie im Abschnitt zur Kompatibilität im SQS-Entwicklerhandbuch.  

SSE (Verschlüsselung auf dem Server) ist für Amazon SQS in allen AWS-Regionen verfügbar, in denen Amazon SQS erhältlich ist. Weitere Informationen zur regionalen Verfügbarkeit von Amazon SQS finden Sie hier.

Dazu verwenden Sie die Amazon SQS API und geben Sie die ID des Customer Master Key (CMK) ID an: Alias, Alias-ARN, Schlüssel-ID oder Schlüssel-ARN des AWS-verwalteten CMK oder einen benutzerdefinierten CMK. Dazu legen Sie das KmsMasterKeyId-Attribut der Aktion "CreateQueue" oder "SetQueueAttributes" fest.

Eine ausführliche Anleitung finden Sie unter Erstellen einer Amazon-SQS-Warteschlange mit serverseitiger Verschlüsselung und Konfigurieren der serverseitigen Verschlüsselung (SSE) für eine vorhandene Amazon-SQS-Warteschlange im Amazon-SQS-Entwicklerhandbuch.

SSE wird von standardmäßigen und FIFO-Warteschlangen unterstützt.

Bevor Sie SSE verwenden, müssen Sie AWS KMS-Schlüsselrichtlinien so konfigurieren, dass die Verschlüsselung von Warteschlangen und die Ver- und Entschlüsselung von Nachrichten zugelassen ist.

Zur Aktivierung von SSE für eine Warteschlange können Sie den AWS-verwalteten CMK für Amazon SQS oder einen benutzerdefinierten CMK verwenden. Weitere Informationen finden Sie unter Customer Master Keys im AWS-KMS-Entwicklerhandbuch.

Zum Senden von Nachrichten an eine verschlüsselte Warteschlange muss der Produzent die Berechtigungen "kms:GenerateDataKey" und "kms:Decrypt" für den CMK besitzen.

Um Nachrichten von einer verschlüsselten Warteschlange zu empfangen, benötigt der Verbraucher die Berechtigung "kms:Decrypt" für jeden CMK, der für die Verschlüsselung von Nachrichten in der angegebenen Warteschlange verwendet wird. Wenn es sich um eine Warteschlange für unzustellbare Nachrichten handelt, muss der Verbraucher zusätzliche die Berechtigung kms:Decrypt für jeden CMK haben, mit dem die Nachrichten in der Quellwarteschlange verschlüsselt werden.

Weitere Informationen finden Sie unter Welche Berechtigungen benötige ich für die Verwendung von SSE? im Amazon-SQS-Entwicklerhandbuch.

Es entstehen keine zusätzlichen Gebühren für Amazon SQS. Allerdings werden für Aufrufe von Amazon SQS an AWS KMS Gebühren erhoben. Weitere Informationen finden Sie unter AWS Key Management Service – Preise.

Die Gebühren für die Nutzung von AWS KMS hängen vom Zeitraum der Wiederverwendung für Datenschlüssel ab, die für Ihre Warteschlangen konfiguriert ist. Weitere Informationen finden Sie unter Wie schätze ich meine Nutzungsausgaben für AWS KMS? im Amazon-SQS-Entwicklerhandbuch.

SSE verschlüsselt den Nachrichtentext in einer Amazon SQS-Warteschlange.

Folgende Komponenten werden von SSE nicht verschlüsselt:

• Metadaten der Warteschlange (Name und Attribute)
• Metadaten der Nachrichten (ID, Zeitstempel und Attribute)
• Metriken pro Warteschlange

Amazon SQS generiert Datenschlüssel basierend auf dem AWS-verwalteten Customer Master Key (CMK) für Amazon SQS oder einen benutzerdefinierten CMK und stellt damit die Umschlagverschlüsselung und die Entschlüsselung von Nachrichten für einen konfigurierbaren Zeitraum (1 Minute bis 24 Stunden) bereit.

Weitere Informationen finden Sie unter Was verschlüsselt SSE für Amazon SQS? im Amazon-SQS-Entwicklerhandbuch.

SSE verwendet den Algorithmus „AES-GCM 256“.

Durch SSE wird der Durchsatz (TPS) von Amazon SQS nicht eingeschränkt. Die Anzahl der SSE-Warteschlangen, die Sie erstellen können, wird von folgenden Faktoren begrenzt:

• Dem Zeitraum für die Wiederverwendung des Datenschlüssels (1 Minute bis 24 Stunden).
• Dem Kontingent von AWS KMS pro Konto (Standard: 100 TPS).
• Der Anzahl der IAM-Benutzer oder -Konten, die auf Warteschlangen zugreifen.
• Dem Vorhandensein eines großen Rückstands (bei einem größeren Rückstand sind mehr AWS KMS-Aufrufe nötig).

Nehmen Sie zum Beispiel Folgendes an:

• Sie legen den Zeitraum für die Wiederverwendung des Datenschlüssels auf 5 Minuten (300 Sekunden) fest.
• Für Ihr Konto gilt das standardmäßige AWS KMS TPS-Kontingent von 100 TPS.
• Sie verwenden eine Amazon SQS-Warteschlange ohne Rückstand und mit 1 IAM-Benutzer für alle "SendMessage"- oder "ReceiveMessage"-Aktionen für alle Warteschlangen.

Dann können Sie die theoretische Höchstzahl an Amazon SQS-Warteschlangen mit SSE wie folgt berechnen:

300 Sekunden × 100 TPS / 1 IAM-Benutzer = 30 000 Warteschlangen

Um Ihre Ausgaben besser zu planen und Ihre AWS-Rechnung besser zu verstehen, müssen Sie wissen, wie oft Amazon SQS Ihren CMK verwendet.

Hinweis: Mit der nachstehenden Formel erhalten Sie eine gute Vorstellung davon, welche Kosten auf Sie zukommen werden. Allerdings können die tatsächlichen Kosten aufgrund der verteilten Struktur von Amazon SQS höher liegen.

Zur Berechnung der Anzahl der API-Anfragen pro Warteschlange (R) verwenden Sie folgende Formel:

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

B ist der Abrechnungszeitraum (in Sekunden).

D ist der Zeitraum für die Wiederverwendung des Datenschlüssels (in Sekunden).

P ist die Anzahl der Prinzipale, die Nachrichten an die Amazon SQS-Warteschlange senden.

C ist die Anzahl der Verbraucher, die Nachrichten aus der Amazon SQS-Warteschlange erhalten.

Wichtig: Für Produzenten entstehen in der Regel doppelt so hohe Kosten wie für Verbraucher. Weitere Informationen finden Sie unter Wie funktioniert der Zeitraum für die Wiederverwendung des Datenschlüssels? im Amazon-SQS-Entwicklerhandbuch.

Die Kosten erhöhen sich, wenn der Produzent und der Verbraucher unterschiedliche IAM-Benutzer haben.

Weitere Informationen finden Sie unter Wie schätze ich meine Nutzungsausgaben für AWS KMS? im Amazon-SQS-Entwicklerhandbuch.

Ja. Amazon SQS verfügt über eine PCI DSS-Zertifizierung (Level 1). Weitere Informationen finden Sie unter PCI-Compliance.

Ja, AWS hat sein HIPAA-Compliance-Programm auf Amazon SQS als HIPAA-fähigen Service ausgeweitet. Wenn Sie über eine aktive Business Associate Agreement (BAA) mit AWS verfügen, können Sie Amazon SQS zum Erstellen von HIPAA-konformen Anwendungen verwenden, Nachrichten während der Übertragung speichern und Nachrichten übermitteln – darunter auch Nachrichten, die geschützte Gesundheitsdaten (Protected Health Information, PHI) enthalten.

Wenn Sie bereits über eine aktive BAA mit AWS verfügen, können Sie Amazon SQS sofort verwenden. Wenn Sie keine BAA oder weitere Fragen zur Verwendung von AWS für Ihre HIPAA-konformen Anwendungen haben, setzen Sie sich mit uns in Verbindung.

Hinweis: Falls Sie keine PHI über Amazon SQS übertragen möchten (oder wenn Sie Nachrichten haben, die größer als 256 KB sind), können Sie Amazon-SQS-Nachrichtennutzlasten auch über Amazon S3 senden. Verwenden Sie dazu die Erweiterte Clientbibliothek für Java für Amazon SQS (Amazon S3 ist ein HIPAA-konformer Service, mit Ausnahme der Verwendung von Amazon S3 Transfer Acceleration). Weitere Informationen finden Sie im Thema zum Verwenden der erweiterten Clientbibliothek für Java für Amazon SQS im Amazon-SQS-Entwicklerhandbuch.

Durch die längere Aufbewahrung von Nachrichten können Sie flexibler bestimmen, wann Nachrichten erstellt und genutzt werden.

Sie können den Aufbewahrungszeitraum für Amazon SQS-Nachrichten mit einem Wert von 1 Minute bis zu 14 Tagen festlegen. Der Standardwert ist 4 Tage. Sobald das Kontingent für die Nachrichtenaufbewahrung erreicht ist, werden Ihre Nachrichten automatisch gelöscht.

Richten Sie das MessageRetentionPeriod-Attribut mithilfe der Console oder mithilfe der Distributiveness-Methode ein, um den Aufbewahrungszeitraum für Nachrichten zu konfigurieren. Mit diesem Attribut wird festgelegt, wie viele Sekunden eine Nachricht von Amazon SQS aufbewahrt wird.

Über das Attribut „MessageRetentionPeriod“ kann ein beliebiger Aufbewahrungszeitraum für Nachrichten zwischen 60 Sekunden (1 Minute) und 1 209 600 Sekunden (14 Tage) festgelegt werden. Weitere Informationen über die Verarbeitung dieses Nachrichtenattributs finden Sie im Amazon-SQS-API-Referenzhandbuch.

Zum Konfigurieren der maximalen Nachrichtengröße, nutzen Sie die Konsole oder legen Sie das Attribut "MaximumMessageSize" mithilfe der "SetQueueAttributes"-Methode fest. Dieses Attribut gibt die Anzahl von Bytes an, die eine Amazon SQS-Nachricht enthalten darf. Legen Sie dieses Attribut auf einen Wert zwischen 1024 Byte (1 KB) und 262 144 Byte (256 KB) fest. Weitere Informationen finden Sie unter Verwenden von Amazon SQS-Nachrichtenattributen im Amazon-SQS-Entwicklerhandbuch.

Um Nachrichten mit mehr als 256 KB zu senden, können Sie die Erweiterte Clientbibliothek für Java für Amazon SQS verwenden. Diese Bibliothek ermöglicht das Senden einer Amazon SQS-Nachricht, die eine Referenz bezüglich eines Nachrichteninhalts in Amazon S3 enthält, welche bis zu 2 GB groß sein kann.

Amazon SQS-Nachrichten können bis zu 256 KB an Textdaten, darunter XML, JSON und unformatierten Text, enthalten. Die folgenden Unicode-Zeichen sind zugelassen:

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

Weitere Informationen finden Sie in der Spezifikation für XML 1.0.

Eine einzelne Amazon SQS-Nachrichtenwarteschlange kann eine unbeschränkte Anzahl von Nachrichten enthalten. Es gibt jedoch ein Kontingent von 120 000 für die Anzahl von "inflight"-Nachrichten bei Standardwarteschlangen und von 20 000 bei FIFO-Warteschlangen. Nachrichten sind "inflight", nachdem sie aus der Warteschlange von einer verbrauchenden Komponente empfangen, aber noch nicht aus der Warteschlange gelöscht wurden.

Sie können eine beliebige Anzahl von Nachrichtenwarteschlangen erstellen.

Die Namen von Warteschlangen sind auf 80 Zeichen beschränkt.

Alphanumerische Zeichen sowie Bindestriche (-) und Unterstriche (_) sind zulässig.

Der Name einer Nachrichtenwarteschlange muss innerhalb eines AWS-Kontos und einer Region eindeutig sein. Sie können den Namen einer Nachrichtenwarteschlange wiederverwenden, nachdem Sie die Nachrichtenwarteschlange gelöscht haben.

Sie können der gemeinsam zu nutzenden Nachrichtenwarteschlange eine Zugriffsrichtlinienerklärung zuweisen (in der die Berechtigungen näher definiert sind). Amazon SQS bietet APIs für das Erstellen und Verwalten von Zugriffsrichtlinienerklärungen:

• AddPermission
• RemovePermission
• SetQueueAttributes
• GetQueueAttributes

Weitere Informationen finden Sie in der Amazon-SQS-API-Referenz.

Der Inhaber der Nachrichtenwarteschlange bezahlt den gemeinsamen Nachrichtenwarteschlangenzugriff.

Die Amazon SQS-API verwendet die AWS-Kontonummer zur Identifizierung der AWS-Benutzer.

Die gemeinsame Nutzung einer Nachrichtenwarteschlange mit einem AWS-Benutzer ist möglich, indem Sie die vollständige URL der Nachrichtenwarteschlange bereitstellen, die Sie gemeinsam nutzen möchten. Die Vorgänge CreateQueue und ListQueues geben diese URL in ihrer Antwort an.

Ja. Sie können eine Zugriffsrichtlinie konfigurieren, die anonymen Benutzern den Zugriff auf eine Nachrichtenwarteschlange gestattet.

Die Berechtigungs-API bietet eine Schnittstelle für den gemeinsamen Zugriff auf eine Nachrichtenwarteschlange für Entwickler. Diese API kann aber keinen bedingten Zugriff oder kompliziertere Anwendungsfälle bewältigen.

Der "SetQueueAttributes"-Vorgang unterstützt die vollständige Zugriffsrichtliniensprache. Unter Verwendung der Richtliniensprache können Sie beispielsweise den Zugang zur Nachrichtenwarteschlange nach IP-Adresse und Tageszeit eingrenzen. Weitere Informationen finden Sie unter Amazon-SQS-Richtlinienbeispiele im Amazon-SQS-Entwicklerhandbuch.

Die Serviceverfügbarkeit in Regionen finden Sie in der Tabelle für globale Infrastrukturregionen von AWS.

Nein. Jede Amazon SQS-Nachrichtenwarteschlange ist in der jeweiligen Region unabhängig.

Die Amazon SQS-Preise sind in allen Regionen gleich. Lediglich die Region China (Peking) bildet eine Ausnahme von dieser Regel. Weitere Informationen finden Sie unter Amazon SQS – Preise.

Datenübertragungen zwischen Amazon SQS und Amazon EC2 oder AWS Lambda innerhalb einer Region sind gebührenfrei.

Datenübertragungen zwischen Amazon SQS und Amazon EC2 oder AWS Lambda in verschiedenen Regionen werden nach den normalen Datenübertragungstarifen berechnet. Weitere Informationen finden Sie unter Amazon SQS – Preise.

Eine Dead-Letter-Queue (DLQ) ist eine Amazon SQS-Warteschlange, an die eine Quell-Warteschlange Nachrichten senden kann, wenn die Anwendung des Quell-Warteschlangen-Konsumenten nicht in der Lage ist, die Nachricht zu erhalten. Dead-Letter-Queues erleichtern es Ihnen, Nachrichten-Konsumtionsfehler zu handhaben und verwalten den Lebenszyklus von nichtkonsumierten Nachrichten. Sie können einen Alarm für alle an eine Dead-Letter-Queue gesendeten Nachrichten konfigurieren, Logs nach Ausnahmen durchsuchen, die für die Lieferung an die Warteschlange ursächlich sein könnten und die Nachrichteninhalte analysieren, um Probleme mit der Anwendung des Konsumenten zu identifizieren. Nachdem Sie die Konsumenten-Anwendung wiederhergestellt haben, können Sie die Nachrichten von Ihrer DLQ in die Quellwarteschlange zurück verschieben.

Wenn Sie Ihre Quellwarteschlange erstellen, können Sie mit Amazon SQS eine Warteschlange für unzustellbare Nachrichten (DLQ) und die Bedingung angeben, unter der SQS Nachrichten in die DLQ verschieben soll. Die Bedingung ist die maximale Anzahl von Nachrichten, die ein Konsument aus der Warteschlange erhalten kann, sie wird als maxReceiveCount definiert. Die Konfiguration der DLQ mit einer Quellwarteschlange und dem maxReceiveCount ist als Redrive-Richtlinie bekannt. Wenn der ReceiveCount einer Nachricht maxReceiveCount für eine Warteschlange überschreitet, ist Amazon SQS darauf ausgelegt, die Nachricht in eine DLQ zu verschieben (mit ihrer Orginal-Nachrichten-ID). Wenn beispielsweise die Quellwartschlange eine Redrive-Richtlinie mit einem maxReceiveCount von fünf hat und der Konsument der Quellwarteschlange sechs mal eine Nachricht erhält ohne sie erfolgreich zu konsumieren, verschiebt SQS die Nachricht in die Dead-Letter-Queue.

Die Redrive-Richtlinie verwaltet die erste Hälfte des Lebenszyklus einer nicht-konsumierten Nachricht., indem sie diese aus der Quellwarteschlange in die DLQ verschiebt. Die erneute Verschiebung aus der DLQ zurück in die Quellwarteschlange vervollständigt diesen Zyklus, indem die Nachricht – wie unten gezeigt – wieder in die Quellwarteschlange verschoben wird.

Zunächst erlaubt Sie Ihnen ein Teil der Nachrichten in der DLQ zu untersuchen, indem Sie die richtigen Attribute und Metadaten auswählen. Nachdem Sie diese geprüft haben, können Sie sie zurück in ihre Quellwarteschlangen schieben. Sie können auch die Geschwindigkeit für die Rückverschiebung auswählen, um zu bestimmten mit welcher Geschwindigkeit Amazon SQS Nachrichten aus der DLQ in die Quellwarteschlange schiebt.

Ja. Jedoch müssen Sie bei einer FIFO-Warteschlange eine FIFO-Warteschlange für unzustellbare Nachrichten verwenden. (Ebenso können Sie bei einer Standardwarteschlange nur eine Standardwarteschlange für unzustellbare Nachrichten verwenden.)