Amazon SQS Reviews

Our primary use case was to connect SQS with S3 so that we could count the number of downloads of our objects within S3. However, we had to switch to using the CloudFront URL instead. We initially used SQS to help in decoupling and to find the number of messages coming in.

The most valuable feature is the ability to decouple components. It is beneficial because our architecture usually has different components and the communication aspect of components is crucial. SQS is effective in decoupling or buffering to prevent overwhelming components in case there is increased traffic, aiding in the management of communication loads. By design, it is scalable, and its SAGRAM feature helps to lower loads during surges.

The primary issue was the increase in costs due to frequent polling for messages. The cost became an issue, leading us to consider other solutions.

We used SQS for a project, however, due to cost concerns, we had to switch to a different solution.

We did not encounter any challenges with the stability of SQS. The only challenge we faced was with the cost.

SQS is scalable. It is designed to handle varying loads well, with the SAGRAM feature assisting in managing and lowering loads during increased traffic.

Understanding the service requires prior knowledge, and we could not just use it directly. We needed to first understand the service itself for deployment.

The main challenge we encountered was related to the cost increase due to frequent polling for messages.

We switched from using SQS to CloudFront, as CloudFront was a better fit for our needs and was more cost-effective.

I would recommend SQS to others depending on their use case. 

Overall, I would rate SQS a nine out of ten.

We use Amazon SQS for triggering other resources, such as Lambda, API Gateway, EC2 instances, and various tasks running inside different compute services. 

It's primarily used for queuing different tasks, alerting, and monitoring pipelines. Additionally, it is used for message distribution.

All Amazon Web Services resources are easy to configure. The configuration process is straightforward, making it easy to use. It's easy to get started with it.

There is room for improvement in all the resources. That said, it's currently pretty good. For example, improvement is needed in terms of troubleshooting and logs, as there is not much logging in SNS and SQS services. More specific logs would be helpful, as it's hard to troubleshoot without them.

I've been using it for quite a while, about four years.

Stability-wise, it's pretty good. It doesn't really break down, but it does freeze sometimes. However, the freezing is not that significant.

It is very scalable. Scalability-wise, I would give it a ten out of ten.

Personally, it's pretty good because, from my workplace, we receive special support. However, for the general public, it's not as good. The more you pay, the more support you get.

Neutral

I previously used both cloud and on-prem solutions. Of course, cloud is better than on-prem since there's no maintenance, but it comes at a cost.

It is expensive. The cloud is expensive.

I would recommend this product to bigger businesses.

I'd rate the solution nine out of ten.

Amazon SQS is used when the need arises to publish a message. This could be a natural message or a message to a service to execute a process. The consumer, which is usually a service, will catch it, consume it, and execute the process based on the message that is passed to the queue. This describes the general concept of our use case.

Amazon SQS helps process all the requests that come from the clients, and it enhances the client-side performance, making it faster. It ensures data is processed correctly with no data loss, especially with the Dead Letter Queue (DLQ) feature. This feature ensures that even if a message is not processed properly, it can be reprocessed later on.

The dead-letter queue is very helpful in maintaining the messages that come into the queue. It allows the consumer to process it again later when it is available, preventing the queue from being overlooked when the same message has been retried more than the specified attempts.

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.

I have been working with Amazon Suite for a couple of months now.

The stability of Amazon SQS is really high, and I would rate it a nine out of ten. The stability ensures the data is processed correctly without any loss.

The scalability is pretty good, and I rate it around nine out of ten. It is possible to configure Amazon SQS to have several queues that may serve the same line but are divided into several consumers.

Currently, I haven't communicated with technical support for Amazon SQS since I haven't faced any specific problems requiring their support.

Positive

There was no previous solution before Amazon SQS.

The initial setup was mostly straightforward. I would rate my experience with it a nine. The problem was not with the configuration but with understanding the AWS implementation.

Only I was needed for the deployment since it was straightforward.

Amazon SQS contributes greatly to processing client requests, improves client-side performance, and maintains a high level of satisfaction for the consumers.

The pricing is rather affordable, and I would rate it at two to three out of ten, with ten being the most expensive.

I haven't evaluated alternate solutions for the use case of SQS.

I'd advise new users to look at the documentation and try to understand the basic queue and the implementation in Amazon SQS.

I'd rate the solution nine out of ten.

We use Amazon SQS for an asynchronous solution. We receive data through API calls, which we process and log to our database. To avoid doing this during the API call, we offload it to Amazon SQS. We have a service that monitors Amazon SQS to process the data in the background.

It helps with high volumes of data on the API, preventing us from doing too much processing for every API call. By using Amazon SQS as a holding area, we process data in the background, which does not affect the user experience on the front end.

Amazon SQS is reliable, with no issues to date. It handles its load well, and the graphs for monitoring are good. It offers durable storage, reducing data loss. The messages remain until processed and deleted, with a retention period of a maximum of 14 days.

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.

