HAQM SQS FAQs

You pay only for what you use, and there is no minimum fee.

The cost of HAQM SQS is calculated per request, plus data transfer charges for data transferred out of HAQM SQS (unless data is transferred to HAQM Elastic Compute Cloud (EC2) instances or to AWS Lambda functions within the same region). For detailed pricing breakdowns per queue type and region, see HAQM SQS Pricing.

The HAQM SQS Free Tier provides you with 1 million requests per month at no charge.

Many small-scale applications are able to operate entirely within the limits of the Free Tier. However, data transfer charges might still apply. For more information, see HAQM SQS Pricing .

The Free Tier is a monthly offer. Free usage does not accumulate across months.

Yes, for any requests beyond the free tier. All HAQM SQS requests are chargeable, and they are billed at the same rate.

No. Batch operations (SendMessageBatch, DeleteMessageBatch, and ChangeMessageVisibilityBatch) all cost the same as other HAQM SQS requests. By grouping messages into batches, you can reduce your HAQM SQS costs.

There are no initial fees to begin using HAQM SQS. At the end of the month, your credit card will be automatically charged for the month’s usage.

You can view your charges for the current billing period at any time on the AWS website:

1. Log into your AWS account.
2. Under Your Web Services Account, select Account Activity.

You can tag and track your queues for resource and cost management using cost allocation tags. A tag is a metadata label comprised of a key-value pair. For example, you can tag your queues by cost center and then categorize and track your costs based on these cost centers.

For more information, see Tagging Your HAQM SQS Queues in the HAQM SQS Developer Guide. For more information on cost allocation tagging of AWS resources, see Using Cost Allocation Tags in the AWS Billing and Cost Management User Guide.

Except as noted otherwise, our prices don't include any applicable taxes and duties such as VAT or applicable sales tax.

For customers with a Japanese billing address, the use of AWS in any region is subject to Japanese Consumption Tax. For more information, see the HAQM Web Services Consumption Tax FAQ.

Yes. You can make your applications more flexible and scalable by using HAQM SQS with compute services such as HAQM EC2, HAQM Elastic Container Service (ECS), and AWS Lambda, as well as with storage and database services such as HAQM Simple Storage Service (HAQM S3) and HAQM DynamoDB.

You can access HAQM SQS using the AWS Management Console, which helps you create HAQM SQS queues and send messages easily.

HAQM SQS also provides a web services API. It is also integrated with the AWS SDKs, allowing you to work in the programming language of your choice.

For information on message queue operations, see the HAQM SQS API Reference.

Only an AWS account owner (or an AWS account that the account owner has delegated rights to) can perform operations on an HAQM SQS message queue.

Yes. You can take advantage of the scale, low cost, and high availability of HAQM SQS without the worry and high overhead of running your own JMS cluster. 

HAQM provides the HAQM SQS Java Messaging Library that implements the JMS 1.1 specification and uses HAQM SQS as the JMS provider. For more information, see Using JMS with HAQM SQS in the HAQM SQS Developer Guide.

Java Message Service (JMS)

All messages have a global unique ID that HAQM SQS returns when the message is delivered to the message queue. The ID isn’t required to perform any further actions on the message, but it is useful for tracking the receipt of a particular message in the message queue.

When you receive a message from the message queue, the response includes a receipt handle that you must provide when deleting the message.

For more information, see Queue and Message Identifiers in the HAQM SQS Developer Guide.

In HAQM SQS, you can use the API or the console to configure dead letter queues, which receive messages from other source queues. When configuring a dead letter queue, you are required to set appropriate permissions for the dead letter queue redrive using RedriveAllowPolicy.

RedriveAllowPolicy includes the parameters for the dead-letter queue redrive permission. It defines which source queues can specify dead-letter queues as a JSON object.

Once you make a dead letter queue, it receives messages after a maximum number of processing attempts cannot be completed. You can use dead letter queues to isolate messages that can't be processed for later analysis.

For more information, see Using HAQM SQS Dead Letter Queues in the HAQM SQS Developer Guide.

The visibility timeout is a period of time during which HAQM SQS prevents other consuming components from receiving and processing a message. For more information, see Visibility Timeout in the HAQM SQS Developer Guide.

