PacketSensei

AWS `ThrottlingException / RequestLimitExceeded`: What It Means and How to Fix It

PacketSensei

ThrottlingException / RequestLimitExceeded is the AWS API rate limiter, which is usually reacting to code that polls in a loop. It comes from All AWS APIs, and the message reads:

Rate exceeded / Request limit exceeded.

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error ThrottlingException / RequestLimitExceeded
Service All AWS APIs
Message Rate exceeded / Request limit exceeded.
Most common cause A polling loop with no backoff

What it actually means

Every AWS API has request rate limits, implemented as token buckets with a refill rate and a burst capacity. Exceeding them returns a throttling error, which SDKs retry automatically with exponential backoff.

Seeing throttling in application logs usually means the retries also failed, which means the request rate is sustained rather than bursty. The rate limits themselves are mostly undocumented and are shared across the whole account and region, so another team’s runaway script can throttle yours.

Describe calls are the usual offenders. They are cheap to write, feel free, and are heavily rate-limited.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 A polling loop with no backoff Code that calls describe-instances every second to check state. Use a waiter, which backs off properly, or an EventBridge rule that reacts to the state change instead of polling for it.
2 A large fleet all calling at once A thousand instances running the same cron at the same minute. Add jitter.
3 Terraform or CloudFormation on a large state A big plan issues thousands of describe calls. Reduce parallelism (terraform apply -parallelism=5) and split the state.
4 Another workload in the same account Limits are per account and region. Check CloudTrail for who else is calling the same API.
5 Pagination without MaxResults Fetching a huge result set one default page at a time multiplies the call count.

How to tell which one you have

# Who is calling this API, and how often?
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DescribeInstances \
  --start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --query 'Events[].[EventTime,Username,SourceIPAddress]' --output text \
  | sort | uniq -c | sort -rn | head

CloudTrail sampling makes this indicative rather than exact, but the top caller is usually obvious.

Preventing it

Turn polling into events. Almost everything worth polling for in AWS emits an EventBridge event — instance state changes, ECS task state changes, S3 object creation, CodePipeline stage transitions. An event-driven design makes zero describe calls.

Where polling is unavoidable, use the SDK’s waiters rather than a hand-written loop, enable adaptive retry mode (AWS_RETRY_MODE=adaptive), and add jitter to anything running on a schedule across a fleet.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.