Amazon SQS に関するよくある質問

使用した分にのみコストがかかります。最低料金はありません。

Amazon SQS の料金は、リクエストごとに計算される分に加えて、Amazon SQS から転送されるデータに対してデータ転送料金をお支払いいただきます (データが同じリージョン内の Amazon Elastic Compute Cloud (EC2) インスタンス、または AWS Lambda 関数に転送される場合を除きます)。キューの種類およびリージョンごとの詳細な料金明細については、「Amazon SQS の料金」を参照してください。

Amazon SQS の無料利用枠では、毎月 100 万件のリクエストを無料でご利用いただけます。

多くの小規模アプリケーションは、完全にこの無料利用枠内で運用できます。ただし、データ転送料金は別途必要です。詳細については、「Amazon SQS の料金」を参照してください。

無料利用枠は月ごとに利用できます。無料利用枠は月をまたいで累積されることはありません。

はい、無料利用枠を超えるすべてのリクエストに対して課金されます。Amazon SQS のすべてのリクエストに対して課金され、一律単価で請求されます。

いいえ。バッチオペレーション (SendMessageBatch、DeleteMessageBatch、ChangeMessageVisibilityBatch) のコストはすべて、Amazon SQS の他のリクエストと同じです。メッセージをバッチにグループ化することにより、Amazon SQS のコストを削減できます。

Amazon SQS の使用を開始するための初期料金はありません。月末に、その月の使用料金が自動的にお客様のクレジットカードに請求されます。

現在の請求期間の料金は、AWS のウェブサイトでいつでも確認できます。

1. AWS アカウントにログインします。
2. [Your Web Services Account] で [Account Activity] を選択します。

リソースとコスト管理のキューは、コスト配分タグを使用してタグ付けして追跡できます。タグは、キーと値のペアで構成されるメタデータラベルです。たとえば、コストセンターでキューをタグ付けしてから、それらのコストセンターに基づいてコストを分類し、追跡することができます。

詳細については、Amazon SQS デベロッパーガイドの「Amazon SQS キューのタグ付け」を参照してください。AWS リソースのコスト配分タグ付けの詳細については、AWS 請求とコスト管理ユーザーガイドの「コスト配分タグの使用」を参照してください。

別途記載がない限り、表示される料金には VAT、売上税、その他取引に対して適用される一切の税金および関税は含まれません。

日本の請求連絡先をお持ちのお客様が AWS をご利用になった場合は、ご利用になったリージョンにかかわらず、料金とあわせて別途消費税をご請求させていただきます。詳細については、「アマゾン ウェブ サービス消費税率変更についてのよくある質問」を参照してください。

はい。アプリケーションの柔軟性とスケーラビリティを向上させるために、Amazon SQS を、Amazon EC2、Amazon Elastic Container Service (ECS)、AWS Lambda といったコンピューティングサービス、および Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB といったストレージサービスやデータベースサービスと共に使用できます。

AWS マネジメントコンソールを使用して Amazon SQS にアクセスすると、簡単に Amazon SQS キューを作成してメッセージを送信できます。

Amazon SQS はウェブサービス API も提供します。また、AWS SDK とも統合されているため、任意のプログラミング言語で作業することが可能になります。

メッセージキューのオペレーションの詳細については、「Amazon SQS API リファレンス」を参照してください。

AWS アカウントの所有者 (またはアカウント所有者が権限を委任した AWS アカウント) のみが、Amazon SQS メッセージキューでオペレーションを実行できます。

はい。JMS クラスター運用のオーバーヘッドの高さについて心配することなく、Amazon SQS の規模、低いコスト、および高可用性を生かせます。 

Amazon では、JMS 1.1 仕様を実装し Amazon SQS を JMS プロバイダーとして使用する Amazon SQS Java メッセージングライブラリを提供しています。詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS での JMS の使用」を参照してください。

Java Message Service (JMS)

すべてのメッセージには、メッセージがメッセージキューに配信される際に Amazon SQS から返される、グローバルに一意の ID が割り当てられます。メッセージをさらに処理するためにこの ID が必要になるわけではありませんが、メッセージキューの特定のメッセージが受信状況を追跡するのに役立ちます。