Yes. An HAQM SQS message can contain up to 10 metadata attributes. You can use message attributes to separate the body of a message from the metadata that describes it. This helps process and store information with greater speed and efficiency because your applications don't have to inspect an entire message before understanding how to process it.

HAQM SQS message attributes take the form of name-type-value triples. The supported types include string, binary, and number (including integer, floating-point, and double). For more information, see Using HAQM SQS Message Attributes in the HAQM SQS Developer Guide.

To determine the time-in-queue value, you can request the SentTimestamp attribute when receiving a message. Subtracting that value from the current time results in the time-in-queue value.

Typical latencies for SendMessage, ReceiveMessage, and DeleteMessage API requests are in the tens or low hundreds of milliseconds.

When the AWS account ID is not available (for example, when an anonymous user sends a message), HAQM SQS provides the IP address.

HAQM SQS long polling is a way to retrieve messages from your HAQM SQS queues. While the regular short polling returns immediately, even if the message queue being polled is empty, long polling doesn’t return a response until a message arrives in the message queue, or the long poll times out.

Long polling makes it inexpensive to retrieve messages from your HAQM SQS queue as soon as the messages are available. Using long polling might reduce the cost of using SQS, because you can reduce the number of empty receives. For more information, see HAQM SQS Long Polling in the HAQM SQS Developer Guide.

No. Long-polling ReceiveMessage calls are billed exactly the same as short-polling ReceiveMessage calls.

In almost all cases, HAQM SQS long polling is preferable to short polling. Long-polling requests let your queue consumers receive messages as soon as they arrive in your queue while reducing the number of empty ReceiveMessageResponse instances returned.

HAQM SQS long polling results in higher performance at reduced cost in the majority of use cases. However, if your application expects an immediate response from a ReceiveMessage call, you might not be able to take advantage of long polling without some modifications to your application.

For example, if your application uses a single thread to poll multiple queues, switching from short polling to long polling will probably not work, because the single thread will wait for the long-poll timeout on any empty queues, delaying the processing of any queues that might contain messages.

In such an application, it is a good practice to use a single thread to process only one queue, allowing the application to take advantage of the benefits that HAQM SQS long polling provides.

In general, you should use a maximum of 20 seconds for a long-poll timeout. Because higher long-poll timeout values reduce the number of empty ReceiveMessageResponse instances returned, try to set your long-poll timeout as high as possible.

If the 20-second maximum doesn't work for your application (see the example in the previous question), set a shorter long-poll timeout, as low as 1 second.

All AWS SDKs work with 20-second long polls by default. If you don't use an AWS SDK to access HAQM SQS, or if you configured your AWS SDK to specifically have a shorter timeout, you might need to modify your HAQM SQS client to allow longer requests or to use a shorter long-poll timeout.

The HAQMSQSBufferedAsyncClient for Java provides an implementation of the HAQMSQSAsyncClient interface and adds several important features:

• Automatic batching of multiple SendMessage, DeleteMessage, or ChangeMessageVisibility requests without any required changes to the application
• Prefetching of messages into a local buffer that allows your application to immediately process messages from HAQM SQS without waiting for the messages to be retrieved

Working together, automatic batching and prefetching increase the throughput and reduce the latency of your application while reducing your costs by making fewer HAQM SQS requests. For more information, see Client-Side Buffering and Request Batching in the HAQM SQS Developer Guide.

You can download the HAQMSQSBufferedAsyncClient as part of the AWS SDK for Java.

No. The HAQMSQSBufferedAsyncClient for Java is implemented as a drop-in replacement for the existing HAQMSQSAsyncClient.

If you update your application to use the latest AWS SDK and change your client to use the HAQMSQSBufferedAsyncClient for Java instead of the HAQMSQSAsyncClient, your application will receive the added benefits of automatic batching and prefetching.

1. In the HAQM SQS console, select an HAQM SQS standard queue.
2. Under Queue Actions, select Subscribe Queue to SNS Topic from the drop-down list.
3. In the dialog box, select the topic from the Choose a Topic drop-down list, and click Subscribe.

For more information, see Subscribing a Queue to an HAQM SNS Topic in the HAQM SQS Developer Guide.

Yes. You can delete all messages in an HAQM SQS message queue using the PurgeQueue action.

When you purge a message queue, all the messages previously sent to the message queue are deleted. Because your message queue and its attributes remain, there is no need to reconfigure the message queue; you can continue using it.

