- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure, OCI, and Private Kubernetes
- On Azure
Coverage by target cloud
How the targets compare
Each row compares a capability of SNS with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
On Google Cloud
Via Google Cloud Pub/Sub
How it works
The SNS service adapter maps topics to Google Cloud Pub/Sub and creates a durable pull subscription for each SNS subscription. The application continues to address SNS ARNs. Separate SNS records retain subscription lifetimes, filters and receiver consent; broker names and labels do not grant permission to send a notification. A publication records its captured routing revision. Workers match each broker copy to that revision, evaluate the selected SNS filter and check current receiver permission before delivery. Google operates broker storage and redelivery, while the adapter handles SNS recipient protocols.
Pub/Sub retains message copies; SNS records govern who may receive them.
Acknowledgement and recovery
Acknowledgement follows a recorded outcome: destination acceptance, a filter nonmatch, or a terminal refusal. Temporary failures leave work for broker redelivery. The acknowledgement deadline coordinates receipt of a broker copy; it does not replace the check of current subscription and destination permissions. After SQS enqueue, SQS owns the accepted message. Lambda owns execution retries after durable asynchronous acceptance. A lost acknowledgement can still repeat the handoff, so recipients must tolerate duplicates. On restart, workers recover subscription mappings from durable SNS records. A recreated subscription has a new lifetime and cannot receive a retired subscription’s retained work.Limitations
- SNS filter subset. Attribute and JSON-body filters are evaluated by the adapter rather than translated into Pub/Sub filters; unsupported operators are refused.
- Standard topics. Pub/Sub ordering keys are not exposed as SNS FIFO ordering or deduplication.
- Recipient scope. SQS, HTTP, HTTPS and Lambda are supported; email, SMS, Firehose and mobile push are refused.
- HTTP receiver setup. Confirmation and tenant signing-key trust are required. An AWS SigningCertURL-only verifier is incompatible. Plaintext HTTP requires explicit private-network approval.
- Policies and redrive. AWS topic resource policies are not translated, and subscription RedrivePolicy is refused.
Other considerations
Use workload identity for broker access and configure queue consent and endpoint reachability before publisher cutover. Retention and subscription backlog constrain how long a destination may remain unavailable. An empty broker subscription alone does not distinguish delivery from filtering or expiry. Outstanding AWS notifications remain on AWS. The June 2026 Publish benchmark measured a p50 of 57.12 ms through Pub/Sub and 9.27 ms on native SNS at 50 open-loop connections, with both paths sustaining about 100 operations per second. These figures cover Publish acceptance and exclude fan-out, filter evaluation and subscriber receipt.Via Google Cloud SQL for PostgreSQL
How it works
Applications use the SNS API and retain topic and subscription ARNs. Google Cloud SQL for PostgreSQL stores each notification’s bytes. A separate durable store holds SNS subscriptions, permissions and delivery records. The two stores have separate commits: the message is saved first, then the publication and its selected deliveries are recorded together. This order prevents an accepted delivery from referring to a message that was never saved. If the process stops between the writes, the stored bytes authorize no delivery. Once both writes succeed, workers can find pending work without relying on the publisher process’s memory.
Publish returns after the first two steps. Subscriber receipt happens later.
Delivery and retries
Subscription selection uses the filter revision captured for the publication. Before sending a selected notification, the worker checks that the subscription and receiver permission are still current. Unsubscribe prevents new delivery admissions; it cannot recall a message already accepted by a queue. Each subscription has its own result. SQS takes responsibility after durable enqueue, and Lambda takes responsibility for execution and execution retries after durable asynchronous acceptance. HTTP and HTTPS attempts remain with SNS until their responses are classified. If a destination accepts a notification but its acknowledgement or the delivery record is lost, another attempt can produce a duplicate with the sameMessageId. Recipients must make repeated effects safe.
Limitations
- Standard topics. FIFO topics, ordering and deduplication are outside this mapping.
- Filter subset. Message attributes and JSON bodies use a restricted filter grammar; unsupported operators are refused.
- Receiver setup. SQS queues must permit the topic. Lambda requires its local service adapter and an unqualified function destination. HTTP and HTTPS require confirmation and tenant signing-key trust; an AWS SigningCertURL-only verifier is incompatible.
- Protocol and redrive scope. SQS, HTTP, HTTPS and Lambda are supported. Email, SMS, mobile push, Firehose and subscription RedrivePolicy are refused.
- Topic access policies. AWS topic resource policies are not translated. Caller permissions and destination consent must be configured separately.
Other considerations
Google operates Cloud SQL maintenance and the database features selected for the deployment. Configure database capacity, private connectivity, TLS and backups for the expected workload. Recovery must preserve both the message database and the SNS subscription and delivery records; a backup of either one alone is insufficient. Before redirecting publishers, verify queue consent, destination receipt and recovery in the selected configuration. Existing AWS delivery backlog is not copied into Cloud SQL. Monitor database storage and connection pressure alongside pending deliveries and destination failures.On Azure, OCI, and Private Kubernetes
Via PostgreSQL
How it works
The application keeps its SNS client and uses a service adapter in the target cluster. PostgreSQL retains notification bytes; a separate durable SNS store records topic and subscription lifetimes, filters, receiver permissions and delivery results. Publish holds the bytes without sending them, then commits the publication and selected deliveries. Only after both writes succeed does it return aMessageId. A process failure between writes leaves unreferenced bytes, not permission to contact a recipient. Committed work remains discoverable after workers restart.
Message storage and delivery admission are separate durable writes.
Delivery and ownership
The publication’s captured subscription and filter revisions determine selection. Current receiver permission is checked before sending. A retired subscription cannot authorize another attempt, and a replacement subscription does not inherit its backlog. Each recipient has an independent outcome. Once SQS durably enqueues a message, it owns that message; after Lambda durably accepts an asynchronous event, it owns function execution and retries. SNS continues to own HTTP and HTTPS delivery attempts. An uncertain acceptance can result in a repeated notification with the sameMessageId, so recipient side effects must tolerate duplicates.
Limitations
- Standard topics. FIFO ordering, deduplication and MessageGroupId are refused.
- Four subscriber protocols. SQS, HTTP, HTTPS and Lambda are supported; email, SMS, Firehose and mobile push are refused.
- Filter and raw-delivery scope. Attribute and JSON-body filters use a restricted grammar. Raw delivery applies only to SQS; HTTP and HTTPS receive notification envelopes.
- Receiver configuration. Queues must permit the topic. HTTP and HTTPS require confirmation and tenant signing-key trust; AWS SigningCertURL-only verification is incompatible.
- Policies and redrive. AWS topic resource policies are not translated, and subscription RedrivePolicy is refused.
Other considerations
The deployment operator runs PostgreSQL storage, replication, backups and recovery on the target cluster. Size the database for retained notifications and connection demand, and preserve both payloads and the separate SNS records during backup and restore. Validate destination permissions and restart recovery before redirecting publishers. Existing AWS delivery work is not copied into PostgreSQL; drain or expire it on AWS as part of the cutover.On Azure
Via Azure Service Bus Premium
How it works
Each SNS topic maps to a Service Bus Premium topic with a durable broker subscription for each SNS subscription. The application keeps its SNS ARNs. Subscription lifetimes, filter revisions and receiver consent remain in separate SNS records; the broker owns retained message copies. A worker receives a copy under PeekLock, matches it to the captured SNS routing revision and checks current receiver permission before sending. Results are independent across subscriptions. A successful Publish confirms acceptance into the delivery system, not receipt by every destination.
A Service Bus lock coordinates a receive; it does not authorize the destination.
Restart and delivery outcomes
Workers recover SNS subscription records, create or verify the corresponding Service Bus entities and read their settings before receiving. A new subscription lifetime uses a new binding; messages retained for a removed subscription cannot become work for its replacement. Broker completion follows a recorded delivery result. A temporary failure leaves the copy for redelivery. If the destination accepts a notification before the worker loses its lock or acknowledgement, a later attempt may deliver it again. Recipients must make repeated effects safe. SQS takes ownership after durable enqueue. Lambda takes ownership of execution and execution retries after durable asynchronous acceptance; SNS does not wait for the handler to finish or retry its execution. HTTP and HTTPS responses determine whether SNS completes, retries or stops that delivery.Limitations
- Standard SNS topics. Service Bus sessions are not presented as SNS FIFO ordering or deduplication.
- SNS filter subset. Captured SNS policies are evaluated by the adapter; unsupported operators are refused.
- Four subscriber protocols. SQS, HTTP, HTTPS and Lambda are supported; email, SMS, Firehose and mobile push are refused.
- HTTP receiver setup. Confirmation and tenant signing-key trust are required; an AWS SigningCertURL-only verifier is incompatible. Plaintext HTTP requires explicit private-network approval.
- Policies and redrive. AWS topic resource policies are not translated, and SNS RedrivePolicy is refused. Service Bus dead-letter state is a separate broker facility.
Other considerations
Microsoft operates Service Bus. Configure namespace capacity, workload-identity access and private connectivity for the target Azure environment. The selected Premium namespace uses a 4096-KiB message limit that is read back before readiness; this is transport capacity, not an increase in the SNS Publish limit. An encoded notification must also fit its destination’s limit. Monitor backlog, message age, lock loss and dead-letter state alongside destination outcomes. Retain SNS subscription records during recovery as well as the broker entities. Validate destination receipt before cutover; outstanding AWS notifications are not transferred into Service Bus.Via Azure Database for PostgreSQL Flexible Server
How it works
The application keeps its SNS client while notification bytes are stored in Azure Database for PostgreSQL Flexible Server. Microsoft Entra workload identity and TLS provide database access. Durable SNS records retain subscription lifetimes, captured filters and receiver permissions separately from the message database. Publish saves the bytes before recording the publication and its selected deliveries. Success requires both writes; there is no transaction spanning the two stores. A failure between them leaves bytes that cannot be delivered. After acceptance, workers discover pending work from durable records.
Flexible Server stores the payload; separate SNS records govern delivery.
Delivery and database operations
A publication selects subscriptions using its captured filter revision. Each selected destination is checked against current receiver permission before an attempt. Removing and recreating a subscription does not give the replacement permission to receive the old subscription’s backlog. SQS owns a durably enqueued message. Lambda owns function execution and its retries after accepting an asynchronous event. SNS records those acceptances independently; an HTTP failure does not require repeating a completed queue delivery. An acceptance whose acknowledgement is lost can still cause a duplicate, so recipients must tolerate repeatedMessageId values.
Microsoft operates Flexible Server. Availability and recovery depend on the selected database configuration, region and backup policy. Size storage and connections for retained messages as well as normal traffic, and preserve SNS subscription and delivery records alongside the payload database.
Limitations
- Standard topics. FIFO ordering and deduplication are not provided.
- Filter subset. Message-attribute and JSON-body filters use a restricted grammar; unsupported operators are refused.
- Destination scope. SQS and unqualified Lambda destinations use their local service adapters in the same tenant and region. Email, SMS, Firehose and mobile push are refused.
- HTTP receiver changes. HTTP and HTTPS require recipient confirmation and tenant signing-key trust. An AWS SigningCertURL-only verifier is incompatible; plaintext HTTP also requires explicit private-network approval.
- Policies and redrive. AWS topic resource policies are not translated, and subscription RedrivePolicy is refused.