2.2 Notification Architecture & Alarm Invocation

2.2 Notification Architecture & Alarm Invocation

Amazon Simple Notification Service (Amazon SNS) serves as the primary notification and alert-routing backbone for AWS operational monitoring. When Amazon CloudWatch alarms detect threshold violations or anomaly band breaches, they invoke automated actions by publishing messages to Amazon SNS topics. From there, SNS fans out notifications to diverse human and automated endpoints. For CloudOps engineers preparing for the SOA-C03 exam, deep knowledge of SNS topic types, resource access policies, KMS encryption configurations, delivery retry mechanisms, subscription filter policies, and dead-letter queues (DLQs) is essential.

Amazon SNS Topic Architecture: Standard vs. FIFO

Amazon SNS supports two distinct topic types designed for different architectural workloads:

A critical exam distinction is that CloudWatch alarms cannot publish actions directly to SNS FIFO topics. If an alarm action specifies an SNS FIFO topic ARN, the CloudWatch alarm configuration will fail validation. Therefore, all operational alert-routing topologies rely on SNS Standard topics.

Standard topics utilize the asynchronous fan-out pattern. A single alarm publication to an SNS topic can simultaneously broadcast messages across thousands of heterogeneous subscriber protocols:

• Amazon SQS Queues: Buffering incident records for asynchronous processing by backend ticketing systems.
• AWS Lambda Functions: Executing custom remediation scripts, querying CMDBs, or updating incident dashboards.
• HTTPS Webhooks: Forwarding alert payloads to incident management platforms like PagerDuty, Opsgenie, or Slack/Microsoft Teams gateways.
• Email (SMTP) & SMS: Delivering direct text notifications to on-call system administrators.

Security, Access Control & KMS Encryption

Because Amazon SNS topics are communication gateways, their access must be strictly governed by resource-based SNS Topic Access Policies. By default, only the topic owner can publish messages. When a CloudWatch alarm triggers, the CloudWatch service publishes to the SNS topic on the user's behalf.

To allow CloudWatch alarms to publish to an SNS topic without exposing the topic to unauthorized third parties or falling victim to the confused deputy problem, the topic policy must explicitly permit the cloudwatch.amazonaws.com service principal, restricted by the aws:SourceArn or aws:SourceAccount condition:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudWatchAlarmsToPublish",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudwatch.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:cloudops-alarms-topic",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:*"
        }
      }
    }
  ]
}

Server-Side Encryption (SSE) with AWS KMS

Enterprise security standards often require server-side encryption at rest for SNS topics. SNS integrates with AWS Key Management Service (KMS) using customer managed keys (CMK) or AWS managed keys (aws/sns).

A frequent scenario tested on the CloudOps exam involves CloudWatch alarms failing to deliver notifications to encrypted SNS topics. When an SNS topic is encrypted with the default AWS managed key (aws/sns), CloudWatch alarms cannot publish to it. This occurs because the default aws/sns KMS key policy cannot be modified to grant permissions to external service principals like cloudwatch.amazonaws.com.

To successfully publish alarm notifications to an encrypted SNS topic, organizations must use a customer managed KMS key (CMK) and update its key policy to explicitly grant the cloudwatch.amazonaws.com service principal permissions to generate data keys and decrypt them:

{
  "Sid": "AllowCloudWatchKMSAccess",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudwatch.amazonaws.com"
  },
  "Action": [
    "kms:GenerateDataKey*",
    "kms:Decrypt"
  ],
  "Resource": "*",
  "Condition": {
    "ArnLike": {
      "aws:SourceArn": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:*"
    }
  }
}

Delivery Retries, Dead-Letter Queues (DLQs) & Message Filtering

When SNS attempts to deliver an alarm message to an HTTPS endpoint or webhook, network partitions or target downtime may cause delivery failures. SNS manages transient failures through configurable delivery retry policies.

For HTTP/S endpoints, SNS executes a four-phase retry protocol:

1. Immediate Retries: Attempts delivery immediately without delay.
2. Linear Backoff: Retries at steady, short intervals.
3. Exponential Backoff: Gradually doubles retry wait times.
4. Geometric Backoff: Applies a multiplier to delay intervals until the maximum retry limit (up to 100 attempts over several hours or days) is reached.

If an endpoint remains unreachable after exhausting all retries, the message is permanently dropped unless a Dead-Letter Queue (DLQ) is attached. In Amazon SNS, DLQs are Amazon SQS queues attached directly to specific subscriptions, rather than to the topic itself. If a subscriber webhook fails, SNS offloads the failed message, headers, error codes, and delivery timestamps to the SQS DLQ for diagnostic analysis and replay.

Message Filtering with Subscription Filter Policies

By default, every subscriber to an SNS topic receives every message published. In large-scale operations, broadcasting all alerts to all channels creates alert fatigue. CloudOps engineers implement SNS Subscription Filter Policies to filter messages based on message attributes.

When a message is published with attributes such as Severity = "CRITICAL" or Service = "RDS", subscribers define filter policies in JSON:

{
  "Severity": ["CRITICAL", "HIGH"],
  "Environment": ["Production"]
}

Subscribers whose policies do not match the published attributes are bypassed entirely without incurring Lambda execution fees, webhook spam, or email flooding.

Operational Scenario: Tiered Incident Routing

A typical enterprise operational architecture routes alerts based on severity and destination requirements:

• Tier 1 (Critical Severity): An SNS topic filters for Severity = "CRITICAL". Subscriptions dispatch immediately to an on-call PagerDuty HTTPS webhook and an automated remediation Lambda function. The subscription is backed by an SQS DLQ to prevent dropped incidents during API throttling.
• Tier 2 (Warning Severity): An SNS topic filters for Severity = "WARNING". Messages route to an Amazon SQS queue polled by a corporate chat application (e.g., Slack or Teams) and a daily operational digest email.