Amazon SQS, SNS en MQ naar STACKIT RabbitMQ

Twee queues, een topic en een broker: invoer en concept

Een messagingomgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld: een standaardqueue met een dead-letter queue, een FIFO-queue, een SNS-topic met een SQS-subscription en een e-mailsubscription, en een Amazon MQ RabbitMQ-broker. Links: de SQS- en SNS-invoer. Rechts: het ene resourceblok dat de run daarvoor schrijft; de reviewcommentaren boven het blok in het bestand zijn hier weggelaten.

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

• Eén instance voor veel queues

  De vier SQS- en SNS-eenheden worden vervangen door één stackit_rabbitmq_instance. Uw team maakt de queues en exchanges erin aan, omdat ze buiten Terraform in de instance worden aangemaakt. Let op: het concept schrijft alleen een credential voor de instance van de broker, niet voor deze gedeelde instance. Voeg vóór het plannen een stackit_rabbitmq_credential toe voor de queueclients.

• De toegangslijst vult u zelf in

  sgw_acl wordt opgebouwd uit een variabele zonder standaardwaarde. Blijft die leeg, dan past STACKIT zijn standaardtoegangslijst toe, dus de run vraagt u de clientnetwerken te noemen vóór het plannen.

De migratie in zes stappen

De volgorde volgt de run: de golven plaatsen de dead-letter queue vóór de queue die ernaar verwijst en het topic als laatste. Het dataverplaatsingsdocument voor de broker zet de structuur eerst, dan de producers en als laatste de consumers die leegdraaien.

1. 01

   1. Inventariseer elke queue, elk topic en elke subscription

   Som elke queue op met type (standaard of FIFO), visibility timeout, retentie, redrive policy en de producers en consumers die ervan gebruikmaken. Doe hetzelfde voor elk SNS-topic en de protocollen van de subscriptions. De run noemt de eenheden die hij vond; de instellingen die niet worden overgenomen, staan per eenheid in het concept.

2. 02

   2. Bepaal het brokermodel

   Kies tussen RabbitMQ voor alles en de opt-in PubSub API voor queue-achtige objecten. De run stelt RabbitMQ op en schrijft de PubSub-aanroepen als JSON-bestanden die u in plaats van RabbitMQ mag gebruiken, nooit in aanvulling daarop.

3. 03

   3. Pas de instance toe en vul de toegangslijst

   Stel project_id, het plan, de versie en de clientnetwerken in en pas toe. Lees de credential-outputs die het concept voor de instance van de broker schrijft (host, poort, management-URL, wachtwoord) en voeg zelf een credential toe aan de gedeelde instance. Geef beide vóór elke cutover door aan de clients.

4. 04

   4. Maak de topologie opnieuw aan

   Maak de queues, de dead-letter exchange en de fan-out exchange met hun bindings aan. Exporteer voor een Amazon MQ-broker de definities van de broker, verwijder wat niet wordt overgenomen, oefen de import op een scratch virtual host en importeer daarna echt.

5. 05

   5. Verplaats producers, laat consumers leegdraaien

   Producers schakelen eerst over naar de nieuwe instance, zodat er niets meer naar de oude queues wordt gepubliceerd; consumers blijven de oude queues lezen tot die leeg zijn en schakelen dan over.

6. 06

   6. Controleer, houd de weg terug open, faseer de bron uit

   Publiceer één bericht end-to-end, vergelijk de definities aan beide kanten, leg vast hoe lang de bron blijft bestaan en wat er gebeurt met berichten die intussen zijn verzonden, en verwijder de bron pas na de retentie die u hebt bepaald.

Wat de run koppelt

Uit assessment.json van de run: vijf eenheden uit zeven resources. De twee SNS-subscriptions gaan op in hun topic.

RECONFIGURE betekent dat het product hetzelfde blijft en de release en instellingen veranderen. REPLATFORM betekent dat het programmeermodel verandert: clients verlaten de SQS- of SNS-API en spreken AMQP. De queue en het topic hebben zekerheidsniveau LOW; de bevinding die ze onderscheidt, is dat elk een andere eenheid noemt die het concept niet als eigen resource aanmaakt.

Wat het concept aan uw team overlaat

