RabbitMQ & CloudAMQP EU Alternative 2026: CLOUD Act Analysis and GDPR Compliance

Post #2 in the sota.io EU Message Broker Series

RabbitMQ is everywhere. The open-source message broker powers everything from fintech payment queues to healthcare HL7 message routing. CloudAMQP — the managed RabbitMQ SaaS run by Swedish company 84codes AB — handles millions of queues for tens of thousands of developers worldwide.

Here is the complication European compliance officers face in 2026: CloudAMQP is Swedish-owned (EU parent) but your messages flow through AWS Frankfurt, GCP Belgium, and Azure West Europe — all US-controlled infrastructure subject to the CLOUD Act. This creates a nuanced sub-processor risk that standard vendor questionnaires miss.

This guide breaks down: the CLOUD Act status of CloudAMQP (84codes AB), the GDPR Art.28 sub-processor chain, and which EU-native alternatives give you zero US-jurisdiction exposure for your message broker layer.

What Is RabbitMQ and Why Is It GDPR-Relevant?

RabbitMQ is an open-source AMQP message broker originally developed by Rabbit Technologies Ltd (acquired by VMware in 2010, then by Broadcom in 2023). It implements the Advanced Message Queuing Protocol (AMQP 0-9-1) and supports MQTT, STOMP, and WebSockets through plugins.

GDPR relevance of message queues:

Message brokers are rarely discussed in GDPR impact assessments, but they carry significant personal data risks:

• Queue payloads: Order confirmations, user notification events, and webhook deliveries often contain names, email addresses, and purchase history — all GDPR Art.4(1) personal data.
• Consumer group metadata: RabbitMQ tracks which consumers processed which messages. This creates a processing log that may constitute personal data under Art.4(2).
• Dead-letter queues (DLQs): Failed messages containing PII can persist in DLQs for days or weeks longer than intended, violating Art.5(1)(e) storage limitation.
• Exchange routing keys: In multi-tenant architectures, routing keys often encode user IDs or customer identifiers.
• Shovel and Federation plugins: Cross-cluster replication can move data across jurisdictions automatically — triggering GDPR Chapter V transfer obligations with zero developer awareness.

When a US authority issues a CLOUD Act demand to AWS or GCP for "all data stored on your servers in Germany," that demand covers RabbitMQ queue contents stored on those servers — including message payloads your application briefly passes through.

CloudAMQP (84codes AB): The EU Parent / US Infrastructure Problem

Company: 84codes AB, Gothenburg, Sweden EU Entity: Yes — Swedish Aktiebolag, incorporated under Swedish law CLOUD Act Direct Exposure: Low — Swedish entity not subject to US CLOUD Act §2713(a) CLOUD Act Indirect Exposure: Moderate — infrastructure runs on AWS, GCP, and Azure

What 84codes AB Offers

CloudAMQP is 84codes AB's flagship SaaS: managed RabbitMQ with automatic backups, TLS, monitoring, and clustering across 19 cloud regions. Plans range from the free "Little Lemur" (shared instance, 100 connections) to "Bunny" dedicated clusters at €36/month.

84codes AB also maintains CloudMQTT (managed MQTT broker) and LavinMQ — a high-performance, open-source AMQP 1.0 broker written in Crystal that 84codes developed as a RabbitMQ alternative for high-throughput workloads.

The Sub-Processor Chain (GDPR Art.28)

This is the critical compliance issue for CloudAMQP:

Your Application → CloudAMQP (84codes AB, SE) → AWS Frankfurt / GCP Belgium / Azure West EU
                     ↑                             ↑
              EU Data Controller              US Sub-processors (CLOUD Act applies here)

Under GDPR Art.28(2), 84codes AB as your data processor must impose the same data protection obligations on its own processors (AWS, GCP, Azure) that apply to 84codes itself. Art.28(4) requires written contracts with sub-processors that include the same Art.28(3) guarantees.

What this means in practice:

