SNS

On this page

• Coverage by target cloud
• How the targets compare
  • Max adaptation
• On Google Cloud
• On Azure, OCI, and Private Kubernetes
  • Via CloudNativePG
• On Azure
  • Via Azure Service Bus
  • Via PostgreSQL Flexible Server

​

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

​

From SNS Publish to subscriber

The adapter maps an SNS topic to a Google Cloud Pub/Sub topic. Publish sends the message to Pub/Sub, which places it on the topic’s subscriptions. SNS subscriber destinations are not Pub/Sub consumers by themselves: a Tensor9 delivery worker pulls each subscription and forwards the notification using the destination’s HTTP/S, SQS or SMS transport. The worker initiates its connection to Pub/Sub from the customer environment. This design does not require Pub/Sub to open an inbound connection to the private adapter. The destination still needs to be reachable from the delivery worker, and external transports need their provider setup.

​

Subscription identity and retry ownership

Topic and subscription ARNs are encoded into valid Pub/Sub resource identifiers. The durable identity excludes the advertised region. Subscription metadata records the SNS protocol and endpoint so the delivery worker can reconstruct the destination after an adapter restart. The worker acknowledges a Pub/Sub message after delivery succeeds. A failed delivery is negatively acknowledged and Pub/Sub controls redelivery through its subscription settings. If delivery succeeds but acknowledgment is lost, the message can be delivered again. Consumers must tolerate duplicates. Review retry and dead-letter settings separately from the SNS API features this mapping supports.

​

Migration and performance scope

Provision the topic and required subscriptions before changing publishers. Existing AWS backlog does not move to Pub/Sub. Test destination access and consumer behavior, including any SNS signature or subscription-confirmation checks; message-body compatibility alone does not satisfy a signature verifier. Google operates the broker. Tensor9 operates the service adapter and delivery worker. Monitor broker backlog and destination delivery separately: Publish latency measures acceptance by the broker, not delivery to every subscriber. The recorded Publish benchmark does not measure the complete notification path.

​

On Azure, OCI, and Private Kubernetes

​

Via CloudNativePG

​

Publishing and subscriber delivery

The application sends its SNS requests to the Tensor9 adapter. PostgreSQL stores topics, subscriptions, messages and pending deliveries. For each Publish, the adapter commits the message and one pending delivery for each current subscription in the same database transaction. A successful Publish means that work is stored; it does not mean every subscriber has received it. Delivery workers claim pending work and send the notification to the configured subscriber. HTTP/S, SQS and SMS require different delivery transports. An SQS destination uses that queue’s selected adapter; an HTTP destination must be reachable from the customer environment. Configure the required external delivery provider for SMS.

​

Retries, duplicates and terminal failures

A worker temporarily leases a delivery record. Other workers skip records already claimed, allowing several workers to process different deliveries. If a worker stops, its unfinished lease eventually expires and another worker can retry the record. A subscriber can accept a notification just before the worker fails to record success. Retrying that delivery produces a duplicate. Consumers should recognize repeated MessageId values and make side effects safe to repeat; the database transaction does not include the subscriber’s work. Successful deliveries are recorded as delivered. Temporary failures are rescheduled with increasing delay, subject to an attempt limit. Permanent failures, exhausted attempts and deliveries whose subscription was removed become terminal records. Monitor those failures and the age of pending work; accepting a Publish is not a guarantee that an unreachable subscriber will receive it.

​

Identity, integration and operation

Stored topic identity uses the account and topic name independently of the advertised AWS region. The API reconstructs the advertised ARN. Changing presentation region therefore need not create a new topic or abandon its pending deliveries. Notification-body compatibility and subscriber verification are separate requirements. Check any consumer that validates SNS signatures, certificate URLs or subscription confirmation; a JSON document with familiar fields is not sufficient to satisfy those checks. The platform team operates the PostgreSQL service and its backups in a self-managed deployment; Tensor9 operates the adapter and delivery workers. Provision subscriptions and test each delivery path before switching producers. Existing AWS notifications are not copied into this outbox. Review the profile’s filtering, FIFO, raw-delivery and redrive limitations for the workload.

​

On Azure

​

Via Azure Service Bus

​

How it works

An Azure Service Bus topic sends each published message to every subscription. The Tensor9 adapter accepts your application’s SNS API calls, publishes the message to Service Bus, then delivers each subscription’s notification to its endpoint in the SNS format. Service Bus manages message storage and retry. The adapter handles delivery over HTTP/S, SQS and SMS; Service Bus does not send those notifications itself. Both Azure targets use runtime adaptation for the SNS API and notification delivery. Email, Lambda and application subscriptions are dropped with a deployment notice, as listed in the support table.

​

One namespace, shared with your queues

The generated Terraform creates a Standard Service Bus namespace and one topic per SNS topic. Standard is required because Basic does not support topics. If your stack also has SQS queues, they share the same namespace with the topics, regardless of which service is compiled first. Plan capacity and monitor quotas for that shared namespace. The generated Terraform contains no Service Bus connection string; the adapter obtains credentials at runtime, keeping them out of Terraform plans and state.