To delete only specific messages, use the DeleteMessage or DeleteMessageBatch actions.

For more information, see this Tutorial: Purging Messages from an HAQM SQS Queue.

FIFO queues are available in all AWS regions where HAQM SQS is available. See here for details on HAQM SQS region availability.

FIFO queues are designed to never introduce duplicate messages. However, your message producer might introduce duplicates in certain scenarios: for example, if the producer sends a message, does not receive a response, and then resends the same message. HAQM SQS APIs provide deduplication functionality that prevents your message producer from sending duplicates. Any duplicates introduced by the message producer are removed within a 5-minute deduplication interval.

For standard queues, you might occasionally receive a duplicate copy of a message (at-least-once delivery). If you use a standard queue, you must design your applications to be idempotent (that is, they must not be affected adversely when processing the same message more than once).

For more information, see Exactly-Once Processing in the HAQM SQS Developer Guide.

No. HAQM SQS standard queues (the new name for existing queues) remain unchanged, and you can still create standard queues. These queues continue to provide the highest scalability and throughput; however, you will not get ordering guarantees and duplicates might occur.

Standard queues are appropriate for many scenarios, such as work distribution with multiple idempotent consumers.

No. You must choose the queue type when you create it. However, it is possible to move to a FIFO queue. For more information, see Moving From a Standard Queue to a FIFO Queue in the HAQM SQS Developer Guide.

To take advantage of FIFO queue functionality, you must use the latest AWS SDK.

FIFO queues use the same API actions as standard queues, and the mechanics for receiving and deleting messages and changing the visibility timeout are the same. However, when sending messages, you must specify a message group ID. For more information, see FIFO Queue Logic in the HAQM SQS Developer Guide.

Some AWS or external services that send notifications to HAQM SQS might not be compatible with FIFO queues, despite allowing you to set a FIFO queue as a target.

The following features of AWS services aren't currently compatible with FIFO queues:

• Auto Scaling Lifecycle Hooks
• AWS IoT Rule Actions
• AWS Lambda Dead Letter Queues

For information about compatibility of other services with FIFO queues, see your service documentation.

FIFO queues aren't currently compatible with the HAQM SQS Buffered Asynchronous Client.

FIFO queues are compatible with the HAQM SQS Extended Client Library for Java and the HAQM SQS Java Message Service (JMS) client.

FIFO queues support all metrics that standard queues support. For FIFO queues, all approximate metrics return accurate counts. For example, the following AWS CloudWatch metrics are supported:

• ApproximateNumberOfMessagesDelayed - The number of messages in the queue that are delayed and not available for reading immediately.
• ApproximateNumberOfMessagesVisible - The number of messages available for retrieval from the queue.
• ApproximateNumberOfMessagesNotVisible - The number of messages that are in flight (sent to a client but have not yet been deleted or have not yet reached the end of their visibility window).

Messages are grouped into distinct, ordered "bundles" within a FIFO queue. For each message group ID, all messages are sent and received in strict order. However, messages with different message group ID values might be sent and received out of order. You must associate a message group ID with a message. If you don't provide a message group ID, the action fails.

If multiple hosts (or different threads on the same host) send messages with the same message group ID are sent to a FIFO queue, HAQM SQS delivers the messages in the order in which they arrive for processing. To ensure that HAQM SQS preserves the order in which messages are sent and received, ensure that multiple senders send each message with a unique message group ID.

For more information, see FIFO Queue Logic in the HAQM SQS Developer Guide.

Yes. One or more producers can send messages to a FIFO queue. Messages are stored in the order that they were successfully received by HAQM SQS.

If multiple producers send messages in parallel, without waiting for the success response from SendMessage or SendMessageBatch actions, the order between producers might not be preserved. The response of SendMessage or SendMessageBatch actions contains the final ordering sequence that FIFO queues use to place messages in the queue, so your multiple-parallel-producer code can determine the final order of messages in the queue.

By design, HAQM SQS FIFO queues don't serve messages from the same message group to more than one consumer at a time. However, if your FIFO queue has multiple message groups, you can take advantage of parallel consumers, allowing HAQM SQS to serve messages from different message groups to different consumers.