メッセージキューからメッセージを受信すると、応答に受信ハンドルが含まれます。受信ハンドルは、メッセージを削除する際に入力する必要があります。

詳細については、「Amazon SQS デベロッパーガイド」の「キューとメッセージの識別子」を参照してください。

Amazon SQS では、API やコンソールを使用してデッドレターキューを設定できます。デッドレターキューは、他のソースキューからメッセージを受信します。デッドレターキューを設定する際には、RedriveAllowPolicy を使用してデッドレターキューのリドライブに適切な許可を設定する必要があります。

RedriveAllowPolicy には、デッドレターキューのリドライブ許可のパラメータが含まれています。どのソースキューが JSON オブジェクトとしてデッドレターキューを指定できるかを定義します。

一度デッドレターキューを作ると、そのキューは、完了できなかった処理試行が最大数に達した後にメッセージを受信します。デッドレターキューを使用すると、処理できないメッセージを後で分析するために分離できます。

詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS デッドレターキューの使用」を参照してください。

可視性タイムアウトは、Amazon SQS で、他の消費コンポーネントがメッセージの受信と処理を行わないようにする期間です。詳細については、「Amazon SQS デベロッパーガイド」の「可視性タイムアウト」を参照してください。

はい。Amazon SQS のメッセージには、最大 10 件のメタデータ属性を含めることがきます。メッセージ属性を使用して、メッセージの本文と本文を記述するメタデータを分離できます。これにより、アプリケーション側で処理方法を判断するためにメッセージ全体を調査する必要がなくなり、情報を処理して保存する速度と効率が向上します。

Amazon SQS メッセージ属性の形式は、名前-タイプ-値の 3 部から構成されます。サポートされるタイプには、文字列、バイナリ、および数値 (整数、浮動小数点、および倍精度浮動小数点数を含む) があります。詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS メッセージ属性の使用」を参照してください。

"キューされていた時間" の値を判断するため、メッセージの受信時に SentTimestamp 属性をリクエストできます。"キューされていた時間" の値で、現在の時間の結果からその値を差し引きます。

SendMessage、ReceiveMessage、DeleteMessage の各 API リクエストの場合、レイテンシーは通常数十ミリ秒～数百ミリ秒です。

AWS アカウント ID を利用できない場合 (メッセージの送信元が匿名ユーザーの場合など) は、Amazon SQS から IP アドレスが提供されます。

Amazon SQS ロングポーリングは、Amazon SQS キューからメッセージを取得する方法です。通常のショートポーリングは、ポーリングされたメッセージキューが空であっても直ちに応答を返しますが、ロングポーリングではメッセージがメッセージキューに達するか、ロングポーリングがタイムアウトになるまで応答を返しません。

ロングポーリングの場合、Amazon SQS キューでメッセージを利用できるようになった時点ですぐに、そのメッセージを低コストで取り出せます。ロングポーリングを使用すると、何も受信しない回数が減るため、SQS の使用コストが下がります。詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS ロングポーリング」を参照してください。

いいえ。ロングポーリングの ReceiveMessage 呼び出しに対して請求される料金は、ショートポーリングの ReceiveMessage 呼び出しの場合と同額です。

ほとんどの場合、Amazon SQS ショートポーリングではなく、Amazon SQS ロングポーリングを使用することをお勧めします。ロングポーリングリクエストを使用すると、メッセージがキューに達した時点ですぐに、キューの消費コンポーネントがそのメッセージを受信でき、また ReceiveMessageResponses インスタンスが空で返される回数が減ります。

ほとんどのユースケースで、Amazon SQS ロングポーリングはパフォーマンスの向上とコスト削減につながります。ただし、アプリケーションが ReceiveMessage 呼び出しから直ちに応答を受け取る必要がある場合は、アプリケーションに多少の変更を加えないとロングポーリングのメリットを活用できない可能性があります。

例えば、複数のキューを単一スレッドでポーリングするアプリケーションの場合は、ショートポーリングからロングポーリングへの切り替えが機能しない可能性があります。単一スレッドは、すべての空のキューでロングポーリングタイムアウトを待機し、メッセージが含まれる可能性のあるキューの処理が遅れるためです。

