Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service that enables you to decouple microservices, distributed systems, and serverless applications. Understanding SNS subscriptions and filtering is essential for the AWS Certified SysOps Administrator exam.
SNS Subscr…Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service that enables you to decouple microservices, distributed systems, and serverless applications. Understanding SNS subscriptions and filtering is essential for the AWS Certified SysOps Administrator exam.
SNS Subscriptions allow endpoints to receive messages published to topics. Supported protocols include HTTP/HTTPS, Email, SMS, SQS, Lambda, and mobile push notifications. When you create a subscription, you specify the topic ARN, protocol, and endpoint. Subscriptions require confirmation before becoming active, except for Lambda and SQS endpoints which are confirmed automatically.
Message Filtering is a powerful feature that allows subscribers to receive only a subset of messages published to a topic. Instead of receiving all messages and filtering on the subscriber side, you can define filter policies that specify which message attributes a subscription should receive.
Filter policies are JSON objects containing attribute names and values. They support exact matching, prefix matching, numeric matching, and exists matching. For example, you can filter messages based on attributes like order_type, customer_tier, or region.
Key benefits of SNS filtering include reduced processing costs since subscribers only receive relevant messages, simplified architecture by eliminating the need for separate topics per message type, and improved performance through reduced message volume.
From a SysOps perspective, monitoring SNS involves tracking metrics like NumberOfMessagesPublished, NumberOfNotificationsDelivered, and NumberOfNotificationsFailed through CloudWatch. You can set up alarms for failed deliveries and configure dead-letter queues (DLQ) to capture undeliverable messages for troubleshooting.
Best practices include implementing appropriate retry policies, using server-side encryption for sensitive data, applying least privilege IAM policies, and regularly reviewing subscription configurations. Understanding these concepts helps maintain reliable, cost-effective messaging architectures in AWS environments.
SNS Subscriptions and Filtering - Complete Guide
Why SNS Subscriptions and Filtering is Important
Amazon Simple Notification Service (SNS) is a critical component for building decoupled, scalable architectures in AWS. Understanding subscriptions and filtering is essential for the SysOps Administrator exam because it directly impacts how you design notification systems, manage costs, and ensure the right messages reach the right endpoints. Proper filtering reduces unnecessary processing and prevents subscribers from receiving irrelevant messages.
What is SNS Subscriptions and Filtering?
An SNS subscription is the connection between an SNS topic and an endpoint that receives messages. Supported endpoint types include: - Amazon SQS queues - AWS Lambda functions - HTTP/HTTPS endpoints - Email and Email-JSON - SMS - Platform application endpoints (mobile push) - Amazon Kinesis Data Firehose
Subscription filtering allows subscribers to receive only a subset of messages published to a topic by defining a filter policy. This policy specifies which message attributes a message must have for the subscriber to receive it.
How SNS Subscriptions Work
1. Create a Topic: First, you create an SNS topic that acts as the central communication channel.
2. Subscribe Endpoints: Endpoints subscribe to the topic. Each subscription has a unique ARN.
3. Confirmation: Some subscription types (HTTP/HTTPS, Email) require confirmation before becoming active. SQS and Lambda subscriptions are confirmed automatically when proper permissions exist.
4. Message Publishing: When a message is published to the topic, SNS delivers it to all confirmed subscribers unless filter policies are applied.
How Subscription Filter Policies Work
Filter policies are JSON objects attached to subscriptions that define conditions for message delivery:
- Attribute-based filtering: Filters messages based on message attributes (not the message body by default) - Payload-based filtering: Can filter based on message body content when enabled
Filter Policy Operators: - Exact matching: String values must match exactly - Prefix matching: Strings starting with specified prefix - Numeric matching: Supports exact, range, and comparison operators - Anything-but matching: Excludes specified values - Exists matching: Checks if an attribute exists - IP address matching: Matches CIDR blocks
Filter Policy Scope: - MessageAttributes (default): Filters based on message attributes - MessageBody: Filters based on the payload content
Key Configuration Considerations
- Messages that do not match any subscriber's filter policy are discarded - If no filter policy is set, the subscriber receives ALL messages - Filter policies have a maximum size of 256 KB - You can have up to 5 conditions per policy and 150 values across all conditions - Raw message delivery affects how messages are formatted for SQS and HTTP endpoints
Exam Tips: Answering Questions on SNS Subscriptions and Filtering
1. Remember the confirmation requirement: HTTP/HTTPS and Email subscriptions require explicit confirmation. If a subscription shows as 'Pending Confirmation,' the endpoint has not confirmed yet.
2. Filter policies reduce costs: When asked about reducing Lambda invocations or SQS messages for specific use cases, filter policies are often the answer.
3. No filter policy = all messages: A subscription with no filter policy receives every message published to the topic.
4. Message attributes vs. message body: Know that filtering by default uses message attributes. Payload-based filtering must be explicitly enabled.
5. Cross-account subscriptions: SNS supports cross-account subscriptions with proper IAM and resource policies. Expect questions about this configuration.
6. Dead-letter queues: SNS can send failed deliveries to an SQS dead-letter queue. This is important for troubleshooting delivery failures.
7. Fanout pattern: SNS to multiple SQS queues is a common architecture pattern. Filtering helps route specific messages to specific queues.
8. Delivery retries: SNS has built-in retry policies for different endpoint types. HTTP endpoints have configurable retry policies.
9. Access control: Both IAM policies and SNS access policies control who can subscribe and publish. Know the difference between these approaches.
10. Encryption: SNS supports server-side encryption using AWS KMS. Subscribers need appropriate KMS permissions to decrypt messages.