Amazon SQS Reviews

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.

Amazon SQS is basically a queue service. Each message is treated as an event and added to a container. When a message needs to be processed, a trigger can be set.

One of the useful features is the ability to schedule a call after a certain number of messages accumulate in the container. For example, if there are ten messages in the container, you can perform a specific action.

Recently, I encountered an issue where I couldn't send a message to multiple recipients. If two subscribers are subscribed to the same channel, the message can only be sent to either one of them, not both. I believe this is an area that needs improvement.

So, I cannot send a message to multiple people simultaneously. It can only be sent to one recipient.

I've been using Amazon SQS for about six months.

Amazon SQS is not very stable. 

It does not that stable because you can't deliver the same message to two people; how can you add that feature on the AWS. So we have the option to add multiple subscribers to the same message, but it's not delivering this message to all the people at the same instant.

Amazon SQS is a scalable product. There are 30 people using Amazon SQS in our company.

Amazon SQS was easy to set up.

If you only have one job to run, I would recommend using it. However, if you need to handle multiple jobs, I would not recommend it.

Overall, I would rate the solution a five out of ten. Since it doesn't support sending the same message to multiple subscribers, it lacks usefulness in certain cases.

Generally, we use it for asynchronous communication. We have actively utilized it for the past three years. Basically, we use it to exchange events and messages when we need communication and integration in our architecture.

Amazon SQS has provided us with a better experience, better performance, and better communication in our scenario. It is a valuable tool for our needs.

There are many valuable features, such as resuming messages, high performance, first-in-first-out (FIFO) capability, message grouping, and integration with AWS Key Management Service (KMS). With SQS, we can trigger events in various cloud environments. It offers numerous benefits for us.

There is room for improvement in the performance system.  Sometimes, we have to switch to another component similar to SQS because the patching tool for SQS is relatively slow for us. 

Recently, we had a necessity for encryption and a stronger security strategy. We faced difficulties in providing this with scalability. So, I'm not sure about the specific feature. There are good and new features related to security, secret chaining, and threat security that can be improved in the future for our clients and close customers.

I have been using Amazon SQS for more than three years. I use the latest version. 

It's very stable.

Amazon SQS is a scalable solution. We have specific needs for this product currently. Generally, we are working with big data size, and Amazon SQS provides stability and the necessary features for our data reports.

So, in the future, we will continue using it in our factory and as part of our in-house solution.

The technical support is very good. We have an enterprise support model, so when we raise a ticket, we receive feedback within one hour and thirty minutes.

It is worth the investment. Generally, it's more expensive. For example, in the cloud, the initial setup may be more expensive in size and investment, but the returns are better for us. 

But, it depends on the specific case, you know, like starting small and configuring the services according to your needs. It's better for us in the cloud but varies depending on the situation.

The pricing model is pay-as-you-use. It depends on your usage and configuration. But generally, it's better. The cost benefits are better for us.

I would definitely recommend using the solution. Overall, I would rate the solution a nine out of ten.

It's a streaming application. For example, it is basically an autonomous vehicle solution for the case management side. It gives alerts and we have devices that will connect to IoT and the other service processes to provide data and then put it in a queue. 

The solution is simple to use. I like it. I don't need to do too many things. However, it is basically dependent on the vendor configuration.

It can really integrate with any other telemetry angle. It can integrate with CloudWatch and CloudWatch is configured with AWS. 

I am able to find out what's going on very easily.

The initial setup was easy.

Their telemetry could be better. Whene we see something going wrong, we need to find out the telemetry separately. That's fine if it's just one case, however, if we have 100 services and have many queues to manage and you need to understand what's going on in your system, there are not enough tools that are available. We have to move all data and then go through a service vendor. It would be easier to have a dashboard that allows us to see everything and manage everything since we have so many queues. We need to have more power to observe all that's happening. We need to rely on plugins to assist. 

The solution needs to be more of an all-in-one solution.

I've used the solution for the last three years. 

While the solution is stable, based on my long stint in IT my experience is that anything can be improved.

