AWS Messaging & Streaming Services

AWS のメッセージングとストリーミングに関する質問に答える際は、サービス固有のスキルまたは公式の AWS ドキュメントから具体的な数値、バージョン、制限、動作の詳細を確認してください。不確実な場合は、推測するのではなく、スキルまたはドキュメントを検索してください。不正な設定オプションや間違ったバージョン番号は、不確実性を認めることより悪いです。

推奨設定 (CloudWatch アラーム設定、しきい値、欠落データ処理) に関する質問の場合は、一般的なベストプラクティスに依存するのではなく、サービス固有のスキルまたはドキュメントを検索してください。

Overview

プロデューサーとコンシューマー間でデータを移動する AWS サービスを選択および使用するためのドメインエキスパーティス。 このスキルは、メッセージング と ストリーミング という 2 つの基本的なパターンと、各パターンを実装する AWS サービスをカバーしています。 このスキルを使用して、どのパターンがワークロードに適しているかを決定し、適切なサービスを選択し、サービス間の統合方法を理解してください。

個別の AWS サービスに関する具体的なガイダンスについては、リファレンスファイルまたはサービス固有のスキルを参照してください。

Streaming and Messaging

What Is Messaging?

メッセージングは、コンポーネント間の 分離された非同期通信 を可能にします。プロデューサーがメッセージを送信し、1 つ以上のコンシューマーがそれを受け取って処理します。処理されると、メッセージは通常削除されます。メッセージングサービスは配信保証、再試行、デッドレターのルーティングを処理します。

主な特徴:

• メッセージは 1 回消費される (ポイント・ツー・ポイント) か、ファンアウト (パブ/サブ) され、その後削除される
• リプレイなし — 確認されたメッセージは消去される
• コマンド/リクエストワークロード、タスク配布、イベント通知向け

What Is Streaming?

ストリーミングは、順序付けられた、永続的な、高スループットの継続的なデータフロー を可能にします。プロデューサーはログにレコードを追記し、コンシューマーはそのログ内の位置から読み込みます。レコードは消費に関係なく設定可能な保持期間保持されます。

主な特徴:

• レコードは保持され、保持期間内でリプレイ可能
• パーティション/シャード内での厳密な順序付け
• 複数の独立したコンシューマーが異なる位置で同じデータを読み込める
• イベントソーシング、リアルタイム分析、変更データキャプチャ、継続的処理向け

Key Differences

Dimension	Messaging	Streaming
Data lifecycle	消費後に削除	リプレイのため保持 (数時間から無制限)
Ordering	ベストエフォート (Standard) またはグループごと (FIFO)	パーティション/シャードごとに厳密
Consumer model	競争するコンシューマー (作業配布)	独立した読者 (位置によるファンアウト)
Throughput pattern	バースト、変数	持続、高ボリューム
Replay	サポートなし (DLQ リドライブを除く)	ネイティブ — 保持期間内の任意位置にシーク
Typical latency	ミリ秒 (プッシュまたは短いポール)	ミリ秒から低秒
Scaling unit	同時実行性 (コンシューマー/ポーラー)	パーティションまたはシャード

Messaging Use Cases

• リクエスト/レスポンスまたはコマンドパターンによるマイクロサービスの分離
• 競争するコンシューマープールにわたる作業配布 (タスクキュー)
• 各サブスクライバーが独立して動作するファンアウト通知
• バースト的であり、キューバッファリングの恩恵を受けるワークロード
• 既存の JMS/AMQP アプリケーションの移行 (Amazon MQ)

Streaming Use Cases

• 継続的で高スループットのデータ取り込み (ログ、メトリクス、クリックストリーム、IoT テレメトリ)
• 時間内の任意のポイントからリプレイする必要があるコンシューマーのイベントソーシング
• 複数の独立したコンシューマーが同じデータを異なる方法で処理
• リアルタイム分析、ウィンドウ集約、複雑なイベント処理
• 変更データキャプチャ (CDC) パイプライン

Messaging Services

これらのサービスは一般的にメッセージングワークロードに使用されます。 正確なユースケースと要件によっては、ストリーミングサービス (Kinesis Data Streams、Managed Streaming for Apache Kafka) もメッセージングワークロードに使用される場合があります。

Service	Best For	Key Differentiator
Amazon SQS	タスクキュー、分離、バッファリング	フルマネージド、無制限スループット (Standard)、正確に 1 回 (FIFO)、マルチテナントワークロード向けの公平なキュー
Amazon SNS	ファンアウト、パブ/サブ通知	複数のサブスクライバーへのプッシュ (SQS、Lambda、HTTP、メール、SMS)
Amazon EventBridge	イベントルーティング、クロスアカウント/SaaS 統合	コンテンツベースのフィルタリング、スキーマレジストリ、200 以上の AWS ソース統合
Amazon MQ	既存 JMS/AMQP/MQTT アプリケーションのリフト・アンド・シフト	プロトコル互換性 (ActiveMQ、RabbitMQ) によるレガシー移行

Streaming Services

これらのサービスは一般的にストリーミングワークロードに使用されます。