このようなアプリケーションで複数のキューを処理する場合は、単一スレッドを使用しないようにすることができます。これにより、そのアプリケーションで Amazon SQS ロングポーリングのメリットを活用できるようになります。

通常は、ロングポーリングタイムアウトの上限値である 20 秒を指定できます。ロングポーリングタイムアウト値を大きくすると、ReceiveMessageResponses インスタンスが空で返される回数が減るので、ロングポーリングタイムアウトはできるだけ大きい値に設定するようにしてください。

アプリケーションが最大値の 20 秒で動作しない場合 (前の質問の例を参照)、ロングポーリングタイムアウトを最小で 1 秒まで減らせます。

AWS SDK はすべて、デフォルトの 20 秒のロングポーリングで動作します。Amazon SQS へのアクセスに AWS SDK を使用しない場合、または AWS SDK に短いタイムアウトを特別に設定した場合は、長いリクエストを許可するように、または短いロングポーリングタイムアウトを使用するように、Amazon SQS クライアントを変更しなければならないことがあります。

AmazonSQSBufferedAsyncClient for Java には AmazonSQSAsyncClient インターフェイスが実装され、以下のようないくつかの重要な機能が追加されています。

• アプリケーションに変更を加えることなく、複数の SendMessage、DeleteMessage、または ChangeMessageVisibility といったリクエストに対して自動バッチ処理を実行する。
• ローカルバッファにメッセージをプリフェッチする。アプリケーションは、Amazon SQS からメッセージが取り出されるのを待たずに直ちにメッセージを処理できる。

こうした自動バッチ処理とプリフェッチの連携によって、スループットが向上してアプリケーションのレイテンシーが減少するほか、Amazon SQS リクエストが減り、コストが削減されます。詳細については、「Amazon SQS デベロッパーガイド」の「クライアント側のバッファリングとリクエストのバッチ処理」を参照してください。

AmazonSQSBufferedAsyncClient は、AWS SDK for Java の一部としてダウンロードできます。

いいえ。AmazonSQSBufferedAsyncClient for Java は、既存の AmazonSQSAsyncClient のドロップインリプレースメントとして実装されています。

最新の AWS SDK を使用できるようアプリケーションを更新し、クライアントを AmazonSQSAsyncClient から AmazonSQSBufferedAsyncClient for Java に変更されるなら、ご使用のアプリケーションで自動バッチ処理とプリフェッチの追加のメリットを利用できるようになります。

1. Amazon SQS コンソールで Amazon SQS 標準キューを選択します。
2. [Queue Actions] で、ドロップダウンの一覧から [Subscribe Queue to SNS Topic] を選択します。
3. ダイアログボックスで、[Choose a Topic] ドロップダウンの一覧からトピックを選択して、[Subscribe] をクリックします。

詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SNS トピックへのキューのサブスクライブ」を参照してください。

はい。PurgeQueue アクションを使用して Amazon SQS メッセージキューのすべてのメッセージを削除できます。

メッセージキューを消去すると、それまでにそのキューに送信されたすべてのメッセージが削除されます。メッセージキューとその属性は残るため、再設定しなくてもメッセージキューを使い続けることができます。

特定のメッセージのみを削除するには、DeleteMessage アクションまたは DeleteMessageBatch アクションを使用します。

詳細については、チュートリアル: Amazon SQS キューからメッセージを消去するを参照してください。

FIFO キューは、Amazon SQS が利用可能なすべての AWS リージョンで利用できます。Amazon SQS が利用可能なリージョンについては、こちらをご覧ください。

FIFO キューは、重複メッセージがないように設計されています。ただし、特定のシナリオではメッセージのプロデューサーによって重複が起きることもあります。例えば生産者がメッセージを送信し、応答がない場合に、同じメッセージを再送信する場合などです。Amazon SQS API には、メッセージのプロデユーサーが重複して送信しないようにする重複排除機能が用意されています。メッセージの生産者によって発生した重複は、5 分間の重複排除間隔で削除されます。

標準キューについては、重複したメッセージのコピーを受信することもあります (少なくとも 1 回の配信)。標準キューを使用する場合は、アプリケーションがべき等性を持つように設計する必要があります (つまり、同じメッセージを複数回処理したときにアプリケーションが悪影響を受けてはいけません)。

