AWS 146: Amazon SNS topics
Why this lesson matters
Fan one publication to multiple subscribers while controlling topic policy, filtering, delivery retries, encryption, and endpoint-specific failure handling.
What you will be able to do
By the end, you can:
- explain amazon sns topics in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Fan one publication to multiple subscribers while controlling topic policy, filtering, delivery retries, encryption, and endpoint-specific failure handling. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon SNS. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon SNS. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid using an email subscription as a reliable machine workflow or assuming topic encryption grants subscriber permissions. |
How the request flows
+----------------------+
| Publisher |
+----------------------+
|
v
+------------------------+
| SNS topic and filter |
+------------------------+
|
v
+-----------------------------+
| Independent subscriptions |
+-----------------------------+
|
v
+-------------------------------------------+
| Delivery status and endpoint processing |
+-------------------------------------------+For Amazon SNS, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon SNS. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon SNS. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use SNS for push-based fanout to several supported endpoints that each own their processing. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid using an email subscription as a reliable machine workflow or assuming topic encryption grants subscriber permissions. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Fanout and independent delivery
A publisher sends once to a topic; SNS evaluates every confirmed subscription, filter and endpoint independently. One slow subscriber does not block another, but each needs its own retry, DLQ, monitoring and downstream idempotency. Standard topics support broad endpoint types with at-least-once/best-effort-order delivery. FIFO topics add groups, deduplication and ordered delivery to supported SQS subscribers; pairing with a standard queue gives up FIFO consumer guarantees.
Filters inspect message attributes or body according to filter scope. They reduce unwanted delivery, not publisher authorization. Treat filter/schema changes as code and tolerate propagation/duplicates. Raw delivery removes the SNS envelope for supported endpoints but changes parsing and attribute constraints.
Topic policy plus publisher IAM authorize Publish. An SQS subscription also needs a queue policy allowing sns.amazonaws.com constrained by aws:SourceArn; encrypted topics/queues need compatible KMS permissions. HTTPS subscribers must confirm and verify SNS message signatures, certificate chain, topic and timestamp. Email/SMS/mobile are human channels with regulatory, spend and delivery limits - not reliable machine queues.
Retries are protocol-specific. A subscription DLQ captures messages SNS could not deliver after its policy; it does not capture failures after SQS accepted a message or Lambda started processing. Monitor published, delivered, failed, filtered and redriven counts plus endpoint status. FIFO topics currently support bounded archive/replay; standard replay needs an external durable archive and republisher.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open SNS, Topics and Subscriptions; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws sns list-topics --query 'Topics[].TopicArn' --output table
aws sns list-subscriptions --query 'Subscriptions[].{Protocol:Protocol,Endpoint:Endpoint,Topic:TopicArn,Arn:SubscriptionArn}' --output tableExpected interpretation
A confirmed subscription can receive eligible publications, but successful publish does not prove every endpoint accepted or processed the message.
Practical work
Design an order-event topic with separate SQS billing, analytics, and fraud subscriptions. Add filter policies, raw delivery decision, queue policies, DLQs, encryption, and delivery-status evidence.
Choose Standard or FIFO and define group/dedup keys. Test unauthorized publish, unconfirmed subscription, filter mismatch, queue-policy and KMS denial, unavailable HTTPS endpoint, duplicate delivery and FIFO replay. Trace one message ID to each subscription and distinguish delivery from business completion. Add privacy, human-notification consent/opt-out, spend limits and cleanup.
Diagnose this topic from its own evidence
Publish success without endpoint outcome requires subscription-level evidence: confirmation, filter counters, delivery status, DLQ, endpoint/queue policy and KMS. FilteredOut can be expected. SQS absence plus SNS failures often means queue policy/KMS; HTTPS needs status/retry/signature/TLS evidence; Lambda zero invokes needs function resource policy. Do not repeatedly republish non-idempotent events while troubleshooting.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Fan one publication to multiple subscribers while controlling topic policy, filtering, delivery retries, encryption, and endpoint-specific failure handling.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon SNS.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon SNS.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid using an email subscription as a reliable machine workflow or assuming topic encryption grants subscriber permissions.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass when the learner explains fanout, Standard/FIFO guarantees, filtering/raw delivery, endpoint policies/retries, DLQ scope, encryption and archive/replay. Every subscriber owns idempotency, monitoring and recovery, with negative tests and cost/privacy controls. Fail if encryption is said to grant endpoint access, email is used as durable machine integration, or delivery equals completed processing.