AWS SQS EU Alternative 2026: Message Queues, CLOUD Act, and GDPR Compliance

Post #702 in the sota.io EU Compliance Series

AWS Simple Queue Service (SQS) is the default message queue for AWS-based applications. It decouples microservices, buffers workloads, and reliably delivers messages between application components. Millions of applications use SQS to queue order confirmations, user event streams, payment notifications, document processing jobs, and background tasks — many of them processing personal data from EU users.

The integration is seamless: SQS fits naturally into any AWS-native architecture. But seamless integration with AWS means seamless integration with US jurisdiction.

Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) compels US companies to produce data stored anywhere in the world when served a valid government order. SQS queues in eu-west-1 (Ireland) or eu-central-1 (Frankfurt) are AWS infrastructure — they are not outside US legal reach. The queue configuration, message bodies, dead letter queues, and access logs are all held by an entity subject to CLOUD Act compulsion.

This is a critical distinction for EU applications processing personal data. When an order confirmation message sits in an SQS queue between your checkout service and your fulfillment service, it contains customer name, shipping address, order contents — personal data under GDPR Art.4(1). If that message is in an SQS queue, it is held by a US corporation that can be compelled to hand it over without notifying you or your customer.

This analysis covers: what SQS stores under US jurisdiction, the GDPR and CLOUD Act risk surface for message queue data, and the EU-native message queue alternatives that give EU applications full data sovereignty.

What AWS SQS Stores Under US Jurisdiction

Message bodies. The core risk is the message content itself. SQS stores messages as they await delivery to consumers. Standard queues can retain messages for up to 14 days; FIFO queues maintain strict ordering with up to 20,000 in-flight messages. During that retention window, the message body — and all personal data it contains — sits in SQS infrastructure operated by a US entity.

What travels through SQS queues in production EU applications? Order data with customer names, billing addresses, and product details. User registration events with email addresses and profile information. Payment processing notifications with transaction references. Document processing jobs with file references linking to personal documents. Webhook payloads from EU user actions containing behavioral data. Notification jobs with recipient phone numbers and email addresses for GDPR Art.14 communications.

Each of these message types constitutes personal data under GDPR when it relates to an identifiable natural person. Storing them — even temporarily — in SQS means storing them under CLOUD Act jurisdiction.

Message attributes and metadata. SQS supports structured message attributes — key-value pairs attached to each message that can carry additional context without embedding it in the message body. Common uses include: sender ID, correlation ID linking the message to a specific user session, priority level, content-type headers, idempotency keys that may encode user or transaction identifiers, and routing metadata that reveals application architecture.

Message attributes are stored alongside message bodies under the same retention policies. Attributes that encode user identifiers or session references constitute personal data even when the message body itself is anonymized.

Queue configuration and policies. Each SQS queue has a configuration stored under US jurisdiction: queue name, visibility timeout, delivery delay, maximum message size, retention period, and access policy (JSON IAM policy documents). For applications using SQS with attribute-based access control or resource-based policies that reference specific IAM principal ARNs (which may embed AWS account IDs, team names, or application identifiers), the queue policy is operational metadata under US jurisdiction.

Dead-letter queue (DLQ) configuration is particularly significant. DLQs capture messages that fail processing after a configurable number of attempts. Failed messages — often containing personal data from transactions that encountered errors — can accumulate in DLQs for up to 14 days. DLQs are frequently less monitored than primary queues, creating a secondary store of personal data under US jurisdiction that may be overlooked in GDPR Article 30 Records of Processing Activities.

SQS access logs and CloudTrail events. SQS API calls — SendMessage, ReceiveMessage, DeleteMessage, ChangeMessageVisibility — are logged in AWS CloudTrail when CloudTrail is enabled (which it should be for any production AWS account). CloudTrail logs capture: the identity of the IAM principal that called the API, the timestamp, the queue URL (which reveals queue names and account IDs), request parameters, and response metadata.

CloudTrail is itself an AWS service under US jurisdiction. Even if SQS message bodies are encrypted and never logged in cleartext, the CloudTrail record of every ReceiveMessage call reveals that specific application components processed specific queue messages at specific times — behavioral metadata about your application's processing of EU user data.

Server-side encryption keys. SQS supports server-side encryption (SSE) using AWS Key Management Service (KMS). When SSE-KMS is enabled, SQS message bodies are encrypted at rest using a KMS key that is itself managed under US jurisdiction. The encryption provides protection against unauthorized access to AWS storage infrastructure, but it does not protect against CLOUD Act compulsion: AWS holds the KMS key and can decrypt message bodies when legally required to do so.

