某公司有一個在 Amazon EC2 執行個體上執行的舊版資料處理應用程式。資料是循序處理的，但結果的順序並不重要。該應用程式使用單體式架構，目前僅透過增加執行個體大小來擴展。開發人員正在將該應用程式重寫為 Amazon Elastic Container Service (Amazon ECS) 上的微服務。解決方案架構師應該建議微服務之間如何通訊？

正確答案是使用 Amazon SQS 佇列。由於資料是循序處理的且結果順序不重要，SQS 提供了可靠的非同步通訊機制，非常適合解耦微服務。生產者將訊息發送到佇列，消費者獨立地從佇列中拉取並處理訊息，提高了系統的彈性和可擴展性。 Amazon SNS 主題適用於發佈/訂閱模式，但通常用於多個訂閱者需要接收相同訊息的場景，且不保證訊息處理順序或持久性，不適合此處的循序處理需求。AWS Lambda 函數傳遞訊息會增加不必要的複雜性，且 Lambda 函數本身並非為持久性訊息佇列而設計。Amazon DynamoDB 表格搭配 DynamoDB Streams 雖然可以追蹤資料變更，但其主要用途是資料庫而非訊息佇列，且實作起來比 SQS 更複雜，不符合此情境的最佳實踐。