詳細については、「Amazon SQS デベロッパーガイド」の「1 回だけの処理」を参照してください。

いいえ。Amazon SQS 標準キュー (既存のキューの新しい名称) は変わらず、標準キューをこれまで通りに作成できます。これらのキューでは引き続き、最高レベルのスケーラビリティとスループットが提供されますが、順序保証はなく、重複が発生することがあります。

標準キューは、複数のべき等消費者との作業配分など、多くのシナリオに適しています。

いいえ。作成時にキューのタイプを選択する必要があります。ただし、FIFO キューに移行することはできます。詳細については、「Amazon SQS デベロッパーガイド」の「標準キューから FIFO キューへの移行」を参照してください。

FIFO キューの機能を利用するには、最新の AWS SDK を使用している必要があります。

FIFO キューでは、標準キューと同じ API アクションが使用され、メッセージの受信と削除の仕組みや可視性タイムアウトの変更も同じです。ただし、メッセージの送信時には、メッセージグループ ID を指定する必要があります。詳細については、「Amazon SQS デベロッパーガイド」の「FIFO キューのロジック」を参照してください。

FIFO キューでは、標準キューでサポートされているすべてのメトリクスをサポートしています。FIFO キューでは、すべての近似メトリクスで正確な数が戻されます。例えば、以下の AWS CloudWatch メトリクスがサポートされています。

• ApproximateNumberOfMessagesDelayed – キュー内の、遅延が発生したためにすぐに読み取ることができないメッセージの数。
• ApproximateNumberOfMessagesVisible – キューから取得可能なメッセージの数。
• ApproximateNumberOfMessagesNotVisible – 転送中の (クライアントに送信されたが、まだ削除されていない、または可視性ウィンドウの末尾にまだ到達していない) メッセージの数。

メッセージは FIFO キュー内で別個の、順序が付けられた「バンドル」にグループ化されます。メッセージグループ ID ごとに、すべてのメッセージが厳密な順序で送受信されます。ただし、異なるメッセージグループ ID 値のメッセージは、送信および受信の順序が入れ替わる場合があります。メッセージグループ ID をメッセージに関連付ける必要があります。メッセージグループ ID を指定しないと、アクションは失敗します。

複数のホスト (または同じホスト上の異なるスレッド) が、同じメッセージグループ ID を持つメッセージを FIFO キューに送信した場合、Amazon SQS は到着順にメッセージを配信して処理に回します。Amazon SQS でメッセージが送信および受信された順序が確実に保持されるように、複数の送信者はそれぞれすべてのメッセージ送信で一意のメッセージグループ ID を使用するようにしてください。

詳細については、「Amazon SQS デベロッパーガイド」の「FIFO キューのロジック」を参照してください。

はい。1 つまたは複数のプロデューサーが FIFO キューにメッセージを送信できます。メッセージは Amazon SQS で正常に受信された順序で保管されます。

複数のプロデューサーが、SendMessage アクションまたは SendMessageBatch アクションからの成功応答を待たずに、メッセージを並行に送信する場合、そのプロデューサー間の順序が保たれない場合があります。SendMessage アクションまたは SendMessageBatch アクションの応答には最終的な順序シーケンスが含まれます。FIFO キューはこれを使用してキューにメッセージを配置します。そのため複数の並行の生産者コードによってキューにおける最終的なメッセージの順序を決定できます。

設計上、Amazon SQS FIFO キューでは、同じメッセージグループからのメッセージを同時に複数のコンシューマーに提供することはありません。ただし、FIFO キューに複数のメッセージグループが存在する場合、並列の消費者を利用して、別のメッセージグループからのメッセージを別のコンシューマーに提供するよう Amazon SQS を設定できます。

デフォルトでは、FIFO キューはバッチ処理ありで 1 秒あたり最大 3,000 件のメッセージを、またはバッチ処理なしで最大 300 件のメッセージを (1 秒あたり 300 件の送受信または削除) をサポートしています。より高いスループットが必要な場合は、Amazon SQS コンソールで FIFO の高スループットモードを有効にできます。これにより、バッチ処理なしで 1 秒あたり最大 70,000 件のメッセージがサポートされ、バッチ処理ではさらに多くのメッセージがサポートされます。リージョンごとの FIFO ハイスループットモードクォータの詳細な内訳については、AWS ドキュメントを参照してください。

