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. 在您的 Web 服务账户下，选择账户活动。

您可以使用成本分配标签来标记和跟踪您的队列，以进行资源和成本管理。标签是由键值对组成的元数据标签。例如，您可以按成本中心标记您的队列，然后根据这些成本中心对成本进行分类和跟踪。

有关更多信息，请参阅 Amazon SQS 开发人员指南中的“标记 Amazon SQS 队列”。有关 AWS 资源成本分配标记的更多信息，请参阅 AWS 账单和成本管理用户指南中的使用成本分配标签。

除非另行说明，否则我们的价格不包括任何适用的税费 (例如增值税和适用的销售税)。

账单地址为日本地址的客户使用任何区域的 AWS 均需承担日本消费税。有关更多信息，请参阅 Amazon Web Services 消费税常见问题。

符合。您可以将 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 还提供 Web 服务 API。此外，它还与 AWS SDK 集成，这使您能够根据需要选择编程语言。

有关消息队列操作的消息，请参阅 Amazon SQS API 参考。

只有 AWS 账户拥有者（或账户拥有者指派的 AWS 账户）可以在 Amazon SQS 消息队列上执行操作。

符合。您可以享受 Amazon SQS 的规模、低成本和高可用性，而不必担心运行自己的 JMS 集群的开销。 

Amazon 提供的 Amazon SQS Java Messaging Library 采用 JMS 1.1 规范，并将 Amazon SQS 用作 JMS 提供者。有关更多信息，请参阅《Amazon SQS 开发人员指南》中的结合使用 JMS 与 Amazon SQS。

Java Message Service（JMS）

所有消息都带有一个全局唯一的 ID，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 消息属性采用“名称-类型-值”这种由三项元素构成的格式。支持的类型包括字符串、二进制和数字（包括整数、浮点数和双数）。有关更多信息，请参阅《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 长轮询都比使用短轮询更好。长轮询请求可以让使用队列的应用程序在消息进入队列后接收消息，同时减少返回的空 ReceiveMessageResponse 实例的数量。

Amazon SQS 长轮询在大多数使用案例中的效果都更好，成本也更低。但是，如果您的应用程序希望从 ReceiveMessage 调用中获得即时响应，则可能需要对应用程序进行一些修改才能利用长轮询的优势。

例如，如果您的应用程序使用单个线程来轮询多个队列，那么短轮询可能无法切换为长轮询，因为单个线程会等待所有空队列的长轮询超时，从而导致延迟处理可能包含消息的任何队列。

在这种应用程序中，建议使用单个线程来处理一个队列，从而使应用程序能够利用 Amazon SQS 长轮询的优势。

通常，长轮询超时最多为 20 秒。较高的长轮询超时值会减少返回的空 ReceiveMessageResponse 实例的数量，因此，请将长轮询超时值设置为尽可能高的值。

如果 20 秒的最大值不适用于您的应用程序（请参阅上一问题中的示例），则您可以设置较短的长轮询超时，最短为 1 秒。

默认情况下，所有 AWS 开发工具包都支持 20 秒的长轮询。如果您未使用 AWS 开发工具包访问 Amazon SQS，或者您将 AWS 开发工具包特别配置为使用较短的超时，则您可能需要修改您的 Amazon SQS 客户端，才能允许时间更长的请求或者使用较短的长轮询超时。

适用于 Java 的 AmazonSQSBufferedAsyncClient 可以让用户使用 AmazonSQSAsyncClient 接口，并添加了几项重要功能：

• 自动批处理多个 SendMessage、DeleteMessage 或 ChangeMessageVisibility 请求，而无需对应用程序进行任何更改
• 将消息预取到本地缓冲区，让您的应用程序可以立即处理来自 Amazon SQS 的消息，无需等待检索消息

自动批处理和预取功能结合到一起以后，可以提高吞吐量并降低应用程序延迟，并且提交的 Amazon SQS 请求更少，从而节省成本。有关更多信息，请参阅 Amazon SQS 开发人员指南中的客户端缓冲和请求批处理。

您可以下载适用于 Java 的 AWS SDK，其中就包含适用于 Java 的 AmazonSQSBufferedAsyncClient。

