aws-messaging-and-streaming

AWS Messaging & Streaming Services

AWS のメッセージングおよびストリーミングに関する質問に回答する際は、サービス固有のスキルまたは AWS の公式ドキュメントで、具体的な数値、バージョン、制限、動作の詳細を確認してください。不確かな場合は、推測するのではなくスキルやドキュメントを検索してください。設定オプションをでっち上げたり、バージョン番号を誤って伝えたりするよりも、不確かであることを認めるほうが適切です。

推奨設定（CloudWatch アラームの設定、しきい値、欠落データの扱いなど）について質問された場合は、一般的なベストプラクティスに頼るのではなく、サービス固有のスキルやドキュメントを検索してください。

概要

データをプロデューサーからコンシューマーへ移動させる AWS サービスの選定と使用に関する専門知識です。 このスキルでは、基本となる 2 つのパターンであるメッセージングとストリーミング、およびそれぞれを実現する AWS サービスを扱います。 また、アプリケーションコンポーネントではなく人にメッセージを届ける「顧客へのコミュニケーション」との境界を示し、それぞれのチャネルを担当するスキルまたは AWS ドキュメントへ案内します（「顧客コミュニケーション（アプリケーションから個人へ）」を参照）。 このスキルを使って、ワークロードに適したパターンを判断し、適切なサービスを選択し、各サービスの連携方法を理解してください。

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

ストリーミングとメッセージング

メッセージングとは？

メッセージングでは、コンポーネント間の疎結合で非同期な通信を実現します。プロデューサーがメッセージを送信し、1 つ以上のコンシューマーが受信して処理します。処理後、通常はメッセージが削除されます。メッセージングサービスは、配信保証、再試行、デッドレターへのルーティングを処理します。

主な特徴：

• メッセージは一度消費される（ポイントツーポイント）か、ファンアウトされ（パブリッシュ／サブスクライブ）、その後削除されます
• リプレイには対応していません。一度確認応答されると、メッセージは消失します
• コマンド／リクエストのワークロード、タスクの分配、イベント通知向けに設計されています

ストリーミングとは？

ストリーミングでは、順序が保たれ、永続的で、高スループットの連続的なデータフローを実現します。プロデューサーはログにレコードを追加し、コンシューマーはそのログ内の位置からレコードを読み取ります。レコードは、消費されたかどうかにかかわらず、設定可能な保持期間にわたって保持されます。

主な特徴：

• レコードは保持され、保持期間内であればリプレイできます
• パーティション／シャード内で厳密な順序が保たれます
• 複数の独立したコンシューマーが、同じデータを異なる位置から読み取れます
• イベントソーシング、リアルタイム分析、変更データキャプチャ、継続的な処理向けに設計されています

主な違い

項目	メッセージング	ストリーミング
データのライフサイクル	消費後に削除	リプレイ用に保持（数時間から無期限）
順序	ベストエフォート（Standard）またはグループ単位（FIFO）	パーティション／シャード単位で厳密
コンシューマーモデル	競合するコンシューマー（作業の分散）	独立したリーダー（位置によるファンアウト）
スループットのパターン	突発的で変動する	継続的で大量
リプレイ	非対応（DLQ からの再配信を除く）	ネイティブ対応 — 保持期間内の任意の位置へ移動可能
一般的なレイテンシー	ミリ秒単位（プッシュまたはショートポーリング）	ミリ秒から数秒程度
スケーリング単位	同時実行数（コンシューマー／ポーラー）	パーティションまたはシャード

メッセージングのユースケース

• リクエスト／レスポンスまたはコマンドパターンによるマイクロサービスの疎結合化
• 競合するコンシューマーのプールへの作業の分配（タスクキュー）
• 各サブスクライバーが独立して処理するファンアウト通知
• 突発的な処理が発生し、キューによるバッファリングが有効なワークロード
• 既存の JMS／AMQP アプリケーションの移行（Amazon MQ）

ストリーミングのユースケース

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

メッセージングサービス

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

サービス	最適な用途	主な差別化要因
Amazon SQS	タスクキュー、疎結合化、バッファリング	フルマネージド、スループット無制限（Standard）、正確に 1 回の処理（FIFO）、マルチテナントワークロード向けの公平なキュー
Amazon SNS	ファンアウト、Pub/Sub 通知	複数のサブスクライバーへのプッシュ（SQS、Lambda、HTTP。メール／SMS エンドポイントは運用アラートに適しています。顧客向けメールまたは SMS については「顧客コミュニケーション（アプリケーションから個人へ）」を参照してください）
Amazon EventBridge	イベントルーティング、アカウント間／SaaS 統合	コンテンツベースのフィルタリング、スキーマレジストリ、200 以上の AWS ソースとの統合
Amazon MQ	既存の JMS／AMQP／MQTT アプリのリフトアンドシフト	レガシー移行向けのプロトコル互換性（ActiveMQ、RabbitMQ）

ストリーミングサービス

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

サービス	最適な用途	主な差別化要因
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 倍）、幅広いコネクターエコシステム

