A developer is receiving HTTP 400: ThrottlingException errors intermittently when calling the Amazon CloudWatch API. When a call fails, no data is retrieved. What best practice should first be applied to address this issue?
A.
Contact AWS Support for a limit increase.
B.
Use the AWS CLI to get the metrics.
C.
Analyze the applications and remove the API call.
D is the right answer.
https://aws.amazon.com/premiumsupport/knowledge-center/cloudwatch-400-error-throttling/
It's a best practice to use the following methods to reduce your call rate and avoid API throttling:
Distribute your API calls evenly over time rather than making several API calls in a short time span. If you require data to be available with a one-minute resolution, you have an entire minute to emit that metric. Use jitter (randomized delay) to send data points at various times.
Combine as many metrics as possible into a single API call. For example, a single PutMetricData call can include 20 metrics and 150 data points. You can also use pre-aggregated data sets, such as StatisticSet, to publish aggregated data points, thus reducing the number of PutMetricData calls per second.
Retry your call with exponential backoff and jitter.
This is a retry mechanism where the client waits for an increasing amount of time between retries after each failure. This approach helps to prevent overwhelming the API further and allows time for the system to recover.
Usually, when a function or a service return an error, we can implement a retry mechanism with exponential backoff in order to try to call the function several times. So D is the correct answer
D is the answer
Resolution
It's a best practice to use the following methods to reduce your call rate and avoid API throttling:
Distribute your API calls evenly over time rather than making several API calls in a short time span. If you require data to be available with a one-minute resolution, you have an entire minute to emit that metric. Use jitter (randomized delay) to send data points at various times.
Combine as many metrics as possible into a single API call. For example, a single PutMetricData call can include 20 metrics and 150 data points. You can also use pre-aggregated data sets, such as StatisticSet, to publish aggregated data points, thus reducing the number of PutMetricData calls per second.
Retry your call with exponential backoff and jitter.
The answer is D.
Key Word is "sporadically", this means the error does not occur very often, exponential backoff is the way to go. If it was a persistent issue, you should go with A
Answer is B.
If you're not using an AWS SDK, you should retry original requests that receive server (5xx) or throttling errors. However, client errors (4xx) indicate that you need to revise the request to correct the problem before trying again.
https://docs.aws.amazon.com/general/latest/gr/api-retries.html
You have it in your comment and yet you select wrong aswer. The question is about the throttling error which as you mentioned should be handled by exponential backoff. So D is the answer.
D is WRONG!!!! the developer is getting a 400 error which is from the client side not server side !!! Exponential backoff is NOT an option !! B is the correct answer.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
awscertified
Highly Voted 3 years, 7 months agojnara
3 years, 6 months agoGoozian
3 years, 5 months agonewbie2019
Highly Voted 3 years, 7 months agosumanshu
Most Recent 4 months, 1 week agoMelisa202401
1 year, 1 month agoNaghamAbdellatif
1 year, 7 months agoRachitNandi1997
1 year, 8 months agoninomfr64
1 year, 8 months agorcaliandro
1 year, 10 months agosichilam
2 years, 3 months agospeer
2 years, 4 months agohumble_developer
2 years, 4 months agomohamedba
2 years, 11 months agojoesome
3 years, 4 months agoleliodesouza
3 years, 5 months agojc966
3 years, 5 months agoVlasto
3 years, 2 months agosanthoshmj
3 years, 5 months agoceeee
3 years, 5 months agoEV123
3 years, 5 months ago