AWS SDK Retry Defaults Changed: What .NET Developers Need to Know

AWS made updated retry behavior the default in selected SDK and tool releases on November 10, 2026. For .NET, AWS lists AWSSDK.Core 4.0.103.0. The update changes how Standard and Adaptive modes retry transient failures, spend retry quota and handle DynamoDB. Java and Kotlin default rollouts were still pending in the announcement.

Which SDK versions get the new default?

Tool	First default version listed by AWS
AWS SDK for .NET	AWSSDK.Core 4.0.103.0
AWS CLI	2.40.0
AWS Tools for PowerShell	AWS.Tools.Common, AWSPowerShell.NetCore and AWSPowerShell 5.0.332
Python and JavaScript	botocore 1.44.0 and JavaScript SDK 3.1166.0 with @smithy/core 3.40.0 or later
Java and Kotlin	Default dates pending in the November 10 announcement

AWS also lists release thresholds for Go, PHP, Ruby, Rust, Swift and C++. Compare the package actually deployed with the AWS rollout table. The May announcement introduced an opt-in. The newer default releases stop reading AWS_NEW_RETRIES_2026. Earlier versions that support the flag can still honor it.

What changes for AWS SDK for .NET?

Behavior	Previous .NET Standard setting	Updated setting
General transient base delay	1,000 ms	50 ms
General throttling base delay	1,000 ms	1,000 ms
General maximum total attempts	3	3
Transient retry quota cost	5 tokens	14 tokens
DynamoDB and DynamoDB Streams transient base delay	1,000 ms	25 ms
DynamoDB and DynamoDB Streams maximum total attempts	10	4

These are baseline values from the .NET SDK tracking issue, not promises about an individual request. Explicit overrides take precedence for the settings they cover. A maximum of three attempts permits the initial call and at most two retries. A request can stop earlier because the error is not retryable, cancellation fires, or the retry quota is exhausted.

How backoff, jitter and quotas interact

Exponential backoff grows the delay as retries accumulate. Jitter spreads requests over the backoff window so a fleet does not all retry at the same moment. The base delay is an input to that calculation. The service error classification matters too. A throttled call and a connection reset can use different delays. AWS documents five tokens for throttling retries and fourteen for transient retries in the updated behavior.

The retry quota limits retries during sustained failure. It is separate from Adaptive mode’s client-side rate limiter. Standard mode governs retry timing and quota. Adaptive adds request-rate control that can delay even the first request. Sharing one Adaptive client across resources with unrelated throttling limits can make an overloaded resource slow healthy ones. Scope the client to the service’s throttling dimension if you choose Adaptive.

AWS also documents a backoff for certain long-polling operations, such as SQS ReceiveMessage, when the retry quota is exhausted. Check worker cancellation, visibility timeout and shutdown behavior under that condition. AWS retry behavior reference.

Review SDK retry behavior.

How to configure an explicit .NET policy

This configuration uses AWS SDK for .NET v4 client properties. MaxErrorRetry counts retries after the initial attempt. Create the client through your existing dependency injection setup and reuse it. The example uses the default credential and Region resolution unless you supply them through normal application configuration. See the AWS .NET client configuration reference.

using Amazon.Runtime;
using Amazon.S3;

var config = new AmazonS3Config
{
    RetryMode = RequestRetryMode.Standard,
    MaxErrorRetry = 2
};
using var client = new AmazonS3Client(config);

To set a shared default through environment configuration where supported, use AWS_RETRY_MODE=standard and AWS_MAX_ATTEMPTS=3. The environment setting counts total attempts. Review per-client settings first because explicit client configuration can supersede shared defaults. On a machine with mixed SDKs, avoid setting Legacy globally to recover one application’s behavior. Some tools no longer accept it. Use an isolated profile or a targeted override where the SDK supports the intended behavior.

What to monitor during the migration

1. Inventory AWSSDK.Core and service packages in the deployment artifact. Check AWS CLI and PowerShell independently. An application package update does not update a runner’s CLI.
2. Record end-to-end latency, retry attempts, classified failures, throttling and final errors before changing the SDK. Break out DynamoDB and queue workers.
3. Test recovery from a short transient failure and from sustained throttling in a controlled environment. Compare tail latency and visible failures at equivalent load.
4. Align the SDK request budget with caller deadlines and cancellation. If a job wrapper or Polly also retries, calculate the worst-case number of calls. Two outer attempts and three SDK attempts can produce six underlying calls.
5. Use idempotency safeguards for mutations where the API supports them. A timeout can leave the result unknown even when the first write succeeded.

Retries can add requests, time and downstream load. Billing effects depend on the service, request type and workload. Compare measured request counts and service-specific billing rather than assuming a savings figure. For the application-level side of that policy, see ASP.NET PB’s HTTP resilience guide.

FAQs

Does setting AWS_NEW_RETRIES_2026=false restore the old behavior? The default-rollout versions ignore that flag. Use a supported specific override if a previous value is required.

Did every SDK switch on November 10? The post identifies release versions and exceptions. The installed package determines which behavior applies.

Is Adaptive always better for throttling? Use it when you can scope the client to the appropriate throttling boundary and have measured how it affects latency. Standard is the general-purpose starting point.