I have used Amazon SQS for about two years now.

Amazon SQS is stable and handles its load effectively.

While Amazon SQS itself is not scalable, it supports scalability. It acts as a holding area between high volumes of messages, allowing us to scale and receive more messages without worrying about whether Amazon SQS can handle it.

I have not needed to escalate any issues to Amazon SQS customer support. It has been reliable without any need for assistance.

Positive

I have used Azure queues and Azure services. Azure allowed me to see the messages in the queue, which I found beneficial. However, Amazon SQS can store more messages at a time than Azure.

The initial setup was fairly straightforward.

From a programming and reliability standpoint, Amazon SQS is a good part of the infrastructure. It saves a lot of headaches and helps maintain system integrity.

The pricing and licensing details are abstracted from me, so I have not looked into them.

I have considered Azure queues and Azure services.

Using queues in an infrastructure is a good idea for certain scenarios. If you're going to use AWS and need queues, then Amazon SQS is the solution. I would recommend its use if you have simple enough needs.

I'd rate the solution eight out of ten.

I mainly use SQS to buffer tasks or jobs, so that our system can handle spikes in traffic without losing messages or slowing down processing.

Amazon SQS (Simple Queue Service) has significantly improved the way our organization manages asynchronous communication between different components of our system. Before adopting SQS, our services were tightly coupled, meaning that if one service experienced a delay or failure, it would directly impact other parts of the system. This led to bottlenecks, failed processes, and a lot of manual intervention to recover lost or delayed tasks. Introducing SQS allowed us to decouple these services, enabling each component to operate independently while still reliably communicating with others.

One of the most noticeable improvements has been in system reliability. By placing messages in SQS queues, we can ensure that tasks are not lost even if a downstream service is temporarily unavailable. The visibility timeout and retry mechanisms built into SQS have been particularly valuable. They have reduced the risk of message duplication or loss and have allowed us to handle failures gracefully without human intervention. Additionally, dead-letter queues have been instrumental in tracking and troubleshooting messages that repeatedly fail, improving our operational efficiency and reducing the time spent debugging errors.

SQS has also had a major impact on scalability. Our system now handles varying workloads more efficiently because messages can be queued and processed at a pace that matches downstream processing capabilities. During peak traffic, requests no longer overwhelm our services, as SQS buffers them effectively. This has not only improved performance but has also made our infrastructure more resilient to spikes in demand.

The features of Amazon SQS that I have found most valuable are message durability, decoupling, dead-letter queues, and visibility timeouts.

1. Message durability ensures that messages are never lost, even if downstream services fail temporarily. This reliability is critical for maintaining business processes without manual intervention.

2. Decoupling of services has been a game-changer. By placing a queue between components, we can scale, update, or maintain individual services independently without affecting the overall system. This reduces bottlenecks and simplifies architecture.

3. Dead letter Queues are incredibly useful for error handling. They allow us to capture and analyze messages that fail repeatedly, helping us troubleshoot issues efficiently without impacting other processes.

A few points are there which can be improve the product a lot.

1. Message Ordering: Standard queues don’t guarantee order, FIFO queues have throughput limits. Better handling of high-volume ordered messages would help.

2. Real-Time Streaming: SQS is not designed for instant analytics or event streaming, faster propagation would be valuable.

3. Monitoring & Debugging: More built-in tools for tracing message flow and identifying bottlenecks could simplify operations.

I have been using Amazon SQS for 4 years.

The solution is working fine. Whenever there is some issue around it, we look into it.  Sometimes, there are issues with its important sensors. Also, there are issues with the data center.

I rate the solution’s stability an eight or nine out of ten.

There are three or four users, but multiple instances are connected this way between different applications.

I rate the solution’s scalability a ten out of ten.

Customer support is very bad. There's no tech support from the AWS side. If you want it, you must pay a lot of money, which is 2,000 dollars. They have a lot of customers. They have an open application and use a support team. If you're willing to pay that much, something significant is happening with your application. There's no direct connection if a small customer wants to get some information from AWS.

Negative

I have been using Amazon SQS for three to four years.

The initial setup is easy. It depends on the time limit for setting up the queues, but whatever standard time is defined should be sufficient.

The solution costs 200 dollars. We don't manage it if we don't use any queues.

Initially, we didn't have any code. Our lead engineers had the most knowledge about our system. We decided to pursue a customized design due to cost concerns. We soon realized that we could not focus on our product because we were constantly distracted by tasks such as deployments and managing scalability. That's why we decided to transition to SQS fully. SQS provides scalability and fixes related issues. Whenever we require a set of messages, we need to set them up in our system, and SQS takes care of the rest. The keys are functioning perfectly fine for now.

Overall, I rate the solution a ten out of ten.

