以下几个因素可帮助您决定选择哪一个：

1. RabbitMQ默认为FIFO。Amazon SQS队列可以选择设置为FIFO。
   1.您可以使用RabbitMQ设置自己的服务器，但在Amazon SQS的情况下则不行，因此这里涉及到成本。
   1.建立自己的服务器需要很好的知识，这样你就不会留下任何一个角落未被触及。亚马逊SQS就不是这样了，因为它入门相当快。
   1.您自己的RabbitMQ服务器意味着维护成本下降，这是不与亚马逊SQS的情况。

SQS将是我的首选比RabbitMQ，这里是为什么。

1. SQS是一项托管服务。因此，您不必担心运行消息传递系统的操作方面，包括管理、安全、监控等。Amazon将为您完成这些工作，并在出现问题时提供支持。
2. SQS是弹性的，可以扩展到非常大的速率/容量（根据AWS，无限制;））
3. SQS的可用性中有很多9，并且有Amazon的支持，这在您的应用程序中是一件不用担心的事情。
   但是RabbitMQ可能会为put和get提供更快的响应时间，从我的测试来看，通常是几万个TPS。为了让SQS提供这样的吞吐量，您必须通过多个示例水平扩展。因此，如果您正在寻找低于5 ms的put，RabbitMQ可能是一个可以考虑的选择，因为我已经看到接近20 ms-30 ms的时间，从我的SQS测试在1000 s的TPS，这是略高于RabbitMQ。
   我们刚刚将消息传递基础设施从ActiveMQ迁移到SQS，我们非常高兴，我们发现这比在云中维护我们自己的ActiveMQ集群更便宜。
   希望这能有所帮助！让我们知道进展如何。

我实际上在商业环境中使用了这两种方法，并取得了相当的成功。
简短的回答是，除非有特定的极端情况，否则最好使用AWS SQS。
编码（Tie）：RabbitMQ和AWS SQS都已经建立了库和大量示例。
可见性超时（SQS）：SQS在RabbitMQ上提供了一个更广泛的可见性超时概念。在RabbitMQ中，如果消费者在确认之前死亡，消息将被放回到队列中。但是SQS有一个更广泛的可见性超时概念，它不与特定的调用者绑定。因此，您可以启动一个工作单元，设置具有较长超时（最长12小时）的可见性，断开连接，在我的设计中，我们广泛地利用了这一点，并消除了额外的服务/存储来管理潜在的大型“正在进行的”有效负载。
死信处理（RabbitMQ -按“野兔”）SQS提供基本死信处理，他们称之为“重新驱动策略”，将消息转储到死信队列中（只是另一个队列）。它是基本的，只有消息计数的概念。RabbitMQ有死信交换，当消息过期时，它提供将消息推入DLE的功能。但这有点像“如果你不”的概念。不要看着你的服务和消息过期，那么它将进入DLE”。这对RabbitMQ来说是一个小小的胜利，因为我发现这个论点与直觉相悖。为什么你要监视你的队列而不是你的服务？（如果有的话，这是相反的方式）
管理（SQS）：SQS没有管理。你只需支付API调用的费用。所有常见的麻烦，如操作系统/应用程序安全补丁、扩展（添加更多节点）、磁盘都由AWS团队处理。它还符合FedRamp（政府使用）。它是一个真正的“安装后就不用再管”系统。RabbitMQ需要常见的操作系统/服务补丁、AMI、集群、安全加固等。虽然AMI非常罕见，但它可能会关闭。或者有时需要移动，因此需要开箱即用的集群。SQS消除了所有这些麻烦。
成本（SQS）：一个SQSAPI调用可以包含“批处理多达10条消息/256 k大小”和“长轮询”可以大大降低成本。此外，有一些策略，比如消息压缩，可以将几十个（有些人声称数百条或更多）消息可以在单个有效负载中发送，以进一步降低成本。这还没有考虑人们花在监控/修补/修复问题上的时间。SQS也是伟大的'PoC项目'，如果它闲置，没有成本。
FIFO（TIE）：AWS在2016年引入了FIFO支持，每百万API调用的额外成本约为0.10美元（每百万API请求，FIFO队列为0.50美元，标准（非FIFO）队列为0.40美元，均未扣除折扣）。您可以选择是否使用FIFO。对于非FIFO，我们很少看到重复的消息。
储存（SQS）：AWS不收取存储费用，但你有14天的限制。在RabbitMQ上，你将不得不分配、扩展和管理需要峰值存储容量和额外缓冲区的磁盘空间。这只是更头痛。
指标（SQS）：SQS提供了开箱即用的指标。虽然你可以将它们添加到AWS中，但这只是更多的工作。
本地设备（连接）：大多数现代商店都喜欢有本地环境，现在有几个选择允许RabbitMQ和SQS的 Docker 。
高吞吐量/非常大的消息（RabbitMQ --有点）当你推送SQS〉1000个请求/秒时，SQS的延迟就会增加。有几种策略可以解决这个问题。但是我发现这种情况非常罕见，因为大多数工作都可以被划分到多个队列中。但是对于这些需要100 k/秒的情况，我认为Kafka更好。（我们在我的工作中也使用Kafka）很少有一个工作单元需要1000+请求/秒和低延迟。* 请参阅下面的详细说明
总结：如果你打算在AWS工作，并愿意嫁给SQS，那么SQS是一个不用动脑筋的问题。但是你应该继续读下去，因为有一些重要的事情需要考虑。
RabbitMQ的经典策略（和其他队列）的方法是创建几种类型的队列，这些队列针对特定类型的工作进行了优化。然后，对这些队列中的每一个进行微调，并将类似的工作分组为少量的队列。（通常非常大）队列。由于SQS没有管理开销，因此实际上最好为每个工作分配专用队列。通过这样做，它允许扩展，但也消除了队列饱和（令人不快的工作使队列饱和并淹没其他工作者）、更好地查看工作（默认度量）等。

新的策略让我的团队更好地了解工作是如何分配的。“升级示例以获得更多负载”的日子已经一去不复返了。在过去，我们会看到一个无法解释的大峰值，这会对其他服务造成副作用，或者只是猜测累积的数字看起来差不多正确。现在流量是分开的，我们实际上发现了许多以前没有注意到的问题，并且可以清楚地解释有多少流量流向了哪里。2虽然实现度量和工具是非常可能的，但是SQS提供了所有这些开箱即用的功能。
RabbitMQ仍有大量案例需要认真考虑

- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.

如果您对成本敏感，Amazon SQS可能会更贵。我说可能是因为你仍然需要在某个地方托管你的RabbitMQ服务器。SQS给你第一个100万个请求免费，然后每100万个请求收取0.4美元。有一个技巧可以降低你的SQS成本，尽管通过启用长轮询，即设置你的receive_message_wait_time为20s。这并不意味着你的消息只会每20秒发送一次，而是意味着如果你的que为空（每20秒），SQS不会向你收取“请求”费。
如果你每小时使用1000个请求，你一个月就需要744000个请求。在免费层内免费，在层外大约0.74* 0.4美元= 0.2976美元。你可以通过启用等待时间来进一步减少请求。所以在你的情况下，SQS实际上可能会更便宜，因为大多数托管服务最低起价为5美元以上（除非你有一个来自AWS的EC2免费层）。你应该可以选择最小的选项，因为RMQ只建议128MB RAM左右开始。
我发现SQS对用户更友好，RabbitMQ更技术化，如果你有这种倾向的话。
更新：
实际上，我发现AWS简单通知服务更适合我所需要的https://stackoverflow.com/a/13692720/5403449，主要是因为它基于推送，即非轮询