不需要。适用于 Java 的 AmazonSQSBufferedAsyncClient 用于替换现有的 AmazonSQSAsyncClient。

您可以通过更新应用程序来使用最新 AWS 开发工具包，并通过更改客户端来用适用于 Java 的 AmazonSQSBufferedAsyncClient 替换 AmazonSQSAsyncClient，这样，您的应用程序就能获得自动批处理和预取功能所带来的新优势。

1. 在 Amazon SQS 控制台中，选择一个 Amazon SQS 标准队列。
2. 在“队列操作”下，从下拉列表中选择“订阅队列至 SNS 主题”。
3. 在对话框中，从“选择一个主题”下拉列表中选择主题，然后单击“订阅”。

有关更多信息，请参阅 Amazon SQS 开发人员指南中的为队列订阅 Amazon SNS 主题。

符合。您可以使用 PurgeQueue 操作删除 Amazon SQS 消息队列中的所有消息。

当您清除消息队列时，之前发送到该消息队列的所有消息都将被删除。因为您的消息队列及其属性将会保留，所以不需要重新配置消息队列；您可以继续使用。

如果只想删除特定的消息，可以使用 DeleteMessage 或 DeleteMessageBatch 操作。

有关更多信息，请参阅此教程：从 Amazon SQS 队列清除消息。

FIFO 队列可在提供 Amazon SQS 的所有 AWS 区域中使用。请参阅此处，了解有关 Amazon SQS 的区域可用性的详细信息。

FIFO 队列的设计宗旨是不引入重复消息。但是，在某些情况下，消息创建器可能会引入重复消息：例如，如果创建器发送一条消息，未收到响应，然后又重发了同一条消息。Amazon SQS API 提供重复数据删除功能，可防止消息创建器发送重复消息。由消息创建器引入的任何重复消息都会在 5 分钟重复数据删除时间间隔内被删除。

对于标准队列，您可能偶尔会收到一条消息的重复副本 (至少一次传送)。如果您使用标准队列，则必须将应用程序设计为幂等应用程序 (也就是说，应用程序即使多次处理同一条消息也不会受到不利影响)。

有关更多信息，请参阅《Amazon SQS 开发人员指南》中的一次性处理。

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，操作就会失败。

如果多个主机 (或同一主机上的不同线程) 向 FIFO 队列中发送了具有相同消息组 ID 的消息，则 Amazon SQS 按照它们到达的顺序来传送消息。为确保 Amazon SQS 在发送和接收消息时保持相同顺序，请确保多个发送者发送每一条消息时均具有唯一的消息组 ID。

有关更多信息，请参阅《Amazon SQS 开发人员指南》中的 FIFO 队列逻辑。

符合。一个或多个创建器可以向一个 FIFO 队列发送消息。消息按 Amazon SQS 成功接收到它们时的顺序存储。

如果多个创建器并行发送消息，而不等待来自 SendMessage 或 SendMessageBatch 操作的成功响应，则创建器之间的顺序可能不会保留。SendMessage 或 SendMessageBatch 操作的响应包含 FIFO 队列用于将消息放到队列中的最终顺序，因此您的并行多创建器代码可以确定消息在队列中的最终顺序。

根据设计，Amazon SQS FIFO 队列不能一次将同一消息组中的消息提供给多个使用者。但是，如果您的 FIFO 队列具有多个消息组，则您可以利用并行使用者，以便 Amazon SQS 将不同消息组中的消息提供给不同的使用者。

默认情况下，如果使用批处理，FIFO 队列每秒最多可以支持 3000 条消息；如果不使用批处理，则每秒最多可以支持 300 条消息（每秒执行 300 个发送、接收或删除操作）。如果您需要更高的吞吐量，可以在 Amazon SQS 控制台上为 FIFO 启用高吞吐量模式。如果不使用批处理，该模式每秒最多可以支持 70,000 条消息。有关每个区域的 FIFO 高吞吐量模式配额的详细明细，请参阅 AWS 文档。

FIFO 队列的名称必须以 .fifo 后缀结尾。后缀将计入 80 个字符的队列名称限制。要确定队列是否为 FIFO 队列，您可以检查队列名称是否以该后缀结尾。