FIFO キューの名前は .fifo サフィックスで終わる必要があります。.fifo サフィックスは、キュー名の制限である 80 文字には含まれます。キューが FIFO であるかどうかを確認するには、キュー名がサフィックスで終わるかどうかをチェックします。

Amazon SQS では、すべてのメッセージキューとメッセージを、可用性の高い単一の AWS リージョン内で、冗長性のある複数のアベイラビリティーゾーン (AZ) に保存しています。そのため単一のコンピュータ、ネットワーク、AZ などの障害により、SQS メッセージがアクセスできなくなることはありません。詳細については、「Amazon Relational Database Service ユーザーガイド」の「リージョンとアベイラビリティーゾーン」を参照してください。

認証メカニズムにより、Amazon SQS メッセージキューに保存されているメッセージが不正アクセスから保護されます。誰がメッセージをメッセージキューに送信できるか、またメッセージキューから誰がメッセージを受信できるかを制御できます。セキュリティを強化するため、メッセージキューに配置する前にメッセージを暗号化するアプリケーションを構築できます。

Amazon SQS には独自のリソースベースのアクセス権限システムがあり、AWS Identity and Access Management (IAM) のポリシーと同じ言語で記述されたポリシーが使用されます。たとえば、IAM ポリシーと同様に変数を使用できます。詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS ポリシーの例」を参照してください。

Amazon SQS は、SSL プロトコルおよび Transport Layer Security (TLS) プロトコル経由の HTTP (HTTPS) に対応しています。ほとんどのクライアントでは、コードまたは設定を変更することなく、TLS の新しいバージョンに自動的にネゴシエートできます。Amazon SQS では、すべてのリージョンで Transport Layer Security (TLS) プロトコルのバージョン 1.0、1.1、1.2 に対応しています。

Amazon SQS がお客様にメッセージを返すと、実際にメッセージが受信されたかどうかにかかわらず、そのメッセージはメッセージキューに残ります。メッセージの削除はお客様の側で行ってください。削除リクエストで、お客様がメッセージの処理を終えたことを確認します。

メッセージを削除しないと、Amazon SQS は別の受信リクエストを受信したときに、そのメッセージを再配信します。詳細については、「Amazon SQS デベロッパーガイド」の「可視性タイムアウト」を参照してください。

いいえ。FIFO キューでは重複メッセージは発生しません。

標準キューの場合、ごくまれに以前に削除したメッセージを再受信することがあります。 

以前に削除したメッセージに対して DeleteMessage リクエストを発行すると、Amazon SQS は成功という応答を返します。

サーバー側の暗号化を使うと、機密データを暗号化されたキューで送信できます。SSE を使用すると、AWS Key Management Service (AWS KMS) で管理されているキーを使用して、Amazon SQS キューのメッセージの内容が保護されます。SSE では、Amazon SQS でメッセージを受信した時点ですぐに暗号化します。メッセージは暗号化された形式で保存され、Amazon SQS は許可された消費者に送信された場合のみメッセージを復号化します。

詳細については、Amazon SQS デベロッパーガイドのサーバー側暗号化 (SSE) および AWS KMS を使用したデータの保護を参照してください。

はい。そうするには、SSE を使用して AWS のサービス (Amazon CloudWatch Events、Amazon S3、Amazon SNS など) とキューの間の互換性を有効にする必要があります。詳細な手順については、「SQS デベロッパーガイドの互換性に関するセクション」を参照してください。 

Amazon SQS のサーバー側の暗号化 (SSE) は、Amazon SQS が利用できる全 AWS リージョンで使用可能です。Amazon SQS が利用可能なリージョンについては、こちらをご覧ください。

Amazon SQS API を使用して新規または既存のキューで SSE を有効にするには、CreateQueue または SetQueueAttributes アクションの KmsMasterKeyId 属性を設定して、AWS 管理の CMK またはカスタム CMK のカスタマーマスターキー (CMK) ID (エイリアス、エイリアス ARN、キー ID、またはキー ARN) を指定します。

詳細な手順については、「Amazon SQS デベロッパーガイド」の「サーバー側の暗号化 (SSE) を使用して Amazon SQS キューを作成する」および「既存の Amazon SQS キューにサーバー側の暗号化 (SSE) を設定する」を参照してください。