By default, FIFO queues support up to 3,000 messages per second with batching or up to 300 messages per second (300 send, receive, or delete operations per second) without batching. If you require higher throughput, you can enable high throughput mode for FIFO on the HAQM SQS console, which will support up to 70,000 messages per second without batching and even higher with batching. For a detailed breakdown of FIFO high throughput mode quotas per region, please see AWS Documentation.

The name of a FIFO queue must end with the .fifo suffix. The suffix counts towards the 80-character queue name limits. To determine whether a queue is FIFO, you can check whether the queue name ends with the suffix.

HAQM SQS stores all message queues and messages within a single, highly-available AWS region with multiple redundant Availability Zones (AZs), so that no single computer, network, or AZ failure can make messages inaccessible. For more information, see Regions and Availability Zones in the HAQM Relational Database Service User Guide.

Authentication mechanisms ensure that messages stored in HAQM SQS message queues are secured against unauthorized access. You can control who can send messages to a message queue and who can receive messages from a message queue. For additional security, you can build your application to encrypt messages before they are placed in a message queue.

HAQM SQS has its own resource-based permissions system that uses policies written in the same language as AWS Identity and Access Management (IAM) policies: for example, you can use variables, just like in IAM policies. For more information, see HAQM SQS Policy Examples in the HAQM SQS Developer Guide.

HAQM SQS supports the HTTP over SSL (HTTPS) and Transport Layer Security (TLS) protocols. Most clients can automatically negotiate to use newer versions of TLS without any code or configuration change. HAQM SQS supports versions 1.0, 1.1, and 1.2 of the Transport Layer Security (TLS) protocol in all regions.

When HAQM SQS returns a message to you, the message stays in the message queue whether or not you actually receive the message. You're responsible for deleting the message and the deletion request acknowledges that you’re done processing the message.

If you don’t delete the message, HAQM SQS will deliver it again when it receives another receive request. For more information, see Visibility Timeout in the HAQM SQS Developer Guide.

No. FIFO queues never introduce duplicate messages.

For standard queues, under rare circumstances, you might receive a previously-deleted message a second time. 

When you issue a DeleteMessage request on a previously-deleted message, HAQM SQS returns a success response.

SSE lets you transmit sensitive data in encrypted queues. SSE protects the contents of messages in HAQM SQS queues using keys managed in the AWS Key Management Service (AWS KMS). SSE encrypts messages as soon as HAQM SQS receives them. The messages are stored in encrypted form and HAQM SQS decrypts messages only when they are sent to an authorized consumer.

For more information, see Protecting Data Using Server-Side Encryption (SSE) and AWS KMS in the HAQM SQS Developer Guide.

Yes. To do this you need to enable compatibility between AWS services (eg. HAQM CloudWatch Events, HAQM S3, and HAQM SNS), and Queues with SSE. For detailed instructions see the Compatibility section of the SQS Developer Guide.  

Server-side encryption (SSE) for HAQM SQS is available in all AWS regions where HAQM SQS is available. See here for details on HAQM SQS region availability.

To enable SSE for a new or existing queue using the HAQM SQS API, specify the customer master key (CMK) ID: the alias, alias ARN, key ID, or key ARN of an AWS-managed CMK or a custom CMK by setting the KmsMasterKeyId attribute of the CreateQueue or SetQueueAttributes action.

For detailed instructions, see Creating an HAQM SQS Queue with Server-Side Encryption and Configuring Server-Side Encryption (SSE) for an Existing HAQM SQS Queue in the HAQM SQS Developer Guide.

Both standard and FIFO queues support SSE.

Before you can use SSE, you must configure AWS KMS key policies to allow encryption of queues and encryption and decryption of messages.

To enable SSE for a queue, you can use the AWS-managed customer master key (CMK) for HAQM SQS or a custom CMK. For more information, see Customer Master Keys in the AWS KMS Developer Guide.

To send messages to an encrypted queue, the producer must have the kms:GenerateDataKey and kms:Decrypt permissions for the CMK.

To receive messages from an encrypted queue, the consumer must have the kms:Decrypt permission for any CMK that is used to encrypt the messages in the specified queue. If the queue acts as a dead letter queue , the consumer must also have the kms:Decrypt permission for any CMK that is used to encrypt the messages in the source queue.

For more information, see What Permissions Do I Need to Use SSE? in the HAQM SQS Developer Guide.