Links: twee commentaarregels uit messaging.tf van de run, ongewijzigd gekopieerd; de overige commentaarregels daartussen zijn weggelaten. Rechts: een van de PubSub-payloads die de run als alternatief schrijft. De payloads worden pas toegepast nadat u hebt ingestemd met de opt-in-beslissing voor een API die nog kan wijzigen, en ze vervangen de RabbitMQ-instance in plaats van eraan toe te voegen. De ackDeadline van 60s van de subscription neemt de visibility timeout van 60 seconden van de queue over; de topicpayload neemt de retentie over 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-afhandeling

  AWS verplaatst een bericht naar de dead-letter queue na maxReceiveCount ontvangsten, ingesteld in de redrive policy, en raadt een langere retentie op de dead-letter queue aan dan op de bronqueue, zoals in deze omgeving (14 dagen tegenover 4). In RabbitMQ declareert uw team, als algemene praktijk, per queue een dead-letter exchange en bij quorum queues een delivery limit.

• Visibility timeout

  RabbitMQ kent geen visibility timeout (algemeen gedrag van RabbitMQ). Een bericht blijft onbevestigd tot de consumer het bevestigt of het kanaal sluit, dus consumercode die op de timeout steunde, wordt beoordeeld. De run noemt visibility_timeout_seconds en receive_wait_time_seconds daarom als niet overgenomen.

• FIFO en deduplicatie

  Het plan noemt de FIFO-queue onder wat niet kan worden gemigreerd: een standaardqueue zou berichten stilzwijgend herordenen en dupliceren, dus volgorde en deduplicatie worden herontworpen voordat er een doel wordt opgesteld, bijvoorbeeld met een geordende consumer en idempotente verwerking op basis van een volgnummer.

De Amazon MQ-broker: een eigen instance

De run houdt een aparte instance en credential voor de broker aan; de reviewcommentaren boven beide blokken zijn hier weggelaten. Berichten maken geen deel uit van de definities en de gebruikers van de broker worden niet overgenomen: clients krijgen de gebruiker die STACKIT voor de credential genereert.

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
}

• Overgang tussen versies

  De bron draait RabbitMQ 3.13. De run signaleert dat classic queue mirroring in de 4.x-lijn is verwijderd, dus een gemirrorde classic queue wordt een quorum queue en de mirroringsleutels worden vóór de import uit de policies verwijderd.

• Te bevestigen versie

  De catalogus die de run las, noemt 4.1 voor de regio. De lifecyclepagina van STACKIT noemt per november 2026 4.0 als huidige hoofdversie zonder einddatum en geeft september 2025 als einde van de levensduur van 3.13, de versie van de bron. Bevestig vóór de cutover welke versie de instance accepteert.

• Single instance geconstateerd

  De bronbroker is een SINGLE_INSTANCE. De omvang van het plan is een variabele met een voorgestelde standaardwaarde die u bevestigt. Het concept stelt niet dat de redundantie gelijkwaardig is.

De definities van de broker verhuizen in vier stappen

Uit het dataverplaatsingsdocument dat de run voor de broker schrijft. Elk commando is een template, overgenomen uit dat document; de wachtwoorden komen uit omgevingsvariabelen. Eigenaar van elke stap: de Data Architect.

Beslissingen van uw architecten

Het beslissingsregister van de run bevat twaalf open records voor deze omgeving. Dit zijn de records die het ontwerp veranderen.

• RabbitMQ of de PubSub API

  Het accepteren van de opt-in-beslissing voor API's die nog kunnen wijzigen schakelt queue-achtige objecten om naar PubSub. Het is de enige beslissing hier die stappen in het plan tegenhoudt.

• Publiek endpoint en toegangslijst

  Het RabbitMQ-endpoint is publiek en beperkt door sgw_acl. De run houdt dat als standaard aan en vraagt u dit te bevestigen of een ander ontwerp te kiezen als clients het niet van buitenaf mogen bereiken.

• Omvang van het plan

  De omvang wordt voorgesteld op basis van de instanceklasse van de bron. Bevestig of kies een plan.

• E-mail- en sms-subscriptions

  Het SNS-topic heeft een e-mailsubscription. AWS noemt HTTP- en HTTPS-, e-mail-, Firehose-, SQS-, Lambda-, platformapplicatie- en sms-endpoints; RabbitMQ levert zelf niet aan e-mail, sms, mobiele push of HTTP-endpoints. Een kleine eigen service consumeert een queue die aan de exchange is gebonden en levert af.

• Berichten onderweg

  Berichten worden niet door het concept gemigreerd. Beslis of queues leegdraaien voordat de producers overschakelen, of dat een replaymethode wordt ingeoefend.

Vragen van messagingteams

Bronnen

• STACKIT RabbitMQ-documentatie
• Amazon SQS dead-letter queues
• Creating a subscription to an Amazon SNS topic
• STACKIT RabbitMQ: lifecycle
• Amazon MQ: managing RabbitMQ engine versions