> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SNS
> AWS SNS. Publish-subscribe messaging where one topic fans a message out to many subscribers: queues, Lambda functions, HTTP endpoints, email and SMS.
**On this page**
* [Coverage by target cloud](#coverage-by-target-cloud)
* [How the targets compare](#how-the-targets-compare)
* [Max adaptation](#max-adaptation)
* [On Google Cloud](#on-google-cloud)
* [On Azure, OCI, and Private Kubernetes](#on-azure-oci-and-private-kubernetes)
* [Via CloudNativePG](#via-cloudnativepg)
* [On Azure](#on-azure)
* [Via Azure Service Bus](#via-azure-service-bus)
* [Via PostgreSQL Flexible Server](#via-postgresql-flexible-server)
## Coverage by target cloud
| Target | Available |
| ------------------ | --------- |
| Google Cloud | ✓ |
| Azure | ✓ |
| OCI | ✓ |
| Private Kubernetes | ✓ |
## 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
| Capability | SNS | Google Cloud | Azure, OCI, and Private Kubernetes · CloudNativePG | Azure · Azure Service Bus | Azure · PostgreSQL Flexible Server |
| -------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Delivery guarantee | at-least-once | at-least-once (native Pub/Sub delivery; a delivery worker forwards to each endpoint) | at-least-once (durable outbox; bounded retries, with terminal failures recorded) | at-least-once (native Service Bus delivery) | at-least-once (durable outbox; bounded retries, with terminal failures recorded) |
| Topic fan-out · one Publish → every subscription | native | native: a real Google Pub/Sub topic fans out to its subscriptions | a durable outbox row per subscription, written in the publish transaction | native: a Service Bus topic fans out to its subscriptions | a durable outbox row per subscription, written in the publish transaction |
| Delivery protocols · subscription endpoints | SQS / HTTP-S / SMS / email / Lambda / application | SQS, HTTP/S, SMS (an email / Lambda / application subscription is omitted with a deployment notice; the topic still fans out to the rest) | SQS, HTTP/S, SMS (an email / Lambda / application subscription is omitted with a deployment notice; the topic still fans out to the rest) | SQS, HTTP/S, SMS (an email / Lambda / application subscription is omitted with a deployment notice; the topic still fans out to the rest) | SQS, HTTP/S, SMS (an email / Lambda / application subscription is omitted with a deployment notice; the topic still fans out to the rest) |
| Message durability | managed, durable | native Pub/Sub durability (Google-operated) | durable before Publish returns (committed to Postgres); survives a restart | native Service Bus durability (Microsoft-operated) | durable before Publish returns, on a Microsoft-operated server (backup + HA) |
| Delivery retry · who re-delivers a failed endpoint | SNS-owned | Google Cloud Pub/Sub (the cloud's own delivery retry) | Tensor9's delivery layer (durable, at-least-once retry) | Azure Service Bus (the broker's own delivery retry) | Tensor9's delivery layer (durable, at-least-once retry) |
| API coverage | full | partial | high | partial | high |
## On Google Cloud
| Operation | Area | Support | Depth | Notes |
| ------------------------------------------------------------------ | ------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SetTopicAttributes (policy / delivery policy) | Control plane | Out of scope | Full surface | topic resource policies grant access to other identities; this target does not translate them, and deployment rejects a declared policy |
| GetTopicAttributes | Discovery | Supported | Most usage | returns the topic ARN and name; policy and delivery-policy attributes are not modeled |
| ListTopics | Discovery | Supported | Most usage | returns the declared topics |
| FIFO topics (ordering + content-based dedup) | Ordering | Out of scope | Full surface | FIFO ordering and content-based deduplication are not offered (a FIFO topic is caught at deploy) |
| Publish | Publish | Supported | Common | each Publish writes to a native Google Pub/Sub topic; fan-out is the cloud's own and a delivery worker forwards each message to the subscription's HTTP/SQS/SMS endpoint |
| PublishBatch | Publish | Supported | Most usage | publishes each batch entry separately and returns its result |
| ConfirmSubscription | Subscriptions | Supported | Most usage | the HTTP/S confirmation handshake is honored so a confirmed subscription begins receiving |
| Email / Lambda / application subscriptions | Subscriptions | Partial | Full surface | these delivery protocols are omitted with a deployment notice; the topic and its SQS/HTTP-S/SMS subscriptions still fan out |
| SetSubscriptionAttributes (filter policy / raw delivery / redrive) | Subscriptions | Out of scope | Full surface | message filtering, raw delivery, and subscription redrive (DLQ) are not offered: a declared filter, raw-delivery, or redrive policy is caught at deploy rather than being silently ignored; failed-endpoint retry is owned by the tier's delivery layer |
| Subscribe | Subscriptions | Supported | Common | connects SQS, HTTP/S or SMS subscriptions to their endpoints; an SQS subscription delivers directly to the corresponding queue |
| Unsubscribe | Subscriptions | Supported | Common | removes the subscription |
| CreateTopic | Topics | Supported | Common | your aws\_sns\_topic compiles to a topic on the target; the topic name must be a literal known at build time (a computed or prefixed topic name is rejected rather than guessed at) |
| DeleteTopic | Topics | Supported | Common | removes the compiled topic |
#### 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
| Operation | Area | Support | Depth | Notes |
| ------------------------------------------------------------------ | ------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SetTopicAttributes (policy / delivery policy) | Control plane | Out of scope | Full surface | topic resource policies grant access to other identities; this target does not translate them, and deployment rejects a declared policy |
| GetTopicAttributes | Discovery | Supported | Most usage | returns the topic ARN and name; policy and delivery-policy attributes are not modeled |
| ListTopics | Discovery | Supported | Most usage | returns the declared topics |
| FIFO topics (ordering + content-based dedup) | Ordering | Out of scope | Full surface | FIFO ordering and content-based deduplication are not offered (a FIFO topic is caught at deploy) |
| Publish | Publish | Supported | Common | each Publish inserts the message and one delivery row per subscription in a single transaction, durable before the call returns; the adapter then delivers each row and owns the retry |
| PublishBatch | Publish | Supported | Most usage | publishes each batch entry separately and returns its result |
| ConfirmSubscription | Subscriptions | Supported | Most usage | the HTTP/S confirmation handshake is honored so a confirmed subscription begins receiving |
| Email / Lambda / application subscriptions | Subscriptions | Partial | Full surface | these delivery protocols are omitted with a deployment notice; the topic and its SQS/HTTP-S/SMS subscriptions still fan out |
| SetSubscriptionAttributes (filter policy / raw delivery / redrive) | Subscriptions | Out of scope | Full surface | message filtering, raw delivery, and subscription redrive (DLQ) are not offered: a declared filter, raw-delivery, or redrive policy is caught at deploy rather than being silently ignored; failed-endpoint retry is owned by the tier's delivery layer |
| Subscribe | Subscriptions | Supported | Common | connects SQS, HTTP/S or SMS subscriptions to their endpoints; an SQS subscription delivers directly to the corresponding queue |
| Unsubscribe | Subscriptions | Supported | Common | removes the subscription |
| CreateTopic | Topics | Supported | Common | your aws\_sns\_topic compiles to a topic on the target; the topic name must be a literal known at build time (a computed or prefixed topic name is rejected rather than guessed at) |
| DeleteTopic | Topics | Supported | Common | removes the compiled topic |
#### 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
| Operation | Area | Support | Depth | Notes |
| ---------------------------------------------------------------------- | ------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SetSubscriptionAttributes (filter / raw) / SetTopicAttributes (policy) | Control plane | Out of scope | Full surface | message filtering, raw delivery, and topic resource policies are not offered (they are caught at deploy); topic access policies require role-based access control (RBAC) and Shared Access Signatures (SAS), which this deployment does not configure |
| GetTopicAttributes | Discovery | Supported | Most usage | returns the topic name |
| ListTopics | Discovery | Supported | Most usage | returns the declared topics |
| FIFO topics (ordering + dedup) | Ordering | Out of scope | Full surface | FIFO topics need Service Bus sessions for ordered delivery; not offered (a FIFO topic is caught at deploy) |
| Publish | Publish | Supported | Common | the adapter publishes the SNS message in an envelope to a Service Bus topic, which sends a copy to every subscription |
| PublishBatch | Publish | Supported | Most usage | publishes each batch entry separately and returns its result |
| ConfirmSubscription | Subscriptions | Supported | Most usage | the HTTP/S confirmation handshake is honored so a confirmed subscription begins receiving |
| Email / Lambda / application subscriptions | Subscriptions | Partial | Full surface | these delivery protocols are omitted with a deployment notice; the topic still fans out to its SQS/HTTP-S/SMS subscriptions |
| SetSubscriptionAttributes (redrive policy) | Subscriptions | Out of scope | Full surface | a subscription redrive (DLQ) policy is not offered: a declared redrive policy is caught at deploy rather than being silently ignored; failed-endpoint retry is Azure Service Bus's own |
| Subscribe | Subscriptions | Supported | Common | each subscription maps to a Service Bus subscription on the topic, and the adapter delivers to its endpoint over the SQS, HTTP/S, or SMS protocol |
| Unsubscribe | Subscriptions | Supported | Common | removes the Service Bus subscription |
| CreateTopic | Topics | Supported | Common | your aws\_sns\_topic compiles to an azurerm\_servicebus\_topic on a shared Standard namespace; the topic name must be a literal known at build time |
| DeleteTopic | Topics | Supported | Common | removes the compiled Service Bus topic |
#### 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
| Operation | Area | Support | Depth | Notes |
| ------------------------------------------------------------------ | ------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SetTopicAttributes (policy / delivery policy) | Control plane | Out of scope | Full surface | topic resource policies grant access to other identities; this target does not translate them, and deployment rejects a declared policy |
| GetTopicAttributes | Discovery | Supported | Most usage | returns the topic ARN and name; policy and delivery-policy attributes are not modeled |
| ListTopics | Discovery | Supported | Most usage | returns the declared topics |
| FIFO topics (ordering + content-based dedup) | Ordering | Out of scope | Full surface | FIFO ordering and content-based deduplication are not offered (a FIFO topic is caught at deploy) |
| Publish | Publish | Supported | Common | each Publish inserts the message and one delivery row per subscription in a single transaction, durable before the call returns; the adapter then delivers each row and owns the retry |
| PublishBatch | Publish | Supported | Most usage | publishes each batch entry separately and returns its result |
| ConfirmSubscription | Subscriptions | Supported | Most usage | the HTTP/S confirmation handshake is honored so a confirmed subscription begins receiving |
| Email / Lambda / application subscriptions | Subscriptions | Partial | Full surface | these delivery protocols are omitted with a deployment notice; the topic and its SQS/HTTP-S/SMS subscriptions still fan out |
| SetSubscriptionAttributes (filter policy / raw delivery / redrive) | Subscriptions | Out of scope | Full surface | message filtering, raw delivery, and subscription redrive (DLQ) are not offered: a declared filter, raw-delivery, or redrive policy is caught at deploy rather than being silently ignored; failed-endpoint retry is owned by the tier's delivery layer |
| Subscribe | Subscriptions | Supported | Common | connects SQS, HTTP/S or SMS subscriptions to their endpoints; an SQS subscription delivers directly to the corresponding queue |
| Unsubscribe | Subscriptions | Supported | Common | removes the subscription |
| CreateTopic | Topics | Supported | Common | your aws\_sns\_topic compiles to a topic on the target; the topic name must be a literal known at build time (a computed or prefixed topic name is rejected rather than guessed at) |
| DeleteTopic | Topics | Supported | Common | removes the compiled topic |
#### 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](/service-adapters/catalog).
