Amazon SQS, SNS und MQ zu STACKIT RabbitMQ

Zwei Queues, ein Topic und ein Broker: Eingabe und Entwurf

Eine für diese Seite geschriebene Messaging-Umgebung, am 4. November 2026 von StackToIT bewertet: eine Standard-Queue mit Dead-Letter-Queue, eine FIFO-Queue, ein SNS-Topic mit SQS- und E-Mail-Abonnement und ein Amazon-MQ-RabbitMQ-Broker. Links die Eingabe für SQS und SNS, rechts der eine Ressourcenblock, den der Lauf dafür schreibt; die Prüfkommentare über dem Block sind hier ausgelassen.

resource "aws_sqs_queue" "orders_dlq" {
  name                      = "orders-dlq"
  message_retention_seconds = 1209600
}

resource "aws_sqs_queue" "orders" {
  name                       = "orders"
  visibility_timeout_seconds = 60
  message_retention_seconds  = 345600
  receive_wait_time_seconds  = 10
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.orders_dlq.arn
    maxReceiveCount     = 5
  })
}

resource "aws_sqs_queue" "invoices" {
  name                        = "invoices.fifo"
  fifo_queue                  = true
  content_based_deduplication = true
}

resource "aws_sns_topic" "order_events" {
  name = "order-events"
}

resource "aws_sns_topic_subscription" "orders_to_queue" {
  topic_arn = aws_sns_topic.order_events.arn
  protocol  = "sqs"
  endpoint  = aws_sqs_queue.orders.arn
}

resource "aws_sns_topic_subscription" "orders_to_email" {
  topic_arn = aws_sns_topic.order_events.arn
  protocol  = "email"
  endpoint  = "ops@example.com"
}

resource "stackit_rabbitmq_instance" "messaging" {
  project_id = var.project_id
  name       = "messaging"
  plan_name  = var.rabbitmq_plan_name
  version    = var.rabbitmq_version
  parameters = {
    sgw_acl = join(",", var.rabbitmq_allowed_cidrs)
  }
}

• Eine Instanz für viele Queues

  Die vier SQS- und SNS-Einheiten werden durch eine stackit_rabbitmq_instance ersetzt. Queues und Exchanges darin legt Ihr Team an, denn sie entstehen in der Instanz außerhalb von Terraform. Beachten Sie: Der Entwurf schreibt einen Zugang nur für die Instanz des Brokers, nicht für diese gemeinsame Instanz. Ergänzen Sie vor dem Plan ein stackit_rabbitmq_credential für die Clients der Queues.

• Die Zugriffsliste füllen Sie

  sgw_acl wird aus einer Variablen ohne Standardwert gebildet. Bleibt sie leer, gilt die Standardliste von STACKIT; der Lauf verlangt daher, die Client-Netzwerke vor dem Plan zu nennen.

Die Migration in sechs Schritten

Die Reihenfolge folgt dem Lauf: Seine Wellen setzen die Dead-Letter-Queue vor die Queue, die auf sie verweist, und das Topic zuletzt; sein Dokument zum Datenumzug des Brokers stellt die Struktur an den Anfang, dann die Producer, zuletzt die Consumer, die die alten Queues leeren.

1. 01

   1. Alle Queues, Topics und Abonnements erfassen

   Erfassen Sie jede Queue mit Typ (Standard oder FIFO), Visibility Timeout, Aufbewahrung, Redrive-Policy sowie ihre Producer und Consumer. Dasselbe gilt für jedes SNS-Topic und die Protokolle seiner Abonnements. Der Lauf listet die gefundenen Einheiten; nicht übernommene Einstellungen sind im Entwurf je Einheit benannt.

2. 02

   2. Das Brokermodell entscheiden

   Wählen Sie zwischen RabbitMQ für alles und der PubSub-API für queueartige Objekte, die bewusst zugeschaltet werden muss. Der Lauf entwirft RabbitMQ und schreibt die PubSub-Aufrufe als JSON-Dateien, die Sie stattdessen nutzen können, nie zusätzlich.

3. 03

   3. Instanz anlegen und Zugriffsliste füllen

   Setzen Sie project_id, Plan, Version und Client-Netzwerke und wenden Sie den Entwurf an. Lesen Sie die Zugangsausgaben, die der Entwurf für die Instanz des Brokers schreibt (Host, Port, Management-URL, Passwort), und legen Sie für die gemeinsame Instanz selbst einen Zugang an. Geben Sie beides vor jedem Cutover an die Clients weiter.

