Amazon SQS Reviews

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 used SQS for the Kapolei system to ensure that certain tasks were executed precisely once. The first-in, first-out (FIFO) capability was a great feature for us. Additionally, its redundancy out of the box meant we didn't have to worry about missing messages. It provided peace of mind and automatically instilled trust, relieving us of any concerns.

When you have millions of messages, it can get quite tender. Initially, Amazon SQS's maximum payload size wasn't sufficient for our needs. However, we found a workaround by splitting the payload into smaller chunks and only providing the URL within the SQL structure.

I have been using Amazon SQS for five years.

I rate the solution’s stability a nine out of ten.

The solution is scalable, so we didn't need to care about it. We encountered no glitches or bugs.

I rate the solution’s scalability a ten out of ten.

We were utilizing business support, which is relatively costly compared to other vendors. However, each time we reached out, the service was quite satisfactory.

Positive

The solution is easy to deploy and to configure. The implementation, including our application side, takes less than four hours. It was really quick.

The installation was handled by one person. That one person spent four hours working on it. We had prior knowledge of SQS. So, it was about trusting the installation and configuration process rather than figuring out how the system releases.

I rate the initial setup a ten out of ten, where one is difficult, and ten is easy.

The solution has a monthly subscription, which costs around 22 dollars.

One person is enough for the solution's maintenance.

We don't have to maintain our tooling system, which was quite flaky. We had problems with high availability, and when we covered the below balance of the Reddit cluster, we sometimes encountered cases where the job was executed twice.

Overall, I rate the solution a ten out of ten.

The product has excellent documentation for its services. It provides information on how to use it and its current availability. Users can refer to the documentation to understand its features and build their services accordingly.

The solution is easy to set up. You don't have to worry about scaling, etc. If the number of licenses increases, you don't have to worry about it. The Amazon SQS will take care of it. If you're doing it alone, you must take care of everything.

Support could be improved.

I have been using Amazon SQS for 3 to 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.

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.

In our system, we have millions of users, and for certain actions, we need to send millions of messages, which Amazon SQS handles smoothly without any problems. It serves as a communication line between different applications or services. I use it to send messages between separate systems since we have multiple services built in a microservice architecture. These distributed services communicate with each other using SQS to send messages.

Amazon SQS handles a high volume of messages smoothly, without any problems, allowing efficient communication between services in our system.

The most valuable features include the ability to handle a huge number of messages and the presence of a dead letter queue. If any messages are missed from a service, they will go to the dead letter queue, allowing us to handle these cases. It's also a distributed queue, which is perfect for our system because we deal with large numbers of messages. Additionally, it provides data security, as failed messages go to the dead letter queue where they can be handled later.

I have a problem with Logstash when searching logs. The search should be more user-friendly, allowing me to search for a longer period of time and return results faster. This is my problem with AWS when searching the logs using Logstash.

I have been working with SQS for many years because it's a main component in our system. In one project, I worked with CloudFormation for around two months. My experience with CloudFormation was about a year and a half ago, as we built it one time and rarely updated the stack.

I haven't encountered any stability issues while using Amazon SQS.

The scalability is excellent. Amazon SQS can handle millions of messages smoothly and without issues.

I'm not directly involved in communication with AWS technical support; this is typically handled by the DevOps team.

Positive

Before Amazon SQS, the company used Kafka. SQS was implemented, possibly because it is scalable by itself and doesn't require extra effort from developers or cloud personnel to handle scalability and queue size.

The initial setup is straightforward. The documentation is clear, allowing anyone to read it in ten minutes and start using the solution. There are detailed developer documents available, which are useful for understanding how it works and its technical details.

The cost of AWS services, including SQS, can become high as the system scales. When handling a high volume or scalable system, the price increases and this might be a problem.

For me, no other message queue solutions have been used besides Amazon SQS.

For users considering Amazon SQS, they should consider their budget, whether it is low or high, as pricing can be a concern.

I'd 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 Amazon SQS for an asynchronous solution. We receive data through API calls, which we process and log to our database. To avoid doing this during the API call, we offload it to Amazon SQS. We have a service that monitors Amazon SQS to process the data in the background.

It helps with high volumes of data on the API, preventing us from doing too much processing for every API call. By using Amazon SQS as a holding area, we process data in the background, which does not affect the user experience on the front end.

Amazon SQS is reliable, with no issues to date. It handles its load well, and the graphs for monitoring are good. It offers durable storage, reducing data loss. The messages remain until processed and deleted, with a retention period of a maximum of 14 days.

It would be beneficial to have the ability to peek at messages currently in Amazon SQS without needing to monitor incoming messages. Additionally, when using Azure, I could look at messages while they were there. Such a feature would be useful in Amazon SQS as well.

I have used Amazon SQS for about two years now.

Amazon SQS is stable and handles its load effectively.

While Amazon SQS itself is not scalable, it supports scalability. It acts as a holding area between high volumes of messages, allowing us to scale and receive more messages without worrying about whether Amazon SQS can handle it.

I have not needed to escalate any issues to Amazon SQS customer support. It has been reliable without any need for assistance.

Positive

I have used Azure queues and Azure services. Azure allowed me to see the messages in the queue, which I found beneficial. However, Amazon SQS can store more messages at a time than Azure.

The initial setup was fairly straightforward.

From a programming and reliability standpoint, Amazon SQS is a good part of the infrastructure. It saves a lot of headaches and helps maintain system integrity.

The pricing and licensing details are abstracted from me, so I have not looked into them.

I have considered Azure queues and Azure services.

Using queues in an infrastructure is a good idea for certain scenarios. If you're going to use AWS and need queues, then Amazon SQS is the solution. I would recommend its use if you have simple enough needs.

I'd rate the solution eight out of ten.

We have recently started using Amazon SQS and we are in the R&D phase. We want to see how resilient the solution is. We use Amazon SQS for integration purposes between our different applications.

The most valuable feature of Amazon SQS is the interface.

I have been using Amazon SQS for approximately 

Amazon SQS is stable from the usage that we have had so far.

The scalability of the solution is good. We can scale it to different regions and deploy it within Amazon AWS.

I have not used the support from Amazon SQS.

We previously were using ActiveMQ and we had to manage it manually on our on-premise server.  We have seen that a lot of times the messaging queuing service stopped responding or we had to restart the server or the services themselves on the server. This is the reason we are switching to Amazon SQS.

Amazon SQS is well integrated with Amazon AWS which is helpful if it is needed to be scaled. ActiveMQ is open-source and free to use but it is not resilient or dependable. It stops working at times and you have to manage the server yourself. Amazon SQS is serverless, you don't have to manage the server, you only have to manage the permissions.

The initial setup of Amazon SQS is in the middle range of difficulty. You need to learn Amazon AWS and know how to navigate, create resources, and structures, and provide rules.

The pricing of Amazon SQS is reasonable. The first million requests are free every month, and after, it's cost 40 cents for every million requests. There are not any additional fees.

This is a free-to-use solution for somebody who wants to do 1 million requests, and this is sufficient for any application at a small organization. It's cost-effective, reliable, and easily scalable.

I rate Amazon SQS an eight out of ten.