某公司在 Amazon EC2 上執行一個基於 REST 的應用程式，該應用程式從第三方供應商接收近乎即時的資料。此應用程式會處理並儲存這些資料。由於運算容量激增且應用程式達到最大容量，供應商在傳送資料時收到許多 503 Service Unavailable 錯誤。解決方案架構師應推薦哪種設計來提供更具擴展性的解決方案？

此方案旨在解決應用程式因運算容量不足而導致的 503 錯誤，並提供可擴展的解決方案。Amazon Kinesis Data Streams 是一個高度可擴展且持久的資料串流服務，能夠處理高吞吐量的即時資料，有效解決資料擷取階段的容量問題。AWS Lambda 函數則提供無伺服器運算，可根據資料量自動擴展，處理 Kinesis 中的資料，無需管理伺服器，因此能有效應對突發的運算需求。 其他選項的不足之處： Amazon API Gateway 雖然能提供配額限制，但無法解決後端應用程式的處理能力瓶頸。 Amazon SNS 主要用於訊息發布/訂閱，不適合作為即時資料串流的擷取服務。將 EC2 放入 Auto Scaling 群組雖能擴展，但仍需管理 EC2 執行個體，且可能無法即時應對極端流量。 將應用程式重新封裝為容器並使用 Amazon ECS 搭配 Auto Scaling 群組確實能提高擴展性，但相較於 Kinesis Data Streams 和 Lambda 的組合，其管理和維護成本更高，且在處理即時資料串流方面，Kinesis 提供了更優化的解決方案。