SSE-SQS (using SQS-managed keys) provides similar protections with similar limitations. Neither encryption option removes CLOUD Act exposure because the key management authority remains with AWS.

Large message references via S3. When SQS messages exceed the 256 KB size limit — common for document processing payloads, image metadata, or large JSON structures — applications use the SQS Extended Client Library to store the actual payload in Amazon S3 and put a reference pointer in the SQS message. This creates a two-service personal data exposure: the message body in SQS (containing the S3 reference) and the actual payload in S3 (also under US jurisdiction). GDPR Article 30 documentation should capture both services in this pattern.

GDPR Legal Basis Problems with SQS

Chapter V transfer requirements. Every EU application that uses SQS is transferring personal data to the United States under GDPR Chapter V. Amazon offers Standard Contractual Clauses (SCCs) through the AWS GDPR Data Processing Addendum. SCCs are valid for most use cases post-Schrems II — but Schrems II (C-311/18) requires a Transfer Impact Assessment (TIA) evaluating whether US surveillance law undermines the SCC protections.

The CLOUD Act is the primary surveillance law at issue. The EDPB's Recommendations 01/2020 specifically call out broad US government access powers as a risk factor that TIAs must address. For SQS processing sensitive personal data (health data under Art.9, financial data, children's data), the TIA must document why the CLOUD Act risk is acceptable. Many Data Protection Officers conclude it is not acceptable for high-risk processing under Art.35 DPIA obligations.

Data minimization and message retention. GDPR Art.5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary." SQS's default 4-day retention period (configurable up to 14 days) means personal data in messages sits in US-jurisdiction storage for days after processing. Applications that retry failed messages via DLQs can retain personal data for weeks. Each day of retention in SQS is a day of unnecessary CLOUD Act exposure for personal data that has already been processed.

EU applications should evaluate whether message content can be pseudonymized: storing only a reference token in the SQS message body and keeping the personal data in an EU-resident database. This limits SQS exposure to reference tokens rather than personal data — though the operational architecture must ensure the token cannot be re-linked to personal data via a CLOUD Act subpoena to SQS combined with a separate subpoena to the application's AWS RDS database.

Article 28 processor requirements. AWS is a data processor under GDPR Art.28 when it processes personal data on your behalf (storing message bodies counts). The AWS DPA provides an Art.28 compliant processor agreement. However, Art.28(3)(b) requires that the processor "processes the personal data only on documented instructions from the controller." CLOUD Act compulsion — processing personal data by handing it to US authorities — is not an instruction from the EU controller. This is the fundamental tension that SCCs and DPAs cannot fully resolve for US-based processors.

NIS2 and DORA implications. EU organizations in regulated sectors face additional constraints. NIS2 Article 21(2)(b) requires risk management measures including "supply chain security" for critical services. Using SQS to queue messages for critical business processes — payment processing, user authentication events, access control decisions — means a US-based service is in the critical path. DORA (Digital Operational Resilience Act) Article 28 requires financial entities to ensure that ICT third-party providers (including message queue services) meet contractual requirements for data access, security, and operational resilience. CLOUD Act compulsion without prior notice to the financial entity may violate DORA's Article 28(4) requirements.

EU-Native Message Queue Alternatives for 2026

RabbitMQ (Self-Hosted on EU Infrastructure)

RabbitMQ is the most widely deployed open-source message broker. Deploying RabbitMQ on EU-resident infrastructure — Hetzner Cloud, OVHcloud, Scaleway, or any EU-based server — eliminates CLOUD Act exposure entirely.

Deployment options:

• Hetzner Cloud (Germany): Deploy RabbitMQ on a CX21 or CX31 instance in Falkenstein or Nuremberg. Hetzner AG is a German company; infrastructure is not subject to CLOUD Act. Monthly cost: €5-10/month for the server.
• OVHcloud Managed Kubernetes (France): Run RabbitMQ via the official Helm chart on OVHcloud Managed Kubernetes in GRA (France) or SBG (Strasbourg). OVHcloud SAS is a French company.
• Scaleway (France): Scaleway's Dedibox or Elastic Metal instances in Paris or Amsterdam for high-throughput RabbitMQ deployments.

RabbitMQ vs SQS for EU developers:

