Amazon SQS provides scalable, reliable communication for asynchronous messaging. Supporting both standard and FIFO queues, it efficiently handles millions of messages while connecting with AWS services like Lambda and EC2.
| Product | Mindshare (%) |
|---|---|
| Amazon SQS | 5.5% |
| IBM MQ | 21.3% |
| ActiveMQ | 20.0% |
| Other | 53.2% |
| Company Size | Count |
|---|---|
| Small Business | 13 |
| Midsize Enterprise | 4 |
| Large Enterprise | 13 |
| Company Size | Count |
|---|---|
| Small Business | 110 |
| Midsize Enterprise | 80 |
| Large Enterprise | 142 |
Amazon SQS is designed for robust asynchronous messaging, facilitating event-driven architectures across applications. Its features ensure reliable microservice communication, managing retries and dead-letter queues to maintain stability. Ease of integration with services like API Gateway, Lambda, and EC2 allows users to seamlessly process large message volumes. Message durability and precise FIFO execution ensure accurate delivery. Despite its capabilities, there's room for enhancement in telemetry, cost estimation, and integration breadth. Improvements like better message handling, increased retention, and faster processing could enhance Amazon SQS's performance.
What features make Amazon SQS reliable?In industries like e-commerce, finance, and tech, Amazon SQS is vital for enabling scalable messaging and processing large volumes of transactions. Companies utilize it to build efficient event-driven architectures, ensuring their systems operate smoothly and accommodate growth demands. Its integration with AWS tools supports varied application needs, enhancing operational efficiency.
EMS, NASA, BMW, Capital One
| Author info | Rating | Review Summary |
|---|---|---|
| Senior Data & AI Engineer at Imprint | 5.0 | I find Amazon SQS easy to use, highly stable, and effortlessly scalable. It's simpler than alternatives like RabbitMQ, requires little management, and comes with great customer support. I confidently rate it a 10 and recommend it. |
| IT Specialist at a financial services firm with 51-200 employees | 5.0 | I primarily use Amazon SQS for asynchronous messaging in our distributed system. Its data retention, message durability, and queue generation features are valuable. Compared to RabbitMQ and ActiveMQ, SQS offers better reliability and reduced management overhead, enhancing productivity. |
| Senior Cloud Engineer - AWS at Bytedance | 3.5 | I have been using Amazon SQS for ten years as part of AWS for asynchronous data transitions between systems. Its event-driven invocation is valuable. However, its handling of large-scale data could improve, especially compared to Kinesis. |
| Senior Java Engineer at Centers for Medicare & Medicaid Services | 3.5 | I use AWS services like Lambda, S3, EC2, ECS, and SNS SQS for tasks like our email notification system. I find AWS Lambda, ECS, and QuickSight valuable, but I believe integrating Kafka could improve data streaming flexibility. |
| AWS Academy Accredited Instructor - ACF & CCA at APU | 4.5 | I use SQS for reliable, scalable messaging, leveraging its diverse queues and serverless design. It's very stable, with easy setup and good economy. I wish for broader protocol support and integrated features. I rate it 9/10. |
| AWS Competency Lead at trask | 4.5 | I use Amazon SQS to synchronize logistics and customer orders with its scalability, availability, and cost-effectiveness. While the FIFO pricing could improve, SQS remains a favored choice over RabbitMQ in Europe, though some prefer Apache Kafka for compatibility. |
| Senior DevOps Engineer | AWS | Kubernetes | Terraform | CICD | Cyber Security Specialist at a tech services company with 11-50 employees | 5.0 | I use Amazon SQS to decouple applications by converting monoliths into microservices, leveraging its scalability and FIFO queue for message order. However, I wish it allowed viewing message content without removing it from the queue. |
| AWS Authorized Instructor at Next Step Foundation | 4.5 | We used SQS for decoupling and its scalability, finding it stable. However, the cost of frequent polling led us to switch to CloudFront for our download counting, despite still recommending SQS for suitable use cases. |
| AWS Architect at a computer software company with 501-1,000 employees | 4.5 | I've used Amazon SQS for over four years in serverless, decoupled solutions. SQS excels in handling large data scales and integrates well with other AWS services. However, it has a message size limit and uses a pull-based system. |
| AWS Consultant at HCLTech | 4.5 | I use Amazon SQS for triggering resources and message distribution. It's easy to configure and straightforward to use. However, troubleshooting needs improvement due to limited logging. Though previously using cloud and on-prem solutions, cloud is preferable despite its cost. |
If you need a messaging service to help decouple your application, Amazon SQS would be a smart choice because it's easy to use and very easy to manage.
Amazon SQS is a simple service to use. If we compare with other solutions such as RabbitMQ for messaging, Amazon SQS is easier to use and easier to create the queue.
All AWS services are easy to use, and Amazon SQS follows this same pattern.
There is nothing I can remember that I would want as new features for Amazon SQS.
The stability of Amazon SQS is very good, as I find it to be very stable. I have no problems with using Amazon SQS.
The scalability of Amazon SQS is very good. It is very stable.
I can easily scale up or down with Amazon SQS without any issues.
The customer support team from Amazon is really good. They are always great.
Positive
I would recommend Amazon SQS to other people. On a scale of 1-10, I rate this solution a 10.
Positive
I am using Amazon SQS as part of my use of AWS over the past ten years. I have been leveraging it for data transitions between different systems, especially in my current project. It helps in creating different sporadic systems that can interact asynchronously.
Amazon SQS aids in facilitating the communication between systems by allowing asynchronous operations. This helps in managing systems that don't have to be in sync and can reduce costs through better management of data flow and infrastructure.
One of the most valuable features of Amazon SQS is its event-driven invocation. The ability to have different consumers interact with the queue and create systems that do not need to be synchronized is beneficial. It allows different systems to execute at their own pace but still communicate efficiently.
There is room for improvement in handling large-scale data. For significant data bursts, Kinesis is a better option than SQS. The SQS could enhance its performance in managing large volumes of data more efficiently.
I have not faced stability issues with Amazon SQS. It has been reliable in my experience.
The Amazon support team is great. On the few occasions I've needed to interact with them, they were prompt and very understanding of our problems, showcasing their knowledge and troubleshooting abilities effectively.
Positive
The initial setup is not difficult. Following AWS's comprehensive documentation makes setting up SQS relatively easy.
The cost-effectiveness of AWS, including Amazon SQS, depends on usage patterns. For example, using API Gateway with Lambda instead of always-on EC2 instances, or opting for DynamoDB over more expensive database solutions, can reduce costs significantly. AWS provides multiple options for optimizing costs based on organizational needs and data requirements.
I would recommend Amazon SQS as it is a good product. However, the choice between SQS and other AWS services like Kinesis should be based on data requirements and organizational needs.
I'd rate the solution seven out of ten.
I am using multiple services such as AWS Lambda, S3, EC2, ECS, and the SNS SQS services, along with QuickSight reports and some of the VPC concepts.
We have an email notification system integrated with Spring Branch. Once a batch job completes, SNS and SQS trigger events, sending notification emails to users. These notifications are based on user lists fetched from the database.
The most valuable features of the solution are AWS Lambda services, ECS, and QuickSight reports, which are beneficial for data analysis. SQS is also appreciated for messaging and querying needs.
There is room for improvement by making use of Kafka services to create more flexible data streams.
I have been using the solution for four years.
Initially, there were some stability issues. However, later on, there were not many.
Initially, writing scripts for ECS deployment using Docker and Kubernetes required effort, especially in addressing deployment steps and security vulnerabilities.
Once the scripts were ready, deployment became straightforward.
The pricing is moderately cheaper compared to others.
I would recommend Amazon SQS to others. I'd rate it seven out of ten.
I primarily use SQL Server for messaging services, and I need to offer loose couplings. SQS is handy for offloading non-urgent tasks that can be reverted later. I use it as a queue management service for deferring processing or ensuring important messages are preserved in the queue before being processed by Lambda integrators. Lambda can pull messages from the queue, process them to completion, and then erase them, providing reliable communication.
The most valuable feature for me is the variety of queues offered, such as the standard and FIFO queues, providing reliable communication. FIFO queues ensure a message is processed once, preventing duplicate processing. This product is serverless, managed, and scalable, with benefits similar to Lambda Compute. It offers high scalability, availability, and protection against failures, eliminating my need for EC2 infrastructure for messaging processing. My campus has become cashless, with all transactions digitized and utilizing AWS for scalability. The migration to the cloud has satisfied our students, staff, and finance department, with a reduced responsibility. There are no concerns regarding the solution's cost.
AWS provides another messaging service, which is fine for certain purposes. SQS meets the cloud messaging workload requirements. However, combining the features of both products could be an easier option for me. Currently, it mainly supports HTTP, HTTPS communication protocols and lacks support for others. In hybrid workloads where existing apps use different messaging protocols, AWS directs me to another service. Combining features into a single product would ease my adaptation.
I started using Lambda and SQS in 2018.
It is very stable for me because it's a regional service, not dependent on a single point of failure. I would rate its availability as nine out of ten.
Peak workloads show me that SQS doesn't have scalability limits, similar to Lambda. The product scales automatically, handling peak and off-peak hours. I've never lost messages within SQS, and all message infrastructure is managed by AWS.
Positive
Proprietary protocols like GMS, AMQP, etc., were in place previously. With workloads migrated to the cloud, SQS now meets all my messaging workloads requirements.
The setup is straightforward for me, as it's HTTPS based. Communication and setup are easy, and target SDKs are available for different client frameworks. Due to its simplified deployment and SDK availability, I would rate it nine out of ten.
I am not the project owner for SQS, but I'm aware of its usage. I have not heard complaints about it from my team.
It's quite economical for me. I would say a rating of four to five out of five is appropriate, as charges are based on usage.
Overall, I'd rate it nine out of ten. The serverless stack offered by AWS provides me with good guidance. Serverless patterns from AWS need better reference. Cloud adoption will have general discussions, but more proprietary cloud frameworks should learn from serverless tech, facilitating infrastructure as code. Open-source frameworks for building serverless applications are beneficial for setting up full stack apps promptly.
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.
Our primary use case was to connect SQS with S3 so that we could count the number of downloads of our objects within S3. However, we had to switch to using the CloudFront URL instead. We initially used SQS to help in decoupling and to find the number of messages coming in.
The most valuable feature is the ability to decouple components. It is beneficial because our architecture usually has different components and the communication aspect of components is crucial. SQS is effective in decoupling or buffering to prevent overwhelming components in case there is increased traffic, aiding in the management of communication loads. By design, it is scalable, and its SAGRAM feature helps to lower loads during surges.
The primary issue was the increase in costs due to frequent polling for messages. The cost became an issue, leading us to consider other solutions.
We used SQS for a project, however, due to cost concerns, we had to switch to a different solution.
We did not encounter any challenges with the stability of SQS. The only challenge we faced was with the cost.
SQS is scalable. It is designed to handle varying loads well, with the SAGRAM feature assisting in managing and lowering loads during increased traffic.
Understanding the service requires prior knowledge, and we could not just use it directly. We needed to first understand the service itself for deployment.
The main challenge we encountered was related to the cost increase due to frequent polling for messages.
We switched from using SQS to CloudFront, as CloudFront was a better fit for our needs and was more cost-effective.
I would recommend SQS to others depending on their use case.
Overall, I would rate SQS a nine 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.
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.
