AWS SNS

The AWS SNS sink publishes log events to Amazon Simple Notification Service (SNS) topics.

Think of SNS as a fan-out notification bus (pub/sub): Worker publishes once to a topic, and SNS delivers copies to one or many subscribers (SQS queues, Lambda, HTTP endpoints, email/SMS in some setups). This is different from SQS, which is a single-consumer queue pattern unless you explicitly fan out yourself.

Typical use: “send this log/event to multiple downstream systems” (alerting, enrichment pipelines, different teams, different regions/accounts).

Logs

You generally need:

An existing SNS Topic ARN (or at least a known target topic) One or more topic subscriptions (SQS/Lambda/HTTP/etc.) if you expect anything to consume it AWS credentials available to Kron TP (instance role, task role, IRSA, env vars, credential files) IAM permission to Publish to the SNS topic

Topic (required conceptually) SNS publishes to a topic, not a queue. So the “main” identifier should be the SNS Topic ARN (or equivalent topic reference).

If you see a parameter named queue_url under an SNS sink, treat it as a documentation/sample mismatch (queue URL is the SQS concept). Operationally, for SNS you care about the topic identifier, not an SQS queue URL.

Region (optional) The AWS region of the SNS service/topic. If not set explicitly, it’s usually inferred from the environment.

Endpoint (optional) A custom AWS endpoint for AWS-compatible setups or special routing.

Auth (optional) Controls how worker obtains AWS credentials and (optionally) assumes roles.

Common patterns:

Default AWS credential chain (best for production: instance/task roles, IRSA) Assume-role for cross-account publishing Static keys for local/dev (try to avoid for production)

Goal: least-privileged identity that can only publish to the intended topic(s).

Encoding (required) Determines how each log event is serialized into the SNS message payload.

Practical notes:

Pick an encoding that subscribers can reliably parse (JSON is common) Keep the payload stable (subscriber contracts matter more in pub/sub)

Buffer (optional) Controls how worker buffers before sending to SNS.

This matters because SNS delivery can fail transiently (network, throttling). Buffering defines whether you absorb and retry vs. risk drops or upstream backpressure.

Proxy (optional) Send SNS traffic via HTTP/HTTPS proxies and define “no proxy” destinations.

TLS (optional) Controls certificate verification and trust settings for outbound connections.

In most environments: keep verification enabled and only customize for private endpoints / custom CAs.

Fan-out to multiple pipelines One publish → multiple SQS queues (each queue feeds a different consumer/service/team).

Cross-account distribution Central worker publishes to a shared topic; subscribers in other accounts receive via their subscribed endpoints (often SQS).

Event-driven enrichment SNS → Lambda does quick enrichment/routing → writes to storage/search systems.

SNS: “broadcast this event to many subscribers” SQS: “put this event in a queue for work processing / buffering / one logical consumer group”

If you tell me what your downstream subscribers are (SQS? Lambda? HTTP collector?), I can suggest the cleanest pattern and the main pitfalls (ordering, dedup, payload size, retry behavior, etc.) without going into config snippets.