• AMQP protocol vs. AWS SDK — RabbitMQ uses standard AMQP 0-9-1 with client libraries for every language (Python, Java, Go, Node.js, Ruby, PHP)
• Message routing — RabbitMQ exchanges (direct, topic, fanout, headers) offer more flexible routing than SQS queue types
• Persistence — RabbitMQ queues can be durable (messages survive broker restart); SQS has similar guarantees
• Ordering — SQS FIFO queues guarantee order; RabbitMQ requires single consumer or consistent hashing exchange for ordering
• Max message size — RabbitMQ default 128 MB vs SQS 256 KB (RabbitMQ wins for large payloads)
• Dead letter queues — both support DLQ patterns with configurable retry counts
• Management UI — RabbitMQ Management Plugin provides a web UI for queue inspection and monitoring

Migration from SQS to RabbitMQ: Replace boto3.client('sqs') with the pika library (Python) or amqplib for Go. Map SQS Standard queues to RabbitMQ direct exchanges with durable queues. Map SQS FIFO queues to RabbitMQ single-consumer queues or the Consistent Hash Exchange plugin. DLQs map directly to RabbitMQ dead letter exchanges (x-dead-letter-exchange argument).

CloudAMQP (EU-Hosted Managed RabbitMQ)

CloudAMQP by 84codes AB (Sweden) provides managed RabbitMQ as a service with hosting options in EU data centers including Frankfurt (AWS eu-central-1 infrastructure — note: same CLOUD Act issue), but also Hetzner (EU-sovereignty) and OVHcloud (EU-sovereignty) via their "BYOC" (Bring Your Own Cloud) options.

Important note: CloudAMQP's standard plans run on AWS, GCP, or Azure infrastructure — which does not resolve CLOUD Act exposure. The EU-sovereignty benefit requires selecting their Hetzner or OVHcloud hosting options explicitly.

CloudAMQP plans start at free (Lemur plan, 1 million messages/month, shared instance) up to dedicated plans for production workloads. The Dedicated Hetzner plans provide genuine EU sovereignty for managed RabbitMQ.

Scaleway Messaging and Queuing

Scaleway (Paris, France) offers a managed messaging service supporting both NATS and SQS-compatible APIs. The SQS-compatible API means applications using AWS SDK SQS clients can switch to Scaleway Messaging with minimal code changes — primarily the endpoint URL and credentials.

Scaleway Messaging and Queuing is operated by Scaleway SAS, a French company. Infrastructure runs in French data centers in Paris (PAR) and Amsterdam (AMS). No US parent company, no CLOUD Act exposure.

Migration from SQS to Scaleway Messaging:

# Before: AWS SQS
import boto3
sqs = boto3.client(
    'sqs',
    region_name='eu-central-1',
    aws_access_key_id='AKIA...',
    aws_secret_access_key='...'
)

# After: Scaleway SQS-compatible API
import boto3
sqs = boto3.client(
    'sqs',
    region_name='fr-par',
    endpoint_url='https://sqs.mnq.fr-par.scaleway.com',
    aws_access_key_id='<scaleway-access-key>',
    aws_secret_access_key='<scaleway-secret-key>'
)

The endpoint swap is the primary change. Queue URLs change format, so queue creation and URL references need updating. SQS message attributes, visibility timeouts, retention periods, and DLQ configuration work identically.

Scaleway Messaging pricing: €0.40 per million requests (vs SQS €0.40/million for standard queues — comparable pricing with full EU sovereignty).

Hetzner + NATS Self-Hosted

NATS is a high-performance messaging system well-suited for microservices and event-driven architectures. NATS JetStream provides persistent messaging with SQS-equivalent features: durable consumers, message retention, replay, dead letter queue equivalents (via republish), and exactly-once delivery.

Self-hosting NATS on Hetzner Cloud (Germany) provides maximum EU data sovereignty at minimal cost. A Hetzner CX11 (€3.29/month) handles light NATS workloads; a 3-node cluster on CX21 instances (€5.77/month each) provides production-grade resilience.

NATS JetStream vs SQS feature comparison:

• Consumers: NATS JetStream push/pull consumers vs SQS polling. JetStream push consumers eliminate SQS-style polling loops.
• Ordering: JetStream sequences messages within a stream with total ordering; SQS FIFO provides per-group ordering.
• Replay: JetStream supports message replay from any sequence or time; SQS has no replay capability.
• At-least-once: Both guarantee at-least-once delivery.
• Exactly-once: JetStream supports idempotent publishing with deduplication; SQS FIFO provides exactly-once within deduplication windows.
• Message size: NATS max payload configurable (default 1 MB, tunable to 64 MB); SQS 256 KB hard limit.

