AWS Developer Tools Blog

Announcing General Availability of DynamoDB Mapper for Kotlin

Ian Botsford — Mon, 03 Aug 2026 21:03:09 +0000

DynamoDB Mapper for Kotlin is now generally available, giving Kotlin developers a fully idiomatic way to read, write, and query Amazon DynamoDB using natural Kotlin data types without managing low-level API details. Since the Developer Preview launch in October 2024, we’ve added significant new capabilities based on community feedback including the updateItem operation, batch and transaction operations, atomic counters, TTL management, and more. These features make DynamoDB Mapper a complete, production-ready solution for Kotlin developers working with DynamoDB.

DynamoDB Mapper is a high-level library that provides idiomatic ways to map data between your Kotlin data classes and Amazon DynamoDB tables. It handles schema generation, type conversion, and expression building so you can focus on your business logic instead of low-level DynamoDB API details. In this post I demonstrate the features, call patterns, and API of DynamoDB Mapper.

Getting started

Start by adding the DynamoDB Mapper dependencies and schema generator plugin to your Gradle build:

// build.gradle.kts
plugins {
    kotlin("jvm") version "2.4.20"
    id("aws.sdk.kotlin.hll.dynamodbmapper.schema.generator")
}

dependencies {
    implementation("aws.sdk.kotlin:dynamodb-mapper:$sdkVersion")
    implementation("aws.sdk.kotlin:dynamodb-mapper-annotations:$sdkVersion")
}

Annotate a data class and let the plugin generate the schema at build time:

@DynamoDbItem
data class Order(
    @DynamoDbPartitionKey  val customerId: String,
    @DynamoDbSortKey val orderId: String,
    val status: String,
    val totalCents: Long,
    val productSkus: List<String>,
)

Then use the mapper with type-safe operations:

val client = DynamoDbClient.fromEnvironment()
val mapper = DynamoDbMapper(client)
val ordersTable = mapper.getOrderTable("orders")

// Write an item
val order = Order(
    customerId = "customer-123",
    orderId = "ORDER#2026-07-08#001",
    status = "PENDING",
    totalCents = 4_999L,
    productSkus = listOf("SKU-1", "SKU-2"),
)
ordersTable.putItem(order)

// Get an item by its partition key and sort key
val fetched = ordersTable.getItem("customer-123", "ORDER#2026-07-08#001").item

DynamoDB Mapper automatically generates code for your data classes including item schemas (for example, OrderItemSchema) and extension methods (for example, Table.getOrderTable).

Features available since Developer Preview

The Developer Preview release of DynamoDB Mapper supported many fundamental features which are unchanged in the GA release including:

Automatic mapping between DynamoDB items and idiomatic Kotlin types. Work with your own data classes and business types rather than low-level attributes. The mapper uses item schemas to control the transformation of data from your business logic into DynamoDB’s API. This keeps your code type-safe, clean, and maintainable. You can generate schemas automatically from your existing data classes or provide completely custom schema implementations for finer control. For an introduction to the mapping features, see Get started with DynamoDB Mapper.
Annotation-driven schema generation. Add annotations to your existing data classes and the mapper’s schema generator plugin for Gradle generates item converters, schemas, and even extension functions for convenient access to tables. For more details, see Generate a schema from annotations.
Support for the deleteItem, getItem, putItem, queryPaginated, and scanPaginated operations. Key CRUD operations are made available as APIs that closely parallel DynamoDB’s low-level API—except operating on your Kotlin-level types instead of items and attributes. Like the low-level DynamoDB client for Kotlin, the mapper’s operations are fully integrated with Kotlin coroutines. One-shot operations use suspend methods and paginated operations return Flow<T> values. For more details, see Operations overview.
DSL syntax for filter expressions. The Kotlin language provides excellent support for domain-specific languages for more natural interaction with structured data. DynamoDB Mapper continues this tradition with an expressive syntax for defining filter criteria, forming attribute paths, and constructing complex boolean logic. For more details, see Use expressions.
And many more! For a full recap, see Announcing the Developer Preview of DynamoDB Mapper for Kotlin.

What’s new since Developer Preview

The GA release expands on the Developer Preview to add more functionality for key use cases. Here are some of the highlights:

Condition expressions

Filter expressions were available in the Developer Preview for queryPaginated and scanPaginated. In GA, those expressions have been extended to optional conditions in the deleteItem, putItem, and updateItem operations:

ordersTable.putItem {
    item = newOrder
    condition { attr["orderId"].notExists() }
}

ordersTable.deleteItem {
    partitionKey = Key("customer-123")
    sortKey = Key("ORDER#2026-07-08#001")
    condition { attr["status"] eq "CANCELED" }
}

The new batch and transaction operations also support per-action conditions. For more information, see Use expressions.

`updateItem` and update expressions DSL

With the newly-added updateItem operation, you can perform partial, in-place updates on items without fetching and re-writing the entire object. The accompanying update DSL supports all four DynamoDB update actions—SET, REMOVE, ADD, and DELETE—with an idiomatic Kotlin syntax:

ordersTable.updateItem {
    partitionKey = Key("customer-123")
    sortKey = Key("ORDER#2026-07-08#001")
    update {
        set {
            attr["status"] = "SHIPPED"
            attr["totalCents"] = attr["totalCents"] - 500L  // apply a discount
            attr["notes"] = attr["notes"] orElse "none"  // if_not_exists
            attr["productSkus"] = attr["productSkus"] appending listOf("SKU-9")
        }
        remove {
            -attr["couponCode"]  // remove an attribute
        }
        add {
            attr["tags"] += setOf("priority")  // add to a set
        }
        delete {
            attr["tags"] -= setOf("gift")  // remove from a set
        }
    }
}

For more information, see Use expressions.

Batch operations

Operate on items across multiple tables in a single call with batchWriteItem and batchGetItem:

// Batch write: put and delete items in one call in one or more tables
mapper.batchWriteItem {
    table(ordersTable) {
        putItem(Order("customer-123", "ORDER#2026-07-08#001", "SHIPPED", 100_000L, listOf("SKU-1", "SKU-2"))
        putItem(Order("customer-123", "ORDER#2026-07-08#002", "REFUNDED", 39_000L, listOf("SKU-2", "SKU-4"))
        deleteKey(Key("customer-234", "ORDER#2026-07-02#006"))
    }
}

// Batch get: retrieve items by key from one or more tables
val response = mapper.batchGetItem {
    table(ordersTable) {
        key("customer-123", "ORDER#2026-07-08#001")
        key("customer-123", "ORDER#2026-07-08#002")
    }
}
val orders = response.table(ordersTable).items

For more information, see Perform batch operations.

Transactions

Perform all-or-nothing operations across multiple tables with full ACID guarantees:

val ordersTable = mapper.getOrderTable("orders")
val productsTable = mapper.getProductTable("products")
val customersTable = mapper.getCustomerTable("customers")

mapper.transactWriteItems {
    table(ordersTable) {
        put(newOrder) {
            condition { attr["orderId"].notExists() }
        }
    }
    table(productsTable) {
        update(Key("SKU-1")) {
            condition { attr["inventory"] gte 1L }
            update {
                set { attr["inventory"] = attr["inventory"] - 1 }
            }
        }
    }
    table(customersTable) {
        update(Key("customer-123")) {
            condition { attr["balanceCents"] gte 4_999L }
            update {
                set { attr["balanceCents"] = attr["balanceCents"] - 4_999L }
            }
        }
    }
}

Transactional reads are also supported:

val response = mapper.transactGetItems {
    table(ordersTable) { key("customer-123", "ORDER#2026-06-25#0042") }
    table(customersTable) { key("customer-123") }
}
val order = response.table(ordersTable).items.firstOrNull()
val customer = response.table(customersTable).items.firstOrNull()

For more information, see Perform transactional operations.

Atomic counters

Annotate a numeric field with @DynamoDbCounter to have it automatically incremented on every putItem or updateItem call. This feature is useful for view counts, sequence numbers, or inventory tracking:

@DynamoDbItem
data class Product(
    @DynamoDbPartitionKey val sku: String,
    val name: String,
    val category: String,
    val priceCents: Long,
    @DynamoDbCounter var viewCount: Long = 0,
)

For more information, see Built-in features.

TTL management

Annotate an attribute with @DynamoDbTtlSeconds to have DynamoDB Mapper automatically set its value to the current time plus the specified lifetime (in seconds) whenever the item is written. This integrates with DynamoDB’s Time to Live feature to automatically delete expired items:

@DynamoDbItem
data class ShoppingCart(
    @DynamoDbPartitionKey val sessionId: String,
    val productSkus: List<String>,
    @DynamoDbTtlSeconds(lifetime = 86_400) var expiresAt: Long,  // 24-hour TTL
)

For more information, see Built-in features.

Custom attribute converters

Use the @DynamoDbAttributeConverter annotation to specify a custom converter for individual attributes. This is useful for types that DynamoDB Mapper doesn’t handle out of the box, like UUID:

object UuidConverter : ValueConverter<UUID> {
    override fun convertRight(from: UUID): AttributeValue = AttributeValue.S(from.toString())
    override fun convertLeft(from: AttributeValue): UUID = UUID.fromString(from.asS())
}

@DynamoDbItem
data class Order(
    @DynamoDbPartitionKey val customerId: String,
    @DynamoDbSortKey val orderId: String,
    // ...
    @DynamoDbAttributeConverter(UuidConverter::class)
    val idempotencyKey: UUID,
)

For more information, see Manually define schemas.

Secondary index annotations

Secondary index querying was available in Developer Preview, but the GA release adds annotation-driven schema generation for index projections. You can now define a dedicated data class for your index’s projected attributes and generate its schema automatically:

@DynamoDbItem
data class ProductByCategory(
    @DynamoDbPartitionKey val category: String,
    @DynamoDbSortKey val priceCents: Long,
    val sku: String,
    val name: String,
)

// Use with a secondary index
val byCategory = productsTable.getIndex("products-by-category", ProductByCategorySchema)
val cheapElectronics = byCategory
    .queryPaginated {
        keyCondition = KeyFilter("Electronics", { sortKey lt 5_000L })
    }
    .items()

For more information, see Use secondary indexes with DynamoDB Mapper.

Bug fixes since Developer Preview

The following bugs have been fixed since the initial release of Developer Preview:

Fixed key field conversion during paginated Scan and Query operations (#1596)
Fixed schema code generation for nullable List and Map elements (#1590)
Fixed condition expression mapping for operations that support conditions, such as putItem and deleteItem

Breaking changes from Developer Preview

If you were using the Developer Preview release, note these changes when upgrading:

@DynamoDbItem annotation: The converterName: String parameter has been replaced with converter: KClass<...> for type safety.
- Example before: @DynamoDbItem("my.custom.item.converter.MyEmployeeConverter")
- Example now: @DynamoDbItem(MyEmployeeConverter::class)
Converter interfaces refactored: The ItemConverter interface has been replaced with a simple type alias of Converter. Item converter implementations no longer need to identify their keys or perform subset conversions. If you have any custom item converter implementations, they only need to implement convertLeft and convertRight.
Filter → FilterDsl and SortKeyFilter → SortKeyFilterDsl: The expression builder interfaces have been renamed for clarity.
Multi-attribute key types: KeySpec.String / KeySpec.Number / KeySpec.ByteArray have been replaced with KeySpec.Key1 through KeySpec.Key4 supporting composite keys.
- Example before: productsTable.getItem { partitionKey = "SKU-1" }
- Example now: productsTable.getItem { partitionKey = Key("SKU-1") }
@ExperimentalApi annotations removed: All APIs are now stable and production-ready.

Next steps

In this post, I covered how to use some of the new features of DynamoDB Mapper for Kotlin. To get started with your own projects, check out:

We’d love to hear how you’re using DynamoDB Mapper. If you have questions, start a discussion on GitHub. If you’ve found a bug, file an issue on GitHub.

AWS Durable Execution SDK for .NET now Generally Available

Garrett Beatty — Mon, 03 Aug 2026 16:36:23 +0000

The AWS Lambda Durable Execution SDK for .NET is now generally available. AWS Lambda now supports durable executions for .NET, joining the existing Python, TypeScript, and Java SDKs. You install the SDK from NuGet, write your workflows in familiar C#, and deploy them with the AWS Extensions for .NET CLI – the same tools you already use for Lambda functions today.

Your multi-step processes that charge cards, wait for approvals, or call external APIs need to survive interruptions. If your Lambda function times out or crashes between steps, you lose the work it already completed unless you build something to preserve it. On Lambda today, you build that yourself. You persist which steps completed and what each one returned. You retry failed calls, re-trigger the function after a delay, and determine where to resume when the next invocation starts. Every new workflow means more of this plumbing, more edge cases in the resume logic, and more code unrelated to your actual goal.

The AWS Durable Execution SDK handles all that coordination for you. You write your workflow in regular C# syntax. The SDK checkpoints progress after each step, retries failures with configurable backoff, and suspends execution during waits for up to a year without billing you for compute while paused. If something interrupts your function, Lambda re-invokes it. The SDK replays from the last checkpoint and returns the cached result for every step that already completed. Your code reads like straightforward sequential logic. The checkpointing, replay, and recovery happen underneath.

In this post, you build an order processing workflow with the SDK. You use steps, retries, waits, and child contexts, then deploy it to the managed dotnet10 runtime.

How Lambda durable functions work

Lambda durable functions extend the familiar Lambda programming model you already use. Your handler receives an IDurableContext parameter. Its methods provide the durable operations: run checkpointed steps, wait, and receive external callbacks. The runtime uses a checkpoint-and-replay mechanism: after each operation completes, Lambda checkpoints the result. The AWS Durable Execution SDK makes your long-running workflows resilient automatically, so you do not have to write your own state management code.

The core operations on IDurableContext are:

Steps: context.StepAsync runs a unit of work, checkpoints its result, and retries with configurable strategies. On replay, the step returns its cached value instead of running again.
Waits: context.WaitAsync suspends the workflow for a duration, from one second up to a year.
Child contexts: context.RunInChildContextAsync groups related steps into a single logical operation that checkpoints them together.
Callbacks: context.WaitForCallbackAsync suspends the workflow until an external system, such as a human approver, a webhook, or another service, delivers a result.
Parallel and map: context.ParallelAsync and context.MapAsync distribute independent branches concurrently and aggregate their results.

Because the workflow code re-runs from the top on every invocation, it must be deterministic: the same operations, in the same order, on each replay.

Prerequisites

Before you begin, make sure you have the following:

Install the .NET 10 SDK or later.
Configure AWS credentials by running aws configure or set up credentials using your preferred method. For more information, see Configuring the AWS SDK for .NET.
Use credentials with permission to deploy and invoke Lambda functions and to create the function’s execution role. For more information, see Durable functions security.

Getting started

The Durable Function blueprint ships with the Amazon.Lambda.Templates package and scaffolds a complete, deployable workflow. The following .NET CLI commands install the lambda tooling and create a new project from the Durable Function blueprint:

dotnet tool install -g Amazon.Lambda.Tools
dotnet new install Amazon.Lambda.Templates
dotnet new lambda.DurableFunction -n OrderProcessor
cd OrderProcessor

To deploy with a CloudFormation serverless.template using Lambda Annotations, use the serverless.DurableFunction blueprint instead. To add the SDK to an existing project, run the following command:

dotnet add package Amazon.Lambda.DurableExecution

Building a production-ready order processing workflow

The blueprint scaffolds a complete order processing workflow in Function.cs. The function validates an order, charges payment, waits out a settlement period, and ships the order, all as one method.

Setup and entry point

Handler is the Lambda entry point the managed runtime invokes directly (via the Assembly::Type::Method handler string in aws-lambda-tools-defaults.json). DurableFunction.WrapAsync bridges the durable invocation envelope to your strongly-typed ProcessOrder workflow, so the workflow itself works with OrderRequest and OrderResult instead of the raw envelope.

using Amazon.Lambda.Core;
using Amazon.Lambda.DurableExecution;
using Amazon.Lambda.Serialization.SystemTextJson;
using Microsoft.Extensions.Logging;

// The durable runtime reads this serializer off ILambdaContext.Serializer to (de)serialize the
// invocation envelope and every checkpointed step input/output.
[assembly: LambdaSerializer(typeof(DefaultLambdaJsonSerializer))]

namespace OrderProcessor;

public class Function
{
    public Task<DurableExecutionInvocationOutput> Handler(
        DurableExecutionInvocationInput input, ILambdaContext context)
        => DurableFunction.WrapAsync<OrderRequest, OrderResult>(ProcessOrder, input, context);

The workflow method

ProcessOrder receives the order and an IDurableContext, and the following snippets show the method body. Because the workflow re-runs from the top on every invocation, always log through context.Logger. This logger suppresses log lines during replay, so a line appears once even if a 30-step workflow replays 30 times.

public async Task<OrderResult> ProcessOrder(OrderRequest order, IDurableContext context)
{
    // The durable logger is replay-aware: this line is emitted once, not once per replay.
    context.Logger.LogInformation("Processing order {OrderId}", order.OrderId);

Step 1: Validate the order

This is a standard step. StepAsync runs the body, checkpoints the result, and on replay returns the cached value instead of running the body again. The body receives an IStepContext (its own replay-aware logger, the 1-based attempt number, and an operation ID) and a CancellationToken linked to the workflow-shutdown signal. Each StepAsync call is a checkpoint boundary.

var itemCount = await context.StepAsync(
    async (step, _) =>
    {
        await Task.CompletedTask;
        step.Logger.LogInformation("Validating order with {Count} item(s)", order.Items?.Length ?? 0);
        if (order.Items is null || order.Items.Length == 0)
            throw new InvalidOperationException("Order has no items.");
        return order.Items.Length;
    },
    name: "validate_order");

Step 2: Charge payment with retries

Payment gateways can return transient errors, so this step carries a retry policy. RetryStrategy.Exponential retries transient failures with backoff and jitter, and the SDK checkpoints only the successful attempt. The built-in RetryStrategy.Default, RetryStrategy.Transient, and RetryStrategy.None presets cover common cases.

StepSemantics.AtMostOncePerRetry keeps the SDK from silently re-running an attempt’s body if the function is interrupted mid-execution. Use it for non-idempotent side effects like charging a card or sending email, and use the default AtLeastOncePerRetry for idempotent operations.

Note: AtMostOncePerRetry limits re-execution within a single attempt, not across the whole step. A step with retries configured can still run its body again on a later attempt. When an attempt is interrupted, it surfaces as a StepInterruptedException and the retry strategy decides whether to start a new one. If you need the charge to run exactly once, combine AtMostOncePerRetry with RetryStrategy.None.

var transactionId = await context.StepAsync(
    async (step, ct) =>
    {
        // step.AttemptNumber is 1-based and increments on each retry, so log it so retries
        // are visible in the history. Forward ct to any cancellation-aware call (HttpClient,
        // the AWS SDK, Task.Delay) so the body unwinds cleanly if the workflow is torn down.
        step.Logger.LogInformation("Charging payment, attempt {Attempt}", step.AttemptNumber);
        await Task.Delay(TimeSpan.FromMilliseconds(50), ct);
        return $"txn-{order.OrderId}";
    },
    name: "charge_payment",
    config: new StepConfig
    {
        RetryStrategy = RetryStrategy.Exponential(
            maxAttempts: 5,
            initialDelay: TimeSpan.FromSeconds(2),
            maxDelay: TimeSpan.FromSeconds(30),
            backoffRate: 2.0),
        Semantics = StepSemantics.AtMostOncePerRetry,
    });

Step 3: Wait out the settlement period

WaitAsync suspends the workflow for a fixed delay, anywhere from one second up to a year, and the runtime re-invokes the function when the timer fires. While the workflow is suspended, you are not billed for compute.

await context.WaitAsync(TimeSpan.FromSeconds(5), name: "settlement_delay");

Step 4: Ship the order in a child context

RunInChildContextAsync groups related steps into a single logical operation that checkpoints together. The pack and label steps run inside a nested IDurableContext with its own operation-ID space. Checkpoints are what make the crash story work: if the function crashes after charge_payment succeeds but before shipping, replay returns the cached transaction ID and resumes at the wait. The SDK never re-runs a charge that has already succeeded.

var trackingId = await context.RunInChildContextAsync(
    async (childContext, _) =>
    {
        await childContext.StepAsync(
            async (step, _) =>
            {
                await Task.CompletedTask;
                step.Logger.LogInformation("Packing order {OrderId}", order.OrderId);
                return "packed";
            },
            name: "pack");

        return await childContext.StepAsync(
            async (_, _) => { await Task.CompletedTask; return $"trk-{order.OrderId}"; },
            name: "label");
    },
    name: "ship_order");

Returning the result

The workflow finishes by logging completion and returning an OrderResult built from the values each step produced.

context.Logger.LogInformation("Order {OrderId} shipped: {TrackingId}", order.OrderId, trackingId);

return new OrderResult
{
    OrderId = order.OrderId,
    Status = "shipped",
    ItemCount = itemCount,
    TransactionId = transactionId,
    TrackingId = trackingId,
};

The workflow returns a plain OrderResult. The input and output are simple POCOs:

/// <summary>Input payload for the workflow.</summary>
public class OrderRequest
{
    public string? OrderId { get; set; }
    public string[]? Items { get; set; }
}

/// <summary>Output payload returned when the workflow completes.</summary>
public class OrderResult
{
    public string? OrderId { get; set; }
    public string? Status { get; set; }
    public int ItemCount { get; set; }
    public string? TransactionId { get; set; }
    public string? TrackingId { get; set; }
}

Adding a human approval step

The scaffolded workflow runs start to finish on its own. Real order pipelines often need a person in the loop: a manager signs off on a high-value order before it ships. Let’s edit the workflow to pause for that approval.

The following C# snippet adds a callback between the payment and settlement steps in ProcessOrder:

// Pause until a manager approves. The submitter runs once, handing the callback ID
// to whatever will resolve it later: a queue, a webhook, an approval UI.
var approval = await context.WaitForCallbackAsync<ApprovalResult>(
    submitter: async (callbackId, cbContext, ct) =>
    {
        await notificationService.RequestApprovalAsync(order.OrderId, callbackId, ct);
    },
    name: "manager_approval");

notificationService and ApprovalResult here are placeholders for your own integration: the way you notify an approver that a decision is needed, and the shape of the result they send back. This snippet is an example showing where that integration plugs in. Replace these with the notification and response mechanisms your system uses.

When the workflow reaches this point it suspends and waits. The approval system resolves the callback by calling SendDurableExecutionCallbackSuccess (or SendDurableExecutionCallbackFailure) with that ID, and the workflow resumes from exactly where it was suspended. The approval can arrive seconds later or days later.

Deploying the workflow

Durable functions run on the managed dotnet10 runtime and deploy as a standard .zip package. A durable execution always runs against a published function version, so pass --function-publish to publish a numbered version when you deploy. The following .NET CLI command deploys and publishes the function:

dotnet lambda deploy-function --function-publish True

You deploy a durable function with the same command as a standard Lambda function. The only difference is two configuration settings that Amazon.Lambda.Tools exposes:

--durable-execution-timeout (durable-execution-timeout in aws-lambda-tools-defaults.json) – the maximum time in seconds a single durable execution may run before it times out. The blueprint sets 86400 (one day).
--durable-retention-period (durable-retention-period) – optional; the number of days to retain execution history after an execution completes.

An execution timeout is required for a durable function, so always set --durable-execution-timeout.

When the tool creates the function’s execution role for you, it automatically attaches the AWSLambdaBasicDurableExecutionRolePolicy managed policy, which grants the checkpoint permissions a durable function needs at runtime. If you supply your own role with --function-role, attach that policy to it.

Then invoke the function with a sample order. You invoke durable functions asynchronously, so pass --invoke-mode DurableExecution. The following .NET CLI command deploys and invokes the function, streaming the operation history as it goes:

dotnet lambda invoke-function OrderProcessor --payload '{"OrderId":"order-123","Items":["sku-1","sku-2"]}' --invoke-mode DurableExecution

The InvocationCompleted event immediately following settlement_delay: WaitStarted indicates that the function has suspended during the wait. A second invocation then resumes at ship_order and does not repeat the earlier steps. The following output shows the complete execution history for a sample order:

Resolved latest version 1 for function OrderProcessor to ARN: arn:aws:lambda:us-west-2:123456789012:function:OrderProcessor:1
Durable execution ARN: arn:aws:lambda:us-west-2:123456789012:function:OrderProcessor:1/durable-execution/ad36ac33-2bb4-4d90-841a-c5491cb6e6ea/5c4aac8e-26c1-3403-9a1b-18c1a2cd0389

Monitoring durable execution progress:
   [2026-07-06 18:18:34Z] ad36ac33-2bb4-4d90-841a-c5491cb6e6ea: ExecutionStarted
      Execution Timeout: 86400
      Input: {"OrderId":"order-123","Items":["sku-1","sku-2"]}
   [2026-07-06 18:18:36Z] validate_order: StepStarted
   [2026-07-06 18:18:36Z] validate_order: StepSucceeded
      Result: 2
      Current Attempt: 1
   [2026-07-06 18:18:36Z] charge_payment: StepStarted
   [2026-07-06 18:18:36Z] charge_payment: StepSucceeded
      Result: "txn-order-123"
      Current Attempt: 1
   [2026-07-06 18:18:36Z] settlement_delay: WaitStarted
      Duration: 5
      Scheduled End Timestamp: 7/6/2026 6:18:41 PM
   [2026-07-06 18:18:36Z] : InvocationCompleted
      Request Id: 851f7662-5f0f-4381-a2eb-0390668411c9
      Start Timestamp: 7/6/2026 6:18:34 PM
      End Timestamp: 7/6/2026 6:18:36 PM
   [2026-07-06 18:18:41Z] settlement_delay: WaitSucceeded
      Duration: 5
   [2026-07-06 18:18:41Z] ship_order: ContextStarted
   [2026-07-06 18:18:41Z] pack: StepStarted
   [2026-07-06 18:18:41Z] pack: StepSucceeded
      Result: "packed"
      Current Attempt: 1
   [2026-07-06 18:18:41Z] label: StepStarted
   [2026-07-06 18:18:41Z] label: StepSucceeded
      Result: "trk-order-123"
      Current Attempt: 1
   [2026-07-06 18:18:42Z] ship_order: ContextSucceeded
      Result: "trk-order-123"
   [2026-07-06 18:18:42Z] : InvocationCompleted
      Request Id: 764c6852-b351-4385-aac6-86e08d5de914
      Start Timestamp: 7/6/2026 6:18:41 PM
      End Timestamp: 7/6/2026 6:18:42 PM
   [2026-07-06 18:18:42Z] ad36ac33-2bb4-4d90-841a-c5491cb6e6ea: ExecutionSucceeded
      Result: {"OrderId":"order-123","Status":"shipped","ItemCount":2,"TransactionId":"txn-order-123","TrackingId":"trk-order-123"}

Durable execution finished with status: SUCCEEDED
Result:
{"OrderId":"order-123","Status":"shipped","ItemCount":2,"TransactionId":"txn-order-123","TrackingId":"trk-order-123"}

The execution history captures every step, wait, and child context with its result. You can retrieve this history at any time through the durable execution APIs or the Lambda console.

Testing locally

You can test your durable workflows locally with the Amazon.Lambda.DurableExecution. Testing package, no AWS resources required. DurableTestRunner runs your handler in-process against the real durable runtime with an in-memory backend. You can assert on the result and on individual checkpointed steps. This approach enables fast iteration and is especially valuable for agentic workflows with complex execution graphs. The following .NET CLI commands add a test project with the required packages:

dotnet add package Amazon.Lambda.DurableExecution.Testing
dotnet add package xunit.v3
dotnet add package xunit.runner.visualstudio

The following C# test class covers the scaffolded workflow end-to-end, including the happy path and the empty-order failure:

using Amazon.Lambda.DurableExecution.Testing;
using Xunit;

public class FunctionTest
{
    [Fact]
    public async Task ProcessOrder_ShipsOrder()
    {
        var function = new Function();

        // The runner drives the workflow to completion in-process using the real durable runtime
        // with an in-memory backend. SkipTime collapses the settlement WaitAsync delay so the test
        // does not actually block for 5 seconds.
        await using var runner = new DurableTestRunner<OrderRequest, OrderResult>(
            handler: function.ProcessOrder,
            options: new TestRunnerOptions { SkipTime = true });

        var input = new OrderRequest { OrderId = "order-123", Items = new[] { "sku-1", "sku-2" } };

        // TestContext.Current.CancellationToken is xunit.v3's per-test token; the runner honors it.
        var result = await runner.RunAsync(input, cancellationToken: TestContext.Current.CancellationToken);

        result.EnsureSucceeded();
        Assert.Equal("order-123", result.Result!.OrderId);
        Assert.Equal("shipped", result.Result.Status);
        Assert.Equal(2, result.Result.ItemCount);
        Assert.Equal("txn-order-123", result.Result.TransactionId);
        Assert.Equal("trk-order-123", result.Result.TrackingId);

        // Each named operation is checkpointed and inspectable.
        Assert.Equal(OperationStatus.Succeeded, result.GetStep("validate_order").Status);
        Assert.Equal(OperationStatus.Succeeded, result.GetStep("charge_payment").Status);
    }

    [Fact]
    public async Task ProcessOrder_EmptyOrder_Fails()
    {
        var function = new Function();

        await using var runner = new DurableTestRunner<OrderRequest, OrderResult>(
            handler: function.ProcessOrder,
            options: new TestRunnerOptions { SkipTime = true });

        var input = new OrderRequest { OrderId = "order-456", Items = System.Array.Empty<string>() };

        var result = await runner.RunAsync(input, cancellationToken: TestContext.Current.CancellationToken);

        Assert.True(result.IsFailed);
    }
}

Run the tests with the following .NET CLI command:

dotnet test

If you added the approval step, the workflow suspends on the callback instead of completing, so RunAsync no longer applies. The following C# example starts the workflow, waits for it to reach the callback, resolves it, and then waits for the result:

var arn = await runner.StartAsync(input);
var callbackId = await runner.WaitForCallbackAsync(arn, name: "manager_approval");
await runner.SendCallbackSuccessAsync(callbackId, new ApprovalResult("approved", "manager-1"));

var result = await runner.WaitForResultAsync(arn);
result.EnsureSucceeded();

Clean up

If you deployed the function, delete it when you finish to avoid incurring charges:

dotnet lambda delete-function OrderProcessor

If the tooling created an execution role for you and you no longer need it, delete the role and its attached policy as well. The local tests run entirely in-memory and create no AWS resources, so there is nothing to clean up for those.

Conclusion

This order workflow is a starting point. You can use these building blocks to compose much more complex workflows and sub-workflows. Checkpoints mean a crash resumes from the last completed step instead of the top. Configurable retries with at-most-once semantics mean an unreliable payment call never charges a card twice. A suspended workflow can pause for minutes or days without incurring compute charges. You get durable orchestration in the language and tools you already use, instead of custom state management and failure-handling code.

Next steps:

Create a project from the lambda.DurableFunction blueprint and deploy your first workflow to the managed dotnet10 runtime.
Explore the SDK on GitHub for advanced patterns like InvokeAsync and WaitForConditionAsync, and refer to the README for more documentation.
Read the AWS Durable Execution SDK Developer Guide.
Check the AWS Lambda Pricing page to see how paused executions are billed.
Create an issue or a pull request if you have ideas for improvements.

Happy building!

– Garrett

Annual .NET target updates for the AWS SDK for .NET

Norm Johanson — Wed, 29 Jul 2026 21:18:33 +0000

Starting November 2026 the AWS SDK for .NET will adopt a new annual schedule of adding and removing .NET build targets for the SDK.

In April 2025, we released V4 of the AWS SDK for .NET. A major goal of V4 was to modernize the .NET targets supported by the SDK so we can start taking advantage of modern high-performance .NET APIs. Since the V4 release, we have continued working with the community to take advantage of modern .NET and improve performance. Here are some performance improvement PRs from this year.

Now that V4 has established a modern foundation for the AWS SDK for .NET, we want to ensure it stays current. To do this, we are defining a predictable annual schedule for adding and removing .NET targets from the SDK.

Background

Across AWS there are many .NET NuGet packages published, and not all packages are considered part of the AWS SDK for .NET. The NuGet packages that are referred to as the AWS SDK for .NET are the core library AWSSDK.Core package and the individual AWS service packages that follow the naming pattern AWSSDK.<service-name> such as AWSSDK.S3 or AWSSDK.SQS.

Today, the V4 AWS SDK for .NET builds for the following targets:

.NET Framework 4.7.2
.NET Standard 2.0
.NET Core 3.1
.NET 8

The .NET Framework 4.7.2 target supports our .NET Framework customers. There is no end-of-life schedule for .NET Framework 4.7.2 from Microsoft, and we will continue to include this target for the foreseeable future. The .NET Standard 2.0 target is currently required for AWS Tools for PowerShell. That means the .NET Standard 2.0 target will also be included for the foreseeable future.

As documented by the Microsoft .NET support cycle modern cross-platform .NET has new major versions released every November, with every other year being an LTS (Long Term Support) release with 3 years of support and the alternating years being STS (Standard Term Support) with 2 years of support.

The case for a defined schedule

Until now, the SDK has only added a new .NET build target when there were new APIs in a .NET release that we wanted to take advantage of. For example, in 2023, we added the .NET 8 target to support Native AOT. This approach works because the SDK only depends on the base .NET runtime, which maintains very strong backward compatibility between releases.

However, this ad hoc approach has led to several issues:

Customer confusion: Customers see in NuGet the latest target is .NET 8 and conclude that we haven’t updated the SDK for .NET 10, thinking we are behind.
Unclear target removal: Without a defined schedule, old .NET targets linger with the SDK building technical debt that reduces the amount of effort that can be spent optimizing for the latest .NET version. These old .NET targets also make it harder for community members to build the SDK because it requires them to have versions well past end of support installed in their development environment.
Delayed feature adoption: Without a schedule, new .NET features require a one-off decision about whether to add a new target, which can result in features being delayed indefinitely with no clear timeline for adoption.

A defined schedule addresses all of these issues by setting clear expectations for both our team and the users of the SDK.

The schedule

Every year, the SDK will be updated to add the build target for the current year’s release. We will attempt to align as closely as possible with the .NET November release cycle but may fall back to December depending on demands for other priorities, particularly for AWS re:Invent. The list of .NET targets will contain at most two LTS versions. If adding the new target would bring the total to three LTS versions, the oldest LTS is removed along with any STS versions that precede the new oldest LTS version.

This schedule gives an additional year of AWS SDK support from AWS after Microsoft has declared end of life for the .NET runtime. That is six months longer than the AWS SDK’s documented Maintenance policy because it provides a better alignment with the .NET yearly release cycle.

Each yearly update of .NET targets will be released as a new minor version of the SDK. In November 2026 we will release V4.1; in November 2027 V4.2; and so on. While the product version receives the minor version bump, the assembly version compiled into the binary will remain 4.0.0. The assembly version is part of the assembly identity. Other assemblies bind to this identity when referenced as a dependency during compilation. This means third-party libraries compiled against V4.0 will continue to work without recompilation because the assembly identity doesn’t change. This follows the same versioning practice we used with V3, ensuring backward compatibility for all third-party libraries.

Yearly target examples

The following examples show how the target list evolves each year. LTS versions are bolded and removed targets are ~~struck out~~.

November 2026 (V4.1)

Because this is the first year the schedule applies, it will be handled as a special case. We will add the .NET 10 LTS version and remove .NET Core 3.1, which has been end of life since December 2022. By the schedule, we would also add the STS .NET 9 target, but adding a target at the time it is going out of support is unnecessary.

.NET Framework 4.7.2
.NET Standard 2.0
~~.NET Core 3.1 (LTS) (Removed)~~
.NET 8 (LTS)
.NET 10 (LTS)
.NET 11 (STS)

November 2027 (V4.2)

The .NET 8 target is removed because it would become a third LTS version.

.NET Framework 4.7.2
.NET Standard 2.0
~~.NET 8 (LTS) (Removed)~~
.NET 10 (LTS)
.NET 11 (STS)
.NET 12 (LTS)

November 2028 (V4.3)

Only the new .NET 13 STS is added and nothing is removed. You can continue to use .NET 10 and .NET 11 for another year even though they have reached Microsoft end of life.

.NET Framework 4.7.2
.NET Standard 2.0
.NET 10 (LTS) (Microsoft end of life)
.NET 11 (STS) (Microsoft end of life)
.NET 12 (LTS)
.NET 13 (STS)

November 2029 (V4.4)

The new .NET 14 LTS is added, triggering the removal of .NET 10 (the oldest LTS) and .NET 11 (STS older than the new oldest LTS).

.NET Framework 4.7.2
.NET Standard 2.0
~~.NET 10 (LTS) (Removed)~~
~~.NET 11 (STS) (Removed)~~
.NET 12 (LTS)
.NET 13 (STS)
.NET 14 (LTS)

What this means for you

For most of you, this schedule is transparent. NuGet will resolve the best matching target for your application automatically. If you are using a .NET version that is no longer a build target in the latest SDK minor version, you have two options:

Stay on the previous SDK minor version. There will be no new releases for the previous minor version, so you will not receive any more SDK updates.
Update to the latest SDK version. NuGet will resolve to the .NET Standard 2.0 version of the SDK. For most use cases, .NET Standard 2.0 provides the functionality you need, though it will be missing some target-specific optimizations. For example, if you were using .NET 8 and updated to V4.2 in 2027 when .NET 8 was dropped, you would fall back to .NET Standard 2.0, losing Native AOT support and .NET 8+ performance optimizations.

Conclusion

This schedule brings predictability to how the SDK evolves with the .NET ecosystem. You will always know that the latest .NET version is supported by the end of the year of its release, and you will have a full year of additional AWS SDK support after Microsoft ends support for a .NET version.

Installing and updating the AWS CLI with single-line commands

Steve Yoo — Tue, 28 Jul 2026 14:55:26 +0000

The AWS Command Line Interface v2 (AWS CLI) can now be installed and updated using single-line commands.

Previously, to install the AWS CLI, you had to download the correct installer for your platform and architecture, configure the installation path, and manually run the installer. To update the AWS CLI, you had to repeat the same installation steps.

To simplify these workflows, we released install scripts that automatically download, configure, and run official AWS CLI installers. We also released aws update, a new command that updates the current AWS CLI installation to the latest version.

In this post, you’ll learn to install the AWS CLI with an install script and update to the latest version with aws update. Before getting started, ensure your system meets the minimum requirements to use AWS CLI installers. See our documentation for details.

Installing

To install, use the following platform-specific guides to download and execute the install script.

macOS and Linux

Run the following command in a terminal. By default, the AWS CLI is installed for the current user in $HOME/.local/share/aws-cli and symlinks are created in $HOME/.local/bin.

curl -fsSL 'https://awscli.amazonaws.com/v2/install.sh' | bash

You can configure the user install location by setting the following environment variables:

XDG_DATA_HOME (default $HOME/.local/share/aws-cli)
XDG_BIN_HOME (default $HOME/.local/bin)

To install for all users system-wide, pass the script’s --system flag. This will install the AWS CLI in /usr/local/aws-cli and create symlinks in /usr/local/bin. Note that this requires root permissions.

curl -fsSL 'https://awscli.amazonaws.com/v2/install.sh' | sudo bash -s -- --system

Windows

Run the following command in PowerShell. By default, the AWS CLI is installed for the current user in %LOCALAPPDATA%\Programs\Amazon\AWSCLIV2.

irm 'https://awscli.amazonaws.com/v2/install.ps1' | iex

To install for all users system-wide, pass the script’s -System flag. This will install the AWS CLI in %ProgramW6432%\Amazon\AWSCLIV2. Note that this requires an elevated shell with administrator privileges.

irm 'https://awscli.amazonaws.com/v2/install.ps1' -OutFile install.ps1; try { .\install.ps1 -System } finally { Remove-Item install.ps1 }

Updating

Starting with version 2.36.0, you can upgrade to the latest AWS CLI version by running aws update. The update command detects and reuses the current AWS CLI installation path.

aws update is supported only for installations managed by an official installer, install script, or the update command itself.

Conclusion

We’ve made it easier to install the AWS CLI using install scripts and upgrade to the latest version using the aws update command. We recommend that you use these new tools instead of the installers to get started faster. To learn more, visit our docs on installing and updating the AWS CLI.

Please share your questions, comments, and issues with us on GitHub.

Updating TypeScript version support in AWS SDK for JavaScript v3

Abhinav Goyal — Wed, 15 Jul 2026 16:07:03 +0000

We’re updating TypeScript version support in the AWS SDK for JavaScript v3. Starting January 4, 2027, the SDK will require TypeScript versions published within the last 2.5 years. Read on to learn what’s changing, why this change is necessary, and what actions you may need to take.

We built the AWS SDK for JavaScript with TypeScript-first development in mind, designed to deliver smaller artifacts while taking advantage of modern TypeScript features. This support policy update also aligns the SDK with the broader TypeScript ecosystem.

What’s changing and why

This change applies only if you use TypeScript with the AWS SDK for JavaScript v3.

The TypeScript ecosystem has broadly converged on supporting only recent compiler versions:

DefinitelyTyped, the central repository for community-maintained TypeScript type definitions (hosting types for 8,000+ npm packages including @types/node and @types/react), only tests packages against TypeScript versions less than 2 years old. For more information, see Support Window on GitHub.
typescript-eslint, the most widely used TypeScript linting framework, mirrors the DefinitelyTyped support window and only supports TypeScript versions less than 2 years old.

Real-world applications depend on many packages beyond the SDK. Once the broader ecosystem drops an older version, you’re likely to encounter incompatible typings regardless.

We are aligning with this ecosystem norm. The SDK will follow the DefinitelyTyped support window plus a 6-month grace period, giving you up to a 2.5-year window to upgrade your TypeScript version. For more information, see AWS SDKs and Tools maintenance policy.

The following table shows the end-of-support timeline for each TypeScript version:

TypeScript version	Release Date	DefinitelyTyped end-of-support	JS SDK end-of-support
<=5.5	June 20, 2024	June 20, 2026*	January 4, 2027
5.6	September 24, 2024	September 24, 2026*	March 31, 2027
5.7	November 22, 2024	November 22, 2026*	May 31, 2027
5.8	March 5, 2025	March 5, 2027*	September 30, 2027
5.9	August 1, 2025	August 1, 2027	February 29, 2028

* Speculative, based on the DefinitelyTyped support window.

What you can expect

A clear minimum supported TypeScript version

We will document a minimum TypeScript version in the GitHub repository’s README and will keep it updated as part of the normal maintenance process. We define “supported” as:

We build and test the SDK against TypeScript versions within the support window.
We may not address issues specific to out-of-window TypeScript versions.

Smaller package artifacts and simpler publishing

This change reduces build and release complexity, published package size, and AWS Lambda artifact size.

What you need to do

You don’t need to take immediate action. If your project uses a TypeScript version within the support window, no changes are needed. For projects on an older TypeScript version, your existing setup will continue to work as long as you don’t update the SDK version. However, we recommend that you upgrade your TypeScript version to continue receiving the latest SDK updates.

You have two options for staying compatible with the SDK:

Option 1: Upgrade TypeScript to a supported version (recommended)

Upgrade TypeScript in your dev dependencies.
Run your project’s type check to validate your code against the new TypeScript version.
Address any new diagnostics.

Tip: Newer compilers often catch issues that older versions missed, so new diagnostics might reveal real bugs in your code.

Option 2: Pin the AWS SDK for JavaScript v3 packages

Pin @aws-sdk/* dependencies to the last version that supported your TypeScript version. This prevents short-term disruption, but you won’t receive newer SDK updates, security patches, or new features.

FAQ

Is this a runtime breaking change?

No. This change affects type-level compatibility (your build) and the SDK’s ability to ship types efficiently. This can cause build failures with older (unsupported) TypeScript compilers.

Why not keep downleveling indefinitely?

Downleveling hasn’t been required since TypeScript 4.7, which was published in May 2022. Down-leveling makes every release heavier:

Downlevel types account for 18% of the published package size in the SDK.
Downleveling is an additional step in the SDK’s release process.

Conclusion

We recommend upgrading to a supported TypeScript version ahead of this change to keep receiving updates, security patches, and new features. For the current minimum supported version, see AWS SDK for JavaScript v3 README on GitHub.

We’d love to hear from you. Open a discussion or issue on our GitHub.

AWS CLI v1 maintenance mode: announcing changes to dependency updates

Kenneth Daily — Wed, 10 Jun 2026 18:31:56 +0000

When version 1 of the AWS Command Line Interface (AWS CLI v1) enters maintenance mode on July 15, 2026, the way its botocore and s3transfer dependencies are bundled will change. This post explains these changes and provides steps to minimize impacts on your workflows and applications. For more information about AWS CLI v1 maintenance mode, refer to the blog post CLI v1 Maintenance Mode Announcement.

Background

The AWS CLI v1 is built on top of two foundational Python libraries:

botocore is the low-level library that provides AWS service definitions, request signing, response parsing, and retry logic. When AWS launches a new service or adds new API operations to an existing service, those changes are delivered through botocore updates.
s3transfer is the library that manages Amazon S3 file transfers, including multipart uploads, parallel downloads, and transfer configuration. High-level S3 commands in the AWS CLI rely on s3transfer, such as aws s3 cp and aws s3 sync.

What’s happening?

Currently, each version of the AWS CLI v1 depends on specific versions of botocore and s3transfer. These dependencies are installed as separate packages. This means that upgrading the AWS CLI v1 also brings in a newer version of these packages. Starting with maintenance mode, botocore and s3transfer will be vendored (bundled and packaged directly) into the AWS CLI v1 codebase. The AWS CLI v1 will no longer rely on the standalone packages. This represents a significant shift in how dependencies are managed within the AWS CLI v1.

If you rely on automatic dependency updates when upgrading the AWS CLI v1, this behavior will change. The AWS CLI v1 will include its own internal copies of botocore and s3transfer. Updates to these internal copies will only occur when AWS releases a new version of CLI v1. Installing or upgrading the standalone botocore or s3transfer packages will have no effect on the versions used by the AWS CLI v1.

botocore and s3transfer will continue to be developed and released as separate packages, because they are also dependencies of the AWS SDK for Python (boto3). However, those standalone package updates will not affect the AWS CLI v1—the CLI will only use its own bundled copies.

How you may be affected

Upgrading the AWS CLI v1 will no longer upgrade the standalone botocore and s3transfer packages. The AWS CLI v1 will use only its own internal copies, and the standalone packages will remain at whatever version is independently installed.

If your environment has both the AWS CLI v1 and boto3 installed, they will each use their own separate copies of botocore and s3transfer. Updating either the AWS CLI or boto3 will not affect the other’s dependencies. Additionally, because the AWS CLI v1 will bundle its own copies of botocore and s3transfer alongside the standalone packages used by boto3, environments with both installed will contain two copies of these libraries.

Updates to the standalone botocore and s3transfer packages will continue as before, since they are also dependencies of boto3. However, those updates will not reach the AWS CLI v1 unless a new AWS CLI v1 version is released with updated internal copies. As described in the maintenance mode announcement, new AWS CLI v1 versions will only be released to address critical bug fixes and security issues.

Recommended actions

To stay updated with the latest AWS services and features, we recommend that you migrate to AWS CLI v2. To learn more about transitioning to AWS CLI v2, refer to the Migration guide for the AWS CLI version 2. Additionally, verify if your workflows rely on botocore or s3transfer brought into your environment via the AWS CLI v1. If you have other applications in the same environment that consume them, you may need to explicitly pin their dependency versions. Be sure to validate your existing scripts and automation with the new maintenance mode releases. Last, monitor the AWS CLI changelog to stay informed about new AWS CLI v1 versions and vendored dependency updates.

Conclusion

As the AWS CLI v1 enters maintenance mode on July 15, 2026, the botocore and s3transfer dependencies will be vendored, which may affect your workflows and scripts. While the CLI v1 will continue to receive critical updates, we encourage you to migrate to AWS CLI v2 for the latest features and improvements.

Feedback

If you need migration assistance or have feedback, reach out to your usual AWS support contacts. You can also open an issue on GitHub. Thank you for using the AWS CLI!

Introducing Open-Source Skills for AWS SDK Best Practices

David Yaffe — Tue, 02 Jun 2026 18:54:26 +0000

We released a set of AWS SDK Skills as part of the open-source Agent Toolkit for AWS. These are AI skills that teach coding agents how to follow AWS SDK best practices. The project is available on GitHub under the Apache-2.0 license.

The problem

AI coding agents know the general shape of AWS SDK usage, but they get the details wrong. They generate incorrect API names, use incorrect parameter types, and miss SDK-specific patterns like paginators, waiters, and high-level APIs such as the transfer manager for Amazon Simple Storage Service (Amazon S3). These errors are especially common for newer SDKs like the AWS SDK for Swift, where agents generate code that looks plausible but fails to compile.

As developers increasingly rely on AI agents to write AWS SDK code, we need to make sure those agents produce code that compiles, follows best practices, and uses each SDK the way it was intended to be used.

What’s in a skill

Skills are modular packages that give AI coding agents specialized SDK knowledge. Each skill is authored by the SDK team that owns the language, so it reflects the things agents consistently get wrong for that specific SDK. A skill includes:

SKILL.md — core instructions with SDK-specific patterns and concrete examples
references/ — on-demand documentation for deeper topics, loaded only when needed
scripts/ — automation for build, test, and validation workflows

Skills are agent-agnostic. They work with any coding agent that supports the open skills format.

Common mistakes skills help prevent

Code that doesn’t compile. This is the most common failure mode for newer SDKs where the agent’s training data is thin or out of date. The AWS SDK for Swift uses Swift concurrency throughout. Operations are async-throwing, and so are the convenience client constructors. Agents frequently miss this and produce code that looks reasonable but doesn’t build:

// What agents tend to write. Does not compile.
let client = S3Client()
let response = client.listBuckets(input: ListBucketsInput())

Both lines are wrong: S3Client() is async throws, and so is listBuckets. With the Swift skill installed, the agent writes the modern Swift concurrency form:

let config = try await S3Client.S3ClientConfig(region: "us-west-2")
let client = S3Client(config: config)
let response = try await client.listBuckets(input: ListBucketsInput())

The first version sends the developer back to the docs to figure out why a plausible-looking line won’t build. The second one runs.

Code that runs but performs poorly or costs more. Agents often skip SDK features that exist precisely to make AWS calls efficient: paginators for ListObjects and similar APIs, waiters for resource-state polling, and the SDK’s high-level file methods like upload_file / download_file for large transfers. A handwritten loop that calls ListObjects without pagination silently drops results past the first page, polling code without waiters burns API calls and risks throttling, and manual file I/O for S3 transfers gives up multipart uploads and parallelism. The code compiles and often appears to work in small tests, but breaks once you’re dealing with real data volumes. With a skill installed, the agent reaches for the right SDK feature for the job: paginators for list operations, waiters for state polling, and the high-level transfer methods for files.

Code that runs but has subtle bugs. Manually marshalling DynamoDB types like {"S": "value"} is easy to get slightly wrong in ways that fail only on certain inputs. Catching a generic Exception instead of typed exceptions like ConditionalCheckFailedException makes retry logic swallow real failures. With a skill installed, the agent reaches for the document client (which handles the conversion correctly) and uses typed exceptions tied to the actual operations it’s calling.

Measuring the impact

We evaluate each skill against a benchmark of real SDK tasks (Amazon S3 operations, Amazon DynamoDB queries, client configuration, presigned URL generation, credential management) and grade the generated code on whether it compiles, passes lint, and actually does what the task asked for (judged by an LLM). Every task runs twice: once with no skill installed, and once with the relevant skill loaded.

Across our test suite, code generated with a skill installed consistently passed more checks than code generated without one.

Available skills

The following table summarizes the skills available at launch:

Skill	SDK	What it covers
`aws-sdk-swift-usage`	AWS SDK for Swift	Async patterns, struct-based config types, client initialization
`aws-sdk-js-v3-usage`	AWS SDK for JavaScript v3	Package structure, client styles, middleware, runtime validation
`aws-sdk-python-usage`	Boto3 / botocore	Client vs. resource interfaces, paginators, waiters, error handling

Get started

You’ll need a coding agent that supports the open skills format. To install a skill from the Agent Toolkit for AWS, run:

npx skills add aws/agent-toolkit-for-aws/skills --skill <skill>

Replace <skill> with the one you want:

aws-sdk-swift-usage
aws-sdk-js-v3-usage
aws-sdk-python-usage

Or pass --skill multiple times to install more than one.

If your favorite SDK is missing or you’ve seen agents make mistakes that aren’t covered yet, open an issue or submit a skill. Visit the repository on GitHub to try it out.

Announcing the General Availability of the AWS IoT Device SDK for Swift

Vera Xia — Mon, 01 Jun 2026 23:15:34 +0000

We are excited to announce the General Availability (GA) of the AWS IoT Device SDK for Swift. This release gives Swift developers a production-ready SDK with stable APIs and integrated service clients to connect applications to AWS IoT Core.

What’s New

The GA release now provides easy-to-configure service clients for three essential AWS IoT Core services:

AWS IoT Device Shadow: Synchronize and share data between devices, apps, and other cloud services.
AWS IoT Jobs : Manage remote operations that can run on devices connected to AWS IoT Core.
Device provisioning: Automatically create the certificates and policies needed for secure communication, eliminating manual certificate management.

The SDK supports macOS, iOS, tvOS, and Linux, with X.509 certificate-based authentication and TLS 1.3 encryption on iOS and tvOS. For a detailed overview of platform and security capabilities, see Introducing the AWS IoT Device SDK for Swift (Developer Preview).

Getting Started

The SDK provides service client samples (Device Shadow, Jobs, and Device provisioning) on the GitHub website. The following walkthrough demonstrates how to set up a Shadow client and retrieve a shadow state.

Prerequisites

Before you start with the service client, set up the required AWS IoT resources: For more information, see What is AWS IoT? and Create AWS IoT resources.

After you complete these steps, you will have three items required for client configuration:

Your IoT endpoint
Your X.509 certificate file
Your associated private key file

Use AWS IoT Shadow client

Step 1: Add the SDK dependency

The IoT Shadow client is a product within the aws-iot-device-sdk-swift package. Add the package as a dependency and reference the Shadow client in your target’s Package.swift file:

let package = Package(
    name: "MyApp",
    dependencies: [
        .package(
            url: "https://github.com/aws/aws-iot-device-sdk-swift.git", 
            from: "1.0.0"
        ),
    ],
    targets: [
        .executableTarget(
            name: "MyApp",
            dependencies: [
                .product(name: "IotShadowClient", package: "aws-iot-device-sdk-swift"),
            ]
        )
    ]
)

Step 2: Create an MQTT 5 client

Before you create a Shadow client, create an MQTT 5 client. This example uses the endpoint and certificate files from the Prerequisites section.

// Create an Mqtt5ClientBuilder configured using a certificate and private key
let clientBuilder = try Mqtt5ClientBuilder.mtlsFromPath(
         endpoint: self.endpoint, 
         certPath: self.cert, 
         keyPath: self.key)

// Create the MQTT5 client using the Mqtt5ClientBuilder and start a connection session
let client = try builder.build()        
client.start()

For more information about the certificates, see X.509 client certificates.

Step 3: Create the Shadow client

After you start the MQTT 5 client, configure the client options and create the Shadow client. These options to cap the client’s subscription usage and reserve capacity for other parts of your IoT application.

Configure the following options based on your application’s subscription needs:

maxRequestResponseSubscription: Maximum number of concurrent subscriptions that request-response client uses. Each request usually uses 1-2 subscriptions until completion.
maxStreamingSubscription: Maximum number of concurrent streaming operation subscriptions that the client will allow. Set based on the number of streaming operations you plan to use simultaneously.
operationTimeout: Request timeout in seconds.

The following example creates a Shadow client with values that work well for applications that use a single shadow with limited streaming operations. Adjust these values based on your application’s needs:

// Set up options for the MqttRequestResponseClient
let options = MqttRequestResponseClientOptions(
        maxRequestResponseSubscription: 3,
        maxStreamingSubscription: 2,
        operationTimeout: 5)
 
// Create a Shadow client using the MQTT5 client and the options created above
let shadowClient = try IotShadowClient(mqttClient: client, options: options)

Step 4: Perform Shadow Operations

With the Shadow client ready, you can perform operations such as retrieving, updating, or deleting a shadow state. The following example retrieves a named shadow state:

let request: GetShadowRequest = GetShadowRequest(thingName: inputThingName)
do {
       let response = try await shadowClient.getShadow(request: request)
} catch {
       // Log errors
}

For more information, see the Shadow sample on the GitHub website. Additional service client samples are also available on GitHub:

Known Limitations

The SDK has the following known limitations:

TLS 1.3 on macOS: While TLS 1.3 is not currently supported on macOS, we are actively developing support and will add it in a future release. This limitation does not affect iOS, tvOS, or Linux platforms.
HTTP Proxy Support: HTTP proxy support is available on macOS and Linux only; it is not currently supported on iOS and tvOS.

For updates on these limitations, see GitHub Discussions.

Conclusion

In this post, we showed you how to get started with the AWS IoT Device SDK for Swift from adding the SDK dependency to performing shadow operations. The SDK also includes clients for Jobs and Device Provisioning. Use the Jobs client to manage remote device operations or the Device Provisioning client to automate certificate creation at scale.

For more information, see Getting started with AWS IoT Core tutorials and connect your first device to AWS IoT Core.

Let us know how you’re using the SDK in the comments. You can also:

Share ideas and ask questions in GitHub Discussions.
Report issues through GitHub Issues.

AWS SDK for .NET V3 end-of-support announcement

Muhammad Othman — Mon, 01 Jun 2026 19:14:51 +0000

As previously announced, version 3 of the AWS SDK for .NET entered maintenance mode on March 1, 2026. In alignment with our SDKs and Tools Maintenance Policy, AWS SDK for .NET V3 has now reached end-of-support as of June 1, 2026.

Starting June 1, 2026, there are no plans for further updates or releases for V3, including security fixes. Previously published releases should continue to be available via NuGet and the source code will remain on GitHub.

What this means for you

If you are still using AWS SDK for .NET V3, your existing applications should continue to function. However, you should be aware of the following:

No new service support: V3 will not receive updates for new AWS services or new features for existing services.

No security patches: V3 will no longer receive security fixes. If a vulnerability is discovered, it will only be addressed in V4.

No bug fixes: No further bug fixes will be released for V3.

Migrating to V4

We strongly encourage all customers still on V3 to migrate to AWS SDK for .NET V4 as soon as possible. V4 includes performance enhancements, bug fixes, and continued support for AWS services and regions.

To help with your migration:

Review the Migration Guide to understand the breaking changes.

Update and test your applications with V4 in a development environment before updating production.
If you encounter issues during migration, open an issue on our GitHub repository.

Conclusion

AWS SDK for .NET V3 has reached end-of-support. We strongly recommend migrating to V4 to continue receiving security updates, bug fixes, and support for AWS services. Migration documentation is available to guide you through the update process.

For any questions or issues that arise while updating to the V4 SDK, please utilize the GitHub repository’s discussion forums or open GitHub issues to reach out to us. If you find dependencies that are preventing you from updating to V4, please let us know to see if we can help.

AWS Tools for PowerShell V4 end-of- support announcement

Muhammad Othman — Mon, 01 Jun 2026 19:14:48 +0000

As previously announced, version 4 of the AWS Tools for PowerShell entered maintenance mode on March 1, 2026. In accordance with our SDKs and Tools Maintenance Policy, AWS Tools for PowerShell V4 has now reached end-of-support as of June 1, 2026.

Starting June 1, 2026, there are no plans for further updates or releases for V4, including security fixes. Previously published releases should continue to be available via the PowerShell Gallery and the source code will remain on GitHub.

What this means for you

If you are still using AWS Tools for PowerShell V4, your existing scripts and automation should continue to function. However, you should be aware of the following:

No new service support: V4 will not receive cmdlets for new AWS services or new features for existing services.

No security patches: V4 will no longer receive security fixes. If a vulnerability is discovered, it will only be addressed in V5.

No bug fixes: No further bug fixes will be released for V4.

Migrating to V5

We strongly encourage all customers still on V4 to migrate to AWS Tools for PowerShell V5 as soon as possible. V5 includes performance enhancements, bug fixes, and continued support for AWS services and regions.

To help with your migration:

Review the Migration Guide to understand the breaking changes.

Update and test your scripts with V5 in a development environment before updating production.

If you encounter issues during migration, open an issue on our GitHub repository.

Conclusion

AWS Tools for PowerShell V4 has reached end-of-support. We strongly recommend migrating to V5 to continue receiving security updates, bug fixes, and support for AWS services. Migration documentation is available to guide you through the update process.

For any questions or issues that arise while updating to the V5, please utilize the GitHub repository’s discussion forums or open GitHub issues to reach out to us. If you find dependencies that are preventing you from updating to V4, please let us know to see if we can help.

Introducing multipart download support for AWS Tools for PowerShell v5

Sanket Tangade — Mon, 01 Jun 2026 19:04:35 +0000

The new multipart download support in AWS Tools for PowerShell v5 improves the performance of downloading large objects from Amazon Simple Storage Service (Amazon S3) compared to the single-stream downloads. The Read-S3Object and Copy-S3Object cmdlets now deliver faster download speeds through an opt-in switch parameter -UseMultipartDownload for multipart downloads, reducing the need for complex code to manage concurrent connections, handle retries, and coordinate multiple download streams. It uses the AWS SDK for .NET v4 S3 Transfer Manager under the hood to execute the downloads.

In this post, we’ll show you how to configure and use these new multipart download capabilities, including downloading single objects and directories, choosing between download strategies, customizing parallelism settings, and migrating your existing download methods to take advantage of these performance improvements.

Parallel download using part numbers and byte-ranges

For download operations, Read-S3Object and Copy-S3Object now support both part number and byte-range fetches. Part number fetches download the object in parts, using the part number that Amazon S3 assigned to each object part during upload. Byte-range fetches download the object with byte ranges and work on objects, regardless of whether they were originally uploaded using multipart upload or not. The transfer manager splits your GetObject request into multiple smaller requests, each of which retrieves a specific portion of the object. The transfer manager executes your requests through concurrent connections to Amazon S3.

Choosing between part number and byte-range strategies

Choose between part number and byte-range downloads based on your object’s structure. Part number downloads (the default) work best for objects uploaded with standard multipart upload part sizes. If the object is a non-multipart object, choose byte-range downloads. Range downloads facilitate greater parallelization when objects have large parts and work with S3 objects regardless of the upload method that was used.

Keep in mind that smaller range sizes result in more S3 requests. Each API call incurs a request cost beyond the data transfer itself, so balance parallelism benefits against the number of requests for your use case.

Now that you understand the download strategies, let’s get started.

Getting started

To get started with multipart downloads in AWS Tools for PowerShell, follow these steps:

Update your module

Update AWS Tools modules to latest version. Available from version 5.0.208 and later.

 # Modular (recommended)
PS> Update-Module AWS.Tools.S3

# Or monolithic
PS> Update-Module AWSPowerShell.NetCore

# Or Windows PowerShell monolithic
PS> Update-Module AWSPowerShell

Download an object to file

To download an object from an Amazon S3 bucket to a local file with multipart support, add the -UseMultipartDownload switch to your Read-S3Object command. You must provide the source bucket, the S3 object key, and the destination file path.

# Download large file with multipart support (Part number strategy)
PS> $response = Read-S3Object -BucketName amzn-s3-demo-bucket -Key "data/large-dataset.zip" `
    -File "C:\downloads\large-dataset.zip" `
    -UseMultipartDownload
	
$response.ContentRange
$response.ETag
$response.ChecksumType
# And other 33 response object parameters.

# Download using byte-range strategy (works with any S3 object)
PS> Read-S3Object -BucketName amzn-s3-demo-bucket -Key "data/any-object.dat" `
    -File "C:\downloads\any-object.dat" `
    -UseMultipartDownload `
    -MultipartDownloadType RANGE `
    -PartSize 16MB

You can customize the following options:

# Custom concurrent connections (default is 10) (Linux based example)
PS> Read-S3Object -BucketName amzn-s3-demo-bucket -Key "data/large-file.bin" `
    -File "/home/user/downloads/large-file.bin" `
    -UseMultipartDownload `
    -MultipartDownloadType RANGE `
    -PartSize 64MB `
    -ConcurrentServiceRequest 20

Experiment with these values to find the best configuration for your use case. Factors like object size and available network bandwidth will influence which settings work best.

Download a directory

To download multiple objects from an S3 bucket prefix to a local directory, use the -KeyPrefix and -Folder parameters with -UseMultipartDownload. The cmdlet automatically applies multipart download to each individual object in the directory.

# Download entire directory with multipart support for large files
PS> Read-S3Object -BucketName amzn-s3-demo-bucket -KeyPrefix "data/" `
    -Folder "C:\downloads\data" `
    -UseMultipartDownload `
    -ConcurrentServiceRequest 10 `
    -DownloadFilesConcurrently

The -DownloadFilesConcurrently parameter facilitates file-level parallelism, downloading multiple files at the same time. When combined with -UseMultipartDownload, each individual file also benefits from part-level parallelism, providing high throughput for directory downloads containing many large files.

Using Copy-S3Object

The same multipart download parameters are available on Copy-S3Object for S3-to-local download operations.

PS> $response = Copy-S3Object -BucketName -Key "data/large-file.bin" `
    -LocalFile "C:\downloads\large-file.bin" `
    -UseMultipartDownload `
    -MultipartDownloadType RANGE `
    -PartSize 16MB
$response.ContentRange
$response.ETag
$response.ChecksumType
# And other 33 response object parameters.

Note: The multipart download parameters only apply to S3-to-local download operations in Copy-S3Object. They are not available for S3-to-S3 copy operations.

New parameters at a glance

	Parameter	Description
1	`-UseMultipartDownload`	Opt-in switch for multipart parallel download
2	`-MultipartDownloadType`	`PART` (default) or `RANGE`
3	`-PartSize`	Part size for RANGE mode (e.g., `8MB`, `64MB`, `1GB`). Default is 8 MB
4	`-ConcurrentServiceRequest`	Maximum number of parallel HTTP connections. Default is 10
5	`-DownloadFilesConcurrently`	File-level parallelism for directory downloads
6	`-FailurePolicy`	`AbortOnFailure` (default) or `ContinueOnFailure` for directory downloads

Migration path

The new -UseMultipartDownload parameter comes with both multipart performance as well as access to S3 response metadata. Here’s how to migrate your existing code:

# Existing code (still works but returns legacy response object System.IO.FileInfo) 
PS> Read-S3Object -BucketName amzn-s3-demo-bucket -Key "data/large-dataset.zip" -File "C:\downloads\large-dataset.zip"

For directory downloads:

# Existing code (still works but returns legacy response object System.IO.DirectoryInfo) 
PS> Read-S3Object -BucketName amzn-s3-demo-bucket -KeyPrefix "data/" -Folder "C:\downloads\data"

# Enhanced version with multipart support (returns S3 response metadata) 
PS> Read-S3Object -BucketName amzn-s3-demo-bucket -KeyPrefix "data/" `
    -Folder "C:\downloads\data" `
    -UseMultipartDownload `
    -ConcurrentServiceRequest 10 `
    -DownloadFilesConcurrently

Conclusion

The multipart download support in AWS Tools for PowerShell provides performance improvements for downloading large objects from Amazon S3. By using parallel byte-range or part-number fetches, you can reduce transfer times. This feature is fully opt-in and available in all three module variants: AWS.Tools.S3, AWSPowerShell.NetCore, and AWSPowerShell.

Next steps: Try implementing multipart downloads in your scripts and measure the performance improvements for your specific use cases.

To learn more about AWS Tools for PowerShell, visit the AWS Tools for PowerShell documentation. For questions or feedback about this feature, visit the GitHub issues page. For more details on the underlying multipart download engine, see the AWS SDK for .NET blog post.

Announcing updated retry behavior for AWS SDKs and Tools

Matthew Miller — Wed, 20 May 2026 18:42:23 +0000

When your application calls an AWS service and the request fails with a retryable error, the AWS SDK retries it automatically. The retry behavior controls how long the SDK waits between attempts and when it gives up. Most of this happens in the background, but it directly affects how your application experiences errors and latency.

Until today, retry defaults varied across SDKs. Some waited too long before retrying transient errors, and others would keep retrying instead of failing fast, even during sustained outages. The updated behavior addresses both issues with consistent defaults across all AWS SDKs.

You can opt in to the updated behavior starting today across AWS SDKs, the AWS Command Line Interface (AWS CLI), and AWS Tools for PowerShell. These changes will become the default in November 2026.

This post covers what changed, how to tell if you’re affected, how to opt in, and how to revert.

What changed

This update changes how standard and adaptive (a rate-limiting mode built on standard) retry modes handle failed requests. It also makes standard the default for SDKs that had previously defaulted to legacy.

Most SDKs use the standard retry mode by default. It includes a retry quota, exponential backoff with jitter, and a standard set of retryable errors. Some older SDKs still default to legacy mode, which lacks a retry quota and behaves inconsistently across SDKs. For a full comparison, see Retry behavior.

Retry quota updates

standard mode has always included a retry quota: a token bucket that tracks how many retries your client is making. When failures are persistent, the budget depletes and the SDK stops retrying. At scale, this helps outages resolve faster (retry traffic from many clients can delay recovery) and reduces your client-side latency by failing fast instead of waiting through retries that are unlikely to succeed.

If you were using legacy mode, this is new to you. legacy mode had no standardized retry quota, so the SDK would keep retrying up to the max attempt count regardless of how many requests were failing.

In the updated standard mode, each transient error retry costs 14 tokens (up from 5 in the previous version of standard mode). Retries after throttling responses cost 5 tokens. The higher cost for transient errors means the quota engages sooner during sustained outages, letting the service recover faster. For a deeper look at how the retry quota works, see Retry quota (token bucket).

Faster retries for transient errors

The first retry after a transient error is now much faster, about 25 ms on average for a brief HTTP 503 response, down from hundreds of milliseconds or more.

standard mode now uses different backoff delays depending on the type of error:

Transient errors (connection resets, DNS failures, HTTP 500/502/503/504): 50 ms base delay. These errors are typically short-lived, making them good candidates for immediate retry.
Throttling errors (where the service asks you to slow down): 1,000 ms base delay. A longer delay gives the service time to recover capacity.

Previously, each SDK applied the same base delay regardless of error type, but that delay varied across SDKs, from 10 ms to 1,000 ms.

Amazon DynamoDB tuning

Amazon DynamoDB and Amazon DynamoDB Streams use a shorter base backoff delay (25 ms instead of 50 ms) to match their low-latency profile. These clients default to 4 max attempts. The additional attempt keeps the last retry’s maximum backoff comparable to other services. Previous defaults varied by SDK (up to 10 max attempts in some SDKs). For details, see DynamoDB in the retry behavior documentation.

Long-polling operations

Long-polling operations (such as the Amazon SQS ReceiveMessage operation) now apply a backoff delay before returning an error when the retry quota is depleted. Without this, a depleted quota returns the error immediately, which can cause polling loops to tighten, spiking CPU usage on the client and generating additional load on the service. For details, see Long-polling operations documentation.

Does this impact me?

This update changes behavior within standard and adaptive retry modes. Whether you’re affected depends on your current configuration:

No explicit retry configuration at all? You will see all the changes after you opt in (or after the default rollout in November 2026). For SDKs that currently default to legacy mode (Java, Python, Ruby, PHP, C++, and the AWS CLI), this also switches the default to standard, which adds a retry quota.
Explicitly set retry mode to standard or adaptive? You will see the new backoff timing, retry quota costs, and DynamoDB defaults. Your mode choice doesn’t change, but how these modes behave does.
Explicitly set max_attempts or backoff settings? Those specific values stay as you configured them. Other settings you didn’t override (such as retry quota costs and DynamoDB defaults) will still update to the new defaults.
Explicitly set retry mode to legacy? No changes. legacy mode is unchanged.
Haven’t set AWS_NEW_RETRIES_2026=true? No changes until the default rollout in November 2026.

How to opt in

Set the following environment variable:

export AWS_NEW_RETRIES_2026=true

The flag works across all AWS SDKs that have released support. See SDK availability and GitHub issues below for which SDKs support the flag today.

We recommend testing on a non-production workload first.

Where you might notice a difference

For most workloads, the update is invisible or an improvement. Transient errors recover faster and you don’t need to change any code.

A few things to watch for:

Max attempts may have decreased. Some SDKs previously defaulted to more than 3 max attempts. If your workload relied on a high retry count to eventually succeed, you may see more errors surfaced to your application. You can override max_attempts to restore your previous value.
Some SDKs gain a retry quota for the first time. SDKs that previously defaulted to legacy mode had no standardized retry quota. The SDK will retry up to the max attempt count regardless of how many requests were failing. With standard mode, the SDK tracks a 500-token budget and stops retrying during sustained failures. Your application sees errors sooner during prolonged outages, but it also frees up threads and connections instead of waiting on retries that are unlikely to succeed.
The retry quota activates sooner for transient errors. The higher transient retry cost means the quota depletes at a lower failure rate during sustained transient failures, such as a wave of 500 responses.

For SDK-specific before and after values, see your SDK’s GitHub tracking issue in the table below.

How to revert

Remove or unset the opt-in environment variable:

unset AWS_NEW_RETRIES_2026

After the default rollout in November 2026, the opt-in flag is ignored. To revert at that point, override individual settings such as max_attempts or backoff configuration. See your SDK’s GitHub tracking issue for revert instructions specific to your SDK.

For SDKs that support legacy mode (Java, Python, Ruby, PHP, C++, and the AWS CLI), you can also restore the previous behavior in a single setting:

export AWS_RETRY_MODE=legacy

SDK availability and GitHub issues

Eight SDKs support the opt-in flag today. Six more are coming in the following weeks.

SDK	Opt-in available	GitHub tracking issue
Java 2.x	Available	Tracking issue
Python (boto3)	Available	Tracking issue
.NET	Available	Tracking issue
PowerShell	Available	Tracking issue
JavaScript 3.x	Available	Tracking issue
PHP	Available	Tracking issue
Kotlin	Available	Tracking issue
Rust	Available	Tracking issue
Swift	Coming soon	Tracking issue
Ruby	Coming soon	Tracking issue
Go 2.x	Coming soon	Tracking issue
C++	Coming soon	Tracking issue
AWS CLI	Coming soon	Tracking issue

Each tracking issue includes: minimum SDK version, before-and-after defaults, code examples, and a feedback section.

Conclusion

This update brings consistent, faster retry defaults across all AWS SDKs. You can opt in today by setting AWS_NEW_RETRIES_2026=true and revert at any time if you need to. We encourage you to try it on a non-production workload first, then roll it out to production before the defaults change in November 2026. If you don’t opt in before then, the new behavior will apply automatically.

Give us feedback

If you run into unexpected behavior, or if the changes work well for you, comment on your SDK’s GitHub tracking issue. Your feedback during the opt-in window helps us make the default rollout better for everyone.

Learn more

Retry behavior: retry mode selection, settings, and configuration precedence.
How retries work: backoff formula, error classification, retry quota mechanics, and service-specific behavior.

Announcing AWS SDK for Swift’s Transfer Manager for Amazon S3

Chan Yoo — Mon, 04 May 2026 21:45:13 +0000

We are pleased to announce the general availability of the Amazon S3 Transfer Manager for Swift – a high level file and directory transfer utility for the Amazon Simple Storage Service (Amazon S3) built with the AWS SDK for Swift.

Using Transfer Manager’s simple API, you can perform accelerated uploads of local files and directories to Amazon S3 and accelerated downloads of objects and buckets from Amazon S3 and benefit from enhanced throughput and reliability, which is achieved through concurrent transfers of a set of small parts from a single object. The Transfer Manager is built on top of the AWS SDK for Swift and leverages Amazon S3 multipart upload and byte-range / part-number fetches for parallel transfers. You can also track the progress of transfers in real-time as well.

Parallel upload via multipart upload

For the upload operation, the Transfer Manager uses the Amazon S3 multipart upload API; it sends multiple UploadPart requests concurrently behind the scenes to achieve high performance.

Parallel download via byte-ranges or part numbers

For the download operation, the Transfer Manager utilizes byte-range fetches or part number fetches. Byte range fetches download the object with byte ranges and works on all objects, regardless of whether it was originally uploaded using multipart upload or not. Part number fetches download the object in parts, using the part number assigned to each object part during upload. The transfer manager splits one GetObject request to multiple smaller requests, each of which retrieves a specific portion of the object. Those requests are also executed through concurrent connections to Amazon S3.

Getting Started

To get started with Amazon S3 Transfer Manager for Swift, complete the following steps:

Add the dependency to your Xcode project

Open your project in Xcode and click on your .xcodeproj file, located at the top of the file navigator on the left pane.
Click the project name that appears on the left pane of the .xcodeproj file window.
Click on Package Dependencies tab, and click + button.
In Search or Enter Package URL search bar, enter git@github.com:aws/aws-sdk-swift-s3-transfer-manager.git.
Wait for package to load, and once it’s loaded, choose the target you want to add the S3TransferManager module to.

Add the dependency to your Swift package

Add the below to your package definition:

dependencies: [
    .package(
        url: "https://github.com/aws/aws-sdk-swift-s3-transfer-manager.git",
        from: "<VERSION_STRING>"
    )
],

Add an S3TransferManager module dependency to the target that needs it. For example:

targets: [
    .target(
        name: "YourTargetThatUsesS3TM",
        dependencies: [
            .product(
                name: "S3TransferManager",
                package: "aws-sdk-swift-s3-transfer-manager"
            )
        ]
    )
]

Initialize the S3 Transfer Manager

You can initialize an S3TM instance with all-default settings by simply doing this:

// Creates and uses default S3TM config & S3 client.
let s3tm = try await S3TransferManager()

Or you can pass a configuration object to the initializer to customize S3TM, like this:

// Create the custom S3 client config that you want S3TM to use.
let customS3ClientConfig = try S3Client.S3ClientConfig(
    region: "us-west-2",
    . . . custom S3 client configurations . . .
)

// Create the custom S3TM config with the S3 client config initialized above.
let s3tmConfig = try await S3TransferManagerConfig(
    s3ClientConfig: customS3ClientConfig,
    targetPartSizeBytes: 10 * 1024 * 1024, // 10MB part size.
    multipartUploadThresholdBytes: 100 * 1024 * 1024, // 100MB threshold.
    multipartDownloadType: .part
)

// Finally, create the S3TM using the custom S3TM config.
let s3tm = S3TransferManager(config: s3tmConfig)

For more information about what each configuration does, please refer to the documentation comments on S3TransferManagerConfig.

Upload an object

To upload a file to Amazon S3, you need to provide the input struct UploadObjectInput, which contains a subset of PutObjectInput struct properties and an array of transfer listeners. You must provide the destination bucket, the S3 object key to use, and the object body.

When object being uploaded is bigger than the threshold configured by multipartUploadThresholdBytes (16MB default), S3TM breaks them down into parts, each with the part size configured by targetPartSizeBytes (8MB default), and uploads them concurrently using S3’s multipart upload feature.

// Construct UploadObjectInput.
let uploadObjectInput = UploadObjectInput(
    body: ByteStream.stream(
        FileStream(fileHandle: try FileHandle(forReadingFrom: URL(string: "file-to-upload.txt")!))
    ),
    bucket: "destination-bucket",
    key: "some-key"
)

// Call .uploadObject and save the returned task.
let uploadObjectTask = try s3tm.uploadObject(input: uploadObjectInput)
let uploadObjectOutput = try await uploadObjectTask.value

Download an object

To download an object from Amazon S3, you need to provide the input struct DownloadObjectInput, which contains the download destination, a subset of GetObjectInput struct properties, and an array of transfer listeners. The download destination is an instance of Swift’s Foundation.OutputStream. You must provide the download destination, the source bucket, and the S3 object key of the object to download.

When object being downloaded is bigger than the size of a single part configured by targetPartSizeBytes (8MB default), S3TM downloads the object in parts concurrently using either part numbers or byte ranges as configured by multipartDownloadType (.part default).

// Construct DownloadObjectInput.
let downloadObjectInput = DownloadObjectInput(
    outputStream: OutputStream(toFileAtPath: "destination-file.txt", append: true)!,
    bucket: "source-bucket",
    key: "s3-object.txt"
)

// Call .downloadObject and save the returned task.
let downloadObjectTask = try s3tm.downloadObject(input: downloadObjectInput)
let downloadObjectOutput = try await downloadObjectTask.value

Conclusion

To learn more about how to use the Amazon S3 Transfer Manager for Swift including how to upload a directory, download a bucket, and track transfer progress, visit our README.md on GitHub. Try out the new Transfer Manager today and let us know what you think via the GitHub issues page!

About the authors

Create minimal reproductions for AWS SDK JavaScript v3 with create-aws-sdk-repro

John Lwin — Thu, 23 Apr 2026 18:37:18 +0000

We’re excited to announce create-aws-sdk-repro, an open source tool that generates ready-to-run AWS SDK for JavaScript v3 projects.

You answer a few prompts, pick a service, an operation, environment, and the tool generates a project with everything wired up. With AWS credentials configured, it’s ready to run. In this post, we walk through how the tool works, what it generates, and how to use it.

Use cases

Getting started with a new service

Instead of piecing together documentation and examples, generate a working project for any AWS service in seconds. The correct imports, credential handling, and error handling are already in place.

Testing SDK behavior

Quickly spin up isolated projects to test specific SDK operations without affecting your main codebase.

Troubleshooting SDK issues

If you run into an SDK issue, generate a minimal repro with your service and operation, run it, and share the output in your GitHub issue. A clean project without framework dependencies makes it easier to isolate the problem and get to a resolution faster.

Walkthrough

In this walkthrough, you will generate a Node.js project that calls the Amazon S3 ListBuckets operation in the us-west-2 AWS Region. Each step shows which option to select so you can follow along.

Prerequisites

Install Node.js version 20 or later. See Node.js downloads for instructions.
For Node.js projects, configure AWS credentials by running aws configure. For more information, see Configuring the AWS SDK for JavaScript.
For Browser and React Native projects, set up an Amazon Cognito identity pools. The tool generates a COGNITO_SETUP.md guide with step-by-step instructions. For more information, see Amazon Cognito identity pools.

Step 1: Run the CLI

$ npm create @aws-sdk/repro

Step 2: Select your environment

The CLI prompts for the JavaScript environment:

? Select JavaScript environment: › - Use arrow-keys. Return to submit.
❯   Node.js
    Browser
    React Native

Node.js uses the default AWS credentials chain. Browser generates a Vite-based project with Amazon Cognito identity pools for browser-safe credentials. React Native creates a full native project with required polyfills.

Step 3: Enter a project name

? Enter project name: aws-sdk-repro-a1b2c3d4

The tool suggests a default name with the prefix aws-sdk-repro- followed by a random identifier for uniqueness. You can enter a custom name. The name must be non-empty and cannot contain the characters / \ : * ? " < > | or path traversal sequences (..). For React Native projects, the name is further sanitized to alphanumeric characters only. For this walkthrough, press Enter to use the default.

Step 4: Select an AWS service

? Select or search for AWS service: s3

The tool provides autocomplete across @aws-sdk/client-* packages and matches anywhere in the client name. For example, typing ‘s3’ or ‘dynamo’ filters the list to matching packages. It also suggests corrections for typos. For a full list of supported services, see the AWS SDK for JavaScript v3 client packages.

Step 5: Wait for operation discovery

Fetching available operations for S3...
  Installing @aws-sdk/client-s3...
  Found 107 operations
  Client: S3Client

The tool temporarily installs the SDK package in a temporary directory and scans it for available command classes (e.g., ListBucketsCommand, PutObjectCommand).

Step 6: Select an operation

? Select or search for operation (kebab-case): list-buckets

Step 7: Select a Region

? Select or enter AWS region: us-west-2 - US West (Oregon)

Regions across commercial, GovCloud, and China partitions are available with autocomplete. GovCloud and China Regions require separate AWS accounts with specific access. For more information, see Managing AWS Regions.

Step 8: Review the generated project

The tool creates a project directory with the following files:

// index.js
import { S3Client, ListBucketsCommand } from '@aws-sdk/client-s3';

try {
  const client = new S3Client({ region: 'us-west-2' });
  const input = {}; // Add your input parameters here
  const command = new ListBucketsCommand(input);
  const response = await client.send(command);
  console.log('Success:', response);
} catch (error) {
  console.error('Error:', error);
}

// package.json
{
  "name": "aws-sdk-repro-a1b2c3d4",
  "version": "1.0.0",
  "type": "module",
  "dependencies": {
    "@aws-sdk/client-s3": "latest"
  },
  "scripts": {
    "start": "node index.js"
  }
}

The generated code imports the correct client class (S3Client) and command (ListBucketsCommand) directly from the SDK package. It uses the default credentials chain, so it works with aws configure or environment variables. Error handling is included, and the input object is empty and ready for you to add request parameters.

Step 9: Run the generated project

cd aws-sdk-repro-a1b2c3d4
npm install
npm start

For operations like ListBuckets, DescribeInstances, or ListTables, the empty input object works without additional parameters. For operations that require parameters, add them to the input object in index.js. IDE autocomplete will show available fields since the types are already imported.

The walkthrough above shows a Node.js project. For Browser, the tool generates an index.html, index.js with Cognito credentials, a Vite config, and a COGNITO_SETUP.md guide. For React Native, it scaffolds a full native project with App.js, required polyfills, and Cognito setup. Both include step-by-step instructions for configuring a Cognito identity pools.

Clean up

The generated projects are standalone directories on your local machine. To clean up:

rm -rf aws-sdk-repro-a1b2c3d4

If you created a Cognito identity pools for Browser or React Native testing, delete the Cognito identity pools and any associated IAM roles that are no longer needed. There are no ongoing AWS costs from the tool itself. Standard API pricing applies only when you run the generated project and make API calls.

Conclusion

create-aws-sdk-repro automates the setup for creating a minimal SDK project. Pick a service, operation, Region, and environment (Node.js, Browser, or React Native) – the tool handles the rest: correct client imports, credentials configuration, error handling, and a project that runs immediately. It works across Node.js, Browser (with Amazon Cognito), and React Native, covering the most common environments where developers use the AWS SDK for JavaScript v3.

Whether you’re getting started with a new AWS service, testing SDK behavior in isolation, or troubleshooting an issue, the tool gives you a clean project without the setup overhead. Less time on configuration, more time on the actual work.

For more on the AWS SDK for JavaScript v3, see our Developer Guide and the API Reference.

If you’re working with browser credentials, the Amazon Cognito identity pools documentation covers setup in detail.

Your feedback is greatly appreciated. You can engage with the AWS SDK for JavaScript team directly by opening a discussion or issue on our GitHub repository.

About the authors

Smithy Java client framework is now generally available

Manuel Sugawara — Mon, 06 Apr 2026 17:41:04 +0000

Smithy Java client code generation is now generally available. You can use it to build type-safe, protocol-agnostic Java clients directly from Smithy models. With Smithy Java, serialization, protocol handling, and request/response lifecycles are all generated automatically from your model. This removes the need to write or maintain any of this code by hand.

In this post, you will learn what Smithy Java client generation is, how it works, what makes it different, and how you can use it. Modern service development is built on strong contracts and automation. Smithy provides a model-driven approach to defining services and generating code from those definitions. It produces clients, services, and documentation from a single source of truth that stays aligned with your API as it evolves. Smithy Java client code generation enforces protocol correctness and removes serialization boilerplate, so you can focus on building features instead of hand-writing requests and responses.

How it works

At a high level, Smithy Java client code generation transforms Smithy models into strongly typed Java clients.

Model-driven development

At the core of the workflow is modeling services using Smithy. You define services, operations, and data shapes in a declarative format that captures API structure, constraints, and protocol bindings. These models act as the canonical definition of the API surface. For example:

namespace com.example

use aws.api#service
use smithy.protocols#rpcv2Cbor

@title("Coffee Shop Service")
@rpcv2Cbor
@service(sdkId: "CoffeeShop")
service CoffeeShop {
    version: "2024-08-23"
    operations: [
        GetMenu
    ]
}

@readonly
operation GetMenu {
    output := {
        items: CoffeeItems
    }
} 
...

Smithy Java consumes the models and produces Java client code. The generated output includes typed operations, serializers, deserializers, and protocol handling.

For more information about writing Smithy models, see Smithy’s quick start documentation.

Generated clients

The generated clients support a range of features that are typical for client-service communication, including request/response handling, serialization, protocol negotiation, retries, error mapping, and custom interceptors. You only need to define them in the model, and Smithy Java writes the code for you.

The following is an example of a generated Java client:

var client = CoffeeShopClient.builder()
    .endpointProvider(EndpointResolver.staticEndpoint("http://localhost:8888"))
    .build();

var menu = client.getMenu();

You can regenerate clients after API changes to the model, keeping them up to date without writing any manual code.

For more information about how to start generating Java clients from Smithy models, see our quick start guide.

Key capabilities

Protocol flexibility

Smithy Java generated clients are protocol-agnostic. The framework includes built-in support for HTTP transport, AWS protocols (including AWS JSON 1.0/1.1, restJson1, restXml and Query), and Smithy RPCv2 CBOR. You can swap protocols at runtime without rebuilding the client, enabling gradual protocol migrations and multi-protocol support with no code changes.

Dynamic client

Not every use case requires code generation at build time. Smithy Java includes a dynamic client that loads Smithy models at runtime and can interact with any service API without a codegen step. This is particularly useful for building tools, service aggregators, or systems that must interact with unknown services at build time, all while keeping the deployment footprint small.

The following is an example of calling the Coffee Shop service using the DynamicClient :

var model = Model.assembler().addImport("model.smithy").assemble().unwrap();
var serviceId = ShapeId.from("com.example#CoffeeShop");
var client = DynamicClient.builder().model(model).serviceId(serviceId).build();
var result = client.call("GetMenu");

Shape code generation independent of services

Smithy Java can generate type-safe Java classes from Smithy shapes without any service context. This extends Smithy’s model-first approach beyond service calls into the data and logic layers of your system, enabling code reuse and consistency across projects that share common types.

Built on Java virtual threads

Smithy Java is built from the ground up around Java 21’s virtual threads. Instead of exposing complex async APIs with callbacks or reactive streams, it provides a blocking-style interface that is straightforward to read, write, and debug, without sacrificing performance. Users can concentrate on their business logic while letting Smithy Java and the JVM handle task scheduling, synchronization, and structured error handling.

The following example demonstrates using Amazon Transcribe with Smithy’s Java event streams blocking API. To send an event, Smithy clients use a EventStreamWriter<T> with a write(T event) method, and to receive an event the client uses EventStreamReader with a T read() method. For example:

// Create an Amazon Transcribe client
var client = TranscribeClient.builder().build();
var audioStream = EventStream.<AudioStream>newWriter();

// Create a stream transcription request
var request = StartStreamTranscriptionInput.builder().audioStream(audioStream).build();

// Create a VT to send the audio that we want to transcribe
Thread.startVirtualThread(() -> {
    try (var audioStreamWriter = audioStream.asWriter()) {
        for (var chunk : iterableAudioChunks()) {
            var event = AudioEvent.builder().audioChunk(chunk).build()
            audioStreamWriter.write(AudioStream.builder().audioEvent(event).build());
        }
    }
});

// Send the request to Amazon Transcribe
var response = client.startStreamTranscription(request);

// Create a VT to read the transcription from the audio.
Thread.startVirtualThread(() -> {
    // The reader
    try (var results = response.getTranscriptResultStream().asReader()) {
        // The reader implements Iterable
        for (var event : results) {
            switch (event) {
                case TranscriptResultStream.TranscriptEventMember transcript -> {
                    var transcriptText = getTranscript(transcript);
                    if (transcriptText != null) {
                        appendAudioTranscript(transcriptText);
                    }
                }
                default -> throw new IllegalStateException("Unexpected event " + event);
            }
        }
    }
});

Conclusion

In this post, I explained what Smithy Java client generation is and how it works. With this general availability release, Smithy Java’s public APIs are now stable; we commit to backwards compatibility, making it ready for use in production systems. To get started with Smithy Java client code generation, use our quick start guide and documentation. If you want to send us feedback, ask a question, or discuss, you can reach us through GitHub issues and GitHub discussions.

About the author

Smithy Kotlin client code generation now generally available

Omar Perez — Thu, 02 Apr 2026 15:24:42 +0000

Smithy Kotlin client code generation is now generally available. With Smithy Kotlin, you can keep client libraries in sync with evolving service APIs. By using client code generation, you can reduce repetitive work and instead, automatically create type-safe Kotlin clients from your service models. In this post, you will learn what Smithy Kotlin client generation is, how it works, and how you can use it.

Modern service development increasingly relies on strong contracts, automation, and consistency. Smithy provides a model-driven approach to defining services and enables code generation from those definitions, helping you to produce reliable clients from a single source of truth.

How it works

At a high level, Smithy Kotlin client code generation transforms Smithy service models into strongly typed Kotlin clients. This process bridges the gap between API design and implementation, producing code that handles serialization, protocol details, and request/response lifecycles automatically.

Model-driven development

At the core of the workflow is modeling services using Smithy. You can define services, operations, and data shapes in a declarative format that captures structure, constraints, and protocol bindings. These models specify the canonical definition of the API surface. For example:

namespace com.example

use aws.api#service
use smithy.protocols#rpcv2Cbor

@title("Coffee Shop Service")
@rpcv2Cbor
@service(sdkId: "CoffeeShop")
service CoffeeShop {
    version: "2024-08-23"
    operations: [
        GetMenu
    ]
}

@http(method: "GET", uri: "/menu")
@readonly
operation GetMenu {
    output := {
        items: CoffeeItems
    }
}

Smithy Kotlin consumes the models and produces Kotlin client code. The generated output includes typed operations, serializers, and deserializers, maintaining alignment between the model and client implementation.

For more information about writing Smithy models, see Smithy’s quick start documentation.

Clients

The generated clients support a range of features typical for service communication, including request/response handling, serialization, protocols, and error mapping. You only need to define them in the model and Smithy Kotlin writes the code for you. Because Smithy Kotlin targets Kotlin and generated clients run on the Java Virtual Machine (JVM), they integrate naturally with existing language tools. You can incorporate them into modern build systems, use concurrency features, and combine them with established libraries and frameworks already used in Kotlin. An example of a generated Kotlin client:

CoffeeShopClient {
    endpointProvider = CoffeeShopEndpointProvider {
        endpointUrl = Url.parse("http://localhost:8888")
    }
}.use { client ->
    val menu = client.getMenu()
}

For more information about how to start generating Kotlin clients from Smithy models, see the client generation guide.

What does general availability mean?

Smithy Kotlin has been in development and available in developer preview for a few years. This milestone reflects production readiness, stability, and broader confidence in adopting the generated clients as part of standard development workflows.

Conclusion

In this blog post, we covered what Smithy Kotlin client generation is, how it works, and how you can use it. To get started with Smithy Kotlin client code generation see the quick start example and documentation page. If you’d like to share feedback, ask a question, or discuss, you can reach us through GitHub issues and GitHub discussions.

About the author

Upgrading AWS CLI From v1 to v2 Using the Migration Tool

Ahmed Moustafa — Fri, 27 Mar 2026 22:53:53 +0000

Upgrading from AWS Command Line Interface (AWS CLI) v1 to AWS CLI v2 brings valuable improvements, but requires attention to several changes that may affect your existing workflows, such as failing commands, or misconfiguration.

The AWS CLI v1-to-v2 Migration Tool helps you identify and resolve issues before upgrading, making transition easier. It analyzes bash scripts containing AWS CLI v1 commands where behavior differs in AWS CLI v2. The tool will either suggest a change to a command or guide you to resolve a potential risk. It can also automatically create an updated version of the script with implemented changes. Where applicable, the migration tool will change the commands in a way that preserves AWS CLI version 1 behavior.

The AWS CLI v1-to-v2 Migration Tool is a standalone tool compatible with any version of AWS CLI v1, and does not require executing AWS CLI commands. Compared to Upgrade Debug Mode, an alternative solution built into AWS CLI version 1.44.0 or later, the Migration Tool offers broader compatibility and works independently of your CLI installation. For a thorough comparison between the Upgrade Debug Mode and the AWS CLI v1-to-v2 Migration Tool see Choosing Between Upgrade Debug Mode and AWS CLI v1-to-v2 Migration Tool in our Migration guide for the AWS CLI version 2.

In this post, we’ll walk you through using AWS CLI v1-to-v2 Migration Tool to identify potential breaking changes, resolve compatibility issues, and safely transition your scripts to v2.

Prerequisites

Before you begin, you’ll need Python version 3.9 or later, and pip installed on your machine. See the Prerequisites in Using AWS CLI v1-to-v2 Migration Tool to upgrade AWS CLI version 1 to AWS CLI version 2 for instructions to install these prerequisites.

Getting Started

You’ll start by installing the AWS CLI v1-to-v2 Migration Tool. Then, you’ll use this tool to analyze bash scripts for AWS CLI v1 commands that may need to be updated before upgrading to AWS CLI v2. Then, you’ll review the AWS CLI v2 breaking changes list in the Migration guide for the AWS CLI version 2 to manually verify whether your workflows may be broken by upgrading, and safely upgrade to AWS CLI v2.

Step 1: Install the AWS CLI v1-to-v2 Migration Tool

See Installation in Using AWS CLI v1-to-v2 Migration Tool to upgrade AWS CLI version 1 to AWS CLI version 2 for instructions to install the AWS CLI v1-to-v2 Migration Tool.

Step 2: Lint a bash script using interactive mode

Next, you’ll run the migration tool in interactive mode. Interactive mode walks you through each flagged command one at a time. For each detection, it will suggest a change to make the command have the same behavior in AWS CLI v2.

For this blog post, we’ll use the following example bash script, which uses AWS CLI v1 to upload an AWS CloudFormation template to Amazon Simple Storage Service (Amazon S3), copy the template to a backup Amazon S3 bucket, and create a CloudFormation stack from the template.

#!/bin/bash
set -e

TEMPLATE="$1"
BUCKET="$2"
BACKUP="$3"
STACK_NAME="$4"

if [ -z "$TEMPLATE" ] || [ -z "$BUCKET" ] || [ -z "$BACKUP" ] || [ -z "$STACK_NAME" ]; then
    echo "Usage: $0 <template-file> <bucket> <backup-bucket> <stack-name>"
    exit 1
fi

TMPKEY="cloudformation/$(basename "$TEMPLATE")"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_KEY="cloudformation/$TIMESTAMP-$(basename "$TEMPLATE")"

# Upload template
aws s3 cp $TEMPLATE s3://$BUCKET/$TMPKEY

# Copy template to backup bucket
aws s3 cp s3://$BUCKET/$TMPKEY s3://$BACKUP/$BACKUP_KEY

# Create a stack from the template
aws cloudformation create-stack \
  --stack-name "$STACK_NAME" \
  --template-body "https://s3.amazonaws.com/$BUCKET/$TMPKEY"

echo "Stack creation initiated. Stack ID: $(
  aws cloudformation describe-stacks \
    --stack-name "$STACK_NAME" \
    --query 'Stacks[0].StackId' \
    --output text \
    --cli-input-json file://describe_stacks_input.json
)"

You will use the command below to use the migration tool to analyze the bash script upload_s3_files.sh, suggest fixes, and write the modified script to the path upload_s3_files_v2.sh in interactive mode. For the sake of demonstration, this blog post does not include every finding that gets detected in the example script:

$ migrate-aws-cli --script upload_s3_files.sh --output upload_s3_files_v2.sh \
  --interactive
  
19 19│ aws s3 cp $TEMPLATE s3://$BUCKET/$TMPKEY
20 20│ 
21 21│ # Copy template to backup bucket
22   │-aws s3 cp s3://$BUCKET/$TMPKEY s3://$BACKUP/$BACKUP_KEY
   22│+aws s3 cp s3://$BUCKET/$TMPKEY s3://$BACKUP/$BACKUP_KEY --copy-props none
23 23│ 
24 24│ # Create a stack from the template
25 25│ aws cloudformation create-stack \

script.sh:22 [s3-copy] In AWS CLI v2, object properties will be copied from the 
source in multipart copies between S3 buckets. If a copy is or becomes multipart 
after upgrading to AWS CLI v2, extra API calls will be made. See 
https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-s3-copy-metadata.

Apply this fix? [y] yes, [n] no, [a] accept all of type, [r] reject all of type, 
[u] update all, [s] save and exit, [q] quit:

In the preceding finding, the associated breaking change is Improved Amazon S3 handling of file properties and tags for multipart copies. The suggested fix, given in a form similar to a Git diff, is to add the --copy-props none flag to the command. Adding the suggested flag will preserve AWS CLI v1 behavior in AWS CLI v2.

The following output snippet shows another finding:

16 16│ BACKUP_KEY="cloudformation/$TIMESTAMP-$(basename "$TEMPLATE")"
17 17│ 
18 18│ # Upload template
19   │-aws s3 cp $TEMPLATE s3://$BUCKET/$TMPKEY
   19│+aws s3 cp $TEMPLATE s3://$BUCKET/$TMPKEY --cli-binary-format raw-in-base64-out
20 20│ 
21 21│ # Copy template to backup bucket
22 22│ aws s3 cp "s3://$BUCKET/$TMPKEY" "s3://$BACKUP/$BACKUP_KEY"

examples/upload_s3_files.sh:19 [binary-params-base64] In AWS CLI v2, an input 
parameter typed as binary large object (BLOB) expects the input to be base64-encoded. 
If using a BLOB-type input parameter, retain v1 behavior after upgrading to AWS CLI 
v2 by adding `--cli-binary-format raw-in-base64-out`. See 
https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-binaryparam.

Apply this fix? [y] yes, [n] no, [a] accept all of type, [r] reject all of type, 
[u] update all, [s] save and exit, [q] quit:

In the preceding detection, the associated breaking change is that Binary parameters are passed as base64-encoded strings by default. The suggested fix, is to add the --cli-binary-format raw-in-base64-out flag to the command. Adding the suggested flag will preserve AWS CLI v1 behavior in AWS CLI v2.

Note that in this particular case, we are not using a binary-type parameter in the aws s3 cp command. This highlights a core behavior of the migration tool: by design, it errs on the side of caution when detecting potential issues, flagging changes that might be breaking even when uncertain, provided the suggested fix won’t alter the code’s behavior.

The following output snippet shows another finding:

27 27│  --template-body "https://s3.amazonaws.com/$BUCKET/$TEMPLATE_KEY" --cli-binary-format raw-in-base64-out --no-cli-pager
28 28│
29 29│echo "Stack creation initiated. Stack ID: $(
30 30│  aws cloudformation describe-stacks \
31 31│    --stack-name "$STACK_NAME" \
32 32│    --query 'Stacks[0].StackId' \
33 33│    --output text \
34 34│    --cli-input-json file://describe_stacks_input.json --cli-binary-format raw-in-base64-out --no-cli-pager
35 35│)"

examples/upload_s3_files.sh:30 [MANUAL REVIEW REQUIRED] [cli-input-json] In AWS CLI 
v2, specifying pagination parameters via `--cli-input-json` turns off automatic 
pagination. If pagination-related parameters are present in the input JSON specified 
with `--cli-input-json`, remove the pagination parameters from the input JSON to 
retain v1 behavior. See 
https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-skeleton-paging.

[n] next, [s] save, [q] quit:

In the preceding detection, the detected breaking change is AWS CLI version 2 is more consistent with paging parameters. The migration tool cannot automatically modify the script in this case, so the detection is flagged with [MANUAL REVIEW REQUIRED].

For detections that require manual fixes, such as the example, you’ll enter n and manually address the finding after the migration tool finishes executing.

After all detections are displayed, a summary is printed, including the number of issues found and the path to the modified script:

Found 10 issue(s). 9 fixed. 1 require(s) manual review.
Changes written to: upload_s3_files_v2.sh

To resolve the detections that were flagged for manual review, follow the guidance in the suggested actions.

Step 3: Upgrade to AWS CLI v2

Customers are responsible for safely migrating their scripts; using the migration tool does not guarantee that all commands will have the same behavior in AWS CLI v2. To complete a manual review, reference the breaking changes list in the AWS CLI v2 Migration Guide.

After going through and applying any required changes identified in the previous steps, you are now ready to upgrade to AWS CLI v2 following the installation guide.

Step 4: Uninstall migration tool if no longer needed

After migration, you can uninstall the migration tool and remove original scripts if no longer needed.

Important Considerations

The AWS CLI v1-to-v2 Migration Tool uses static analysis to identify most compatibility considerations in your scripts. However, some scenarios—such as parameters stored in variables or determined at runtime—fall outside the tool’s detection scope and require manual review.

For more details on the limitations of the AWS CLI v1-to-v2 Migration Tool, see Limitations in Using AWS CLI v1-to-v2 Migration Tool to upgrade AWS CLI version 1 to AWS CLI version 2.

We strongly recommend customers understand our breaking changes list published in our AWS CLI v2 Migration Guide.

Conclusion

In this blog post, we showed you how to get started with the new AWS CLI v1-to-v2 Migration Tool to assist your upgrade from AWS CLI v1 to AWS CLI v2. To learn more, visit Using AWS CLI v1-to-v2 Migration Tool to upgrade AWS CLI version 1 to AWS CLI version 2. We would love your feedback! You can also open a discussion or issue on GitHub. Thank you for using the AWS CLI!

Have you encountered challenges migrating from AWS CLI v1 to AWS CLI v2? Share your experience in the comments below.

Transfer Manager Directory Support for AWS SDK for Ruby

Juli Tera — Thu, 19 Mar 2026 14:39:01 +0000

Managing bulk file transfer to Amazon Simple Storage Service (Amazon S3) can be complex when transferring directories containing multiple files and subdirectories. AWS SDK for Ruby Transfer Manager (aws-sdk-s3 version 1.215) now supports directory upload and download. This feature can help streamline bulk transfers by providing multipart handling and parallelism options.

Previously, uploading directories to Amazon S3 required manual iteration and handling. You also had to manage multipart uploads for large files and implement parallelism for performance. With directory support in Transfer Manager, you can handle this with a single method call that automates the process. In this post, we show you how to upload and download directories using Transfer Manager, customize transfer with filtering options and handle results effectively.

Getting started

This support requires aws-sdk-s3 version 1.215 or higher. Add aws-sdk-s3 to your Gemfile:

gem 'aws-sdk-s3', '>= 1.215'

Initialize the Transfer Manager

To initialize a Transfer Manager with a default S3 client:

require 'aws-sdk-s3' 
tm = Aws::S3::TransferManager.new

Or you could create a custom S3 client to pass to the Transfer Manager.

client = Aws::S3::Client.new(region: 'us-east-1')
tm = Aws::S3::TransferManager.new(client: client)

Upload a directory

Upload a local directory to an S3 bucket by providing a source path and bucket name:

tm.upload_directory('/path/to/directory', bucket: 'my-bucket')

By default, only files in the specified directory are uploaded. To include subdirectories, set recursive: true:

tm.upload_directory('/path/to/directory', bucket: 'my-bucket', recursive: true)

Download a directory

Download objects from an S3 bucket to a local directory by providing a destination path and bucket name:

tm.download_directory('/local/path', bucket: 'my-bucket')

To download only objects with a specific prefix, set s3_prefix. The full object key is preserved in the local path. For example, given s3_prefix: 'photos/':

Object key: photos/vacation/beach.jpg
Resolved local path: /local/path/photos/vacation/beach.jpg

tm.download_directory('/local/path', bucket: 'my-bucket', s3_prefix: 'photos/2026/')

Filtering contents

You can also filter transfers by using filter_callback:

# Upload only .txt files 
filter = proc { |_path, name| name.end_with?('.txt') } 
tm.upload_directory('/path/to/directory', bucket: 'my-bucket', filter_callback: filter) 

# Download only .jpg files 
filter = proc { |obj| obj.key.end_with?('.jpg') } 
tm.download_directory('/local/path', bucket: 'my-bucket', filter_callback: filter)

Handling results

On success, both operations return a hash containing completed and failed transfer details:

result = tm.upload_directory('/path/to/directory', bucket: 'my-bucket') 
# => { completed_uploads: 7, failed_uploads: 0 }

By default, an error raises an exception, which stops the transfer but does not clean up completed transfers. You can set ignore_failure: true to continue transferring remaining files and see what errors occurred in the results hash.

result = tm.upload_directory(
  '/path/to/directory', 
  bucket: 'my-bucket', 
  ignore_failure: true
)
# => { completed_uploads: 5, failed_uploads: 2, errors: [...] }

Conclusion

Directory upload and download support in the AWS SDK for Ruby Transfer Manager can help streamline bulk S3 transfers with built-in parallelism and multipart handling.

Key takeaways:

Use upload_directory and download_directory for bulk transfers with a single method call
Customize behavior with options like recursive, s3_prefix, and filter_callback
Handle errors gracefully with ignore_failure and inspect results for details

These are only a few of the available options. See the API documentation for a full list.

Next steps: Try implementing directory transfers in your applications and explore other Transfer Manager features like upload_file and download_file for single-object transfers.

Share your questions, comments, and issues with us on GitHub.

About the author

Upgrade AWS CLI from v1 to v2 using upgrade debug mode

Ahmed Moustafa — Tue, 10 Mar 2026 15:00:04 +0000

Upgrading from AWS Command Line Interface (AWS CLI) v1 to AWS CLI v2 can be challenging and time-consuming due to changes introduced in AWS CLI v2 that can potentially break your existing workflows. If you don’t properly address breaking changes in your scripts or workflows, then executing these workflows after upgrading to AWS CLI v2 may result in unintended consequences, such as failing commands or misconfiguring resources in your AWS account.

AWS CLI v1’s upgrade debug mode helps you identify and resolve these issues before upgrading, for a safer and seamless transition. This mode detects usage of features in AWS CLI v1 that have been updated with breaking changes in AWS CLI v2, and outputs a warning for each detection.

In this post, we’ll walk you through using AWS CLI v1’s upgrade debug mode to identify potential breaking changes, resolve compatibility issues, and safely transition your workflows to v2.

Getting Started

You’ll start by verifying you have the correct version of AWS CLI v1 to use upgrade debug mode, then you’ll use this mode to test commands in AWS CLI v1 for usage of features that were updated with breaking changes in AWS CLI v2. Then, you’ll review the AWS CLI v2 breaking changes list in the Migration guide for the AWS CLI version 2 to manually verify whether your workflows may be broken by upgrading. Finally, you’ll follow guidance to mitigate breaking your workflows and safely upgrade to AWS CLI v2.

AWS CLI v1

The following steps walk you through using upgrade debug mode to identify potential breaking changes in your existing AWS CLI v1 usage, resolve compatibility issues, and safely transition to AWS CLI v2.

Step 1: Verify you are using AWS CLI v1 version 1.44.0 or higher.

We released the upgrade debug mode feature to the AWS CLI in version 1.44.0.

Using AWS CLI v1, run aws --version, and verify that the AWS CLI version is 1.44.0 or higher.

If the version is older than 1.44.0, see our Developer Guide for instructions to update to a later version.

Step 2: Test your AWS CLI v1 usage with AWS CLI upgrade debug mode

Set the AWS_CLI_UPGRADE_DEBUG_MODE environment variable to true to detect usage of features broken in AWS CLI v2. Alternatively, you can enable this functionality at the command-level using the --v2-debug command line option. If you are upgrading the AWS CLI in existing scripts or workflows to use v2, we recommend testing each AWS CLI command used with this functionality enabled before upgrading them to use AWS CLI v2.

We recommend performing this step in the same environment that you will upgrade to use AWS CLI v2, since the execution environment determines whether commands will experience breaking changes.

For example, suppose you have a script that executes the AWS CLI command below:

aws secretsmanager update-secret --secret-id SECRET-NAME \
  --secret-binary file://BINARY-SECRET.json

Execute the command with the AWS_CLI_UPGRADE_DEBUG_MODE set to true—or with the --v2-debug flag—and check the output for the text “AWS CLI v2 UPGRADE WARNING”. Example output with the environment variable configured is shown below:

$ aws secretsmanager update-secret --secret-id SECRET-NAME \
  --secret-binary file://BINARY-SECRET.json

AWS CLI v2 UPGRADE WARNING: When specifying a blob-type parameter, AWS CLI v2 will 
assume the parameter value is base64-encoded. This is different from v1 behavior, 
where the AWS CLI will automatically encode the value to base64. To retain v1 
behavior in AWS CLI v2, set the `cli_binary_format` configuration variable to 
`raw-in-base64-out`. See 
https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-binaryparam.

{
    "ARN": "ARN",
    "Name": "SECRET-NAME",
    "VersionId": "VERSION-ID"
}

Step 3: Use the warnings to prepare for AWS CLI v2

If breaking changes were detected in step 2, the warnings provide guidance for preparing for the AWS CLI v2 upgrade. Some breaking changes can be mitigated prior to upgrading to AWS CLI v2 by modifying the command or execution environment; the warnings identified in step 2 include links to our AWS CLI v2 breaking changes list that details options to mitigate the breakage.

In the previous example, the warning explains that AWS CLI v2 will assume that the contents of BINARY-SECRET.json will be encoded in base64.

Following the instructions in the warning, you’ll configure the cli_binary_format variable to raw-in-base64-out in the configuration file. Even though cli_binary_format is not a valid configuration setting in AWS CLI v1, it prepares your environment for AWS CLI v2 by configuring AWS CLI v2 to retain the same behavior as AWS CLI v1.

You’ll configure cli_binary_format according to the instructions using the following command:

aws configure set cli_binary_format raw-in-base64-out

Step 4: Verify resolution of warnings

For breaking changes mitigated in step 3, you’ll re-run the command to verify the warning is no longer printed.

Proceeding with the example, you configured the cli_binary_format variable to raw-in-base64-out in step 3. You’ll now re-run the command to verify the mitigation warning is resolved:

aws secretsmanager update-secret --secret-id SECRET-NAME \
    --secret-binary file://BINARY-SECRET.json 
{
    "ARN": "ARN",
    "Name": "SECRET-NAME",
    "VersionId": "VERSION-ID"
}

The warning is no longer printed, signaling that this command is now compatible with AWS CLI v2.

If you used the --v2-debug argument instead of the AWS_CLI_UPGRADE_DEBUG_MODE environment variable in step 2, remember to remove the flag from the command before upgrading to version 2.

Step 5: Manually review for breaking changes

After using upgrade debug mode to automatically detect usage of features that were updated with breaking changes, you will now manually review your AWS CLI usage by reviewing our breaking changes list and AWS CLI v2 Migration Guide.

Step 6: Upgrade to AWS CLI v2

After preparing for the breaking changes identified in the previous steps, you will now upgrade to AWS CLI v2 following the installation guide.

Limitations

The upgrade debug mode feature does not currently support every breaking change introduced with AWS CLI v2, and has false positive cases where it issues a warning even if no breaking changes are actually present.

Additionally, some of the detection depends on API responses, as well as the execution environment running the AWS CLI. For this reason, we recommend running this feature against an AWS account and execution environment that reflect your production workflows as close as possible.

For more details on the limitations of upgrade debug mode, see Using upgrade debug mode to upgrade AWS CLI version 1 to AWS CLI version 2 in Migration guide for the AWS CLI version 2.

We strongly recommend customers understand our breaking changes list published in our AWS CLI v2 Migration Guide.

The only breaking change not supported by the upgrade debug mode is that AWS CLI version 2 provides more consistent return codes across commands.

Conclusion

In this blog post, we showed you how to get started with the new upgrade debug mode. If you’re interested in using this feature to assist your upgrade from AWS CLI v1 to AWS CLI v2, try out upgrade debug mode. To learn more, visit Using upgrade debug mode to upgrade AWS CLI version 1 to AWS CLI version 2 in our AWS CLI v2 Migration Guide. We would love your feedback! You can reach out to us by creating a GitHub Issue.

AWS SDK for .NET V3 Maintenance Mode Announcement

Muhammad Othman — Wed, 04 Mar 2026 19:35:48 +0000

In alignment with our V4.0 GA announcement and SDKs and Tools Maintenance Policy, version 3 of the AWS SDK for .NET will enter maintenance mode on March 1, 2026, and reach end-of-support on June 1, 2026. Starting March 1, 2026 we will stop adding regular updates to V3 and will only provide security updates until end-of-support begins.

Support Timeline

When we announced the general availability of AWS SDK for .NET V4 on April 28, 2025, we committed to a support timeline tied to the AWS Tools for PowerShell, which depends on the SDK. With AWS Tools for PowerShell V5 reaching general availability in August 2025, the 6-month support window for V3 began. For more details on the original support commitment, see the V4.0 GA announcement.

The following table outlines the level of support for each phase of the SDK lifecycle.

SDK Lifecycle Phase	Start Date	End Date	Support Level
General Availability	July 28, 2015	February 28, 2026	During this phase, the SDK is fully supported. AWS will provide regular SDK releases that include support for new services, API updates for existing services, as well as bug and security fixes.
Maintenance Mode	March 1, 2026	May 31, 2026	During the maintenance mode, AWS will limit SDK releases to address critical bug fixes and security issues only. AWS SDK for .NET v3.x will not receive API updates for new or existing services or be updated to support new regions.
End-of-Support	June 1, 2026	N/A	AWS SDK for .NET v3.x will no longer receive updates or releases. Previously published releases will continue to be available via public package managers and the code will remain on GitHub.

Next Steps

We encourage the AWS SDK for .NET community to begin planning your migration to V4 as soon as possible:

Review the Migration Guide to understand the breaking changes.
Test your applications with V4 in a development environment.
Update your code to accommodate the changes.
Provide feedback through our GitHub repository.

Conclusion

With the maintenance mode transition now in effect and end of support on June 1st, 2026, we recommend prioritizing your migration planning to ensure a smooth transition. Migration documentation is available to guide you through the update process.

For questions or issues that arise while updating to the V4 SDK, please use the GitHub repository’s discussion forums or open GitHub issues to reach out to us. If you find dependencies that are preventing you from updating to V4, please let us know to see if we can help.

AWS Developer Tools Blog

Announcing General Availability of DynamoDB Mapper for Kotlin

Getting started

Features available since Developer Preview

What’s new since Developer Preview

Condition expressions

updateItem and update expressions DSL

Batch operations

Transactions

Atomic counters

TTL management

Custom attribute converters

Secondary index annotations

Bug fixes since Developer Preview

Breaking changes from Developer Preview

Next steps

AWS Durable Execution SDK for .NET now Generally Available

How Lambda durable functions work

Prerequisites

Getting started

Building a production-ready order processing workflow

Setup and entry point

The workflow method

Step 1: Validate the order

Step 2: Charge payment with retries

Step 3: Wait out the settlement period

Step 4: Ship the order in a child context

Returning the result

Adding a human approval step

Deploying the workflow

Testing locally

Clean up

Conclusion

Annual .NET target updates for the AWS SDK for .NET

Background

The case for a defined schedule

The schedule

Yearly target examples

November 2026 (V4.1)

November 2027 (V4.2)

November 2028 (V4.3)

November 2029 (V4.4)

What this means for you

Conclusion

Installing and updating the AWS CLI with single-line commands

Installing

macOS and Linux

Windows

Updating

Conclusion

Updating TypeScript version support in AWS SDK for JavaScript v3

What’s changing and why

What you can expect

A clear minimum supported TypeScript version

Smaller package artifacts and simpler publishing

What you need to do

Option 1: Upgrade TypeScript to a supported version (recommended)

Option 2: Pin the AWS SDK for JavaScript v3 packages

FAQ

Is this a runtime breaking change?

Why not keep downleveling indefinitely?

Conclusion

AWS CLI v1 maintenance mode: announcing changes to dependency updates

Background

What’s happening?

How you may be affected

Recommended actions

Conclusion

Feedback

Introducing Open-Source Skills for AWS SDK Best Practices

The problem

What’s in a skill

Common mistakes skills help prevent

Measuring the impact

Available skills

Get started

Announcing the General Availability of the AWS IoT Device SDK for Swift

What’s New

Getting Started

Prerequisites

`updateItem` and update expressions DSL