4. 04

   4. Topologie neu anlegen

   Legen Sie Queues, den Dead-Letter-Exchange und den Fanout-Exchange mit seinen Bindings an. Bei einem Amazon-MQ-Broker exportieren Sie die Definitionen, entfernen, was sich nicht übertragen lässt, proben den Import auf einem Scratch-Virtual-Host und importieren dann produktiv.

5. 05

   5. Producer umstellen, Consumer leerlaufen lassen

   Die Producer wechseln zuerst auf die neue Instanz, damit nichts mehr in die alten Queues geschrieben wird. Die Consumer lesen die alten Queues leer und wechseln danach.

6. 06

   6. Prüfen, Rückweg offenhalten, stilllegen

   Senden Sie eine Nachricht End-to-End durch, vergleichen Sie die Definitionen beider Seiten, halten Sie fest, wie lange die Quelle bleibt und was mit zwischenzeitlich gesendeten Nachrichten geschieht, und löschen Sie die Quelle erst nach der entschiedenen Aufbewahrung.

Was der Lauf zuordnet

Aus der assessment.json des Laufs: fünf Einheiten aus sieben Ressourcen. Die beiden SNS-Abonnements gehen in ihrem Topic auf.

RECONFIGURE heißt: Das Produkt bleibt gleich, Release und Einstellungen ändern sich. REPLATFORM heißt: Das Programmiermodell ändert sich; die Clients verlassen die SQS- oder SNS-API und sprechen AMQP. Die Queue und das Topic tragen die Konfidenz LOW; sie unterscheidet der Befund, dass beide auf eine andere Einheit verweisen, die der Entwurf nicht als eigene Ressource anlegt.

Was der Entwurf Ihrem Team überlässt

Links zwei Kommentarzeilen aus der messaging.tf des Laufs, unverändert; die Kommentarzeilen dazwischen sind ausgelassen. Rechts eine der PubSub-Nutzlasten, die der Lauf als Alternative schreibt. Die Nutzlasten greifen erst, wenn Sie der Opt-in-Entscheidung für eine API zustimmen, die sich noch ändern kann, und ersetzen die RabbitMQ-Instanz, statt sie zu ergänzen. Die ackDeadline von 60s des Abonnements übernimmt das 60-Sekunden-Visibility-Timeout der Queue; die Topic-Nutzlast übernimmt die Aufbewahrung als 345600s.

# NOT CARRIED (aws_sqs_queue.orders): visibility_timeout_seconds = 60, receive_wait_time_seconds = 10 — SQS hides a received message from the other consumers for the visibility timeout and long-polls for receive_wait_time_seconds … the acknowledgement handling of the consumers is checked. (shortened: the whole reason is in the trace of this block)
# CONSUMER CHANGE (aws_sns_topic_subscription.orders_to_queue): the subscriber aws_sqs_queue.orders is a queue that a person binds to the exchange of aws_sns_topic.order_events; the subscription itself has no resource and its settings are not generated.

{
  "displayName": "orders",
  "settings": {
    "ackDeadline": "60s"
  }
}

• Dead-Letter-Behandlung

  AWS verschiebt eine Nachricht nach maxReceiveCount Empfängen in die Dead-Letter-Queue, festgelegt in der Redrive-Policy, und empfiehlt für die Dead-Letter-Queue eine längere Aufbewahrung als für die Quell-Queue, wie in dieser Umgebung (14 gegenüber 4 Tagen). In RabbitMQ deklariert Ihr Team nach gängiger Praxis je Queue einen Dead-Letter-Exchange und bei Quorum-Queues ein Zustelllimit.

• Visibility Timeout

  RabbitMQ kennt kein Visibility Timeout (allgemeines RabbitMQ-Verhalten). Eine Nachricht bleibt unbestätigt, bis der Consumer sie quittiert oder sein Kanal schließt; Consumer-Code, der sich auf das Timeout verlassen hat, wird geprüft. Deshalb nennt der Lauf visibility_timeout_seconds und receive_wait_time_seconds als nicht übernommen.

• FIFO und Deduplizierung

  Der Plan führt die FIFO-Queue unter dem, was sich nicht migrieren lässt: Eine Standard-Queue würde Nachrichten stillschweigend umsortieren und doppelt zustellen. Reihenfolge und Deduplizierung werden daher neu entworfen, bevor ein Ziel entsteht, etwa mit einem geordneten Consumer und idempotenter Verarbeitung über eine Sequenznummer.