​

Declarations that cannot compile

Two declarations stop compilation:

• Terraform subscriptions. An aws_sns_topic_subscription is rejected because this target does not translate the declared endpoint and topic reference into the delivery configuration the adapter needs. Topics without Terraform subscriptions compile; applications can register subscriptions at runtime.
• FIFO topics. Service Bus sessions would be needed to preserve their ordering, and this adapter does not use sessions. A topic with fifo_topic = true is marked incompatible.

​

Limitations

△ Service Bus limitations

• Delivery protocols are served by the adapter, not by Azure. HTTP/S, SQS and SMS notifications are sent by the Tensor9 adapter. Service Bus manages message storage and retry; it does not deliver to these endpoints itself.
• Existing-topic lookups are rejected. A data.aws_sns_topic cannot compile: there is no customer-side SNS topic to read on Azure. Stacks that look up a topic they did not create need that reference resolved another way.
• The namespace is shared, so its limits are shared. Queues and topics from the whole stack live in one namespace. Namespace-level quotas and throughput are therefore a shared resource across everything messaging in the appliance, rather than isolated per topic the way separate SNS topics are.

​

Other considerations

• Your publisher does not change. The application keeps its SNS SDK and its Publish calls; the adapter serves that API inside the customer environment. Review your topic and subscription declarations before migrating.
• Plan publisher cutover and subscription confirmation. Create the namespace, topics and runtime subscriptions before switching publishers. Complete subscription confirmation and let pending AWS deliveries finish; those deliveries are not copied to Service Bus.
• Size the shared namespace. If your stack has queues as well as topics, both land in the same namespace. Size and monitor it as a single shared resource, and remember that its tier is what makes topics available at all.

​

Via PostgreSQL Flexible Server

​

How it works

The adapter accepts your application’s SNS Publish calls and stores each message with one delivery row per subscription in Azure Database for PostgreSQL Flexible Server. These rows form a durable outbox: a record of notifications still to deliver. A delivery loop reads the outbox and sends each notification. Temporary failures retry with increasing delay up to an attempt limit; permanent failures and exhausted attempts are recorded as terminal failures. The message and its delivery rows commit in one database transaction before Publish returns, so a restart does not discard pending notifications. Microsoft manages the database’s backups and high availability. The adapter authenticates through Microsoft Entra using the appliance’s workload identity, with no stored password. This target is preferred over in-cluster CloudNativePG on Azure because Microsoft operates the database.

​

Choosing Service Bus or PostgreSQL

Both Azure SNS targets exclude filter policies, raw message delivery, FIFO topics and subscription redrive. Choose between them based on how messages are stored and retried:

• Service Bus stores one published message for delivery to each subscription and manages retry in the broker. Microsoft operates Service Bus; the adapter delivers notifications to subscription endpoints.
• Flexible Postgres commits the message and all subscription delivery rows together. Tensor9’s delivery loop tracks acknowledgments, bounded retries and terminal failures, while Microsoft operates the database. You can inspect pending deliveries with SQL, and must size the database for notification traffic.

​

Limitations

△ PostgreSQL delivery limitations

• Filter policies are out of scope. Subscription filter policies have no counterpart. Every subscription on a topic receives every message published to it, so filtering that SNS did for you becomes filtering your subscriber has to do. This is the limitation most likely to change a design.
• Raw message delivery is out of scope. The raw-delivery option, which strips SNS’s envelope for SQS and HTTP subscribers, is not offered. Subscribers that were written to expect raw payloads need to read the enveloped form instead.
• FIFO topics are not offered. Ordered SNS topics have no equivalent here. A design that depends on ordering needs that gap closed before this target is viable.
• Subscription redrive is out of scope. SNS subscription redrive to a configured dead-letter queue is not reproduced. The outbox records permanent failures and exhausted attempts as terminal rows; it does not retry them forever or forward them through an SNS redrive policy.
• Delivery is at-least-once, so subscribers must be idempotent. A retry after an unrecorded acknowledgment means a subscriber can see the same notification twice, after a delivery that succeeded but whose acknowledgement was lost, for instance. This matches SNS’s at-least-once contract; subscribers must safely handle duplicate notifications.

​

Other considerations

• Size the database for notification traffic. Flexible Server is managed (backup, patching and HA are Microsoft’s), but its size, storage and connection limits are yours. The outbox is a table, so notification volume consumes database capacity.
• Inspect pending deliveries with SQL. Query the outbox to count undelivered notifications and investigate subscribers whose deliveries keep failing.
• Plan publisher cutover and subscription confirmation. Provision the server and schema, register subscriptions and complete confirmation before repointing publishers. Allow pending AWS deliveries to finish; they are not copied into the new outbox.
• Authentication uses workload identity. The adapter reaches the server through Entra with the appliance’s own workload identity, so no password is emitted into applied Terraform or held anywhere for this path.

Service Catalog.