Amazon SQS Reviews

Positive

I am using multiple services such as AWS Lambda, S3, EC2, ECS, and the SNS SQS services, along with QuickSight reports and some of the VPC concepts. 

We have an email notification system integrated with Spring Branch. Once a batch job completes, SNS and SQS trigger events, sending notification emails to users. These notifications are based on user lists fetched from the database.

The most valuable features of the solution are AWS Lambda services, ECS, and QuickSight reports, which are beneficial for data analysis. SQS is also appreciated for messaging and querying needs.

There is room for improvement by making use of Kafka services to create more flexible data streams.

I have been using the solution for four years.

Initially, there were some stability issues. However, later on, there were not many.

Initially, writing scripts for ECS deployment using Docker and Kubernetes required effort, especially in addressing deployment steps and security vulnerabilities. 

Once the scripts were ready, deployment became straightforward.

The pricing is moderately cheaper compared to others.

I would recommend Amazon SQS to others. I'd rate it seven out of ten.

If you need a messaging service to help decouple your application, Amazon SQS would be a smart choice because it's easy to use and very easy to manage.

Amazon SQS is a simple service to use. If we compare with other solutions such as RabbitMQ for messaging, Amazon SQS is easier to use and easier to create the queue.

All AWS services are easy to use, and Amazon SQS follows this same pattern.

There is nothing I can remember that I would want as new features for Amazon SQS.

The stability of Amazon SQS is very good, as I find it to be very stable. I have no problems with using Amazon SQS.

The scalability of Amazon SQS is very good. It is very stable.

I can easily scale up or down with Amazon SQS without any issues.

The customer support team from Amazon is really good. They are always great.

Positive

I would recommend Amazon SQS to other people. On a scale of 1-10, I rate this solution a 10.

I primarily use SQL Server for messaging services, and I need to offer loose couplings. SQS is handy for offloading non-urgent tasks that can be reverted later. I use it as a queue management service for deferring processing or ensuring important messages are preserved in the queue before being processed by Lambda integrators. Lambda can pull messages from the queue, process them to completion, and then erase them, providing reliable communication.

The most valuable feature for me is the variety of queues offered, such as the standard and FIFO queues, providing reliable communication. FIFO queues ensure a message is processed once, preventing duplicate processing. This product is serverless, managed, and scalable, with benefits similar to Lambda Compute. It offers high scalability, availability, and protection against failures, eliminating my need for EC2 infrastructure for messaging processing. My campus has become cashless, with all transactions digitized and utilizing AWS for scalability. The migration to the cloud has satisfied our students, staff, and finance department, with a reduced responsibility. There are no concerns regarding the solution's cost.

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.

I started using Lambda and SQS in 2018.

It is very stable for me because it's a regional service, not dependent on a single point of failure. I would rate its availability as nine out of ten.

Peak workloads show me that SQS doesn't have scalability limits, similar to Lambda. The product scales automatically, handling peak and off-peak hours. I've never lost messages within SQS, and all message infrastructure is managed by AWS.

Positive

Proprietary protocols like GMS, AMQP, etc., were in place previously. With workloads migrated to the cloud, SQS now meets all my messaging workloads requirements.

The setup is straightforward for me, as it's HTTPS based. Communication and setup are easy, and target SDKs are available for different client frameworks. Due to its simplified deployment and SDK availability, I would rate it nine out of ten.

I am not the project owner for SQS, but I'm aware of its usage. I have not heard complaints about it from my team.

It's quite economical for me. I would say a rating of four to five out of five is appropriate, as charges are based on usage.

Overall, I'd rate it nine out of ten. The serverless stack offered by AWS provides me with good guidance. Serverless patterns from AWS need better reference. Cloud adoption will have general discussions, but more proprietary cloud frameworks should learn from serverless tech, facilitating infrastructure as code. Open-source frameworks for building serverless applications are beneficial for setting up full stack apps promptly. 

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.

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.

I am using Amazon SQS as part of my use of AWS over the past ten years. I have been leveraging it for data transitions between different systems, especially in my current project. It helps in creating different sporadic systems that can interact asynchronously.

Amazon SQS aids in facilitating the communication between systems by allowing asynchronous operations. This helps in managing systems that don't have to be in sync and can reduce costs through better management of data flow and infrastructure.

One of the most valuable features of Amazon SQS is its event-driven invocation. The ability to have different consumers interact with the queue and create systems that do not need to be synchronized is beneficial. It allows different systems to execute at their own pace but still communicate efficiently.

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.

I have been using AWS, including Amazon SQS, for the last ten years.

I have not faced stability issues with Amazon SQS. It has been reliable in my experience.

The Amazon support team is great. On the few occasions I've needed to interact with them, they were prompt and very understanding of our problems, showcasing their knowledge and troubleshooting abilities effectively.

Positive

The initial setup is not difficult. Following AWS's comprehensive documentation makes setting up SQS relatively easy.

The cost-effectiveness of AWS, including Amazon SQS, depends on usage patterns. For example, using API Gateway with Lambda instead of always-on EC2 instances, or opting for DynamoDB over more expensive database solutions, can reduce costs significantly. AWS provides multiple options for optimizing costs based on organizational needs and data requirements.

I would recommend Amazon SQS as it is a good product. However, the choice between SQS and other AWS services like Kinesis should be based on data requirements and organizational needs.

I'd rate the solution seven 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.

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.