In our system, we have millions of users, and for certain actions, we need to send millions of messages, which Amazon SQS handles smoothly without any problems. It serves as a communication line between different applications or services. I use it to send messages between separate systems since we have multiple services built in a microservice architecture. These distributed services communicate with each other using SQS to send messages.

Amazon SQS handles a high volume of messages smoothly, without any problems, allowing efficient communication between services in our system.

The most valuable features include the ability to handle a huge number of messages and the presence of a dead letter queue. If any messages are missed from a service, they will go to the dead letter queue, allowing us to handle these cases. It's also a distributed queue, which is perfect for our system because we deal with large numbers of messages. Additionally, it provides data security, as failed messages go to the dead letter queue where they can be handled later.

I have a problem with Logstash when searching logs. The search should be more user-friendly, allowing me to search for a longer period of time and return results faster. This is my problem with AWS when searching the logs using Logstash.

I have been working with SQS for many years because it's a main component in our system. In one project, I worked with CloudFormation for around two months. My experience with CloudFormation was about a year and a half ago, as we built it one time and rarely updated the stack.

I haven't encountered any stability issues while using Amazon SQS.

The scalability is excellent. Amazon SQS can handle millions of messages smoothly and without issues.

I'm not directly involved in communication with AWS technical support; this is typically handled by the DevOps team.

Positive

Before Amazon SQS, the company used Kafka. SQS was implemented, possibly because it is scalable by itself and doesn't require extra effort from developers or cloud personnel to handle scalability and queue size.

The initial setup is straightforward. The documentation is clear, allowing anyone to read it in ten minutes and start using the solution. There are detailed developer documents available, which are useful for understanding how it works and its technical details.

The cost of AWS services, including SQS, can become high as the system scales. When handling a high volume or scalable system, the price increases and this might be a problem.

For me, no other message queue solutions have been used besides Amazon SQS.

For users considering Amazon SQS, they should consider their budget, whether it is low or high, as pricing can be a concern.

I'd rate the solution ten out of ten.

The solution is used within our company's services, specifically within our microservices. One of the major reasons we use the tool is for retries and different flows. We work closely with e-commerce websites. Whenever we place an order, and if it fails for some reason, we use Amazon SQS to handle the retries or dead-letter queues to ensure that whatever didn't get acknowledged can be retried and completed. We use it mainly for retries.

I think the tool is very reliable. With the dead-letter queues, we can ensure even if a third-party service or an e-commerce website over which we have no control goes down for some time, we can make sure that our workflows remain unaffected and, eventually, we have reached the state where we expect to be. We probably use Amazon SQS in almost all of our microservices, and there are plenty of them, more than a hundred. It is pretty easy to use and do testing on Amazon SQS. It is pretty easy to integrate any new use case or service, and it is easy to sort of manage. AWS makes it very easy to manage and change the resource requirements for a particular Amazon SQS queue. The tool is pretty easy to use.

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.

I have been using Amazon SQS for around two years. I am just a user of the solution.

I would definitely say it is a very stable product.

Most of the back-end developers in my company either use it or have used it maybe once a month. I would say there are 200 to 300 people who use the tool.

I have contacted the technical support for the solution, but it was not specifically for Amazon SQS.

Speaking about the product's initial setup phase, I would say that we have some layers of abstraction on top of AWS Management Console, which allows us to specify the different resource requirements for a particularly new Amazon SQS queue in our own service, which then calls the AWS console APIs internally. It is relatively pretty easy to use the tool.

The solution is deployed using AWS cloud services.

Compared to the other options and based on what I have heard, Amazon SQS is relatively more expensive, but it is not insanely expensive.

I am not sure how Amazon SQS message delay functionality enhances our company's data processing workflow. We do use it for a lot of data processing, but I am not entirely sure about the use of the message delay functionality in the tool.

I would say it is an easy-to-use tool for beginners.

I rate the tool a nine to ten out of ten.

The tool I use to transform and move data can read the entries from Amazon SQS. For example, to start some workflow orchestration, it checks Amazon SQS, reads new messages from it, and then runs some transformation. My responsibility was setting up the new SQS, setting up the right policies, adding some text, and allowing communication.

It's very quick and easy to build or set up Amazon SQS. It's a very stable solution, and we have never faced any downtime issues.

Sending or receiving messages takes some time, and it could be quicker.

I have been using Amazon SQS for one year.

I rate the solution ten out of ten for stability.

Around 500 users are using the solution in our organization.

I rate Amazon SQS ten out of ten for scalability.

The solution’s initial setup is straightforward.

Beginners can very easily set up Amazon SQS. It requires just a few clicks and then some permissions. The solution can be installed in 15 minutes.

Amazon SQS is moderately priced.

Users need to check the number of messages. Since the solution works on a pay-as-you-go model, it could be expensive if the number of messages is very large.

Overall, I rate Amazon SQS a nine out of ten.