AWS SDK and CLI Default Retry Update (Nov 2026): 14-Token Transient Quota, DynamoDB 4-Attempt Cap, and Legacy Profile Traps

A conceptual illustration showing the 50 ms transient retry lane (-14 tokens) and 1,000 ms throttling retry lane (-5 tokens) flowing through the 500-token retry quota bucket into DynamoDB and SQS long-polling controls. This is not an actual console screenshot.

Starting November 10, 2026, AWS made its updated retry behavior the default across major AWS SDKs and tools—including Python (botocore 1.44.0), JavaScript v3 (3.1166.0), Go v2 (v1.48.0), Rust (aws-config 1.13.2), .NET (AWSSDK.Core 4.0.103.0), and the AWS CLI (2.40.0)—while removing the AWS_NEW_RETRIES_2026 opt-in flag introduced in May 2026. Workloads upgrading to these releases automatically inherit faster 50 ms transient-error backoffs, a higher 14-token retry quota cost for transient errors, a 4-attempt default cap for Amazon DynamoDB, and a default mode switch from legacy to standard in Python, Ruby, PHP, and Swift. AWS Developer Tools Blog Announcement, May 2026 Initial Announcement, AWS SDKs and Tools Retry Behavior Guide

The core operational takeaway: setting AWS_NEW_RETRIES_2026=false no longer reverts to the old behavior after you upgrade, and placing retry_mode = legacy in a shared ~/.aws/config file can break other SDKs or cause them to ignore your entire profile (including credentials and Region). Because the 500-token retry bucket now depletes after 35 consecutive transient retries instead of 50–100—and DynamoDB clients now stop after 4 total attempts instead of up to 10–12—teams should audit retry-sensitive workloads and configure explicit per-client overrides before rolling these SDK versions into production.

This guide analyzes the five algorithmic changes, the per-SDK version cutoff table, and safe override patterns based on the November 10, 2026 AWS Developer Tools Blog post and the AWS SDKs and Tools Reference Guide. It does not report live AWS regional outage benchmarks; the local Python checks below verify token-bucket depletion math and detect shared-profile configuration hazards.

1. Five Core Retry Changes Now Active by Default

The November 2026 update modifies how standard and adaptive retry modes handle failed requests and migrates the remaining legacy-default SDKs onto standard mode:

Retry Dimension	Previous Default (Before Nov 10, 2026 Releases)	New Default (Nov 10, 2026 Releases & Later)	Production Impact
1. Default Retry Mode (Python, Ruby, PHP, Swift)	Defaulted to `legacy` mode (inconsistent retryable errors, higher attempt counts, and no standardized token-bucket retry quota)	Defaults to `standard` mode (3 max attempts for general services, exponential backoff with jitter, and a 500-token retry quota bucket)	Prevents thread and connection-pool exhaustion during prolonged outages, but surfaces exceptions to application code after fewer attempts
2. Base Backoff Delay by Error Class	Varied across SDKs; transient glitches often waited as long as throttling errors	`50 ms` base delay for transient errors (connection resets, HTTP `500`/`502`/`503`/`504`); `1,000 ms` base delay for throttling errors	Recovers from brief network blips and isolated 5xx responses significantly faster
3. Retry Quota Token Bucket Cost	Transient error retries cost 5 or 10 tokens from the 500-token bucket (allowing 50 to 100 consecutive transient retries)	Transient error retries cost `14 tokens`; throttling retries cost `5 tokens`	During a sustained wave of HTTP 500 errors with zero successes, the quota engages after 35 retries (`500 // 14 = 35`) to fail fast
4. Amazon DynamoDB & Streams Tuning	Varied widely by SDK (up to 10–12 max attempts in some SDKs)	Standardized to a `25 ms` base delay and `4` max attempts (1 initial request + up to 3 retries)	Matches DynamoDB's low-latency profile, but workloads relying on 10+ retries to absorb hot-partition spikes may see errors sooner
5. Long-Polling Backoff & Opt-In Flag Removal	Controlled via `AWS_NEW_RETRIES_2026=true/false`	`AWS_NEW_RETRIES_2026` is completely ignored. When the retry quota is depleted, long-polling calls (such as `SQS ReceiveMessage`) apply a backoff delay before returning an error	Prevents tight error loops on depleted SQS pollers, and eliminates environment-variable opt-outs