標準キューと FIFO キューの両方で SSE をサポートしています。

SSE を使用するには、AWS KMS のキーポリシーを設定し、キューの暗号化とメッセージの暗号化/復号化を許可する必要があります。

キューで SSE を有効にするには、Amazon SQS またはカスタム CMK の AWS 管理のカスタマーマスターキー (CMK) を使用できます。詳細については、「AWS KMS デベロッパーガイド」の「カスタマーマスターキー」を参照してください。

暗号化されたキューにメッセージを送信する場合、生産者には CMK に対する kms:GenerateDataKey および kms:Decrypt 権限が必要です。

暗号化されたキューからメッセージを受信する場合、コンシューマーには、指定されたキューのメッセージを暗号化するのに使用される CMK に対して、kms:Decrypt 権限が必要です。キューがデッドレターキューとして使用される場合、コンシューマーには、ソースキューのメッセージを暗号化するのに使用される CMK に対しても kms:Decrypt アクセス許可が必要です。

詳細については、「Amazon SQS デベロッパーガイド」の「SSE を使用するのに必要な許可」を参照してください。

追加の Amazon SQS 料金はありません。ただし、Amazon SQS から AWS KMS への呼び出しには料金が発生します。詳細については、「AWS Key Management Service の料金」を参照してください。

AWS KMS の使用料金は、キューに設定されているデータキーの再利用期間によって異なります。詳細については、「Amazon SQS デベロッパーガイド」の「AWS KMS の使用料を見積もる方法」を参照してください。

SSE は、Amazon SQS キュー内のメッセージ本文を暗号化します。

SSE は以下のコンポーネントを暗号化しません。

• キューのメタデータ (キュー名と属性)
• メッセージのメタデータ (メッセージ ID、タイムスタンプ、属性)
• キュー単位のメトリクス

Amazon SQS では、Amazon SQS またはカスタム CMK の AWS 管理のカスタマーマスターキー (CMK) を基にデータキーが生成され、設定可能な時間範囲 (1 分～24 時間) でメッセージのエンベロープ暗号化および複合化が行われます。

詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS 用 SSE による暗号化の対象」を参照してください。

SSE では AES-GCM 256 アルゴリズムを使用しています。

SSE では Amazon SQS のスループット (TPS) を制限していません。作成できる SSE キューの数は、以下によって制限されます。

• データキーの再利用期間 (1 分～24 時間)。
• AWS KMS アカウント単位のクォータ (デフォルトでは 100 TPS)。
• キューにアクセスする IAM ユーザーまたはアカウントの数。
• サイズの大きいバックログの存在 (バックログが大きくなると AWS KMS の呼び出しが増えます)。

たとえば、以下の設定を想定してみましょう。

• データキーの再利用期間を 5 分 (300 秒) に設定します。
• KMS アカウントのデフォルトの AWS KMS TPS クォータは 100 TPS です。
• バックログなしで Amazon SQS キューを使用しており、すべてのキューへの SendMessage または ReceiveMessage アクション用に 1 名の IAM ユーザーがいます。

この場合、SSE を使用した Amazon SQS キューの理論上の最大値は以下のように計算できます。

300 秒 × 100 TPS / 1 名の IAM ユーザー = 30,000 キュー

コストを予測し、AWS の請求額をより正確に把握するには、Amazon SQS で CMK が使用される頻度を調べることができます。

注: 以下の計算式を使用することで予想されるコストを大まかに把握することができますが、Amazon SQS の分散性により、実際のコストはもっと高くなる可能性があります。

キューごとの API リクエスト数 (R) を計算するには、以下の数式を使用します。

R = B / D * (2 * P + C)

B は請求期間 (秒) です

D は、データキー再利用期間 (秒) です

P は、Amazon SQS キューに送信する、プロデューサー側のプリンシパル数。

C は、Amazon SQS キューから受信する、コンシューマー側のプリンシパル数です。

重要: 一般的に、プロデューサー側プリンシパルで発生するコストはコンシューマー側プリンシパルの倍程度になります。詳細については、「Amazon SQS デベロッパーガイド」の「データキー再利用期間のしくみ」を参照してください。