There are no additional HAQM SQS charges. However, there are charges for calls from HAQM SQS to AWS KMS. For more information, see AWS Key Management Service Pricing.

The charges for using AWS KMS depend on the data key reuse period configured for your queues. For more information, see How Do I Estimate My AWS KMS Usage Costs? in the HAQM SQS Developer Guide.

SSE encrypts the body of a message in an HAQM SQS queue.

SSE doesn't encrypt the following components:

• Queue metadata (queue name and attributes)
• Message metadata (message ID, timestamp, and attributes)
• Per-queue metrics

HAQM SQS generates data keys based on the AWS-managed customer master key (CMK) for HAQM SQS or a custom CMK to provide envelope encryption and decryption of messages for a configurable time period (from 1 minute to 24 hours).

For more information, see What Does SSE for HAQM SQS Encrypt? in the HAQM SQS Developer Guide.

SSE uses the AES-GCM 256 algorithm.

SSE doesn't limit the throughput (TPS) of HAQM SQS. The number of SSE queues that you can create is limited by the following:

• The data key reuse period (1 minute to 24 hours).
• The AWS KMS per-account quota (100 TPS by default).
• The number of IAM users or accounts that access queues.
• The existence of a large backlog (a larger backlog requires more AWS KMS calls).

For example, let's assume the following:

• You set your data key reuse period to 5 minutes (300 seconds).
• Your KMS account has a default AWS KMS TPS quota of 100 TPS.
• You use an HAQM SQS queue without a backlog and with 1 IAM user for SendMessage or ReceiveMessage actions to all queues.

In this case, you can calculate the theoretical maximum of HAQM SQS queues with SSE as follows:

300 seconds × 100 TPS / 1 IAM user = 30,000 queues

To predict costs and better understand your AWS bill, you might want to know how often HAQM SQS uses your CMK.

Note: Although the following formula can give you a very good idea of expected costs, actual costs might be higher because of the distributed nature of HAQM SQS.

To calculate the number of API requests per queue (R), use the following formula:

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

B is the billing period (in seconds)

D is the data key reuse period (in seconds)

P is the number of producing principals that send to the HAQM SQS queue.

C is the number of consuming principals that receive from the HAQM SQS queue.

Important: In general, producing principals incur double the cost of consuming principals. For more information, see How Does the Data Key Reuse Period Work? in the HAQM SQS Developer Guide.

If the producer and consumer have different IAM users, the cost increases.

For more information, see How Do I Estimate My AWS KMS Usage Costs? in the HAQM SQS Developer Guide

Yes. HAQM SQS is PCI DSS Level 1 certified. For more information, see PCI Compliance.

Yes, AWS has expanded its HIPAA compliance program to include HAQM SQS as a HIPAA Eligible Service. If you have an executed Business Associate Agreement (BAA) with AWS, you can use HAQM SQS to build your HIPAA-compliant applications, store messages in transit, and transmit messages—including messages containing protected health information (PHI).

If you already have an executed BAA with AWS, you can start using HAQM SQS right away. If you don't have a BAA or have other questions about using AWS for your HIPAA-compliant applications, contact us for more information.

Note: If you prefer not to transfer PHI through HAQM SQS (or if you have messages larger than 256 KB), you can alternatively send HAQM SQS message payloads through HAQM S3 using the HAQM SQS Extended Client Library for Java (HAQM S3 is a HIPAA Eligible Service, excluding the use of HAQM S3 Transfer Acceleration). For more information, see Using the HAQM SQS Extended Client Library for Java in the HAQM SQS Developer Guide.

Longer message retention provides greater flexibility to allow for longer intervals between message production and consumption.

You can configure the HAQM SQS message retention period to a value from 1 minute to 14 days. The default is 4 days. Once the message retention quota is reached, your messages are automatically deleted.

To configure the message retention period, set the MessageRetentionPeriod attribute using the console or using the Distributiveness method. Use this attribute to specify the number of seconds a message will be retained in HAQM SQS.

You can use the MessageRetentionPeriod attribute to set the message retention period from 60 seconds (1 minute) to 1,209,600 seconds (14 days). For more information on working with this message attribute, see the HAQM SQS API Reference .