The solution can scale. However, you need to find your requirements to see what is being consumed or reduced to see if there are limitations you can address via configuration. 

We have 300 people using the solution. We use it daily. It is integrated with part of our overall solution.

The support hasn't been ideal. It could be better. They need better response times. Also, sometimes we deal with people who are not extremely knowledgeable. However, it is case by case. They are not consistent. There are other cloud providers that ultimately offer better services. 

Neutral

The solution is easy to implement. I'd rate it a four out of five in terms of the ease of setup. 

The setup was handled in-house. We didn't need any outside support. We have our own team that can handle it. 

A separate team handles licensing. I can't speak to any pricing. However, my understanding is that the solution is moderately priced. It's rather competitive. 

We are a customer and an end-user. 

I'd rate the solution eight out of ten.

We use the service in cloud-native event-driven integrations.

The service needs more user-friendly discoverability for self-service scenarios.

The product is stable.

I would rate the tool's scalability an eight out of ten.

The product's setup is simple. We can speed up the deployment and complete it in a few minutes if we have an AWS contract. 

I would rate the product a nine out of ten. If you are using the AWS platform, then you will find a lot of use cases for the solution.

The primary use case of this solution is to send and receive messages across applications.

Sending and receiving messages is the most valuable feature.

The solution is not available on-premises so that rules out any customers looking for the messaging solution on-premises. The price is on the high end and has room for improvement.

I have used the solution for a couple of years.

The solution is stable.

To the extent necessary, we have been able to scale the solution. We have less than 100 people using the solution.

The technical support is very good.

Positive

There is no setup just some easy configuration required.

The licensing cost is publicly available on the AWS page. Amazon SQS is quite expensive and is at the highest price point compared to other solutions.

The price is based on the number of messages sent and received.

I give the solution a nine out of ten.

For people who don't want any infrastructure and managing overhead, I recommend Amazon SQS.

This is an event-driven solution so messages go through the API gateway onto the queue and are then processed from there. We are customers of Amazon.

The biggest improvement we've seen from SQS is that our backing system is not under strain anymore and messages don't get lost because the queue is now very resilient. If our backing process goes down, the messages remain in the queue. 

There are several valuable features that SQS offers including the standard queue, the AWS interface and the quality documentation provided by AWS. The libraries that connect and manage the queues are rich in features. The visibility of the messages is great and the 256 kilobytes payload is also good. SQS improves the scalability and resilience of the solution. It's also very simple and very straightforward.

If you require event-driven development, there might be advanced queuing requirements that SQS can't offer. I don't think it supports transactions although I'm no expert around that. The biggest issue is likely to be cost estimations because you might get a huge bill if you're not careful.

I've been using this solution for a year. 

The documentation is very good so we've never had to reach out to the SQS technical support team. There's a very rich source of information around SQS.

We initially used Rabbit MQ. SQS is our first attempt at event-driven, asynchronous development. We chose to migrate our infrastructure to AWS and took on the native queuing solution that AWS supplies. It was an opportunity for us and the learning curve to get going with SQS is very low. 

Another reason we went with SQS is the zero maintenance from our point of view. The service is hosted by AWS and doesn't require IT support. 

The initial setup was reasonably straightforward. We deployed in-house and used one engineer for the process. SQS is a managed service by AWS so they carry out the maintenance. Once the solution is running, it gets used by clients who interact with the APIs. In terms of developers we have five users but the system that uses it has billions of users with accounts that get managed through SQS. To date, we've implemented it in two of our in-house projects and there will likely be more. 

Part of the reason we went for SQS is that it's a pay-as-you-use licensing model. 
In addition, they offer a significant amount of free monthly transactions before you start paying. It's possible that down the line SQS will become too expensive and we may need to look for an alternative. 

I would definitely suggest carrying out cost estimations prior to purchase because if you need it for a very high number of requests per month, the costs might be significantly higher and not worth it. In that event, it may be worth looking at ActiveMQ or RabbitMQ, where you can better control licensing costs. That said, this is a very good solution for us.

I rate this solution eight out of 10.