Amazon SQS Reviews

I have been heavily using Amazon SQS for the last more than four years in serverless and decoupled solutions. 

We use it in workflows like order creation, where the order creation task is queued, allowing consumers to pull and process the information in batches. 

SQS helps in loose coupling between producers and consumers and is valuable for storing failed record processing through DLQs.

One of the most valuable features of Amazon SQS is its ability to handle large-scale data with millions of records per queue. The scale it manages is quite impressive. 

Additionally, features such as message retention up to 14 days are impactful, as they allow for the processing of messages if consumer systems are slow or unavailable. Integration capabilities with services like EC2, Lambda, EventBridge, and SNS for a fan-out pattern further enhance its functionality.

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.

I have been using Amazon SQS for more than four years.

Amazon SQS is very stable. It was one of the first services launched by AWS, indicating its mature and reliable nature.

Amazon SQS can handle an increased load and scale vertically without any issues. However, one should be aware of possible message duplicates and sequence changes when handling multiple producers and consumers.

No questions have been escalated to technical support.

The initial setup of Amazon SQS is straightforward, requiring a few minutes if the policies are clearly understood. Proper permissions need to be set in both the SQS policy and resource-based policy to ensure successful message delivery and consumption.

SQS has proven its value in handling sudden spikes of active users and maintaining message integrity. By using DLQs and SNS fan-out methods, workflows are not disrupted by failures. These methods also allow for processing messages later if they're initially unsuccessful.

Amazon SQS offers a generous free tier, beyond which it remains very cost-effective. The cost per million messages is less than a dollar, making it an economical choice.

I would recommend Amazon SQS, especially for designing decoupled systems where one component doesn't depend on another. It's an optimal choice for high availability and reliably handling queuing mechanisms. In terms of size and scalability, SQS excels.

I'd rate the solution nine out of ten.

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 it for event-driven messaging and workflows.

We use SNS as the publisher, and our procurement service subscribes to those events using SQS.

In the past, we relied on time-based or batch-based processes to send data between services on-premises. With SQS, we can trigger actions based on real-time changes in business processes, improving reliability.

Moreover, SQS can grow with our needs.

SQS message delay feature and redundant retention policies helped us to avoid replaying events due to errors and ensure our messages are processed reliably.

We use CloudWatch for monitoring.

It's easy to implement and cost-effective.

The visibility timeout feature is very nice. We use the visibility timeout in our internal processes to ensure that if a message fails to process, it becomes available for other consumers after a set period.

The current visibility timeout of five minutes is okay. However, I'd like to explore the possibility of extending it for specific use cases.

I have been using it for five to six years now. We (my company) use SQS quite extensively, and it has been quite a good service till now.

It is a stable product.

It is a scalable product. We can handle 10,000 events easily. 

We have a lot of end users using it in my company. We have around 2,000 end users using it. We have multiple locations. 

I have used RabbitMQ. 

The initial setup is very straightforward. It's a simple checkbox-kinda process. 

It is not difficult to maintain it. It is very easy. Overall, it is a very straightforward solution. 

It does a very good job. The cost was the main issue for us.

It's quite expensive. 

It's a great solution. I would recommend using it. 

Overall, I would rate the solution a nine out of ten. I've used it, and it seems to be a solid solution.

The product has excellent documentation for its services. It provides information on how to use it and its current availability. Users can refer to the documentation to understand its features and build their services accordingly.

The solution is easy to set up. You don't have to worry about scaling, etc. If the number of licenses increases, you don't have to worry about it. The Amazon SQS will take care of it. If you're doing it alone, you must take care of everything.

Support could be improved.

I have been using Amazon SQS for 3 to 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.

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.

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 tool helps to process events in a microservices cluster. We use it in the financial industry. 

I like how we can subscribe to multiple topics in Amazon SQS. It's also much simpler and quicker to set up than other solutions. It also supports patterns like Kafka and RapidMQ's fan-out pattern but with easier implementation.

Amazon SQS is costly. I think there could be improvements in how it facilitates comparisons between different AWS products. A calculator would be helpful. The calculator for Kafka is based on factors like throughput or storage used in the last month. In contrast, the calculator for Amazon SQS is based on the number of transactions processed. These different approaches make it challenging to compare them directly. I suggest AWS provide a straightforward calculator where I can input one aspect, and it calculates costs for multiple solutions. 

I have been working with the product for two years. 

I rate the product's stability a ten out of ten. 

I rate the solution's scalability a ten out of ten. My company has 100 users. 

I rate the solution's deployment ease an eight out of ten. Its deployment is generally quick, but it involves considerations around security, which are essential for DevOps teams. Typically, it takes about one week for deployment. However, if I handled it for my project personally, the deployment time would likely be shorter.

I rate the tool's pricing a nine out of ten. 

We manage and monitor our Amazon SQS performance and costs using DataOps. It helps us with intuitive data. Transitioning from our legacy tools to Amazon SQS would be beneficial because it's simple to set up and can serve as a pilot for our approach.

I rate the overall product an eight out of ten.