AWS SNS EU Alternative 2026: Push Notifications, CLOUD Act, and GDPR Compliance

Post #703 in the sota.io EU Compliance Series

AWS Simple Notification Service (SNS) is the default pub/sub and notification service for AWS-based applications. It powers fan-out architectures, mobile push notifications, SMS alerts, email dispatches, and webhook deliveries across millions of AWS workloads. An EU SaaS product might use SNS to notify users of account events, trigger downstream processing pipelines, or fan out a single event to multiple subscribers simultaneously.

SNS fits naturally into AWS architectures. That natural fit also means SNS subscriber lists — containing phone numbers, email addresses, and application endpoints — are stored under the jurisdiction of a US corporation.

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. SNS topics in eu-west-1 (Ireland) or eu-central-1 (Frankfurt) are AWS infrastructure. The CLOUD Act does not distinguish between data centers in Oregon and Frankfurt when the controlling entity is an American corporation.

This matters for EU applications because SNS subscriber data is personal data under GDPR Art.4(1). A subscriber's phone number for SMS notifications, email address for delivery receipts, or device token for mobile push notifications all identify or are linkable to a natural person. That data sits in SNS — controlled by a US entity that can be compelled to produce it without notifying you or your subscribers.

This analysis covers what SNS stores under US jurisdiction, the GDPR risk surface for notification infrastructure, and the EU-native alternatives that give EU applications genuine data sovereignty.

What AWS SNS Stores Under US Jurisdiction

Topic subscriptions and subscriber endpoints. The most significant personal data exposure in SNS is the subscription list itself. Every SNS subscription stores the protocol and endpoint:

• Email and email-json: Full email address of the subscriber
• SMS: Phone number of the subscriber in E.164 format
• HTTP/HTTPS: Webhook URL of the subscribing service
• SQS: ARN of the SQS queue receiving messages
• Lambda: ARN of the Lambda function receiving messages
• Application (mobile push): Platform-specific device token

For SMS and email protocols, the endpoint is personal data under GDPR. A phone number or email address that identifies an EU natural person, stored as an SNS subscription, is personal data held by a US entity subject to CLOUD Act compulsion. An investigation involving a specific phone number would find it in your SNS subscription list if a law enforcement agency issued a CLOUD Act order to AWS.

EU applications with subscriber counts of tens of thousands are maintaining a substantial directory of personal data — every subscriber's notification endpoint — under US jurisdiction simply by using AWS SNS.