1. AWS sub-processor risk: AWS Inc., Seattle WA — subject to CLOUD Act. Even if your RabbitMQ instance runs in Frankfurt, AWS is a US entity. A CLOUD Act warrant to AWS for data on their German servers could reach your queue contents. See our AWS SES analysis for the AWS jurisdiction framework.

2. GCP sub-processor risk: Google LLC, Delaware — PRISM participant. Alphabet family companies have historically cooperated with NSLs (National Security Letters) under FISA §702 without customer notification.

3. Azure sub-processor risk: Microsoft Corporation, Redmond WA — subject to CLOUD Act. Microsoft has published transparency reports on government demands but the EU Data Boundary program explicitly does not cover CLOUD Act obligations.

CLOUD Act Risk Score: CloudAMQP (84codes AB)

Compare: Confluent Inc. (Delaware) scores 18/25 — direct US parent plus AWS control plane.

GDPR Art.28 DPA: What to Request from CloudAMQP

If you continue using CloudAMQP with EU workloads, your DPA with 84codes AB must explicitly:

• List AWS, GCP, and Azure as sub-processors with GDPR Art.28(3) contracts
• Specify that data will only be processed in EU regions (Frankfurt, Belgium, West Europe)
• Include Transfer Impact Assessments (TIAs) for the EU→US sub-processor transfers under GDPR Art.46 Standard Contractual Clauses
• Bind 84codes to Art.28(2): no new sub-processors without your prior written consent

CloudAMQP's standard DPA is available at cloudamqp.com/legal and references AWS, Google, Microsoft, and Hetzner as sub-processors. The Hetzner entry is important — CloudAMQP does offer Hetzner-hosted plans for EU customers, though these are more limited in features than their AWS/GCP offerings.

Broadcom RabbitMQ: The US Parent Risk

When Broadcom acquired VMware in late 2023 for $69 billion, RabbitMQ passed to Broadcom Inc., San Jose, CA — a Fortune 500 technology company with significant US government contracts through VMware and Broadcom's semiconductor business.

Broadcom Inc. CLOUD Act Score: 18/25

Licensing change risk: Post-Broadcom, VMware products moved from perpetual to subscription licensing with significant price increases. Broadcom sunsetted VMware Cloud on AWS, VSphere Essentials+, and numerous SMB products within 12 months of acquisition. RabbitMQ itself remains open-source under the Mozilla Public License 2.0 (MPL-2.0), but Broadcom's managed offerings are now part of the Tanzu portfolio with enterprise pricing.

EU-Native RabbitMQ Alternatives

Option 1: Self-Hosted RabbitMQ on Hetzner (0/25 — Recommended)

CLOUD Act Score: 0/25 Cost: ~€6-26/month (Hetzner VPS) Complexity: Medium

Self-hosted RabbitMQ on Hetzner Cloud eliminates CLOUD Act exposure entirely. Hetzner Online GmbH (Gunzenhausen, Bavaria) is a German company with no US parent, no US-listed shares, and no PRISM program participation.

# Deploy RabbitMQ on Hetzner CX21 (€6.90/month, 2 vCPU, 4GB RAM)
# Step 1: Create Hetzner server
hcloud server create \
  --name rabbitmq-eu \
  --type cx21 \
  --image ubuntu-24.04 \
  --location nbg1 \
  --ssh-key your-key

# Step 2: Install RabbitMQ via official Debian repository
ssh root@YOUR_SERVER_IP << 'EOF'
apt-get update && apt-get install -y curl gnupg apt-transport-https
curl -1sLf "https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73A36E6026DFCA" | gpg --dearmor | tee /usr/share/keyrings/com.rabbitmq.team.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/com.rabbitmq.team.gpg] https://ppa1.novemberain.com/rabbitmq/v3.12.x/deb/ubuntu jammy main" | tee /etc/apt/sources.list.d/rabbitmq.list
apt-get update && apt-get install -y rabbitmq-server
systemctl enable rabbitmq-server && systemctl start rabbitmq-server
rabbitmq-plugins enable rabbitmq_management
rabbitmqctl add_user admin STRONG_PASSWORD
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"
EOF

