Amazon SQS Reviews

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.

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.

We use Amazon SQS for notifying, queuing servers, queuing messages, and notifying the people for alerting systems. We have been using Amazon SQS in one of the projects for queuing messages. For alerting, we have production support where SQS is mostly used.

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

We had no issues with the solution’s stability.

Amazon SQS is highly scalable, both horizontally and vertically. We don't see any scalability issues with the solution. More than 500 users are using the solution in our organization.

I created a support ticket one or two years ago. The technical support team responded promptly and helped us with the issues. I am very much happy with the solution’s technical support. They are knowledgeable, understand our problem easily, and then figure out the issues.

On a scale from one to ten, where one is bad and ten is excellent, I rate the solution’s technical support nine and a half out of ten.

Positive

I've previously used Kafka, which is similar to Amazon SQS but not exactly the same feature-wise. Kafka has different storage functionality, which we don't have in Amazon SQS. I'd say Amazon SQS is the best solution for messaging service.

The solution's initial setup is easy. Compared to other complex services in AWS, Amazon SQS is simple to configure. It is also simple to provision through the console and through Terraform.

Compared to EC2 and other services, Amazon SQS' pricing is cheaper.

Anyone with a basic cloud experience can use the solution. I would recommend Amazon SQS for any support project that needs message queuing and faster and more reliable processing.

Overall, I 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. 

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.

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.