To configure the maximum message size, use the console or the SetQueueAttributes method to set the MaximumMessageSize attribute. This attribute specifies the number of bytes that an HAQM SQS message can contain. Set this attribute to a value between 1,024 bytes (1 KB), and 262,144 bytes (256 KB). For more information, see Using HAQM SQS Message Attributes in the HAQM SQS Developer Guide.

To send messages larger than 256 KB, use the HAQM SQS Extended Client Library for Java . This library lets you send an HAQM SQS message that contains a reference to a message payload in HAQM S3 that can be as large as 2 GB.

HAQM SQS messages can contain up to 256 KB of text data, including XML, JSON and unformatted text. The following Unicode characters are accepted:

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

For more information, see the XML 1.0 Specification .

A single HAQM SQS message queue can contain an unlimited number of messages. However, there is a quota of 120,000 for the number of inflight messages for a standard queue and 120,000 for a FIFO queue. Messages are inflight after they have been received from the queue by a consuming component, but have not yet been deleted from the queue.

You can create any number of message queues.

Queue names are limited to 80 characters.

You can use alphanumeric characters, hyphens (-), and underscores (_).

A message queue's name must be unique within an AWS account and region. You can reuse a message queue's name after you delete the message queue.

You can associate an access policy statement (and specify the permissions granted) with the message queue to be shared. HAQM SQS provides APIs for creating and managing access policy statements:

• AddPermission
• RemovePermission
• SetQueueAttributes
• GetQueueAttributes

For more information, see the HAQM SQS API Reference.

The message queue owner pays for shared message queue access.

The HAQM SQS API uses the AWS account number to identify AWS users.

To share a message queue with an AWS user, provide the full URL from the message queue you want to share. The CreateQueue and ListQueues operations return this URL in their responses.

Yes. You can configure an access policy that allows anonymous users to access a message queue.

The permissions API provides an interface for sharing access to a message queue to developers. However, this API cannot allow conditional access or more advanced use cases.

The SetQueueAttributes operation supports the full access policy language. For example, you can use the policy language to restrict access to a message queue by IP address and time of day. For more information, see HAQM SQS Policy Examples in the HAQM SQS Developer Guide.

For service region availability, see the AWS Global Infrastructure Region Table.

No. Each HAQM SQS message queue is independent within each region.

HAQM SQS pricing is the same for all regions, except China (Beijing). For more information, see HAQM SQS Pricing.

You can transfer data between HAQM SQS and HAQM EC2 or AWS Lambda free of charge within a single region.

When you transfer data between HAQM SQS and HAQM EC2 or AWS Lambda in different regions, you will be charged the normal data transfer rate. For more information, see HAQM SQS Pricing.

A dead-letter queue is an HAQM SQS queue to which a source queue can send messages if the source queue’s consumer application is unable to consume the messages successfully. Dead-letter queues make it easier for you to handle message consumption failures and manage the life cycle of unconsumed messages. You can configure an alarm for any messages delivered to a dead-letter queue, examine logs for exceptions that might have caused them to be delivered to the queue, and analyze message contents to diagnose consumer application issues. Once you recover your consumer application, you can redrive the messages from your dead-letter queue to the source queue.

When you create your source queue, HAQM SQS allows you to specify a dead-letter queue (DLQ) and the condition under which SQS should move messages to the DLQ. The condition is the number of times a consumer can receive a message from the queue, defined as maxReceiveCount. This configuration of a dead-letter queue with a source queue and the maxReceiveCount is known as the redrive policy. When the ReceiveCount for a message exceeds the maxReceiveCount for a queue, HAQM SQS is designed to move the message to a dead-letter queue (with its original message ID). For example, if the source queue has a redrive policy with maxReceiveCount set to five, and the consumer of the source queue receives a message six times without successfully consuming it, SQS moves the message to the dead-letter queue.

The redrive policy manages the first half of the life cycle of unconsumed messages by moving them from a source queue to a dead-letter queue. Now the dead-letter queue redrive to source queue efficiently completes the cycle by moving those messages back to their source queue, as shown below.

First, it allows you to investigate a sample of messages available in the dead-letter queue by showing message attributes and related metadata. Then, once you have investigated the messages, you can move them back to their source queue(s). You can also select the redrive velocity to configure the rate at which HAQM SQS will move the messages from the dead-letter queue to the source queue.

Yes. However, you must use a FIFO dead letter queue with a FIFO queue. (Similarly, you can use only a standard dead letter queue with a standard queue.)