2. Version Cutoffs Across AWS SDKs and CLI Tools

Every SDK and tool below—except Java 2.x and Kotlin—enables the updated retry behavior by default starting in the listed release:

SDK / Tool	Default Starting Version	How Existing Configurations Are Affected
Python (Boto3 / botocore)	`botocore 1.44.0`	Switches unconfigured clients from `legacy` (5 attempts general / 11 attempts DynamoDB) to `standard` (3 attempts general / 4 attempts DynamoDB, 14-token transient cost)
JavaScript v3	`3.1166.0` (with `@smithy/core 3.40.0+`)	Already defaulted to `standard`; updates backoff base delays (50 ms / 1,000 ms), 14-token transient quota cost, and DynamoDB 25 ms / 4-attempt defaults
Go v2	`v1.48.0`	Updates timing, quota cost, and DynamoDB defaults inside `standard` and `adaptive` modes while preserving any explicitly configured `MaxAttempts`
Rust	`aws-config 1.13.2` (with `BehaviorVersion::v2026_11_10()` or later)	Activated when initializing config with `BehaviorVersion::v2026_11_10()` (or `BehaviorVersion::latest()`)
.NET / PowerShell / C++	`AWSSDK.Core 4.0.103.0` / PowerShell `5.0.332` / C++ `1.11.926`	Applies the new backoff timing, quota costs, and DynamoDB defaults in `standard` and `adaptive` modes
Ruby / PHP / Swift	`aws-sdk-core 3.267.0` / PHP `3.403.3` / Swift `1.8.24`	Switches the default retry mode from `legacy` to `standard` alongside the new timing and quota rules
AWS CLI	`2.40.0`	Applies the updated `standard` retry behavior across CLI commands and automation scripts
Java 2.x / Kotlin	To be announced (Kotlin supports opt-in testing in `1.9.0+`)	Retains previous default behavior until a future release announcement

3. Preserving Previous Behavior Without Breaking Shared Profiles

If a workload depends on higher retry counts or legacy behavior, avoid two common traps when configuring overrides:

Trap 1: Setting AWS_NEW_RETRIES_2026=false does nothing: Once you upgrade to the versions in the table above, the SDK ignores AWS_NEW_RETRIES_2026 completely.

Trap 2: Global AWS_RETRY_MODE=legacy or retry_mode = legacy in ~/.aws/config can break other tools: As warned in the AWS announcement, some SDKs and tools do not accept legacy. When a tool that rejects legacy loads a shared ~/.aws/config profile containing retry_mode = legacy, it can fail at startup or silently ignore the entire profile, including your credentials and Region.

Following the AWS configuration precedence rules (Explicit client config in code > Environment variable > Shared ~/.aws/config > SDK default), the safest approach is to override max_attempts (or mode) directly on the SDK client in code:

4. Verifying Token-Bucket Depletion Math and Config Hazards in Python

The dependency-free Python script below models the 500-token retry bucket under the old (10-token) versus new (14-token) transient error cost, and audits environment/profile configurations for ignored flags and legacy profile hazards.

Scope Verified Locally

Executing the script in a local Python environment verified three boundary cases:

Sustained HTTP 500 outage (60 consecutive transient failures): At 10 tokens per retry, the bucket allows 50 retries (remaining_tokens: 0); at the new 14 tokens per retry, the bucket stops after 35 retries (remaining_tokens: 10, quota_blocked: 25).

Sustained HTTP 429 throttling (100 consecutive throttling failures): Because throttling retries still cost 5 tokens, all 100 retries execute before the bucket reaches 0.

Dead opt-out flag and shared legacy profile detection: Auditing a go_v2 service with AWS_NEW_RETRIES_2026=false and a shared legacy profile flags both dead_flag_ignored:AWS_NEW_RETRIES_2026 and profile_or_config_load_failure_on_legacy:go_v2.

5. Pre-Upgrade Checklist

Review DynamoDB and Boto3 retry expectations: If your Python or DynamoDB workloads relied on 5 to 10+ automatic retries under legacy mode, explicitly configure max_attempts / total_max_attempts on your client objects before upgrading to botocore 1.44.0+.

Remove AWS_NEW_RETRIES_2026 from deployment manifests: Clean up the retired environment variable from Kubernetes manifests, ECS task definitions, and CI/CD pipelines so operators do not mistake AWS_NEW_RETRIES_2026=false for an active rollback switch.