# Step 3: Verify management UI accessible at http://YOUR_IP:15672

Production hardening:

• Enable TLS with Let's Encrypt via Certbot
• Configure firewall: only allow 5672 (AMQP) and 15672 (management) from your VPC
• Set loopback_users to none for clustering
• Enable rabbitmq_auth_backend_ldap for enterprise SSO
• Use rabbitmq_shovel plugin only within EU-region clusters

Cost comparison:

• CloudAMQP "Bunny" dedicated: €36/month (shared infrastructure)
• Hetzner CX21 self-hosted: €6.90/month (dedicated, full control)
• Savings: €29.10/month = €349/year

For high-availability clustering:

# Three-node cluster on Hetzner: 3x CX21 = €20.70/month total
# Quorum queues for automatic leader election (RabbitMQ 3.8+)
rabbitmqctl set_policy ha-all "^" \
  '{"ha-mode":"exactly","ha-params":3,"ha-promote-on-shutdown":"when-synced"}' \
  --priority 1 --apply-to queues

Option 2: Aiven for RabbitMQ (4/25 — EU Managed Service)

Company: Aiven Oy, Helsinki, Finland EU Entity: Yes — Finnish Osakeyhtiö (Oy) CLOUD Act Score: 4/25

Aiven is a Finnish company offering managed open-source data infrastructure: PostgreSQL, Kafka, RabbitMQ, Redis, OpenSearch, and more. Like CloudAMQP, Aiven runs on AWS/GCP/Azure infrastructure — but Aiven Oy is an EU entity, giving slightly better GDPR Art.28 standing.

Why Aiven scores 4/25 vs CloudAMQP's 10/25:

• EU parent (Finnish) vs EU parent (Swedish): comparable, both low direct exposure
• Aiven specifically targets enterprise EU compliance customers and has more explicit sub-processor controls
• Aiven's DPA includes GDPR Art.28 contracts with each sub-processor and region-locking at plan level
• Aiven BYOC (Bring Your Own Cloud): deploy Aiven services into your own AWS VPC / GCP VPC — sub-processor becomes your own account

Aiven RabbitMQ pricing:

• Startup-1: €21/month (1 node, 2GB RAM, 10GB storage, shared infrastructure)
• Business-4: €119/month (3 nodes, 8GB RAM, 80GB storage, dedicated)
• EU regions: Frankfurt (AWS), Netherlands (GCP), Amsterdam (Azure)

Migration from CloudAMQP to Aiven:

# Python migration script: CloudAMQP → Aiven
import pika
import json

# Source: CloudAMQP
source_params = pika.URLParameters("amqps://user:pass@YOUR.cloudamqp.com/vhost")
# Destination: Aiven
dest_params = pika.URLParameters("amqps://user:pass@YOUR.aivencloud.com:PORT/vhost")

source_conn = pika.BlockingConnection(source_params)
dest_conn = pika.BlockingConnection(dest_params)

source_ch = source_conn.channel()
dest_ch = dest_conn.channel()

# Declare same queues on destination
queues = ["orders", "notifications", "webhooks"]
for q in queues:
    dest_ch.queue_declare(queue=q, durable=True)

# Drain and republish (for non-time-sensitive queues)
for q in queues:
    while True:
        method, properties, body = source_ch.basic_get(queue=q)
        if method is None:
            break
        dest_ch.basic_publish(
            exchange='',
            routing_key=q,
            body=body,
            properties=properties
        )
        source_ch.basic_ack(method.delivery_tag)
    print(f"Migrated queue: {q}")

Option 3: LavinMQ by 84codes (2/25 — Open Source, EU Deployable)

LavinMQ is 84codes AB's own AMQP broker — written in Crystal for high performance. It is open-source (Apache 2.0) and AMQP 0-9-1 compatible with RabbitMQ, meaning most RabbitMQ clients work without code changes.

When self-hosted on Hetzner, LavinMQ gives you:

