HAQM 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 HAQM SQS werden aus den Kosten pro Anforderung plus den Datenübertragungskosten für die aus HAQM SQS ausgelesenen Daten berechnet (ausgenommen Daten werden an HAQM 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 HAQM SQS.

Im kostenlosen Kontingent für HAQM 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 HAQM 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 HAQM SQS-Anforderungen verursachen Kosten und werden zu derselben Gebühr verrechnet.

Nein. Stapelvorgänge (SendMessageBatch, DeleteMessageBatch und ChangeMessageVisibilityBatch) kosten genauso viel wie andere HAQM 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 HAQM 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 HAQM SQS-Warteschlangen im HAQM 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 HAQM Web Services.

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

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

HAQM 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 HAQM-SQS-API-Referenz.

Vorgänge in einer HAQM 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 HAQM SQS nutzen und müssen sich keine Sorgen um den aufwendigen Betrieb eines eigenen JMS-Clusters machen. 

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

Java Message Service (JMS)

Alle Nachrichten verfügen über eine global eindeutige ID, die HAQM 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 HAQM-SQS-Entwicklerhandbuch.

In HAQM 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 einsetzen, um Nachrichten für eine spätere Analyse zu isolieren, die nicht verarbeitet werden können.

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

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

Ja. Eine HAQM 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.

HAQM 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 HAQM SQS-Nachrichtenattributen im HAQM-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 HAQM SQS die IP-Adresse.

Die HAQM SQS-Langabfrage ist eine Möglichkeit zum Abrufen von Nachrichten aus Ihren HAQM 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 HAQM 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 HAQM-SQS-Langabfragen im HAQM-SQS-Entwicklerhandbuch.

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

In den meisten Fällen ist die HAQM 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 HAQM 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 HAQM 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 HAQM SQS verwenden oder Ihr AWS SDK mit einem kürzeren Zeitbeschränkungswert konfiguriert haben, müssen Sie ggf. den HAQM SQS-Client so ändern, dass längere Anforderungen zulässig sind, oder einen kürzeren Zeitbeschränkungswert für die Langabfrage wählen.

Der HAQMSQSBufferedAsyncClient for Java bietet eine Implementierung der HAQMSQSAsyncClient-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 HAQM 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 HAQM SQS-Anforderungen die Kosten gesenkt. Weitere Informationen finden Sie unter Clientseitige Pufferung und Batch-Verarbeitung von Anforderungen im HAQM-SQS-Entwicklerhandbuch.

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

Nein. Der HAQMSQSBufferedAsyncClient wird im Austausch für den vorhandenen HAQMSQSAsyncClient implementiert.

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

1. Wählen Sie in der HAQM SQS-Konsole eine HAQM 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 HAQM-SNS-Thema im HAQM-SQS-Entwicklerhandbuch.

Ja. Mit der Aktion PurgeQueue können alle Nachrichten in einer HAQM 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 HAQM-SQS-Warteschlangen.

FIFO-Warteschlangen sind in allen AWS-Regionen verfügbar, in denen HAQM SQS angeboten wird. Weitere Informationen zur regionalen Verfügbarkeit von HAQM 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 HAQM 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 HAQM-SQS-Entwicklerhandbuch.

Nein. HAQM-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 HAQM-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 HAQM-SQS-Entwicklerhandbuch.

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 HAQM SQS die Nachrichten in der Reihenfolge zu, in der sie für die Verarbeitung eingehen. Um sicherzustellen, dass HAQM 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 HAQM-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 HAQM 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 HAQM 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 HAQM 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 HAQM-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.

HAQM 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 HAQM Relational Database Service.

Authentifizierungsmechanismen sorgen dafür, dass in HAQM 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.

HAQM 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 HAQM-SQS-Richtlinienbeispiele im HAQM-SQS-Entwicklerhandbuch.

HAQM 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. HAQM SQS unterstützt die Versionen 1.0, 1.1 und 1.2 des Protokolls Transport Layer Security (TLS) in allen Regionen.

Wenn HAQM 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 HAQM SQS bei der nächsten Anforderung erneut. Weitere Informationen finden Sie unter Zeitbeschränkung für die Sichtbarkeit im HAQM-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 HAQM SQS eine success-Antwort zurück.

Mit SSE können Sie vertrauliche Daten in verschlüsselten Warteschlangen übermitteln. SSE schützt die Nachrichteninhalte in HAQM-SQS-Warteschlangen und verwendet dabei Schlüssel, die im AWS Key Management Service (AWS KMS) verwaltet werden. Die Nachrichten werden direkt beim Eingang in HAQM SQS verschlüsselt. Sie werden verschlüsselt gespeichert. HAQM 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 HAQM SQS-Entwicklerhandbuch.

Ja. Dazu müssen Sie die Kompatibilität zwischen AWS Services (z. B. HAQM CloudWatch Events, HAQM S3 und HAQM 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 HAQM SQS in allen AWS-Regionen verfügbar, in denen HAQM SQS erhältlich ist. Weitere Informationen zur regionalen Verfügbarkeit von HAQM SQS finden Sie hier.

Dazu verwenden Sie die HAQM 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 HAQM-SQS-Warteschlange mit serverseitiger Verschlüsselung und Konfigurieren der serverseitigen Verschlüsselung (SSE) für eine vorhandene HAQM-SQS-Warteschlange im HAQM-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 HAQM 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 HAQM-SQS-Entwicklerhandbuch.

Es entstehen keine zusätzlichen Gebühren für HAQM SQS. Allerdings werden für Aufrufe von HAQM 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 HAQM-SQS-Entwicklerhandbuch.

SSE verschlüsselt den Nachrichtentext in einer HAQM 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

HAQM SQS generiert Datenschlüssel basierend auf dem AWS-verwalteten Customer Master Key (CMK) für HAQM 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 HAQM SQS? im HAQM-SQS-Entwicklerhandbuch.

SSE verwendet den Algorithmus „AES-GCM 256“.

Durch SSE wird der Durchsatz (TPS) von HAQM 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 HAQM 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 HAQM 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 HAQM 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 HAQM 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 HAQM SQS-Warteschlange senden.

C ist die Anzahl der Verbraucher, die Nachrichten aus der HAQM 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 HAQM-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 HAQM-SQS-Entwicklerhandbuch.

Ja. HAQM 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 HAQM SQS als HIPAA-fähigen Service ausgeweitet. Wenn Sie über eine aktive Business Associate Agreement (BAA) mit AWS verfügen, können Sie HAQM 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 HAQM 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 HAQM SQS übertragen möchten (oder wenn Sie Nachrichten haben, die größer als 256 KB sind), können Sie HAQM-SQS-Nachrichtennutzlasten auch über HAQM S3 senden. Verwenden Sie dazu die Erweiterte Clientbibliothek für Java für HAQM SQS (HAQM S3 ist ein HIPAA-konformer Service, mit Ausnahme der Verwendung von HAQM S3 Transfer Acceleration). Weitere Informationen finden Sie im Thema zum Verwenden der erweiterten Clientbibliothek für Java für HAQM SQS im HAQM-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 HAQM 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 HAQM 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 HAQM-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 HAQM 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 HAQM SQS-Nachrichtenattributen im HAQM-SQS-Entwicklerhandbuch.

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

HAQM 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 HAQM 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 120 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). HAQM SQS bietet APIs für das Erstellen und Verwalten von Zugriffsrichtlinienerklärungen:

• AddPermission
• RemovePermission
• SetQueueAttributes
• GetQueueAttributes

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

Der Inhaber der Nachrichtenwarteschlange bezahlt den gemeinsamen Nachrichtenwarteschlangenzugriff.

Die HAQM 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 HAQM-SQS-Richtlinienbeispiele im HAQM-SQS-Entwicklerhandbuch.

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

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

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

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

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

Eine Dead-Letter-Queue (DLQ) ist eine HAQM 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 HAQM 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 HAQM 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 HAQM 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.)