$npx -y skills add aws/agent-toolkit-for-aws --skill aws-messaging-and-streamingGuides use of AWS messaging and streaming services. Covers Amazon SQS, Amazon SNS, Amazon EventBridge, Amazon MQ, Amazon Kinesis Data Streams, Amazon Data Firehose, Amazon Managed Service for Apache Flink, and Amazon Managed Streaming for Apache Kafka (MSK). Use when implementing
| 1 | # AWS Messaging & Streaming Services |
| 2 | |
| 3 | When answering AWS messaging and streaming questions, verify specific numbers, versions, limits, and behavioral details from service-specific skills or official AWS documentation. When uncertain, search skills or docs rather than guessing. Fabricated configuration options or incorrect version numbers are worse than admitting uncertainty. |
| 4 | |
| 5 | When a question asks about recommended configurations (CloudWatch alarm settings, thresholds, missing data treatment), search for the service-specific skills or documentation rather than relying on general best practices. |
| 6 | |
| 7 | ## Overview |
| 8 | |
| 9 | Domain expertise for choosing and using AWS services that move data between producers and consumers. |
| 10 | This skill covers two fundamental patterns — **messaging** and **streaming** — and the AWS services that implement each. |
| 11 | Use this skill to decide which pattern fits a workload, select the right service, and understand how services integrate with each other. |
| 12 | |
| 13 | For specific guidance on individual AWS services, see reference files or service-specific Skills. |
| 14 | |
| 15 | ## Streaming and Messaging |
| 16 | |
| 17 | ### What Is Messaging? |
| 18 | |
| 19 | Messaging enables **decoupled, asynchronous communication** between components. A producer sends a message; one or more consumers receive and process it. Once processed, the message is typically deleted. Messaging services handle delivery guarantees, retries, and dead-letter routing. |
| 20 | |
| 21 | **Key characteristics:** |
| 22 | |
| 23 | - Messages are consumed once (point-to-point) or fanned out (pub/sub), then removed |
| 24 | - No replay — once acknowledged, a message is gone |
| 25 | - Designed for command/request workloads, task distribution, and event notification |
| 26 | |
| 27 | ### What Is Streaming? |
| 28 | |
| 29 | Streaming enables **ordered, durable, high-throughput continuous data flow**. Producers append records to a log; consumers read from positions in that log. Records persist for a configurable retention period regardless of consumption. |
| 30 | |
| 31 | **Key characteristics:** |
| 32 | |
| 33 | - Records are retained and replayable within the retention window |
| 34 | - Strict ordering within a partition/shard |
| 35 | - Multiple independent consumers can read the same data at different positions |
| 36 | - Designed for event sourcing, real-time analytics, change data capture, and continuous processing |
| 37 | |
| 38 | ### Key Differences |
| 39 | |
| 40 | | Dimension | Messaging | Streaming | |
| 41 | |---|---|---| |
| 42 | | **Data lifecycle** | Deleted after consumption | Retained for replay (hours to indefinitely) | |
| 43 | | **Ordering** | Best-effort (Standard) or per-group (FIFO) | Strict per-partition/shard | |
| 44 | | **Consumer model** | Competing consumers (work distribution) | Independent readers (fan-out by position) | |
| 45 | | **Throughput pattern** | Bursty, variable | Sustained, high-volume | |
| 46 | | **Replay** | Not supported (except DLQ redrive) | Native — seek to any position in retention | |
| 47 | | **Typical latency** | Milliseconds (push or short-poll) | Milliseconds to low seconds | |
| 48 | | **Scaling unit** | Concurrency (consumers/pollers) | Partitions or shards | |
| 49 | |
| 50 | ### Messaging Use Cases |
| 51 | |
| 52 | - Decoupling microservices with request/response or command patterns |
| 53 | - Distributing work across a pool of competing consumers (task queues) |
| 54 | - Fan-out notifications where each subscriber acts independently |
| 55 | - Workloads that are bursty and benefit from queue buffering |
| 56 | - Migrating existing JMS/AMQP applications (Amazon MQ) |
| 57 | |
| 58 | ### Streaming Use Cases |
| 59 | |
| 60 | - Continuous, high-throughput data ingestion (logs, metrics, clickstreams, IoT telemetry) |
| 61 | - Event sourcing where consumers need to replay from any point in time |
| 62 | - Multiple independent consumers processing the same data differently |
| 63 | - Real-time analytics, windowed aggregations, or complex event processing |
| 64 | - Change data capture (CDC) pipelines |
| 65 | |
| 66 | ### Messaging Services |
| 67 | |
| 68 | These services are generally used for messaging workloads. |
| 69 | Sometimes streaming services (Kinesis Data Streams, Managed Streaming for Apache Kafka) are also used for messaging workloads, depending on exact use case and requirements. |
| 70 | |
| 71 | | Service | Best For | Key Differentiator | |
| 72 | |---|---|---| |
| 73 | | **Amazon SQS** | Task queues, decoupling, buffering | Fully managed, unlimited throughput (Standard), exactly-once (FIFO), fair queues for multi-tenant workloads | |
| 74 | | **Amazon SNS** | Fan-out, pub/sub notifications | Push to multiple subscribers (SQS, Lambda, HTTP, email, SMS) | |
| 75 | | **Amazon EventBridge** | Event routing, cross-account/SaaS integration | Content-based filtering, schema registry, 200+ AWS source integrations | |
| 76 | | **Amazon MQ** | Lift-and-shift of existing JMS/AMQP/MQTT apps | Protocol compatibility (ActiveMQ, RabbitMQ) for legacy migration | |
| 77 | |
| 78 | ### Streaming Services |
| 79 | |
| 80 | These services are generally used for streaming wor |