Senior DevOps Engineer | AWS | Kubernetes | Terraform | CICD | Cyber Security Specialist at a tech services company with 11-50 employees
Real User
Top 5
Oct 7, 2024
A feature I would like to see in Amazon SQS is the ability to view the content of messages without removing them from the queue. Enhanced filtering on the messages would be beneficial, as currently one has to pull all messages out, filter the right one by code, and then re-insert the remaining messages. This solution is not effective with the FIFO queue.
IT Specialist at a financial services firm with 51-200 employees
Real User
Top 10
Apr 7, 2025
The retention period for messages could be improved. Currently, messages are retained for four or seven days. It would be beneficial if there was a provision to configure and retain messages for longer than a week.
AWS Academy Accredited Instructor - ACF & CCA at APU
Real User
Top 5
Jan 3, 2025
AWS provides another messaging service, which is fine for certain purposes. SQS meets the cloud messaging workload requirements. However, combining the features of both products could be an easier option for me. Currently, it mainly supports HTTP, HTTPS communication protocols and lacks support for others. In hybrid workloads where existing apps use different messaging protocols, AWS directs me to another service. Combining features into a single product would ease my adaptation.
AWS Architect at a computer software company with 501-1,000 employees
Real User
Top 5
Nov 25, 2024
A primary area of improvement for Amazon SQS is the message size limitation, which is currently restricted to 256 kilobytes per message. If this could be increased, it would benefit many use cases. Additionally, SQS uses a pull-based mechanism rather than a push-based one, which requires consumers to poll for new messages.
There is room for improvement in handling large-scale data. For significant data bursts, Kinesis is a better option than SQS. The SQS could enhance its performance in managing large volumes of data more efficiently.
There is room for improvement in the pricing, especially for the FIFO model. Although it's a great feature, I feel it is expensive for entry to mid-volumes. A better pricing policy with scaled pricing for higher volumes would be beneficial, as it would ease adoption for developers with light workloads. Additionally, SQS could enhance compatibility with enterprise software by integrating built-in connectors, similar to those available for Apache Kafka.
There could be improvements in the UI for security and scalability. Initially, I struggled to understand the scalability and get the general gist of how it works, but over time, it became clearer.
It would be beneficial to have the ability to peek at messages currently in Amazon SQS without needing to monitor incoming messages. Additionally, when using Azure, I could look at messages while they were there. Such a feature would be useful in Amazon SQS as well.
For Amazon SQS, in particular, I think AWS Management Console has shortcomings. AWS Management Console should be a better pluggable option to help users with some integrations. For example, we had Apache Kafka somewhere, and if we want to switch to Amazon SQS and if it is on Amazon EKS, then we should be able to switch to Amazon SQS more seamlessly, so it is an area that can be improved.
Web Solution Architect at a comms service provider with 1-10 employees
Real User
Top 10
May 24, 2024
When you have millions of messages, it can get quite tender. Initially, Amazon SQS's maximum payload size wasn't sufficient for our needs. However, we found a workaround by splitting the payload into smaller chunks and only providing the URL within the SQL structure.
Recently, I encountered an issue where I couldn't send a message to multiple recipients. If two subscribers are subscribed to the same channel, the message can only be sent to either one of them, not both. I believe this is an area that needs improvement. So, I cannot send a message to multiple people simultaneously. It can only be sent to one recipient.
Data & Analytics Architect at BM&FBOVESPA SA Bolsa de Valores Mercadorias e Futu
Real User
Jun 1, 2023
There is room for improvement in the performance system. Sometimes, we have to switch to another component similar to SQS because the patching tool for SQS is relatively slow for us. Recently, we had a necessity for encryption and a stronger security strategy. We faced difficulties in providing this with scalability. So, I'm not sure about the specific feature. There are good and new features related to security, secret chaining, and threat security that can be improved in the future for our clients and close customers.
Senior IT Architect (Architecture and Solutions Unit) at a tech services company with 1,001-5,000 employees
Real User
Jan 11, 2023
As a company that uses IBM solutions, it's difficult to compare Amazon SQS to other solutions. We have been using IBM solutions for a long time and they are very mature in integration and queuing. In my role as an integration manager, I can say that Amazon SQS is designed primarily for use within the Amazon ecosystem and does not have the same level of functionality as IBM MQ or other similar products. It has limited connectivity options and does not easily integrate with legacy systems.
Solutions Architect at a tech services company with 501-1,000 employees
Real User
Dec 6, 2022
If you require event-driven development, there might be advanced queuing requirements that SQS can't offer. I don't think it supports transactions although I'm no expert around that. The biggest issue is likely to be cost estimations because you might get a huge bill if you're not careful.
The solution is not available on-premises so that rules out any customers looking for the messaging solution on-premises. The price is on the high end and has room for improvement.
Their telemetry could be better. Whene we see something going wrong, we need to find out the telemetry separately. That's fine if it's just one case, however, if we have 100 services and have many queues to manage and you need to understand what's going on in your system, there are not enough tools that are available. We have to move all data and then go through a service vendor. It would be easier to have a dashboard that allows us to see everything and manage everything since we have so many queues. We need to have more power to observe all that's happening. We need to rely on plugins to assist. The solution needs to be more of an all-in-one solution.
Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS eliminates the complexity and overhead associated with managing and operating message oriented middleware, and empowers developers to focus on differentiating work. Using SQS, you can send, store, and receive messages between software components at any volume, without losing messages or requiring other...
A feature I would like to see in Amazon SQS is the ability to view the content of messages without removing them from the queue. Enhanced filtering on the messages would be beneficial, as currently one has to pull all messages out, filter the right one by code, and then re-insert the remaining messages. This solution is not effective with the FIFO queue.
There is nothing I can remember that I would want as new features for Amazon SQS.
The retention period for messages could be improved. Currently, messages are retained for four or seven days. It would be beneficial if there was a provision to configure and retain messages for longer than a week.
AWS provides another messaging service, which is fine for certain purposes. SQS meets the cloud messaging workload requirements. However, combining the features of both products could be an easier option for me. Currently, it mainly supports HTTP, HTTPS communication protocols and lacks support for others. In hybrid workloads where existing apps use different messaging protocols, AWS directs me to another service. Combining features into a single product would ease my adaptation.
A primary area of improvement for Amazon SQS is the message size limitation, which is currently restricted to 256 kilobytes per message. If this could be increased, it would benefit many use cases. Additionally, SQS uses a pull-based mechanism rather than a push-based one, which requires consumers to poll for new messages.
There is room for improvement in handling large-scale data. For significant data bursts, Kinesis is a better option than SQS. The SQS could enhance its performance in managing large volumes of data more efficiently.
Packages sometimes have delays in dropping, indicating reliability issues.
There is room for improvement in the pricing, especially for the FIFO model. Although it's a great feature, I feel it is expensive for entry to mid-volumes. A better pricing policy with scaled pricing for higher volumes would be beneficial, as it would ease adoption for developers with light workloads. Additionally, SQS could enhance compatibility with enterprise software by integrating built-in connectors, similar to those available for Apache Kafka.
There could be improvements in the UI for security and scalability. Initially, I struggled to understand the scalability and get the general gist of how it works, but over time, it became clearer.
It would be beneficial to have the ability to peek at messages currently in Amazon SQS without needing to monitor incoming messages. Additionally, when using Azure, I could look at messages while they were there. Such a feature would be useful in Amazon SQS as well.
For Amazon SQS, in particular, I think AWS Management Console has shortcomings. AWS Management Console should be a better pluggable option to help users with some integrations. For example, we had Apache Kafka somewhere, and if we want to switch to Amazon SQS and if it is on Amazon EKS, then we should be able to switch to Amazon SQS more seamlessly, so it is an area that can be improved.
When you have millions of messages, it can get quite tender. Initially, Amazon SQS's maximum payload size wasn't sufficient for our needs. However, we found a workaround by splitting the payload into smaller chunks and only providing the URL within the SQL structure.
Support could be improved.
Sending or receiving messages takes some time, and it could be quicker.
Recently, I encountered an issue where I couldn't send a message to multiple recipients. If two subscribers are subscribed to the same channel, the message can only be sent to either one of them, not both. I believe this is an area that needs improvement. So, I cannot send a message to multiple people simultaneously. It can only be sent to one recipient.
There is room for improvement in the performance system. Sometimes, we have to switch to another component similar to SQS because the patching tool for SQS is relatively slow for us. Recently, we had a necessity for encryption and a stronger security strategy. We faced difficulties in providing this with scalability. So, I'm not sure about the specific feature. There are good and new features related to security, secret chaining, and threat security that can be improved in the future for our clients and close customers.
There are some issues with SQS's transaction queue regarding knowing if something has been received.
As a company that uses IBM solutions, it's difficult to compare Amazon SQS to other solutions. We have been using IBM solutions for a long time and they are very mature in integration and queuing. In my role as an integration manager, I can say that Amazon SQS is designed primarily for use within the Amazon ecosystem and does not have the same level of functionality as IBM MQ or other similar products. It has limited connectivity options and does not easily integrate with legacy systems.
If you require event-driven development, there might be advanced queuing requirements that SQS can't offer. I don't think it supports transactions although I'm no expert around that. The biggest issue is likely to be cost estimations because you might get a huge bill if you're not careful.
The solution is not available on-premises so that rules out any customers looking for the messaging solution on-premises. The price is on the high end and has room for improvement.
Their telemetry could be better. Whene we see something going wrong, we need to find out the telemetry separately. That's fine if it's just one case, however, if we have 100 services and have many queues to manage and you need to understand what's going on in your system, there are not enough tools that are available. We have to move all data and then go through a service vendor. It would be easier to have a dashboard that allows us to see everything and manage everything since we have so many queues. We need to have more power to observe all that's happening. We need to rely on plugins to assist. The solution needs to be more of an all-in-one solution.
Documentation of this solution can be improved. Sometimes, the images in the document are from older versions.