Amazon SQS Reviews

Amazon SQS is used when the need arises to publish a message. This could be a natural message or a message to a service to execute a process. The consumer, which is usually a service, will catch it, consume it, and execute the process based on the message that is passed to the queue. This describes the general concept of our use case.

Amazon SQS helps process all the requests that come from the clients, and it enhances the client-side performance, making it faster. It ensures data is processed correctly with no data loss, especially with the Dead Letter Queue (DLQ) feature. This feature ensures that even if a message is not processed properly, it can be reprocessed later on.

The dead-letter queue is very helpful in maintaining the messages that come into the queue. It allows the consumer to process it again later when it is available, preventing the queue from being overlooked when the same message has been retried more than the specified attempts.

There could be improvements in the UI for security and scalability. Initially, I struggled to understand the scalability and get the general gist of how it works, but over time, it became clearer.

I have been working with Amazon Suite for a couple of months now.

The stability of Amazon SQS is really high, and I would rate it a nine out of ten. The stability ensures the data is processed correctly without any loss.

The scalability is pretty good, and I rate it around nine out of ten. It is possible to configure Amazon SQS to have several queues that may serve the same line but are divided into several consumers.

Currently, I haven't communicated with technical support for Amazon SQS since I haven't faced any specific problems requiring their support.

Positive

There was no previous solution before Amazon SQS.

The initial setup was mostly straightforward. I would rate my experience with it a nine. The problem was not with the configuration but with understanding the AWS implementation.

Only I was needed for the deployment since it was straightforward.

Amazon SQS contributes greatly to processing client requests, improves client-side performance, and maintains a high level of satisfaction for the consumers.

The pricing is rather affordable, and I would rate it at two to three out of ten, with ten being the most expensive.

I haven't evaluated alternate solutions for the use case of SQS.

I'd advise new users to look at the documentation and try to understand the basic queue and the implementation in Amazon SQS.

I'd rate the solution nine 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.

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.

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.

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.

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.

I use Amazon SQS for notification services.

It allows for easier management of notifications as it serves as a listener with various protocols like HTTPS.

Amazon SQS provides faster search through indexing via OpenSearch.

Packages sometimes have delays in dropping, indicating reliability issues.

I have been using it whenever a notification service was needed, which is approximately six and a half years.

There are occasional reliability issues where packages are delayed.

There is a need for better congestion tools, and Kafka is suggested as an alternative in the market today.

I have never contacted their support team.

Neutral

I was a developer, so we never contacted the support team directly.

I don't know about pricing.

Kafka is used a lot in the market today for notification services.

AWS subscription includes the deployment of the tool along with other services, making it comprehensive under one device.

I'd rate the solution seven out of ten.