• EU jurisdiction (Hetzner Germany)
• AMQP 0-9-1 and AMQP 1.0 support
• Built-in HTTP management API compatible with RabbitMQ management plugin
• Lower memory footprint than RabbitMQ (~30% less RAM for equivalent workloads)
• CLOUD Act Score: 0/25 (self-hosted on EU infrastructure)

# Deploy LavinMQ via Docker on Hetzner
docker run -d \
  --name lavinmq \
  -p 5672:5672 \
  -p 15672:15672 \
  -v lavinmq_data:/var/lib/lavinmq \
  --restart unless-stopped \
  cloudamqp/lavinmq:latest

# LavinMQ is drop-in compatible with most RabbitMQ client code
# Python example (no code changes needed):
import pika
connection = pika.BlockingConnection(
    pika.ConnectionParameters(host='YOUR_HETZNER_IP')
)

GDPR Art.5(1)(e) and Dead-Letter Queue Compliance

One of the most overlooked GDPR risks in RabbitMQ deployments is dead-letter queue (DLQ) accumulation. Under GDPR Art.5(1)(e) (storage limitation principle), personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary."

RabbitMQ's x-dead-letter-exchange routes rejected, expired, or nack'd messages to a separate exchange. In practice:

# This creates GDPR storage limitation risk:
channel.queue_declare(
    queue='orders',
    arguments={
        'x-dead-letter-exchange': 'dlx',
        'x-message-ttl': 86400000  # 24h message TTL
    }
)
# Messages containing PII accumulate in 'dlq' indefinitely
# unless you explicitly set x-message-ttl on the DLQ too

Compliant DLQ configuration:

# Set retention on DLQ matching your data retention policy
channel.queue_declare(
    queue='orders-dlq',
    arguments={
        'x-message-ttl': 604800000,  # 7 days — match your retention policy
        'x-expires': 2592000000      # Auto-delete DLQ if empty for 30 days
    }
)

NIS2 Art.21(2)(e) backup requirements: If you use RabbitMQ's quorum queues for critical infrastructure message passing, NIS2 requires "business continuity management, including backup management and disaster recovery." Quorum queues with 3+ replicas satisfy the HA requirement; cross-datacenter replication satisfies the DR requirement.

Shovel Plugin and Cross-Border Transfer Risks

RabbitMQ's Shovel plugin moves messages between brokers — often used for cross-region replication or connecting development and production queues. If your shovel configuration moves messages from an EU-region CloudAMQP instance to a US-region instance (or vice versa), you trigger GDPR Chapter V international transfer obligations.

// Dangerous shovel configuration (triggers Chapter V obligations):
{
  "src-uri": "amqps://eu.cloudamqp.com/vhost",
  "dest-uri": "amqps://us.cloudamqp.com/vhost",
  "src-queue": "user-events",
  "dest-queue": "user-events-us"
}

Chapter V compliance requirements for this configuration:

1. A Transfer Impact Assessment (TIA) per GDPR Art.46(1) and EDPB Recommendations 01/2020
2. Standard Contractual Clauses (SCCs) covering the transfer (2021 EU-SCCs Module 2 controller-to-processor)
3. Supplementary technical measures: encryption of message payload in transit and at rest, with keys held exclusively in EU

If you cannot guarantee that US authorities cannot access the message contents, the shovel configuration creating US-bound message flows may be unlawful under GDPR Art.44.

Safe alternative: Use RabbitMQ Federation instead of Shovel for read-only message propagation that respects regional boundaries, combined with regional broker clusters that never replicate outside their EU jurisdiction.

CLOUD Act Comparison Table: Message Brokers

4-Week Migration Guide: CloudAMQP → Hetzner Self-Hosted

Week 1: Parallel Setup

# Deploy RabbitMQ on Hetzner
hcloud server create --name rabbitmq-prod --type cx21 \
  --image ubuntu-24.04 --location nbg1

