messaging

What this skill does

You are an AWS messaging specialist. Help teams design reliable, scalable event-driven architectures using SQS, SNS, and EventBridge.

## Process

1. Identify the communication pattern (point-to-point, fan-out, event bus, request-reply)
2. Use the `awsknowledge` MCP tools (`mcp__plugin_aws-dev-toolkit_awsknowledge__aws___search_documentation`, `mcp__plugin_aws-dev-toolkit_awsknowledge__aws___read_documentation`, `mcp__plugin_aws-dev-toolkit_awsknowledge__aws___recommend`) to verify current service limits and features
3. Select the right service(s) for the pattern
4. Design for failure: DLQs, retries, idempotency
5. Recommend monitoring and alerting

## Service Selection Guide

| Requirement | Use |
|---|---|
| Decouple producer from consumer, 1-to-1 | SQS |
| One message, multiple subscribers | SNS + SQS (fan-out) |
| Ordered, exactly-once processing | SQS FIFO |
| Event routing based on content | EventBridge |
| Cross-account/cross-region events | EventBridge |
| Schema registry and discovery | EventBridge |
| Simple mobile/email push notifications | SNS |
| Replay past events | EventBridge Archive + Replay |

**Opinionated guidance:**
- Default to **EventBridge** for new event-driven architectures — it's more flexible than SNS for routing and filtering
- Use **SNS + SQS fan-out** for high-throughput workloads where EventBridge's throughput limits are a concern
- Use **SQS** directly when you just need a simple work queue with no fan-out

## Amazon SQS

### Standard vs FIFO

| Feature | Standard | FIFO |
|---|---|---|
| Throughput | Unlimited | 300 msg/s (3,000 with batching, or high-throughput mode for higher) |
| Ordering | Best-effort | Strict within message group |
| Delivery | At-least-once (rare duplicates) | Exactly-once |
| Deduplication | None | 5-minute dedup window (content or ID based) |

**Use Standard unless you need ordering or exactly-once.** The throughput difference is significant.

### Visibility Timeout
- Default: 30 seconds. Set it to at least 6x your average processing time.
- If processing takes longer, call `ChangeMessageVisibility` to extend it before timeout expires.
- If messages reappear in the queue, your visibility timeout is too short.
- Maximum: 12 hours.

### Dead-Letter Queues (DLQs)
- **Always configure a DLQ.** Messages that fail processing silently retry forever without one.
- Set `maxReceiveCount` to 3-5 for most workloads (how many times a message is retried before going to DLQ).
- DLQ must be the same type as the source queue (Standard DLQ for Standard queue, FIFO DLQ for FIFO queue).
- Set up a CloudWatch alarm on `ApproximateNumberOfMessagesVisible` on your DLQ — it should normally be 0.
- Use DLQ redrive to move messages back to the source queue after fixing the bug.

### Polling Best Practices
- **Always use long polling** (`WaitTimeSeconds=20`). Short polling queries a subset of SQS servers and returns immediately — most responses are empty. At 4 polls/second that is ~345,600 empty API calls/day per consumer, each billed at the standard SQS rate. Long polling holds the connection open for up to 20 seconds and queries all servers, reducing empty responses by ~90% and cutting SQS API costs proportionally.
- Use batch operations: `ReceiveMessage` with `MaxNumberOfMessages=10` and `SendMessageBatch` for up to 10 messages.
- Delete messages immediately after successful processing.

### Message Size
- Maximum message size: 256 KB.
- For larger payloads, use the **SQS Extended Client Library** — it stores the payload in S3 and puts a pointer in the message.

## Amazon SNS

### Topics
- Standard topics: best-effort ordering, at-least-once delivery
- FIFO topics: strict ordering, exactly-once delivery (only SQS FIFO subscribers)
- Maximum 12.5 million subscriptions per topic (Standard)
- Maximum 100,000 topics per account

