AWS SDK retry defaults change November 1, 2026, cutting DynamoDB attempts from 9 to 4

AWS will change the default retry behavior in its SDKs on November 1, 2026, and a post on dev.to argues the shift looks minor on paper but could quietly reshape how services behave under partial failure. The same post introduces an open-source Java library, retrylens, built to measure what the new defaults would do to real production traffic before the deadline arrives.

What changes on November 1, 2026

According to the dev.to post, the change spans AWS SDKs for Java, Python, JavaScript, Go and PHP as well as the CLI, and adjusts these values:

• Maximum attempts for most services drop from 4 to 3.
• Maximum attempts for DynamoDB drop from 9 to 4.
• The base delay for transient errors drops from 100 ms to 50 ms.
• The base delay for throttling rises from 500 ms to 1000 ms.
• LimitExceededException and STS IdpCommunicationErrorException become retryable.

The DynamoDB row is the consequential one, the author writes, because that service has long carried a per-service override allowing up to nine attempts before the SDK gives up. Write paths that quietly ride out brief throttling bursts by leaning on that deeper retry budget may see calls that succeed today begin to fail once the cap is four.

Why the impact is hard to see in advance

The post notes that neither the AWS announcement nor application logs can answer the question that matters: what the new defaults would do to a given workload. The announcement knows nothing about a service's throttling patterns at odd hours, and the SDK's retry loop is largely invisible from the outside — callers observe a final success or failure, not the attempts in between.

Java users on AWS SDK for Java 2.44 and later can opt in early by setting AWS_NEW_RETRIES_2026=true, but the author points out that this changes everything at once, and the only way to learn whether it causes harm is to enable it and observe.

retrylens records attempts and replays the new defaults

To close that gap, the author published retrylens on Maven Central and GitHub under an Apache 2.0 license, describing it as roughly 600 lines of Java with no mandatory runtime dependencies. The library attaches a single ExecutionInterceptor to any AWS SDK v2 client, records each attempt into a bounded ring buffer, and then simulates what the November 2026 defaults would have done to that same traffic.

The simulator computes its projection from recorded attempt outcomes alone: it never re-issues a request, never contacts AWS and needs no credentials, which the author says is what makes it safe to run against a live application. Integration is a single builder call — register the interceptor through the client's overrideConfiguration, then compare the current report against a preview generated with the STANDARD_2026 retry mode and read the difference. The AWS SDK is declared as a provided dependency, so applications keep whichever version they already use, with 2.20 or newer recommended and retry values calibrated for 2.44 and later.

The post shows a representative snapshot from a synthetic DynamoDB, S3 and SQS workload: 1,428 calls with 6 failures under current defaults, projected to 27 failures under the 2026 defaults. That delta — 21 extra failures and 223 fewer attempts — comes mostly from DynamoDB PutItem exhausting its retries sooner under sustained throttling. The author's point is that a concrete number supports a real decision: raise write capacity, set a per-operation retry override, or consciously accept the drop.

Stated limitations

The post is candid about the tool's edges. It does not model the standard-mode retry quota, the token bucket that can suppress retries under sustained failure, so the simulator may overstate how often the new mode retries. It does not model live jitter, reporting backoff timing as the statistical expectation of full jitter rather than one sampled outcome. And because it never re-issues requests, results reflect the recorded traffic mix — if the traffic changes, the measurement should be run again.

What the author recommends now

Whether or not teams adopt the library, the post suggests one of three moves: run the application with AWS_NEW_RETRIES_2026=true in staging for a week and diff CloudWatch failure metrics against the previous week; run retrylens against a canary of production traffic for thirty minutes and read the diff; or set AWS_RETRY_MODE=legacy explicitly in production now, so the opt-out is already in place when November 1 arrives and migration can be scheduled deliberately rather than dictated by the deadline.

Why it matters

Retry configuration is a default most teams never inspect, and changes to it surface only under partial failure — throttling, transient errors, degraded dependencies — precisely when silent shifts in behavior are hardest to diagnose. The DynamoDB cut from nine attempts to four is the sharpest edge, converting some sustained-throttling scenarios from eventual success into surfaced errors. The broader lesson extends beyond Java: any workload that implicitly depends on SDK retry depth should be quantified now, while there is still time to tune capacity, pin legacy behavior, or deliberately accept a new failure profile.