Amazon SQS 将所有消息队列和消息都存储在具有多个冗余可用区 (AZ) 并且高度可用的单个 AWS 区域中，因此，一台计算机、一个网络或一个可用区的故障不会导致消息无法访问。有关更多信息，请参阅《Amazon 关系数据库服务用户指南》中的区域和可用区。

身份验证机制可以确保存储在 Amazon SQS 消息队列中的消息不会受到未经授权的访问。您可以控制谁能向消息队列发送消息以及谁能从消息队列接收消息。如需提高安全性，您可以构建应用程序将消息加密，然后再将其放入消息队列。

Amazon SQS 带有基于资源的权限系统，所用策略的编写语言与 AWS Identity and Access Management（IAM）策略的编写语言相同。举例来说，您可以像在 IAM 策略中一样使用变量。有关更多信息，请参阅《Amazon SQS 开发人员指南》中的 Amazon SQS 策略示例。

Amazon SQS 支持 HTTP over SSL (HTTPS) 协议以及传输层安全性 (TLS) 协议。大多数客户端可自动协商使用新版本 TLS 协议，无需更改任何代码或配置。Amazon SQS 在所有区域中都支持 1.0、1.1 和 1.2 版传输层安全性 (TLS) 协议。

当 Amazon SQS 返回消息给您时，无论您实际上是否收到消息，该消息都会保存在消息队列中。您负责删除消息，而且发送删除请求即表明您已处理了该消息。

如果您不删除消息，则 Amazon SQS 会在收到另一个接收请求时再次传送该消息。有关更多信息，请参阅《Amazon SQS 开发人员指南》中的可见性超时。

不能。FIFO 队列绝不会引入重复消息。

对于标准队列，在极少的情况下，您可能会再次收到之前删除的消息。 

如果对之前删除的消息发出 DeleteMessage 请求，Amazon SQS 会返回一个响应，表明删除成功。

借助 SSE，您可以采用加密队列的方式传输敏感数据。SSE 会使用 AWS Key Management Service（AWS KMS）托管的密钥保护 Amazon SQS 队列中的消息内容。只要 Amazon SQS 收到消息，SSE 就会对其进行加密。这些消息以加密的形式进行存储，且仅当它们发送到授权的客户时，Amazon SQS 才会对其进行解密。

有关更多信息，请参阅《Amazon SQS 开发人员指南》中的使用服务器端加密 (SSE) 和 AWS KMS 保护数据。

符合。为此，您需要启用 AWS 服务（例如 Amazon CloudWatch Events、Amazon S3 和 Amazon SNS）与具有 SSE 的队列之间的兼容性。有关详细说明，请参阅《SQS 开发人员指南》中的“兼容性”部分。 

提供 Amazon SQS 的所有 AWS 区域均提供适用于 Amazon SQS 的服务器端加密 (SSE)。请参阅此处，了解有关 Amazon SQS 的区域可用性的详细信息。

要为使用 Amazon SQS API 的新的或现有 Amazon SQS 队列启动 SSE，可通过设置 CreateQueue 或 SetQueueAttributes 操作的 KmsMasterKeyId 属性，来指定客户主密钥 (CMK) ID：AWS 托管的 CMK 或自定义 CMK 的别名、别名 ARN、密钥 ID 或密钥 ARN。

有关详细说明，请参阅《Amazon SQS 开发人员指南》中的创建采用客户端加密的 Amazon SQS 队列和为现有 Amazon SQS 队列配置服务器端加密（SSE）。

标准队列和 FIFO 队列均支持 SSE。

您必须先将 AWS KMS 密钥策略配置为允许加密队列以及允许加密和解密消息，然后才能够使用 SSE。

要为队列启用 SSE，您可以使用由 AWS 托管且适用于 Amazon SQS 的客户主密钥 (CMK)，也可以使用自定义 CMK。有关更多信息，请参阅《AWS KMS 开发人员指南》中的客户主密钥。

要向加密的队列发送消息，生产者必须拥有 CMK 的 kms:GenerateDataKey 和 kms:Decrypt 权限。