Message payloads in transit. SNS does not retain message payloads long-term like SQS: messages are delivered immediately to subscribers and are not stored for extended periods. However, during delivery attempts — including retries for HTTP/HTTPS endpoints that are temporarily unavailable — the message payload is held in SNS infrastructure under US jurisdiction. Delivery retry policies allow up to 23 retry attempts over a period of up to 23 days for HTTP subscribers. During that window, a message payload containing personal data (a notification about a user's account status, a payment confirmation, a document processing result) is held by a US entity.

For SQS fan-out patterns (SNS → SQS), the message is then held in SQS indefinitely until consumed. The combination creates a pipeline where personal data passes through two AWS services, both under US jurisdiction, with extended retention in the SQS stage.

Subscription attributes and filter policies. SNS subscription filter policies allow subscribers to receive only messages matching specific attribute criteria. These filter policies are stored as subscription attributes alongside the subscriber endpoint. Filter policies may encode user-specific routing logic — subscriber segments, user tier identifiers, geographic routing rules — that, combined with the subscriber endpoint, reveals relationships between users and your application's data structures.

SNS message attributes on the topic side — structured key-value pairs attached to published messages — can contain routing metadata, user identifiers, session tokens, or request correlation IDs. Message attributes are accessible to all subscribers and are held under the same jurisdiction as the message payload during delivery.

Mobile push notification tokens. SNS mobile push uses platform application endpoints to deliver push notifications via Apple APNs (Apple Push Notification Service), Google FCM (Firebase Cloud Messaging), Amazon ADM (Device Messaging), and others. Creating a mobile push endpoint in SNS requires registering a device token — a unique identifier issued by Apple or Google that maps to a specific device and, by extension, a specific user.

SNS stores these device tokens as platform application endpoints. The token itself is not directly a name or email address, but it is a persistent identifier that maps to an identifiable device, which maps to an identifiable person. Under GDPR Art.4(1), any data that can identify a natural person — directly or through linkage — is personal data. Device tokens stored in SNS are personal data under this definition.

For EU applications with mobile apps, the SNS platform endpoint list is effectively a directory of your users' devices under US jurisdiction. A CLOUD Act order could produce every device token your application has ever registered.

SMS delivery data. When SNS delivers SMS messages, it stores delivery metadata including the destination phone number, delivery status, timestamp, and message content reference. SNS SMS delivery logs can be routed to Amazon CloudWatch Logs — which is itself an AWS service under US jurisdiction.

SMS spending limits, sender IDs, and opt-out list management are stored in the SNS account settings. The SNS opt-out registry — tracking which phone numbers have requested SMS opt-out — is a list of phone numbers held under US jurisdiction.

Delivery status logs. SNS supports delivery status logging for all protocols: successful deliveries, failed deliveries, and retried deliveries are logged with timestamps and subscriber endpoint information. These logs are routed to Amazon CloudWatch Logs when enabled. A delivery status log entry records: the subscriber's endpoint (phone number, email, or URL), the delivery outcome, and the timestamp — constituting a behavioral record of your notification infrastructure under US jurisdiction.

Topic policies and access control metadata. Each SNS topic has a resource-based policy (JSON) stored under US jurisdiction. Topic policies that reference specific subscriber ARNs, AWS account IDs, or condition keys encoding subscriber attributes constitute operational metadata about your notification infrastructure.

GDPR Legal Basis Problems with SNS

Chapter V transfer requirements. Every EU application using SNS to store subscriber endpoints is conducting ongoing GDPR Chapter V transfers. The SNS subscriber list is a continuously updated collection of personal data transferred to the United States. AWS offers Standard Contractual Clauses (SCCs) via its GDPR Data Processing Addendum.

Post-Schrems II, SCCs are valid for most transfers but require a Transfer Impact Assessment (TIA) evaluating whether US surveillance law undermines the SCC protections. The CLOUD Act creates a direct legal pathway for US law enforcement to access subscriber data held in SNS — a pathway that SCCs and even EU data center location cannot block. A thorough TIA for SNS must acknowledge this exposure.

Article 5(1)(f): Integrity and confidentiality. GDPR Art.5(1)(f) requires that personal data be processed with appropriate security, protecting against unauthorized access. CLOUD Act compulsion is — from an EU legal perspective — potentially unauthorized access to EU subscriber data. The European Data Protection Board has noted that US surveillance authorities cannot be considered "authorized" access under EU law. Storing subscriber personal data in a US-controlled notification service creates a structural tension with Art.5(1)(f).

Article 14: Information to data subjects. When EU users subscribe to notifications via an application, Art.14 requires informing them of all data recipients. If SNS is the notification infrastructure, AWS is a data processor. Your privacy policy must disclose that subscriber notification data — including phone numbers and email addresses — is processed by a US entity subject to CLOUD Act compulsion. Many EU-facing privacy policies do not make this disclosure with the specificity that GDPR Art.14(1)(e) requires.

Article 30: Records of Processing Activities. SNS subscriber lists, topic configurations, and delivery log pipelines must all be documented in your Art.30 Records of Processing Activities. For each SNS-based notification flow: document the categories of data (phone numbers, email addresses, device tokens), the retention period (duration of subscription), the legal basis for processing, and the transfer mechanism (SCCs + TIA). SMS opt-out registries, mobile push endpoint registries, and CloudWatch delivery logs each constitute separate processing activities requiring their own Art.30 entries.

Article 28: Data processing agreements. SNS usage requires an AWS Data Processing Agreement (DPA). The AWS DPA covers standard controller-processor requirements but does not — and cannot — waive the CLOUD Act. AWS is legally required to comply with valid CLOUD Act orders. Your DPA with AWS will contain standard CLOUD Act carve-outs: AWS must comply with government orders and may be unable to notify you when it does. This means Art.28(3)(e) — the processor obligation to notify the controller — may be legally unenforceable precisely when it matters most.

Fan-Out Architecture Risk Multiplication

Many AWS architectures use SNS-to-SQS fan-out: a single SNS publish triggers delivery to multiple SQS queues, each consumed by a different microservice. In this pattern, personal data in the SNS message is multiplied: it flows from SNS into N SQS queues simultaneously, each retaining the data under US jurisdiction for up to 14 days.

A user registration event published to an SNS topic might fan out to: an SQS queue consumed by the email verification service, an SQS queue consumed by the welcome notification service, an SQS queue consumed by the analytics aggregation service, an SQS queue consumed by the CRM sync service. The personal data in the registration event — email, name, signup metadata — now exists in four separate SQS queues, each under US jurisdiction, each with independent 14-day retention windows.

This risk multiplication is often invisible in architecture diagrams that show SNS-to-SQS fan-out as a clean abstraction. Each arrow in the fan-out diagram represents a separate store of personal data under US jurisdiction with its own retention period.

EU-Native SNS Alternatives

Scaleway Messaging and Queuing — SNS-compatible API

Scaleway's Messaging and Queuing service offers an SNS-compatible API. The same boto3 code that publishes to AWS SNS can publish to Scaleway Messaging by changing the endpoint URL and credentials. Scaleway is a French company headquartered in Paris; its infrastructure is located in French and Dutch data centers. No US-parent entity, no CLOUD Act exposure.

Migration example:

# AWS SNS (before)
import boto3
sns = boto3.client(
    "sns",
    region_name="eu-central-1"
)

# Scaleway SNS-compatible API (after)
sns = boto3.client(
    "sns",
    region_name="fr-par",
    endpoint_url="https://sns.mnq.fr-par.scaleway.com",
    aws_access_key_id=SCALEWAY_ACCESS_KEY,
    aws_secret_access_key=SCALEWAY_SECRET_KEY,
)

# Publish call is identical
sns.publish(
    TopicArn="arn:scw:messaging:fr-par:xxx:my-topic",
    Message=json.dumps(payload),
    MessageAttributes={...}
)

Topic creation, subscription management, and message publishing are API-compatible. HTTP/HTTPS and SQS-compatible subscriber protocols are supported. Scaleway does not currently support SMS or mobile push protocols — for those, see the alternatives below.

Self-Hosted: NATS JetStream on Hetzner

NATS is a CNCF project providing high-throughput pub/sub messaging. JetStream adds persistence, exactly-once delivery, and stream replay. Running NATS on Hetzner (German company, German data centers) gives you a notification backbone with full data sovereignty — no US entity in the data path.

# docker-compose.yml — NATS JetStream
services:
  nats:
    image: nats:2.10-alpine
    command: ["-js", "-m", "8222"]
    ports:
      - "4222:4222"
      - "8222:8222"
    volumes:
      - nats-data:/data

NATS supports fan-out through subject-based subscriptions with wildcard routing. Multiple subscribers can independently subscribe to the same subject, achieving SNS-like fan-out without any US dependency.

EU Email Notifications: Brevo (formerly Sendinblue)

For transactional email notifications, Brevo is a French company (Paris, founded 2012) offering GDPR-compliant transactional email with EU data residency. Brevo processes email exclusively in EU data centers with no US-parent corporate structure.

import sib_api_v3_sdk
from sib_api_v3_sdk.rest import ApiException

configuration = sib_api_v3_sdk.Configuration()
configuration.api_key['api-key'] = BREVO_API_KEY

api_instance = sib_api_v3_sdk.TransactionalEmailsApi(
    sib_api_v3_sdk.ApiClient(configuration)
)

send_smtp_email = sib_api_v3_sdk.SendSmtpEmail(
    to=[{"email": user_email, "name": user_name}],
    sender={"name": "Your App", "email": "noreply@yourapp.eu"},
    subject="Account notification",
    html_content="<p>Your account event occurred.</p>"
)
api_instance.send_transac_email(send_smtp_email)

EU SMS Notifications: MessageBird / Vonage

For SMS notifications replacing SNS SMS, MessageBird (Amsterdam) and Vonage (part of Ericsson, EU data processing available) both offer EU-based SMS delivery with GDPR DPAs. Phone numbers used for SMS delivery remain under EU-resident corporate control.

Mobile Push: Direct Platform APIs

SNS mobile push uses APNs (Apple) and FCM (Google) internally. Both APNs and FCM are US-headquartered services regardless of whether you use SNS as an intermediary. If CLOUD Act sovereignty over device tokens is a hard requirement, the architectural question is whether to use push notifications at all vs. EU-native alternatives like WebSocket-based real-time updates over an EU-resident connection.

For most EU applications, direct FCM/APNs integration (without the SNS intermediary) reduces the number of US services holding subscriber data by one — device tokens are sent directly to Google/Apple rather than also being stored in SNS.

sota.io: Deploy the Full EU Notification Stack

If you're running a notification-heavy application — fan-out messaging, transactional emails, push notifications — on sota.io, you can deploy the full EU-resident notification stack on Hetzner infrastructure:

• NATS JetStream for pub/sub fan-out
• Brevo for transactional email (EU API)
• MessageBird for SMS (EU headquarters)
• Direct APNs/FCM for mobile push (without SNS intermediary)

Every component of the notification pipeline remains under EU corporate control or is deployed on EU infrastructure you operate. No CLOUD Act exposure in the messaging layer.

Migration Checklist: AWS SNS → EU Alternative

Before migrating, audit your SNS usage:

1. List all SNS topics and their subscriber counts by protocol (email, SMS, HTTP, SQS, Lambda, application)
2. Identify personal data in subscriber endpoints: Email subscribers (email addresses), SMS subscribers (phone numbers), application endpoints (device tokens) — all personal data under GDPR
3. Document fan-out chains: Map every SNS → SQS fan-out; each is a separate Art.30 data flow
4. Export subscription lists: SNS does not provide bulk subscription export; use list-subscriptions-by-topic with pagination
5. Check delivery log pipelines: If you have CloudWatch delivery log subscriptions, those logs contain subscriber endpoint data and require separate migration
6. Validate replacement before cutover: Test NATS or Scaleway Messaging with a single topic and subscriber before migrating the full subscriber list
7. Update Art.30 ROPA: Replace AWS DPA references with Scaleway/Brevo/MessageBird DPA references; update transfer mechanism documentation
8. Notify data subjects if required: If your notification service change constitutes a material change to processing, Art.14(3) may require notifying subscribers

Conclusion

AWS SNS is deeply integrated into AWS-native architectures — pub/sub fan-out, notification pipelines, and event-driven triggers all reach for SNS as the default. But that integration comes with a structural GDPR exposure: every phone number, email address, and device token stored as an SNS subscription is personal data under US CLOUD Act jurisdiction.

The EU-native alternatives exist at every protocol layer. Scaleway Messaging offers SNS-API compatibility for pub/sub fan-out. Brevo covers transactional email from French infrastructure. MessageBird handles SMS from Amsterdam. For applications that control their own deployment, NATS JetStream on Hetzner replaces SNS fan-out with full data sovereignty.

The migration path is code-compatible for Scaleway (same boto3 interface, different endpoint URL) and straightforward for the notification-specific alternatives. The GDPR benefit — removing subscriber personal data from US CLOUD Act jurisdiction — is immediate upon migration.

AWS messaging trilogy covered: AWS SQS EU Alternative 2026 — AWS SNS EU Alternative 2026 — AWS EventBridge EU Alternative 2026 (coming next)

sota.io is a European PaaS platform built for teams that take GDPR seriously. Deploy your notification infrastructure — NATS, RabbitMQ, custom notification services — on EU-resident Hetzner infrastructure with no US-parent entity in the data path. Start deploying →