- 新しい順
- 投票が多い順
- コメントが多い順
CloudTrail does not log GetMetricData API calls. So, you cannot correlate the number of such API calls to your costs using CloudTrail.
Further, if CloudTrail were to log this API call, it'd likely be a data event (a high-volume operation) which would not be listed in Event History (or it'll flood Event History rendering it pretty useless to track other events).
The supported CloudWatch API calls (actions) in CloudTrail logs (events) are listed at https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/logging_cw_api_calls.html#cw_info_in_ct
From what you've posted, I can't tell what is causing the requests. However, I recommend enabling CloudTrail [1]. CloudTrail is the AWS audit system. The first trail is free other than storage fees. You can store the CloudTrail logs in an S3 bucket (I also recommend creating a lifecycle policy [2] or those logs will only accumulate costing you money) and you can search the logs through Athena [3] or by going and downloading the logs. Through the CloudTrail logs, you should be able to find the GetMetric entries and that should tell you the ARN of what is making the requests and the user/role that is doing it. From this, you should be able to determine what is causing the costs in Cloud Watch.
[1] https://aws.amazon.com/cloudtrail/ [2] https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html [3] https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html
関連するコンテンツ
AWS公式更新しました 1年前- AWS公式更新しました 1年前
CloudTrail makes 90 days' worth of data available in the Console too without you needing to create a Trail (go to Event History on the menu), so you can use that interface to filter for the GetMetric and ListMetric events without having to set anything else up. If you've already stopped the integration which was causing those APIs to be called and since any Trails you create now will only contain new events, the Event History in the Console is the only way you can see related entries.