Skip to content

Increase AWS retry to 5 - #2148

Merged
NickJosevski merged 1 commit into
mainfrom
nj/aws-raise-retry-budget-for-throttling
Aug 26, 2026
Merged

Increase AWS retry to 5#2148
NickJosevski merged 1 commit into
mainfrom
nj/aws-raise-retry-budget-for-throttling

Conversation

@NickJosevski

@NickJosevski NickJosevski commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

No server change required.

Background

CloudFormation steps intermittently fail with AmazonCloudFormationException: Rate exceeded, surfaced by CloudFormationTests.ShouldDeployChangeset in Server CI (Chain: Full #2026.3.13729).

The SDK's RetryHandler is in the stack trace, so it had already retried. AWS SDK v4 (AWSSDK.Core 4.0.100.9) defaults to Standard retry mode, which does treat throttling as retryable — but MaxErrorRetry is only 2. AsClientConfig left that default in place.

Results

All AWS clients (CloudFormation, S3, IAM, STS) get 5 retries instead of 2, so a transient throttle costs backoff rather than a failed deployment.

How to review this PR

AWS doesn't publish per-operation request rate quotas for CloudFormation — the quotas page documents no request rates at all — so 5 can't be derived from a documented limit. The real measure is the throttle rate afterwards.

Two things worth challenging: it applies to all AWS clients rather than just CloudFormation, and under sustained throttling a deployment now takes longer to fail. Adaptive retry mode would add client-side rate limiting and is arguably the better shape, but the SDK calls it "experimental", which felt wrong for the deployment hot path.

#2149 fixes how the failure is reported once retries are exhausted.

CloudFormation steps intermittently fail with "Rate exceeded". AWS SDK v4 uses
Standard retry mode, which treats throttling as retryable but allows only 2
retries - not enough when deployments share an account and region.

Set MaxErrorRetry explicitly for every AWS client. AWS doesn't publish
CloudFormation request rate quotas, so the value widens the backoff window
rather than matching a documented limit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@NickJosevski
NickJosevski force-pushed the nj/aws-raise-retry-budget-for-throttling branch from a97d4bb to 3fc7c4b Compare August 26, 2026 07:48
@NickJosevski NickJosevski changed the title Raise the AWS retry budget so throttled calls are not fatal Increase AWS retry to 5 Aug 26, 2026
@NickJosevski
NickJosevski marked this pull request as ready for review August 26, 2026 12:12
@NickJosevski

Copy link
Copy Markdown
Contributor Author

Backoff shape, for context on what raising this to 5 actually costs:

StandardRetryPolicy.CalculateRetryDelay is exponential with jitter, capped at 20s (MaxBackoffInMilliseconds). Legacy is exponential capped at 30s; Adaptive inherits Standard's. So this adds three more jittered exponential attempts, not a fixed delay — the shape that avoids a retry stampede when chains run concurrently.

Caveat worth knowing: ThrottleRetries (on by default) drains retry capacity per service URL when failures persist and then fails fast, so 5 is a ceiling rather than a guarantee.

@NickJosevski
NickJosevski enabled auto-merge (rebase) August 26, 2026 23:40

@flin-8 flin-8 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@NickJosevski
NickJosevski merged commit ade66da into main Aug 26, 2026
29 checks passed
@NickJosevski
NickJosevski deleted the nj/aws-raise-retry-budget-for-throttling branch August 26, 2026 23:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants