A logistics platform on EKS already scrapes metrics with Prometheus and wants a managed, Prometheus-compatible query endpoint instead of running its own long-term store. Which service fits?
Select an answer to reveal the explanation.
Short Explanation
You already use Prometheus, so you can keep querying your scraped metrics with PromQL. Amazon Managed Service for Prometheus provides the managed query endpoint you need, rather than turning API records into a metrics store.
Full Explanation
Amazon Managed Service for Prometheus provides a managed, Prometheus-compatible workspace that can receive scraped metrics through remote write and let operators query them with PromQL. It fits because the team wants a managed query endpoint for its existing Prometheus metrics, without running its own long-term store. A CloudTrail trail records API calls, including data events, rather than storing Prometheus time series. VPC Flow Logs stored in S3 are network records, not a query endpoint for cluster metrics. AWS Config rules evaluate resource configuration, such as the EKS node group, but do not store scraped metrics. Caveat: the cluster still needs a collector configured to remote-write metrics to the workspace; choosing the managed workspace does not replace scraping. The workspace is Regional, so the scrape or remote-write configuration must name the intended workspace. PromQL remains the query language, which is the point of choosing this service over a log store. Retention and ingestion limits are set on the workspace, so confirm they suit the expected volume before directing every cluster to it. As a practical check, verify that the workspace is receiving remote-write data and that a sample PromQL query returns the series the team scrapes.