Der Amazon-MQ-Broker: eine eigene Instanz

Der Lauf sieht für den Broker eine eigene Instanz mit eigenem Zugang vor; die Prüfkommentare über beiden Blöcken sind hier ausgelassen. Nachrichten gehören nicht zu den Definitionen, und die Benutzer des Brokers werden nicht übernommen: Die Clients erhalten den Benutzer, den STACKIT für den Zugang erzeugt.

resource "stackit_rabbitmq_instance" "legacy" {
  project_id = var.project_id
  name       = "legacy-rabbit"
  plan_name  = var.legacy_plan_name
  version    = var.legacy_version
  parameters = {
    sgw_acl = join(",", var.legacy_allowed_cidrs)
  }
}

resource "stackit_rabbitmq_credential" "legacy" {
  project_id  = var.project_id
  instance_id = stackit_rabbitmq_instance.legacy.instance_id
}

• Versionssprung

  Die Quelle läuft mit RabbitMQ 3.13. Der Lauf weist darauf hin, dass die klassische Queue-Spiegelung in der Versionslinie 4.x entfernt wurde: Eine gespiegelte klassische Queue wird zur Quorum-Queue, und die Spiegelungsschlüssel werden vor dem Import aus den Policies entfernt.

• Version bestätigen

  Der vom Lauf gelesene Katalog führt für die Region 4.1. Die Lifecycle-Seite von STACKIT nennt Stand November 2026 die aktuelle Hauptversion 4.0 ohne End-of-Life-Datum und für 3.13, die Version der Quelle, September 2025 als End of Life. Bestätigen Sie vor dem Cutover, welche Version die Instanz annimmt.

• Einzelinstanz vermerkt

  Der Quell-Broker ist eine SINGLE_INSTANCE. Die Plangröße ist eine Variable mit einem vorgeschlagenen Standardwert, den Sie bestätigen; der Entwurf behauptet keine gleiche Ausfallsicherheit.

Die Definitionen des Brokers in vier Schritten

Aus dem Dokument zum Datenumzug, das der Lauf für den Broker schreibt. Jeder Befehl ist eine Vorlage aus diesem Dokument; die Passwörter kommen aus Umgebungsvariablen. Verantwortlich für jeden Schritt: der Data Architect.

Entscheidungen Ihrer Architekten

Das Entscheidungsregister des Laufs führt für diese Umgebung zwölf offene Einträge. Diese ändern das Design.

• RabbitMQ oder PubSub-API

  Die Zustimmung zum Zuschalten von APIs, die sich noch ändern können, stellt queueartige Objekte auf PubSub um. Es ist die einzige Entscheidung hier, an der Planschritte hängen.

• Öffentlicher Endpunkt und Zugriffsliste

  Der RabbitMQ-Endpunkt ist öffentlich und über sgw_acl begrenzt. Der Lauf belässt das als Standardwert und bittet um Bestätigung oder ein anderes Design, falls Clients ihn nicht von außen erreichen dürfen.

• Plangröße

  Die Größe wird aus der Instanzklasse der Quelle vorgeschlagen. Bestätigen Sie sie oder wählen Sie einen Plan.

• E-Mail- und SMS-Abonnements

  Das SNS-Topic hat ein E-Mail-Abonnement. AWS nennt HTTP und HTTPS, E-Mail, Firehose, SQS, Lambda, Plattformanwendung und SMS als Endpunkte; an E-Mail, SMS, Mobile-Push oder HTTP-Endpunkte liefert RabbitMQ nicht selbst aus. Ein kleiner eigener Dienst liest eine an den Exchange gebundene Queue und stellt zu.

• Nachrichten im Flug

  Nachrichten werden vom Entwurf nicht migriert. Entscheiden Sie, ob die Queues vor dem Umschalten der Producer leerlaufen oder ob ein Replay-Verfahren geprobt wird.

Fragen von Messaging-Teams

Quellen

• STACKIT-Dokumentation: RabbitMQ
• Amazon SQS: Dead-Letter-Queues
• Abonnement eines Amazon-SNS-Topics anlegen
• STACKIT RabbitMQ: Lifecycle
• Amazon MQ: RabbitMQ-Engine-Versionen verwalten