Announcement: Updated default retry behavior (2026) #10329
Pinned
millems
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Status
AWS_NEW_RETRIES_2026=trueWhat changed
When you set
AWS_NEW_RETRIES_2026=true, the default retry mode changes fromlegacytostandard. Several other retry defaults also update. Thestandardmode adds a retry quota that limits retries when failures are widespread, so your application fails fast instead of waiting on retries that are unlikely to succeed. This also helps outages resolve faster.If you have explicitly configured a retry mode, max attempts, or backoff, your value takes precedence for that setting.
legacystandardTransient errors (such as 500s and connection resets) now use a much shorter backoff than throttling errors (where the service asks you to slow down). For details on backoff timing, error classification, and the retry quota, see Retry behavior in the AWS SDKs. For retry mode selection and configuration options, see Retry behavior in the AWS SDKs.
How to opt in
Once the release ships (we will update this issue), set the environment variable:
export AWS_NEW_RETRIES_2026=trueOn Windows:
How to revert
During the opt-in period, remove the environment variable:
unset AWS_NEW_RETRIES_2026After the default rollout (no sooner than November 2026), the new behavior becomes the default. To restore previous behavior, set the retry mode to
legacy:export AWS_RETRY_MODE=legacyOr in the AWS CLI configuration file (
~/.aws/config):Where you might notice a difference
For most workloads, the change is invisible or strictly better. Transient errors recover faster because the base delay is significantly shorter.
max_attemptsto restore your previous value.sqs receive-messageapply a backoff delay before returning an error, even when retries are blocked. Without this, polling loops tighten during outages, spiking client CPU usage and generating additional load that can delay recovery. For details, see long-polling operations.Overriding specific settings
You do not have to accept all changes as a bundle. If you opt in but want to keep a specific previous value, set it explicitly. Precedence applies per setting.
For example, to use the new backoff timing but keep a higher DynamoDB max attempts, add to your AWS CLI configuration file (
~/.aws/config):Or set the environment variable:
export AWS_MAX_ATTEMPTS=10For the full list of configurable settings and their precedence, see Retry behavior in the AWS SDKs.
Feedback
If you encounter unexpected behavior or have questions, comment on this issue. Your feedback during the opt-in period directly shapes when and how we make this the default.
Beta Was this translation helpful? Give feedback.
All reactions