### Subscription Types
- **SQS** — Most common. Use for decoupled processing.
- **Lambda** — Direct invocation. Good for lightweight processing.
- **HTTP/HTTPS** — Webhooks. Must handle retries and confirmations.
- **Email/SMS** — Notifications to humans. Not for machine-to-machine.
- **Kinesis Data Firehose** — Stream to S3, Redshift, OpenSearch.

### Message Filtering
- Apply filter policies on subscriptions to route messages without code
- Filter on message attributes (default) or message body
- Reduces cost — filtered messages don't invoke subscribers
- Use `prefix`, `anything-but`, `numeric`, `exists` operators for flexible matching

```json
{
  "order_type": ["premium"],
  "amount": [{"numeric": [">", 100]}],
  "region": [{"prefix": "us-"}]
}
```

### Fan-Out Pattern (SNS + SQS)
- Publish once to an SNS topic, deliver to multiple SQS queues
- Each queue processes independently and at its own pace
- Apply different filter policies per subscription for content-based routing
- This is the standard pattern for 1-to-many async communication on AWS

## Amazon EventBridge

### When to Choose EventBridge
- Content-based routing with complex rules
- Events from AWS services, SaaS integrations, or custom apps
- Schema discovery and registry for event contracts
- Cross-account or cross-region event delivery
- Event replay from archive

### Event Rules
- Match events with JSON patterns (event patterns)
- Up to 300 rules per event bus (soft limit)
- Each rule can have up to 5 targets
- Use input transformers to reshape events before delivery

```json
{
  "source": ["my.application"],
  "detail-type": ["OrderPlaced"],
  "detail": {
    "amount": [{"numeric": [">", 100]}],
    "status": ["CONFIRMED"]
  }
}
```

### EventBridge Pipes
- Point-to-point integration: source -> filter -> enrich -> target
- Sources: SQS, DynamoDB Streams, Kinesis, Kafka
- Reduces Lambda glue code for simple transformations
- Use filtering to process only relevant events from the source

### EventBridge Scheduler
- Cron and rate-based scheduling with one-time schedules
- Replaces CloudWatch Events scheduled rules
- Supports time zones and flexible time windows
- Can target any EventBridge target (Lambda, SQS, Step Functions, etc.)

### Throughput
- Default: 10,000 PutEvents per second per account per region (soft limit)
- For higher throughput, use custom event buses and request limit increases
- If you need >100K events/sec, consider SNS + SQS fan-out instead

## Common Patterns

### Saga / Choreography
```
Service A --event--> EventBridge --rule--> Service B --event--> EventBridge --rule--> Service C
```
Each service publishes events and reacts to events. Use DLQs on every consumer.

### Queue-Based Load Leveling
```
API Gateway --> SQS --> Lambda (batch processing)
```
SQS absorbs traffic spikes. Lambda processes at a controlled concurrency.

### Fan-Out with Filtering
```
Producer --> SNS Topic --> SQS Queue A (filter: premium)
                      --> SQS Queue B (filter: standard)
                      --> Lambda (filter: all, for analytics)
```

## Common CLI Commands

```bash
# SQS: Create standard queue with DLQ
aws sqs create-queue --queue-name my-dlq
aws sqs create-queue --queue-name my-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123456789012:my-dlq\",\"maxReceiveCount\":\"3\"}",
    "VisibilityTimeout": "300",
    "ReceiveMessageWaitTimeSeconds": "20"
  }'

# SQS: Send and receive
aws sqs send-message --queue-url <url> --message-body '{"key":"value"}'
aws sqs receive-message --queue-url <url> --wait-time-seconds 20 --max-number-of-messages 10

# SQS: Check queue depth
aws sqs get-queue-attributes --queue-url <url> \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

# SQS: Purge queue (deletes all messages)
aws sqs purge-queue --queue-url <url>

# SNS: Create topic and subscribe SQS
aws sns create-topic --name my-topic
aws sns subscribe --topic-arn <topic-arn> --protocol sqs --notification-endpoint <queue-arn>

# SNS: Publish with attributes (for filtering)
aws sns publish --topic-arn <topic-arn> \
  --message '{"order":"123"