要从加密的队列接收消息，消费者必须拥有用于加密指定队列中的消息的任何 CMK 的 kms:Decrypt 权限。如果队列充当的是死信队列，消费者还必须拥有用于加密源队列中的消息的任何 CMK 的 kms:Decrypt 权限。

有关更多信息，请参阅《Amazon SQS 开发人员指南》中的我需要哪些权限才能使用 SSE？。

无需支付其他任何 Amazon SQS 费用。但是，从 Amazon SQS 到 AWS KMS 之间的调用会产生费用。有关更多信息，请参阅 AWS 密钥管理服务定价。

使用 AWS KMS 所产生的费用取决于您为队列配置的数据密钥重用周期。有关更多信息，请参阅《Amazon SQS 开发人员指南》中的如何估算 AWS KMS 的使用费用？。

SSE 会加密 Amazon SQS 队列中消息的主体。

SSE 不会加密以下部分：

• 队列元数据 (队列名称和属性)
• 消息元数据 (消息 ID、时间戳和属性)
• 每个队列的指标

Amazon SQS 根据由 AWS 托管且适用于 Amazon SQS 的客户主密钥 (CMK) 或自定义 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。
• 您使用一个无积压事务且有 1 个 IAM 用户的 Amazon SQS 队列，对所有队列执行 SendMessage 或 ReceiveMessage 操作。

在这种情况下，您可以按照如下方式计算使用 SSE 的 Amazon SQS 队列的理论最大值：

300 秒 × 100 TPS/1 个 IAM 用户 = 30000 个队列

要预测费用并更好地了解您的 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 签订商业伙伴协议，那么您就可以立即开始使用 Amazon SQS。如果您未签订商业伙伴协议或者在对您的 HIPAA 合规应用程序使用 AWS 的方面有其他问题，请联系我们，以获取详细信息。

注意：如果不想通过 Amazon SQS 传输 PHI（或者，如果消息超过 256KB），那么可以使用适用于 Java 的 Amazon SQS 扩展型客户端库改为通过 Amazon S3 发送 Amazon SQS 消息负载（除使用 Amazon S3 Transfer Acceleration 外，Amazon S3 在其他方面也是一种符合 HIPAA 要求的服务）。有关更多信息，请参阅 Amazon SQS 开发人员指南中的使用适用于 Java 的 Amazon SQS 扩展型客户端库。

较长消息的保留期可以实现更大的灵活性，让消息产生和消息使用之间的间隔时间更长。

您可以将 Amazon SQS 消息保留期配置为 1 分钟至 14 天之间的值。默认为 4 天。一旦达到消息保留期限，您的消息就会被自动删除。

要配置消息保留期，请使用管理控制台或 Distributiveness 方法来设置 MessageRetentionPeriod 属性。该属性用于指定消息在 Amazon SQS 中保留的秒数。

您可以使用 MessageRetentionPeriod 属性将消息保留期设置为 60 秒（1 分钟）到 1209600 秒（14 天）之间的值。有关使用此消息属性的更多信息，请参阅 Amazon SQS API 参考。

要配置最大消息大小，请使用控制台或 SetQueueAttributes 方法来设置 MaximumMessageSize 属性。 该属性用于指定 Amazon SQS 消息可以包含的字节数。可以将属性设为 1024 字节 (1KB) 到 262144 字节 (256KB) 之间的值。有关更多信息，请参阅《Amazon SQS 开发人员指南》中的使用 Amazon SQS 消息属性。

要发送大小超过 256KB 的消息，您可以使用适用于 Java 的 Amazon SQS 扩展型客户端库。借助该库，您可以发送引用了 Amazon S3 中的消息负载的 Amazon SQS 消息，最大可为 2GB。

Amazon SQS 消息可包含不超过 256 KB 的文本数据，包括 XML、JSON 和无格式文本。接受以下 Unicode 字符：

#x9 | #xA | #xD | [#x20 to #xD7FF] | [#xE000 to #xFFFD] | [#x10000 to #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。

符合。您可以配置访问策略，允许匿名用户访问消息队列。

权限 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 队列结合使用。(同样，只能将标准死信队列与标准队列结合使用。)