プロデューサーとコンシューマーの IAM ユーザーが異なる場合は、コストが高くなります。

詳細については、「Amazon SQS デベロッパーガイド」の「AWS KMS の使用料を見積もる方法」を参照してください

はい。Amazon SQS は PCI DSS レベル 1 の認定を受けています。詳細については、「PCI コンプライアンス」を参照してください。

はい。AWS では HIPAA 準拠プログラムを拡張し、Amazon SQS を HIPAA 対応サービスとして追加しました。AWS と事業提携契約 (BAA) を締結している場合は、Amazon SQS を使用して独自の HIPAA 準拠アプリケーションの構築、通信中のデータの保存、および (保護医療情報 (PHI) が含まれるメッセージを含む) メッセージの送信を行うことができます。

すでに AWS と BAA を締結している場合は、今すぐ Amazon SQS の使用を開始することができます。BAA を締結していない場合、またはお使いの HIPAA 準拠アプリケーションへの AWS の使用に関してご質問がある場合は、詳細をお問い合わせください。

注: Amazon SQS 経由での PHI の転送を望まない場合 (または 256 KB より大きなメッセージがある場合) は、代わりに Java 用 Amazon SQS 拡張クライアントライブラリを使用して Amazon S3 経由で Amazon SQS メッセージペイロードを送信することもできます (Amazon S3 は HIPAA 対応サービスです (Amazon S3 Transfer Acceleration の使用を除く))。詳細については、「Amazon SQS デベロッパーガイド」の「Java 用 Amazon SQS 拡張クライアントライブラリの使用」を参照してください。

メッセージの保持期間を延長すると柔軟性が向上し、メッセージの作成から消費までの間隔を延ばすことができます。

Amazon SQS メッセージを保持する期間を、1 分間～14 日間の範囲内で設定できます。デフォルトでは 4 日間になっています。メッセージの保持クォータが終了すると、お客様のメッセージは自動的に削除されます。

メッセージ保持期間を設定するには、コンソールまたは Distributiveness メソッドを使用して MessageRetentionPeriod 属性を設定します。この属性を使用して、メッセージが Amazon SQS に保持される秒数を指定します。

MessageRetentionPeriod 属性を使用すると、メッセージの保持期間を 60 秒間 (1 分間)～1,209,600 秒間 (14 日間) の範囲内で設定できます。このメッセージ属性の使い方の詳細については、Amazon SQS API リファレンスを参照してください。

最大メッセージサイズを設定するには、コンソールまたは SetQueueAttributes メソッドを使用して MaximumMessageSize 属性を設定します。 この属性で、Amazon SQS メッセージに含めることができるバイト数を指定します。1,024 バイト (1 KB)～262,144 バイト (256 KB) の範囲内の値を設定できます。詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS メッセージ属性の使用」を参照してください。

256 KB を超えるメッセージを送信するには、Java 用 Amazon SQS 拡張クライアントライブラリを使用します。このライブラリにより、Amazon S3 のメッセージペイロードへの参照を含む Amazon SQS メッセージを送信できます。S3 のメッセージペイロードは最大 2 GB です。

Amazon SQS のメッセージとして送信できるのは、最大 256 KB のテキストデータ (XML、JSON、未フォーマットのテキストなど) です。以下の Unicode 文字を使用できます。

#x9 | #xA | #xD | [#x20～#xD7FF] | [#xE000～#xFFFD] | [#x10000～#x10FFFF]

詳細については、「XML 1.0 仕様」を参照してください。

単一の Amazon SQS メッセージキューに含めるメッセージの数に制限はありません。ただし、転送中メッセージの数については標準キューで 120,000、FIFO キューで 20,000 のクォータが設定されています。メッセージは、消費コンポーネントによるキューから取得されたものの、キューからまだ削除されていない場合に転送中になります。

作成できるメッセージキューの数は無制限です。

キュー名は 80 文字に制限されています。

英数字、ハイフン (-)、および下線 (_) を使用できます。

メッセージキューの名前は AWS のアカウントとリージョンに対して一意である必要があります。同じ名前のメッセージキューを削除した後に、メッセージキューの名前を再利用できます。

