You are a DevOps consultant.
One client uses AWS CLI put-metric-data to publish the metric data of an application to CloudWatch every second.
The CloudWatch metric stores the data with a resolution of 1 minute.
The client worries about the cost of the put-metric-data requests and wants to reduce the number of calls to put-metric-data
In the meantime, the client does not want to lose the data points.
Which of the following options would you suggest to address this concern?
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer : B.
Option A is incorrect because get-metric-statistics is used to retrieve statistics from CloudWatch.
The AWS CLI put-metric-data should still be used.
Option B is CORRECT because you can aggregate the data in a single put-metric-data request such as “--statistic-values Sum=11,Minimum=2,Maximum=5,SampleCount=3”
Through this method, the number of put-metric-data calls can be reduced.
Option C is incorrect because to add multiple data values in put-metric-data, you would need to use the Values option.
Details can be found in the following references.
Option D is incorrect because the CloudWatch metrics APIs such as GetMetricData, GetMetricStatistics, ListMetrics and PutMetricData are charged too.
Reference:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-data.html https://aws.amazon.com/cloudwatch/pricing/The client is publishing metric data every second to CloudWatch using AWS CLI's put-metric-data. However, CloudWatch stores data with a resolution of one minute. The client is concerned about the cost of the put-metric-data requests and wants to reduce the number of calls while not losing any data points.
Option A suggests aggregating the data in the application and publishing it in one get-metric-statistics call, eliminating the need for the put-metric-data call. However, this approach would lose data points as the get-metric-statistics call only returns aggregated data.
Option B suggests aggregating the data before publishing it to CloudWatch and putting the data into a statistic set that can be published with one put-metric-data call using the --statistic-values option. This option ensures that all data points are stored in CloudWatch and reduces the number of API requests, potentially reducing costs.
Option C suggests putting multiple data values in a single put-metric-data call using the --value option. This option reduces the number of API requests but does not aggregate the data or ensure that all data points are stored in CloudWatch.
Option D suggests that CloudWatch metrics are charged based on the number of metrics instead of API requests, and there is no need to reduce the number of put-metric-data calls. This option is incorrect as CloudWatch charges for both the number of metrics and API requests.
Therefore, option B is the most appropriate solution to address the client's concern. It ensures that all data points are stored in CloudWatch and reduces the number of API requests, potentially reducing costs.