Amazon SQS Reviews

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.

Positive

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.

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.

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. 

In the past, we used Amazon SQS to synchronize distribution systems, particularly for logistics and managing customer orders. It served as a framework for asynchronous connection between different parts of our application, handling around ninety thousand messages per hour with multiple workers processing them. Currently, we use it to integrate with the logistic departments of the automotive industry, suppliers, and carmakers.

Amazon SQS provides an asynchronous glue that is essential for our system. It helps us scale efficiently and manage the workflow with either high parallelization or queued processing. The maturity and stability of the service contribute significantly to our integration projects.

The most valuable features of Amazon SQS are its scalability, availability, and maturity as an AWS service. It works consistently and is economical under a standard non-FIFO model. The dead letter queue feature is also advantageous, allowing for enhanced resilience and retry policies.

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.

I have used Amazon SQS since 2010.

The stability is excellent. We have never faced any corrupted messages or downtime attributed to AWS. It is a straightforward and simple service.

The scalability of Amazon SQS is one of its strengths. It can handle various message volumes and worker processing requirements efficiently. Its integration with other AWS services like SNS or EventBridge and Lambda is a key.

I have not contacted Amazon's support team for Amazon SQS in years. The primary responsibility for issues often lies within our application rather than the service itself. Quotas are generally not a problem, though AWS is more cautious with quotas due to their expanding user base.

Positive

In Europe, RabbitMQ and other MQ services were used. The transition to Amazon SQS was made easier by its similarities, making it a preferred choice.

The initial setup of Amazon SQS is straightforward and can be quickly managed from the console. Issues may arise related to message quotas on newly setup AWS accounts, however, they are usually not significant and AWS support reacts swiftly to quota increase requests.

The pricing is good, although improvements in FIFO pricing could be advantageous. Using standard queues is affordable, but a more progressive pricing strategy for greater volumes is advisable to enable light load users.

People sometimes prefer Apache Kafka in enterprise setups due to its compatibility features. However, Amazon SQS is more economic for some high performance workloads. And you don't need to pay extra for managing Apache Kafka.

I would recommend this product as it is a basic essential in event-driven architecture design. It is cost-effective, reliable, and straightforward.

I'd rate the solution nine out of ten.

The most common use case for Amazon SQS is decoupling an application. Instead of having one monolithic service with a timeout of about a minute, and if there are too many requests at the same time that might fail, the application can be decoupled by deconstructing the monolith into its own microservices. A JSON interface is designed, which has an agreed-upon schema, and in front of each microservice, a queue is installed where messages are sent. It's a common pattern, especially in the development of software solutions that run on an EKS cluster, to use Amazon SQS to enable asynchronous processes.

Amazon SQS has significantly helped by allowing applications to run asynchronously. It enables services to scale by ensuring requests do not overwhelm servers, which can be particularly useful for tasks like generating long videos using AI. By employing SQS, insights into queue lengths are available, and resources can be scaled appropriately without managing a task database.

The most valuable feature of Amazon SQS is its scalability. Particularly when using RabbitMQ as a queue, many services can subscribe and independently pull messages from it, aiding load balancing. 

It is also beneficial for ensuring asynchronous operations, such as generating and processing lengthy tasks, without blocking requests.

Another feature, the first-in-first-out queue, ensures order in processing messages, which is crucial for applications like financial transactions.

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.

I have been working professionally with SQS for at least two and a half years and developing applications for about a year and a half in my spare time.

There are no performance or stability issues with Amazon SQS. It is phenomenally stable.

Amazon SQS is highly scalable. It allows services to subscribe to queues and handle message loads independently, ensuring that applications can scale as needed without overburdening the system.

I worked with AWS Kafka. Although I set up Kafka, I do not recall the details well and cannot discuss it further.

The initial setup of Amazon SQS is very straightforward, whether you're creating a queue through the AWS CDK, Boto3, the CLI, or using Terraform.

Amazon SQS is very cost-effective. A certain amount of messages per month are free, and only after exceeding this do charges incur, which are based on a per-million message rate. The service itself is quite cheap unless it involves a massive scale.

Before choosing SQS, I did not evaluate any other options because if a cloud provides a service, it often fulfills the requirements well. Amazon web services are known for their comprehensive solutions.

I would recommend Amazon SQS to others because it is a cloud-native service with full-time support and extensive documentation. There aren't many issues with it, and updates are generally not disruptive. However, the challenge lies in managing the decoupled nature of the application, which can complicate operations.

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.

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.