共有するメッセージキューとアクセスポリシーステートメントを関連付けます (また、付与する権限を指定します)。Amazon SQS では、アクセスポリシーステートメントを作成および管理するため、以下の API を利用できます。

• AddPermission
• RemovePermission
• SetQueueAttributes
• GetQueueAttributes

詳細については、「Amazon SQS API リファレンス」を参照してください。

共有されたキューアクセスについては、メッセージキュー所有者にお支払いいただきます。

Amazon SQS API では、AWS アカウント番号により AWS ユーザーを識別できます。

他の AWS ユーザーとメッセージキューを共有するには、共有するメッセージキューの完全 URL を伝える必要がありますCreateQueue オペレーションや ListQueues オペレーションは、応答でこの URL を返します。

はい。匿名ユーザーによるメッセージキューへのアクセスを許可するアクセスポリシーを設定できます。

Permissions API は、デベロッパーがメッセージキューへのアクセスを共有するためのインターフェイスとなります。ただし、この API では、条件付きアクセスやより高度なユースケースを許可できません。

SetQueueAttributes オペレーションは、フルアクセスポリシー言語に対応しています。たとえば、このポリシー言語を使用すると、メッセージキューへのアクセスを IP アドレスや時間帯によって制限できます。詳細については、「Amazon SQS デベロッパーガイド」の「Amazon SQS ポリシーの例」を参照してください。

対象となるサービスリージョンについては、「AWS グローバルインフラストラクチャのリージョン表」を参照してください。

いいえ。Amazon SQS メッセージキューはリージョンごとに独立しています。

Amazon SQS は、中国 (北京) を除いたすべてのリージョンで同一料金です。詳細については、Amazon SQS 料金ページを参照してください。

Amazon SQS と同じリージョンにある Amazon EC2 や AWS Lambda の間でデータを転送する場合は無料です。

Amazon SQS と別のリージョンにある Amazon EC2 や AWS Lambda の間でデータを転送する場合は、通常のデータ転送料金が課金されます。詳細については、Amazon SQS 料金ページを参照してください。

デッドレターキューは、ソースキューのコンシューマアプリケーションがメッセージを正常に使用できない場合にソースキューがメッセージを送信できるようにする Amazon SQS キューです。デッドレターキューを使用すれば、メッセージの使用時に失敗を処理し、未使用メッセージのライフサイクルを管理しやすくなります。デッドレターキューに配信されたメッセージのアラームを設定し、キューに配信された可能性のある例外ログを調べ、メッセージの内容を分析してコンシューマアプリケーションの問題を診断できます。コンシューマーアプリケーションが回復すると、メッセージをデッドレターキューからソースキューにリドライブできます。

ソースキューを作成するときに、Amazon SQS では、デッドレターキュー (DLQ) と、SQS がメッセージを DLQ に移動する条件を指定できます。条件は、消費者がキューからメッセージを受信できる回数であり、maxReceiveCount として定義されます。ソースキューと maxReceiveCount を使用したデッドレターキューのこの構成は、リドライブポリシーといいます。メッセージの ReceiveCount がキューの maxReceiveCount を超えると、Amazon SQS はメッセージを (元のメッセージ ID を使用) 配信不能キューに移動するように設計されています。たとえば、ソースキューに maxReceiveCount が 5 に設定されたリドライブポリシーがあり、ソースキューのコンシューマがメッセージを正常に使用せずに 6 回受信した場合、SQS はメッセージをデッドレターキューに移動します。

リドライブポリシーは、未使用メッセージをソースキューから配信不能キューに移動することにより、メッセージのライフサイクル前半を管理します。これで、以下に示すように、ソースキューへのデッドレターキューのリドライブは、これらのメッセージをソースキューに戻すことにより、サイクルを効率的に完了します。

まず、メッセージ属性と関連するメタデータを表示することにより、配信不能キューで使用可能なメッセージのサンプルを調査できます。次に、メッセージを調査したら、それらをソースキューに戻すことができます。リドライブ速度を選択して、Amazon SQS がメッセージをデッドレターキューからソースキューに移動する速度を設定することもできます。

はい。ただし、FIFO キューでは FIFO デッドレターキューを使用する必要があります。(同様に、標準デッドレターキューは標準キューでのみ使用できます。)