# Install RabbitMQ and configure TLS
apt-get install rabbitmq-server -y
rabbitmq-plugins enable rabbitmq_management rabbitmq_shovel rabbitmq_shovel_management

# Add Hetzner instance as shovel destination from CloudAMQP
# (temporary — remove after migration completes)

Week 2: Shadow Traffic

Route 10% of producers to Hetzner broker while keeping CloudAMQP as primary. Monitor message delivery rates, consumer lag, and DLQ accumulation. Verify TLS certificate chain and AMQP connection stability.

Week 3: Cut-Over

1. Scale CloudAMQP shovel to move all producers to Hetzner
2. Keep CloudAMQP consumers running until all queues are drained
3. Update all consumer connection strings to Hetzner endpoint
4. Verify DLQ contents are transferred and not orphaned

Week 4: Cleanup

1. Delete CloudAMQP vhost and queues (after 7-day monitoring period)
2. Cancel CloudAMQP plan
3. Update GDPR Art.30 Record of Processing Activities: remove 84codes AB as processor
4. Update DPAs: remove CloudAMQP from sub-processor list

Estimated savings: CloudAMQP Bunny €36/month → Hetzner CX21 €6.90/month = €29/month saved

GDPR Art.30 Record of Processing: Message Broker Checklist

Every organization using a managed message broker service must maintain a Record of Processing Activities entry under GDPR Art.30. For RabbitMQ/CloudAMQP workloads:

Required Art.30 entries:

• Processing activity name: "Asynchronous message queue processing"
• Purpose of processing: (e.g., "order fulfillment events", "user notification delivery")
• Categories of personal data: message payload contents (enumerate: name, email, order ID, etc.)
• Categories of data subjects: (e.g., registered customers, trial users)
• Recipients: CloudAMQP (84codes AB), then AWS/GCP/Azure as sub-processors
• Transfer to third countries: USA (via AWS/GCP/Azure sub-processors) with SCCs + TIA
• Retention: message TTL + DLQ retention + backup retention

If you migrate to self-hosted Hetzner, the "Transfer to third countries" row becomes "None" — simplifying your Art.30 record and eliminating the need for ongoing SCC monitoring.

Decision Framework

Use CloudAMQP (84codes AB) if:

• You need a managed service with zero operational overhead
• Your legal team is comfortable with EU-parent / US-sub-processor risk
• You've executed a TIA covering AWS/GCP/Azure sub-processors
• Your data classification is "internal" or below (not "confidential" or "restricted")

Use Aiven RabbitMQ if:

• You need a managed service with stronger EU-compliance documentation
• Your enterprise procurement requires ISO 27001, SOC 2, and GDPR DPA with explicit sub-processor controls
• You need multi-cloud managed RabbitMQ with EU-entity SLA

Use Self-hosted RabbitMQ on Hetzner if:

• Your data includes financial transactions, health records, or special category data under GDPR Art.9
• You need zero CLOUD Act exposure with contractual guarantees
• Your team has DevOps capacity for RabbitMQ operations (backup, clustering, monitoring)
• You are subject to DORA (Financial Services) or NIS2 (Critical Infrastructure) and need "sole control" of the data processing environment

Avoid Broadcom/VMware RabbitMQ managed services if:

• You process EU personal data at any scale — the US parent and control plane jurisdiction create unavoidable CLOUD Act exposure that no contractual workaround resolves.

Next in the EU Message Broker Series

• Post #3: Google Pub/Sub EU Alternative 2026 — Google LLC (Delaware) CLOUD Act analysis, Pub/Sub subscription metadata as personal data, and EU-native streaming alternatives
• Post #4: Azure Service Bus EU Alternative 2026 — Microsoft CLOUD Act 21/25, EU Data Boundary limitations, and self-hosted KEDA alternatives
• Post #5: EU Message Broker Comparison Finale — Risk matrix across all 5 providers with decision framework

sota.io is an EU-native managed PaaS running on Hetzner Germany. No US parent. No CLOUD Act exposure. Git push to deploy. From €9/month.