Amazon SQS Reviews

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.

Private Cloud

Amazon Web Services (AWS)

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. 

Public Cloud

Amazon Web Services (AWS)

The primary use case of this solution is for collecting event data for analytic purposes.

In our case, when a user selects a function in our app, the information is collected. Analytics is performed on the data to determine the functionalities that clients use the most. 

Additionally, the data can tell us the most popular service demands such that resources can be assigned accordingly.

Documentation of this solution can be improved. Sometimes, the images in the document are from older versions.
 

I have been using this solution for three years.

We have never had a problem with the stability of the solution.

The solution is easy to scale and cost-effective.

The profile management of this solution is difficult to set up. 

However, after the initial setup, it is easy to deploy, maintain, and test.

The security of a cloud solution is very important and attention must be given to profile management, key generation, and key protection.

Public Cloud

Amazon Web Services (AWS)

As an IT company, we develop various solutions and products for our clients. This particular item is utilized as a component of a comprehensive solution for specific customer needs across various industries.

Amazon SQS is not a complex solution, we mainly use it for its primary purpose. It's an integral part of our application's workflow.

I appreciate that Amazon SQS is fully integrated with Amazon and can be accessed through normal functions or serverless functions, making it very user-friendly. Additionally, the features are comparable to those of other solutions.

As a company that uses IBM solutions, it's difficult to compare Amazon SQS to other solutions. We have been using IBM solutions for a long time and they are very mature in integration and queuing. In my role as an integration manager, I can say that Amazon SQS is designed primarily for use within the Amazon ecosystem and does not have the same level of functionality as IBM MQ or other similar products. It has limited connectivity options and does not easily integrate with legacy systems.

I have been using Amazon SQS for approximately two years.

Amazon SQS is stable.

I rate the stability of Amazon SQS a nine out of ten.

Amazon SQS is scalable. It is not suitable for many use cases. It is suitable for cloud applications but it's not suitable for on-premises or hybrid.

I rate the scalability of Amazon SQS a seven out of ten.

The components are simple in Amazon SQS. The components are not complex to need support. I did not use the support.

I rate Amazon SQS a six out of ten.

SQS is very stable, and it has lots of features.

There are some issues with SQS's transaction queue regarding knowing if something has been received.

SQS is very stable.

Amazon's technical support could be more responsive.

Neutral

SQS's pricing is very good - I would rate it nine out of ten.

I would give SQS a rating of nine out of ten.

I primarily use Amazon SQS for asynchronous messaging. It is part of our distributed system design, where we use it for asynchronous communication by posting a message in SQS, which another microservice will consume. Additionally, if our system cannot handle incoming traffic, one system collects data and puts it in SQS to be consumed without losing any message.

The features of Amazon SQS that I find most valuable include its data retention capabilities and message durability. The retention of data is crucial, as other systems like RabbitMQ or ActiveMQ require management. Furthermore, if there's a failure in the system after consuming a message, SQS's settings ensure the message is not deleted until confirmation. Additionally, generating FIFO and standard queues based on use cases is a helpful feature.

The retention period for messages could be improved. Currently, messages are retained for four or seven days. It would be beneficial if there was a provision to configure and retain messages for longer than a week.

I have been using Amazon SQS for a long time, since around 2017, which would make it almost eight to nine years now.

The deployment process is straightforward. Once we inform our infrastructure team about the type of queue and configurations needed, they set it up. It is a task that can be completed within minutes.

The stability of Amazon SQS is very high. I've faced challenges with other solutions like RabbitMQ, ActiveMQ, and Kafka, which required extensive maintainability. With Amazon SQS, such maintenance is not needed, making it more reliable and secure.

Amazon SQS is highly scalable, automatically managing itself based on the load. We don't need to focus on managing it, and it efficiently supports peak workloads without any concerns.

Although I haven't interacted much with the technical support team, I rate their service as nine out of ten. There are different tech tiers depending on the support you have, and they meet their tasks effectively.

Positive

I used RabbitMQ, ActiveMQ, and Kafka before switching to Amazon SQS. There was a lot of maintainability with those solutions, and there were high chances of data loss if something went wrong. Data is crucial, and Amazon SQS provides better reliability.

The initial setup of Amazon SQS is very easy, rated at a ten. The interface is simple, and depending on the user's experience, it can be set up within a couple of hours.

The setup can be done single-handedly, making it efficient for small teams. Amazon SQS is self-maintained, requiring no additional personnel for maintenance.

Using Amazon SQS has led to increased productivity and reduced man-hour costs. Resources can focus on their primary tasks without worrying about managing the messaging service.

Amazon SQS is cost-effective. On a scale of one to ten, where one is very cheap, I would rate the pricing as one.

Before settling on Amazon SQS, I used RabbitMQ, ActiveMQ, and Kafka.

Overall, I would rate Amazon SQS as ten out of ten. It efficiently manages asynchronous communication and integrates well with other AWS services, resulting in excellent performance.

Public Cloud

Amazon Web Services (AWS)