Service	Best For	Key Differentiator
Amazon Kinesis Data Streams	AWS ネイティブコンシューマーを使用したリアルタイム取り込み	オンデマンド Advantage モード (インスタント スケーリング、シャード管理なし)、1～365 日保持
Amazon Data Firehose	ストレージ/分析への管理者不要の配信	自動スケール、バッファリング、バッチ処理、配信先への配信
Amazon Managed Service for Apache Flink	複雑なストリーム処理 (結合、ウィンドウ、状態)	フル Apache Flink ランタイム — SQL、Java、Python API による ステートフル計算
Amazon MSK	Kafka ネイティブワークロード、エコシステム互換性	Apache Kafka API、Express ブローカー (Standard ブローカー比で 3 倍スループット、20 倍高速スケーリング)、広範なコネクタエコシステム

Common Integration Gotchas

• SQS システム属性 vs. ユーザーメッセージ属性: AWSTraceHeader (X-Ray / EventBridge / Pipes が SQS DLQ に送信する際に設定) や SenderId、SentTimestamp などの属性は SQS システム 属性であり、ユーザーメッセージ属性ではありません。デフォルトでは ReceiveMessage から返されません — AttributeNames=[...] (または MessageSystemAttributeNames) を経由して明示的にリクエストしてください。MessageAttributeNames はユーザー属性を取得し、システム属性とは別です。これは DLQ の場合に重要で、トレースヘッダーはシステム属性に乗り、ユーザー属性スロットはサービスの失敗メタデータ (例: EventBridge の RULE_ARN、ERROR_CODE) を保有します。

• SNS → Firehose → S3 レコード区切り文字: firehose プロトコルを使用する SNS サブスクリプションが S3 に到達する場合、レコードはデフォルトで既に改行区切り (NDJSON) です。Firehose の AppendDelimiterToRecord をオンにしないでください — SNS が改行自体を生成し、プロセッサを有効にすると二重改行が生成されます。

• EventBridge ルール ターゲット DLQ + SNS サブスクリプション DLQ の両方に DLQ キューポリシーが必要。 DLQ を接続するだけでは不十分です — サービスプリンシパルがキューポリシーを許可するまで、DLQ はサイレントにメッセージを破棄します。EventBridge: PutTargets に DeadLetterConfig.Arn=<DLQ>、および SQS ポリシー Allow sqs:SendMessage for Service: events.amazonaws.com with aws:SourceArn = ルール ARN。SNS: SetSubscriptionAttributes RedrivePolicy={"deadLetterTargetArn":"<DLQ>"} および SQS ポリシー allowing Service: sns.amazonaws.com scoped by トピック ARN。

• SQS 本番環境デフォルト: ロングポーリング + カスタマーマネージド暗号化。 新しいキューはショートポール (ReceiveMessageWaitTimeSeconds=0) と SSE-SQS (AWS 所有キー) にデフォルト設定されています。本番環境の場合は、SetQueueAttributes を ReceiveMessageWaitTimeSeconds=20 (ロングポーリング) および KmsMasterKeyId=<customer-managed key id/ARN> に設定してください。alias/aws/sqs は使用しないでください。

• ブローカーと Kafka 認証情報は Secrets Manager に属し、接続文字列には属しません。 ユーザー名、パスワード、SASL/SCRAM 認証情報をアプリケーション設定、環境変数、JAAS ファイル、または IaC にハードコードしないでください。Amazon MQ (ActiveMQ/RabbitMQ) の場合、ブローカーユーザーをシークレットとして保存し、起動時に取得してください。Amazon MQ の Lambda イベントソースマッピングには、ブローカー認証情報を Secrets Manager シークレット ARN (BASIC_AUTH) として提供する必要があり、インライン指定ではありません。MSK SASL/SCRAM の場合、シークレットは必須です。AmazonMSK_ プレフィックスで命名され、デフォルト aws/secretsmanager キーではなく カスタマーマネージド KMS キーで暗号化される必要があります (デフォルトキーで作成されたシークレットはクラスタに関連付けられません)。その後、BatchAssociateScramSecret で接続してください。MSK (SASL/SCRAM または mTLS) およびセルフマネージド Kafka の Lambda イベントソースマッピングもインライン認証情報ではなく Secrets Manager シークレット ARN を参照します。ローテーションを有効にし、IAM 読み取りアクセス (secretsmanager:GetSecretValue) をコンシューマーロールのみにスコープしてください。AWS Well-Architected SEC02-BP03 Store and use secrets securely を参照してください。

• サービスプリンシパルリソースポリシーには aws:SourceArn / aws:SourceAccount 条件が必要です。 キューまたはトピックポリシーが events.amazonaws.com、sns.amazonaws.com、s3.amazonaws.com などのサービスプリンシパルに sqs:SendMessage または sns:Publish 権限を付与する場合、ソース条件を省略すると confused-deputy の穴が開きます — 任意の AWS アカウント内のルール、トピック、またはバケットが書き込みを駆動できます。すべてのステートメントを aws:SourceArn (特定のルール/トピック/バケット/パイプ ARN; ARN が完全に分からない場合は ArnLike を * で使用) および aws:SourceAccount (あなたのアカウント ID) でスコープしてください。S3 イベント通知については、S3 バケット ARN にアカウント ID が含まれていないため、両方のキーが必要です。aws:SourceArn だけではアカウントを制約しません。同じパターンは EventBridge ルールと EventBridge Pipes で使用される IAM ロールのロール信頼ポリシーに適用されます (プリンシパル events.amazonaws.com / pipes.amazonaws.com、aws:SourceArn = ルールまたはパイプ ARN) — 上記で呼び出される DLQ ケースだけではありません。IAM User Guide の The confused deputy problem を参照してください。