OVHcloud Managed Kafka

For high-throughput event streaming use cases that use SQS as a high-volume event bus, OVHcloud Managed Kafka (Streams - Kafka) provides an EU-sovereign Kafka cluster. OVHcloud SAS is a French company; clusters run in OVHcloud data centers (France, Germany, Poland, Spain).

Apache Kafka is not a direct SQS replacement — it's a streaming platform rather than a point-to-point queue. But for EU applications using SQS for high-volume event streaming (user activity events, clickstreams, IoT data), Kafka on OVHcloud provides better throughput, replay capability, and consumer group semantics alongside EU sovereignty.

Ionos Message Queue

IONOS (1&1 IONOS SE, Germany) offers cloud messaging services for EU customers. IONOS SE is a German company, headquartered in Montabaur, Germany, a wholly owned subsidiary of United Internet AG. Infrastructure runs in German and European data centers.

IONOS cloud messaging is suitable for smaller-scale queue use cases with a preference for German-entity providers under strict German data protection requirements (BDSG + GDPR combined obligations).

Evaluating Your SQS Migration Path

The right EU-native alternative depends on your use case:

For SQS Standard queue replacement (simplest path): Scaleway Messaging and Queuing provides a drop-in API-compatible replacement. Code changes limited to endpoint URL and credentials. Choose this for fastest migration with minimum risk.

For self-hosted control and zero managed-service cost: RabbitMQ on Hetzner Cloud provides full control over message data with no vendor dependency beyond EU-based infrastructure. Best for teams comfortable with RabbitMQ operations.

For high-throughput event streaming: OVHcloud Managed Kafka or self-hosted Kafka/Redpanda on Hetzner provides EU-sovereign event streaming for workloads that outgrow SQS semantics.

For new EU-native applications: NATS JetStream on Hetzner provides modern messaging semantics (push consumers, replay, exactly-once) at lower operational complexity than Kafka, self-hosted on EU infrastructure.

The sota.io Connection

sota.io is a European PaaS for application deployment. When you deploy on sota.io, your message queues — whether RabbitMQ, NATS, or Redis Streams — run on EU infrastructure operated by a European company. No US parent entity means no CLOUD Act exposure for your message data.

Applications queued on SQS today can migrate to RabbitMQ or NATS deployed on sota.io with the infrastructure management handled for you. Your queue configurations, message data, and dead letter queues stay in Europe — accessible only under EU law.

For EU applications that process personal data in message queues (which is most of them), this is not a nice-to-have. It is a GDPR Article 44 compliance requirement: personal data leaving the EU must have adequate protection. The CLOUD Act makes adequate protection for SQS a contested legal question at best. EU-hosted RabbitMQ, NATS, or Scaleway Messaging makes it straightforward.

Summary: What to Do with SQS

1. Audit what personal data travels through your SQS queues. Message bodies, attributes, and dead letter queues may contain personal data you have not fully documented in your Art.30 Records of Processing Activities.

2. Update your TIA (Transfer Impact Assessment). If you are transferring personal data to SQS under SCCs, your TIA must address CLOUD Act risk explicitly. For sensitive categories (Art.9 data, financial data), the TIA conclusion may require migrating to EU-native alternatives.

3. Evaluate pseudonymization. If migration is not immediate, can you pseudonymize message bodies — storing only a reference token in SQS and keeping personal data in your EU-resident database? This reduces CLOUD Act exposure to reference tokens rather than personal data.

4. Choose your migration target. For API-compatible migration: Scaleway Messaging. For self-hosted control: RabbitMQ or NATS on Hetzner. For Kafka-scale workloads: OVHcloud Managed Kafka.

5. Update DLQ monitoring. Dead letter queues often accumulate personal data from failed processing attempts. Set retention periods to the minimum needed, monitor DLQ depth, and ensure DLQ contents are included in your GDPR data inventory.

AWS SQS is a well-engineered service. But for EU applications under GDPR, CLOUD Act exposure is not an engineering problem that AWS can solve with encryption or EU-region deployments. The legal exposure exists because AWS is a US company. The solution is EU-sovereign message queue infrastructure — which exists, is production-ready, and in most cases is comparable in cost to SQS.