顧客コミュニケーション（アプリケーションから個人へ）

上記のサービスは、アプリケーション間、つまり同じアプリケーションのコンポーネント間でデータを移動します。 AWS のサービスには、アプリケーションから個人へ（A2P）メッセージを配信する、またはアプリケーション外部の顧客や購読者などの受信者からメッセージを受け取る、別のグループがあります。 この 2 つのグループは相互に置き換えられるものではありません。

チャネル	サービス	スキル
メール	Amazon SES	amazon-ses
WhatsApp	AWS End User Messaging Social	aws-social-messaging
SMS、MMS、RCS、音声	AWS End User Messaging SMS	aws-sms-voice
モバイルプッシュ	AWS End User Messaging Push	なし

このセクションだけで、ワークロードがどちらのグループに属するか、また各チャネルをどのサービスが担当するかという 2 種類の質問に直接回答してください。 チャネルの設定、チャネル経由の送信、配信のトラブルシューティングなど、その他の顧客コミュニケーションに関する質問には、このスキルの情報だけで回答せず、表に記載されたスキルを読み込んで回答してください。 読み込むには、AWS MCP サーバーが利用可能な場合は、表に記載された正確な名前を使って aws___retrieve_skill(skill_name="<skill>") を実行するか、Agent Toolkit の skills/<skill>/SKILL.md にあるスキルドキュメントを読んでください。 表に「なし」と記載されている場合、または該当するスキルを読み込めない場合は、その旨を伝えてから、利用可能であればドキュメントツール（aws___search_documentation、aws___read_documentation）を使い、それらも利用できない場合は、該当するサービスの AWS ドキュメントに基づいて回答してください。

よくある統合時の注意点

• SQS のシステム属性とユーザーメッセージ属性： AWSTraceHeader（SQS の DLQ に送信するときに X-Ray／EventBridge／Pipes が設定）や SenderId、SentTimestamp などの属性は、SQS のシステム属性であり、ユーザーメッセージ属性ではありません。これらは ReceiveMessage からデフォルトでは返されないため、MessageAttributeNames（ユーザー属性を取得）とは別に、AttributeNames=[...]（または MessageSystemAttributeNames）で明示的にリクエストする必要があります。これは DLQ で重要です。トレースヘッダーはシステム属性に含まれ、ユーザー属性の枠にはサービスの障害メタデータ（EventBridge の RULE_ARN、ERROR_CODE など）が格納されます。

• SNS → Firehose → S3 のレコード区切り: firehose プロトコルを使用して S3 に配信される SNS サブスクリプションでは、レコードはデフォルトですでに改行区切り（NDJSON）になっています。Firehose の AppendDelimiterToRecord を有効にしないでください。SNS 自体が改行を出力しており、このプロセッサを有効にすると改行が二重になります。

• EventBridge ルールターゲットの DLQ と SNS サブスクリプションの DLQ には、どちらも DLQ キューポリシーが必要です。 DLQ をアタッチするだけでは不十分です。キューポリシーがサービスプリンシパルを許可するまで、DLQ はメッセージを黙って破棄します。EventBridge: DeadLetterConfig.Arn=<DLQ> を指定した PutTargets、および Service: events.amazonaws.com に対して aws:SourceArn = ルール ARN で sqs:SendMessage を許可する SQS ポリシー。SNS: RedrivePolicy={"deadLetterTargetArn":"<DLQ>"} を指定した SetSubscriptionAttributes、およびトピック ARN でスコープされた Service: sns.amazonaws.com を許可する SQS ポリシー。

• SQS の本番環境でのデフォルト: ロングポーリング + カスタマーマネージド暗号化。 新しいキューはデフォルトでショートポーリング（ReceiveMessageWaitTimeSeconds=0）と SSE-SQS（AWS 所有キー）になります。本番環境では、alias/aws/sqs のままにせず、ReceiveMessageWaitTimeSeconds=20（ロングポーリング）と KmsMasterKeyId=<カスタマーマネージドキー ID/ARN> を指定して SetQueueAttributes を実行してください。

• ブローカーと Kafka の認証情報は、接続文字列ではなく Secrets Manager に保管してください。 ユーザー名、パスワード、SASL/SCRAM 認証情報を、アプリケーション設定、環境変数、JAAS ファイル、IaC にハードコードしないでください。Amazon MQ（ActiveMQ/RabbitMQ）では、ブローカーユーザーをシークレットとして保存し、起動時に取得します。Amazon MQ の Lambda イベントソースマッピングでは、ブローカー認証情報をインラインではなく Secrets Manager シークレット ARN（BASIC_AUTH）として指定する必要があります。MSK の SASL/SCRAM では、シークレットは任意ではありません。AmazonMSK_ プレフィックスを付けて名前を付け、カスタマーマネージド KMS キーで暗号化する必要があり（デフォルトの aws/secretsmanager キーで作成されたシークレットはクラスターに関連付けできません）、その後 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 ユーザーガイドの The confused deputy problem を参照してください。