AWS Developer Tools Blog

Get started with the Agent Toolkit for AWS in the AWS CLI

Andrew Asseily — Wed, 26 Aug 2026 18:14:37 +0000

AI coding agents such as Kiro, Claude Code, Codex, Cursor, and others play an increasingly important role in developer workflows. They write code, fix bugs, scaffold projects, and build infrastructure. By default, these agents have general knowledge of AWS. The Agent Toolkit for AWS gives them specialized, up-to-date expertise, so they’re more likely to pick the right services for the task, use modern APIs, and follow security best practices.

With one command in the AWS Command Line Interface (AWS CLI), your coding agent gets curated AWS expertise.

In this post I walk through what’s in the toolkit, how to install it, and how to manage skills as your work evolves.

What’s in the Agent Toolkit for AWS?

AWS skills – A curated catalog of Markdown files that teach your agent how AWS works. The skills cover a wide range of AWS services and common developer workflows. Each skill is curated and maintained by AWS service teams and updated as services evolve.
The AWS MCP Server – A secure, auditable connection your agent can use to reach thousands of AWS APIs through the Model Context Protocol. With the AWS MCP Server, your agent can list resources, search documentation, and call AWS APIs using your existing AWS Identity and Access Management (IAM) credentials.

These components give your agent the context to write better AWS code, take safer actions, and reach for the right service the first time. The catalog keeps growing as more AWS service teams contribute skills.

Prerequisites

AWS CLI version 2.35.0 or newer. See the AWS CLI v2 install guide to install or upgrade.
One or more supported AI coding agents installed locally. Kiro, Claude Code, Codex, Cursor, and other popular AI coding agents are supported. You can run aws configure agent-toolkit to display the supported agents and detect which are present on your machine.

Set up the Agent Toolkit

To start the interactive setup, use the following command:

aws configure agent-toolkit

The wizard detects the supported AI coding agents on your machine, and you choose which ones to set up. For each agent you select, it installs a default set of AWS skills and configures the AWS MCP Server connection. You can add, update, or remove skills afterward with the aws agent-toolkit commands.

The entire process typically takes a few seconds. The next time you open a chat session, your agent has AWS expertise loaded.

In a non-interactive environment, such as continuous integration or a development container, use the --yes option to accept defaults without prompts:

aws configure agent-toolkit --yes

To explore the other available options, run aws configure agent-toolkit help, or see the AWS CLI section of the Agent Toolkit for AWS User Guide.

Extend as your project grows

You can add, update, and remove skills at any time to match what you’re building. The skills installed by default cover common workflows, but as your project grows, you may need additional skills. Consider a serverless document-processing application that stores uploaded files in Amazon Simple Storage Service (Amazon S3). The application requires semantic search over the uploaded files, implemented with Amazon S3 Vectors, a recently released capability. Because the capability is new, the agent might lack current guidance for it. Complete the following steps to install the relevant skill so the agent has up-to-date guidance before it generates code.

Check what’s installed:

aws agent-toolkit list-installed-skills

The default install doesn’t include a vectors skill. Search for one and add it:

aws agent-toolkit search-skills --search-query vectors
aws agent-toolkit add-skill --skill-name storing-and-querying-vectors

search-skills matches against skill names and descriptions across the full catalog. add-skill downloads the skill and installs it to each detected agent. Use --agent to target a specific one.

As the toolkit and its skills evolve, you can keep them current or remove them:

aws agent-toolkit update-skill aws-cdk
aws agent-toolkit remove-skill aws-cdk

Conclusion

In this post, I showed how to use the Agent Toolkit for AWS to give your AI coding agent AWS expertise and context with a single AWS CLI command. The toolkit installs a curated set of skills, configures the AWS MCP Server for the agents you select, and gives you simple commands to search, install, update, and remove skills as your needs evolve. The result is an agent that writes better AWS code, follows the latest best practices, and gets the answer right the first time more often.
To get started, install or upgrade the AWS CLI to version 2.35.0 or newer, then run aws configure agent-toolkit.

Try it today and tell us what you think. Open an issue or feature request on the AWS CLI GitHub repository

Announcing response streaming for .NET on AWS Lambda

Norm Johanson — Wed, 05 Aug 2026 20:08:43 +0000

Today, we are announcing support for AWS Lambda response streaming for .NET Lambda functions. With response streaming, functions can be more responsive by sending data back to the caller incrementally as it becomes available, rather than buffering the entire response in memory before returning it.

Why response streaming?

With the traditional Lambda invocation model, the function computes the entire response, serializes it, and returns it all at once. For workloads that produce large responses or generate output over time, this means the caller waits for the full response before seeing any data.

Response streaming changes this. Your function can start sending bytes to the caller immediately. This is useful for:

LLM/AI responses — stream tokens from a model as they are generated
Large data exports — send CSV or JSON lines without buffering the full dataset
Larger responses — streaming raises the max response size from 6 MB to 200 MB (or 10 MB when used with Amazon API Gateway).

Getting started with response streaming

Response streaming is available for .NET 8 and later. To use it, your Lambda function calls LambdaResponseStreamFactory.CreateStream() to get a writable .NET System.IO.Stream. All output is written to this stream. If an invocation of the Lambda function creates a response stream, the handler’s return value is ignored.

Here is a simple example that streams “Hello” messages:

using Amazon.Lambda.Core;
using Amazon.Lambda.Core.ResponseStreaming;

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace StreamingHello;

public class Function
{
    public async Task FunctionHandler(string input, ILambdaContext context)
    {
        using var responseStream = LambdaResponseStreamFactory.CreateStream();
        using var writer = new StreamWriter(responseStream);

        for (var i = 1; i <= 100; i++)
        {
            await writer.WriteLineAsync($"Hello {input} - {i}");
            if (i % 10 == 0)
            {
                await writer.FlushAsync();
            }
        }
    }
}

To invoke the function, use the Lambda InvokeWithResponseStream API from the AWSSDK.Lambda package. The following example shows how to call this API and handle the streamed response:

var client = new AmazonLambdaClient();

var request = new InvokeWithResponseStreamRequest
{
    FunctionName = "StreamingHello",
    Payload = new MemoryStream(UTF8Encoding.UTF8.GetBytes("\"World\""))
};

var response = await client.InvokeWithResponseStreamAsync(request);

await foreach (var streamEvent in response.EventStream)
{
    switch (streamEvent)
    {
        case InvokeResponseStreamUpdate payloadChunk:
            {
                var text = Encoding.UTF8.GetString(payloadChunk.Payload.ToArray());
                Console.Write(text);
                break;
            }

        case InvokeWithResponseStreamCompleteEvent complete:
            {
                if (complete.ErrorCode != null)
                {
                    Console.WriteLine($"Error Code: {complete.ErrorCode}");
                }

                if (complete.ErrorDetails != null)
                {
                    Console.WriteLine($"Error Details: {complete.ErrorDetails}");
                }

                if (complete.LogResult != null)
                {
                    var logs = Encoding.UTF8.GetString(
                        Convert.FromBase64String(complete.LogResult));

                    Console.WriteLine("Logs:");
                    Console.WriteLine(logs);
                }

                break;
            }
    }
}

You can also test the Lambda function using the .NET tool Amazon.Lambda.Tools with the invoke-function command and the new --invoke-mode Stream switch. The following command demonstrates invoking the StreamingHello function and receiving its streamed output:

> dotnet lambda invoke-function StreamingHello --invoke-mode Stream --payload "World"
Amazon Lambda Tools for .NET Core applications (7.0.0)
Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet

Payload:
Hello World - 1
Hello World - 2
Hello World - 3
Hello World - 4

...

Hello World - 97
Hello World - 98
Hello World - 99
Hello World - 100


Log Tail:
START RequestId: 3f162d6c-62b0-4e01-a041-9a850b6bd35f Version: $LATEST
END RequestId: 3f162d6c-62b0-4e01-a041-9a850b6bd35f
REPORT RequestId: 3f162d6c-62b0-4e01-a041-9a850b6bd35f  Duration: 33.50 ms      Billed Duration: 34 ms  Memory Size: 512 MB     Max Memory Used: 79 MB

Streaming an LLM response with Microsoft.Extensions.AI

A natural fit for response streaming is AI workloads where a model generates tokens over time. Using the Microsoft.Extensions.AI framework with the AWSSDK.Extensions.Bedrock.MEAI provider, you can stream an Amazon Bedrock model’s response directly to the caller. The following example demonstrates how to do this:

public class Function
{
    IChatClient _chatClient;

    public Function()
    {
        var bedrockClient = new AmazonBedrockRuntimeClient();
        _chatClient = bedrockClient.AsIChatClient(Environment.GetEnvironmentVariable("MODEL_ID"));
    }

    public async Task FunctionHandler(string prompt, ILambdaContext context)
    {
        using var responseStream = LambdaResponseStreamFactory.CreateStream();
        using var writer = new StreamWriter(responseStream);

        await foreach (var update in _chatClient.GetStreamingResponseAsync(prompt))
        {
            if (update.Text is { Length: > 0 })
            {
                await writer.WriteAsync(update.Text);
                await writer.FlushAsync();
            }
        }
    }
}

The caller starts receiving the model’s response as soon as the first tokens are generated. For conversational AI use cases, this makes the experience feel much more responsive.

Response streaming with API Gateway REST API

Lambda response streaming works with the API Gateway REST API. When streaming through API Gateway, the response needs a prelude containing the HTTP status code and headers. Use LambdaResponseStreamFactory.CreateHttpStream to create a stream with a prelude.

The following example downloads an object from Amazon S3 and streams it directly to the caller through API Gateway without buffering the entire object in memory:

public async Task Get(APIGatewayProxyRequest request, ILambdaContext context)
{        
    string? key;
    if (!request.PathParameters.TryGetValue("s3Key", out key))
    {
        var prelude = new Amazon.Lambda.Core.ResponseStreaming.HttpResponseStreamPrelude
        {
            StatusCode = HttpStatusCode.BadRequest,
            Headers = new Dictionary<string, string>
            {
                ["Content-Type"] = "text/plain",
            }
        };

        using var responseStream = LambdaResponseStreamFactory.CreateHttpStream(prelude);
        using var writer = new StreamWriter(responseStream);
        await writer.WriteAsync("Missing 's3Key' path parameter");
    }
    else
    {
        try
        {
            var getResponse = await _s3Client.GetObjectAsync(_bucketName, key);

            var prelude = new Amazon.Lambda.Core.ResponseStreaming.HttpResponseStreamPrelude
            {
                StatusCode = HttpStatusCode.OK,
                Headers = new Dictionary<string, string>
                {
                    ["Content-Type"] = getResponse.Headers.ContentType,
                    ["Content-Disposition"] = $"attachment; filename=\"{key}\""
                }
            };

            using var responseStream = LambdaResponseStreamFactory.CreateHttpStream(prelude);
            await getResponse.ResponseStream.CopyToAsync(responseStream);
        }
        catch (AmazonS3Exception ex) when (ex.StatusCode == HttpStatusCode.NotFound)
        {
            var prelude = new HttpResponseStreamPrelude
            {
                StatusCode = HttpStatusCode.NotFound,
                Headers = new Dictionary<string, string>
                {
                    ["Content-Type"] = "text/plain"
                }
            };

            using var responseStream = LambdaResponseStreamFactory.CreateHttpStream(prelude);
            using var writer = new StreamWriter(responseStream);
            await writer.WriteAsync($"Object '{key}' not found");
        }
    }
}

As the S3 GetObject response is read, the bytes flow directly into the Lambda response stream and out to the caller. This avoids loading the full object into memory, which is particularly useful for files up to the 10 MB API Gateway limit.

The API Gateway integration needs to be configured for streaming. In your AWS CloudFormation or AWS SAM template, the integration URI must use the /response-streaming-invocations path and set responseTransferMode to STREAM. The following template snippet shows the required integration configuration:

"DefinitionBody": {
  "openapi": "3.0.1",
  "info": { "title": "My Streaming API", "version": "1.0" },
  "paths": {
    "/{proxy+}": {
      "x-amazon-apigateway-any-method": {
        "x-amazon-apigateway-integration": {
          "type": "aws_proxy",
          "httpMethod": "POST",
          "payloadFormatVersion": "1.0",
          "uri": {
            "Fn::Sub": "arn:aws:apigateway:${AWS::Region}:lambda:path/2021-11-15/functions/${StreamingFunction.Arn}/response-streaming-invocations"
          },
          "responseTransferMode": "STREAM",
          "timeoutInMillis": 29000
        }
      }
    }
  }
}

Response streaming with ASP.NET Core

If you are using the Amazon.Lambda.AspNetCoreServer.Hosting package to run ASP.NET Core on Lambda, you can enable response streaming by setting EnableResponseStreaming to true in the hosting options. The following example shows how to configure and use response streaming in an ASP.NET Core Lambda app

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAWSLambdaHosting(LambdaEventSource.RestApi, options =>
{
    options.EnableResponseStreaming = true;
});

var app = builder.Build();

app.MapGet("/", () => "Hello from streaming Lambda");

app.MapGet("/stream", async (HttpContext context) =>
{
    context.Response.ContentType = "text/plain";
    var stream = context.Response.BodyWriter.AsStream();
    using var writer = new StreamWriter(stream, leaveOpen: true);

    for (var i = 1; i <= 100; i++)
    {
        await writer.WriteLineAsync($"Line {i}");
        if (i % 10 == 0)
        {
            await writer.FlushAsync();
        }
    }
});

app.Run();

With EnableResponseStreaming set to true, the hosting layer builds the HTTP prelude from the ASP.NET Core response (status code, headers, cookies) and streams the body through the Lambda response stream. Standard ASP.NET Core endpoint returns like Results.Json(...) and Results.Text(...) work without changes.

The API Gateway integration needs to be configured for streaming. In your CloudFormation or SAM template, the integration URI must use the /response-streaming-invocations path and set responseTransferMode to STREAM. The following SAM template demonstrates the full configuration for an ASP.NET Core streaming function:

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Transform": "AWS::Serverless-2016-10-31",
  "Resources": {
    "StreamingApi": {
      "Type": "AWS::Serverless::Api",
      "Properties": {
        "StageName": "prod",
        "DefinitionBody": {
          "openapi": "3.0.1",
          "info": { "title": "ASP.NET Core Streaming", "version": "1.0" },
          "paths": {
            "/": {
              "x-amazon-apigateway-any-method": {
                "x-amazon-apigateway-integration": {
                  "type": "aws_proxy",
                  "httpMethod": "POST",
                  "payloadFormatVersion": "1.0",
                  "uri": {
                    "Fn::Sub": "arn:aws:apigateway:${AWS::Region}:lambda:path/2021-11-15/functions/${AspNetCoreFunction.Arn}/response-streaming-invocations"
                  },
                  "responseTransferMode": "STREAM",
                  "timeoutInMillis": 29000
                }
              }
            },
            "/{proxy+}": {
              "x-amazon-apigateway-any-method": {
                "x-amazon-apigateway-integration": {
                  "type": "aws_proxy",
                  "httpMethod": "POST",
                  "payloadFormatVersion": "1.0",
                  "uri": {
                    "Fn::Sub": "arn:aws:apigateway:${AWS::Region}:lambda:path/2021-11-15/functions/${AspNetCoreFunction.Arn}/response-streaming-invocations"
                  },
                  "responseTransferMode": "STREAM",
                  "timeoutInMillis": 29000
                }
              }
            }
          }
        }
      }
    },
    "AspNetCoreFunction": {
      "Type": "AWS::Serverless::Function",
      "Properties": {
        "Handler": "MyStreamingApp",
        "Runtime": "dotnet10",
        "CodeUri": "",
        "MemorySize": 512,
        "Timeout": 30,
        "Policies": ["AWSLambda_FullAccess"]
      }
    },
    "ApiPermission": {
      "Type": "AWS::Lambda::Permission",
      "Properties": {
        "Action": "lambda:InvokeFunction",
        "FunctionName": { "Ref": "AspNetCoreFunction" },
        "Principal": "apigateway.amazonaws.com",
        "SourceArn": {
          "Fn::Sub": "arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${StreamingApi}/*/*/*"
        }
      }
    }
  },
  "Outputs": {
    "ApiURL": {
      "Value": {
        "Fn::Sub": "https://${StreamingApi}.execute-api.${AWS::Region}.amazonaws.com/prod/"
      }
    }
  }
}

Conclusion

Response streaming opens up new patterns for .NET Lambda functions, particularly for AI workloads and large data transfers. To get started, update to the latest versions of Amazon.Lambda.Core and Amazon.Lambda.RuntimeSupport.

For feedback on .NET Lambda response streaming, open a GitHub issue or discussion on our aws/aws-lambda-dotnet repository.

Building and Deploying .NET AI Agents with Amazon Bedrock AgentCore

Philippe El Asmar — Wed, 05 Aug 2026 16:56:46 +0000

Amazon Bedrock AgentCore is a managed service for running AI agents in production. You bring your agent code packaged as a container, and Bedrock AgentCore handles the operational concerns: scaling, session routing, health checking, and providing managed capabilities like conversation memory.

AWS.AgentCore.Hosting is the .NET library that connects your agent code to this service. It implements the HTTP communication, streaming responses, session management, and memory integration so you can focus on your agent’s logic rather than the infrastructure. Built on Microsoft Agent Framework, the library gives you access to the .NET AI ecosystem, such as tool calling, middleware, multi-agent workflows, and the Model Context Protocol (MCP), with a zero-friction path to production on AWS.

In this post, I’ll walk through building a customer support agent that can look up order status, remember what the customer already asked about, stream responses in real time, and deploy to production. Each section builds on the same agent and shows how to solve each piece of the problem.

What is a .NET Bedrock AgentCore application?

The following diagram shows how the pieces fit together at runtime:

Your container hosts an ASP.NET Core application that includes AWS.AgentCore.Hosting as a dependency, which handles the HTTP communication the AgentCore Runtime expects. Your agent logic runs inside that host and calls out to Amazon Bedrock, or any other model provider, through the standard IChatClient interface.

Write your agent handler

AWS.AgentCore.Hosting provides two developer experiences:

Source generator experience. This approach abstracts away the ASP.NET Core part of the application. Use it when you want to focus solely on your agent’s logic.
Extension method experience. This approach provides extension methods to configure the application for Bedrock AgentCore. Use it when you want more control over the ASP.NET Core part of the application.

Source generator

After you annotate your classes, the source generator produces a Program.cs for you. The generated code creates a WebApplication, calls your ConfigureServices method, maps your handler to the AgentCore Runtime endpoint, and starts the host. You don’t need to write routing or hosting boilerplate. The following example shows a complete agent that uses the source generator:

using AWS.AgentCore.Hosting;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

[AgentCoreStartup]
public class Startup
{
    public void ConfigureServices(WebApplicationBuilder builder)
    {
        builder.AddAgentCore(options =>
        {
            options.ModelId = "global.anthropic.claude-sonnet-4-7";
            options.AgentOptions = new ChatClientAgentOptions
            {
                ChatOptions = new()
                {
                    Tools = [AIFunctionFactory.Create(GetOrderStatus)]
                }
            };
        });
    }

    [Description("Looks up the current status of a customer order.")]
    public static string GetOrderStatus([Description("The order ID.")] string orderId)
        => $"Order {orderId} shipped on July 3 and is expected to arrive tomorrow.";
}

public class Agent(AIAgent agent)
{
    [AgentCoreHandler]
    public async Task<string> HandleInvocation(
        PromptRequest request, AgentCoreRuntimeContext context, CancellationToken ct)
    {
        var session = await agent.CreateSessionAsync(cancellationToken: ct);
        var response = await agent.RunAsync(
            request.Prompt ?? "Hello!", session: session, cancellationToken: ct);
        return response.ToString();
    }
}

public record PromptRequest(string? Prompt);

A few rules to understand about this model:

Discovery is by attribute, not naming convention. The source generator scans for [AgentCoreStartup] and [AgentCoreHandler] at compile time. You can name your classes anything you want.
One handler per project. The generator expects exactly one method marked with [AgentCoreHandler]. This is the single entry point the AgentCore Runtime invokes.
The handler supports DI parameter binding. Just like the extension method experience shown below, you can inject any registered service directly in the handler’s parameter list. AIAgent in the example above is constructor-injected because AddAgentCore() automatically registers it (along with IChatClient, AgentCoreRuntimeContext, and the memory provider if configured).
Return type determines the response mode. Return string or Task<string> for a standard response. Return IAsyncEnumerable<string> for streaming (covered in the Stream responses section below).

Extension methods

If you prefer the Minimal API pattern or want more control over the ASP.NET Core application, use the extension method experience:

var builder = WebApplication.CreateBuilder(args);

builder.AddAgentCore(options =>
{
    options.ModelId = "global.anthropic.claude-sonnet-4-7";
    options.AgentOptions = new ChatClientAgentOptions
    {
        ChatOptions = new()
        {
            Tools = [AIFunctionFactory.Create(GetOrderStatus)]
        }
    };
});

[Description("Looks up the current status of a customer order.")]
static string GetOrderStatus([Description("The order ID.")] string orderId)
        => $"Order {orderId} shipped on July 3 and is expected to arrive tomorrow.";

var app = builder.Build();

app.MapAgentCore<PromptRequest>(async (PromptRequest request, AIAgent agent, CancellationToken ct) =>
{
    var session = await agent.CreateSessionAsync(cancellationToken: ct);
    var response = await agent.RunAsync(request.Prompt ?? "Hello!", session: session, cancellationToken: ct);
    return response.ToString();
});

app.Run();

public record PromptRequest(string? Prompt);

Both the preceding example and the source generator example produce an agent that listens on port 8080, accepts JSON at /invocations, and sends responses back to the AgentCore Runtime.

Select different models

The AddAgentCore() method supports three ways to provide the IChatClient from Microsoft.Extensions.AI. The precedence order is:

options.ChatClient (if provided)
options.ModelId (if provided)
the IChatClient already registered in DI (if provided)

If several IChatClient instances are registered in DI, the most recently registered one is used, following standard dependency injection resolution. If none of the three are provided, AddAgentCore() throws an exception at startup so you get a clear error immediately rather than a null reference on first invocation.

The following example shows each of the three options:

// Option 1: Bedrock model ID (registers IAmazonBedrockRuntime automatically)
builder.AddAgentCore(options => { options.ModelId = "global.anthropic.claude-sonnet-4-7"; });

// Option 2: Explicit IChatClient (OpenAI, Anthropic, Ollama, etc.)
builder.AddAgentCore(options => { options.ChatClient = myOpenAIClient; });

// Option 3: Pre-register in DI (useful for custom pipelines)
builder.Services.AddSingleton<IChatClient>(myClient);
builder.AddAgentCore();

Resolve services with automatic DI

The handler supports dependency injection directly in its parameter list. The runtime resolves services from the container at invocation time:

app.MapAgentCore<PromptRequest>(async (
    PromptRequest request,
    AIAgent agent,
    AgentCoreRuntimeContext context,
    ILogger<Program> logger,
    IChatClient chatClient,
    CancellationToken ct) =>
{
    logger.LogInformation("SessionId={SessionId}, RequestId={RequestId}",
        context.SessionId, context.RequestId);

    var session = await agent.CreateSessionAsync(cancellationToken: ct);
    return (await agent.RunAsync(request.Prompt!, session: session, cancellationToken: ct)).ToString();
});

The AgentCoreRuntimeContext provides session and request metadata passed by the AgentCore Runtime, plus any custom headers configured on the runtime endpoint.

Stream responses

When a customer asks a detailed question like “what’s the return policy for my order?”, they shouldn’t have to wait while the model generates a full response. Return IAsyncEnumerable<string> to stream tokens as they’re produced:

app.MapAgentCore<PromptRequest>((PromptRequest request, AIAgent agent, CancellationToken ct) =>
{
    return StreamResponse(ct);

    async IAsyncEnumerable<string> StreamResponse([EnumeratorCancellation] CancellationToken ct = default)
    {
        var session = await agent.CreateSessionAsync(cancellationToken: ct);
        await foreach (var update in agent.RunStreamingAsync(
            request.Prompt ?? "Hello!", session: session, cancellationToken: ct))
        {
            if (!string.IsNullOrEmpty(update.Text))
                yield return update.Text;
        }
    }
});

Add conversation memory

When a customer asks “where’s my order?” and then follows up with “can you change the shipping address?”, they expect the agent to remember which order they’re talking about. You can add conversation context to your agent with AgentCore Memory, a managed service that stores and retrieves conversation history per session, so your agent maintains context across invocations and container restarts without you managing any storage infrastructure.

You provision a Memory resource through the AWS console, CLI, or CDK (see the AgentCore Memory documentation), which gives you a Memory ID. Pass that ID to your agent configuration:

builder.AddAgentCore(options =>
{
    options.MemoryId = "my-memory-id";
    options.ModelId = "global.anthropic.claude-sonnet-4-7";
});

With this single setting, the library automatically loads conversation history at the start of each invocation and saves new messages after the agent responds. Your agent code doesn’t need to handle history loading or storage.

The key to how this works is the SessionId on AgentCoreRuntimeContext. Each invocation from the AgentCore Runtime carries a session ID, set by the caller through the invoke API. The library combines that session ID with the Memory ID you configured to load and store history in the AgentCore Memory service. Two different users calling the same agent get separate sessions with separate histories. On the first invocation for a new session, the AgentCore Memory service returns empty history and the agent starts fresh.

If you deploy using dotnet aws deploy or with AWS’s Aspire integrations, the memory can also be provisioned for you as part of the deployment.

Add logging and guardrails with middleware

To get visibility into how your agent is performing, such as logging invocations, tracking latency, or adding guardrails, you can add middleware to the Microsoft Agent Framework pipeline:

builder.AddAgentCore(options =>
{
    options.ModelId = "global.anthropic.claude-sonnet-4-7";
    options.ConfigureAgent = agent => agent
        .AsBuilder()
        .Use((innerAgent, services) =>
        {
            var logger = services.GetRequiredService<ILogger<Program>>();
            return innerAgent.AsBuilder()
                .Use(async (messages, session, runOptions, next, ct) =>
                {
                    logger.LogInformation("Agent invoked. Message count: {Count}", messages.Count());
                    await next(messages, session, runOptions, ct);
                    logger.LogInformation("Agent completed.");
                })
                .Build();
        })
        .Build();
});

Middleware intercepts every agent invocation, letting you add logging, guardrails, caching, or custom pre/post-processing without modifying your agent’s core logic.

Aspire integration

With the agent logic in place, you need a way to run and test it alongside the frontend that customers will actually use. The Aspire.Hosting.AWS package provides AddAgentCoreRuntime<T>() for both local development and deployment to AWS.

Local development

During local development, AddAgentCoreRuntime<T>() runs the agent and its supporting services in-process so you can exercise the full experience on your machine:

var builder = DistributedApplication.CreateBuilder(args);

var agent = builder.AddAgentCoreRuntime<Projects.MyAgent>("my-agent")
    .WithAgentCoreStreaming()
    .WithAgentCoreMemory();

builder.AddProject<Projects.Frontend>("frontend")
    .WithReference(agent);

builder.Build().Run();

The preceding example starts three embedded in-process servers, with no Docker or separate processes required:

Runtime emulator: mimics the AgentCore Runtime locally and invokes your agent
Chat UI: provides a web interface for testing your agent interactively
Memory emulator: provides an in-memory implementation of the AgentCore Memory APIs

Projects that call WithReference(agent) have their AgentCore SDK calls automatically routed to the local emulator. No additional configuration is required. Your agent handler is invoked the same way in local development and in production.

Deploying with Aspire

Recently AWS released preview support for deployment with Aspire, presented at Aspire Conf 2026. The deployment support was extended to include Bedrock AgentCore, building off of the local development workflow described in the preceding section. An advantage of the Aspire deployment is that it enables deployment of multiple connected projects as a single action.

When you run the aspire deploy CLI command with the Aspire sample from the preceding section, Aspire takes care of:

Provisioning AgentCore Memory
Deploying the “my-agent” app to Bedrock AgentCore, with the AgentCore Memory links set up so the agent automatically uses the provisioned memory
Deploying the “frontend” to Amazon Elastic Container Service (Amazon ECS) and providing the deployed application with the agent’s ARN through the environment variable AWS:Resources:<aspire-resource-name>:AgentRuntimeArn

You can customize the deployment to Bedrock AgentCore with the PublishAsAgentCoreRuntime extension method. The following example shows how to customize the request header allowlist:

builder.AddAgentCoreRuntime<Projects.AgentCore_StreamingAgent>("my-agent")
    .PublishAsAgentCoreRuntime(new Aspire.Hosting.AWS.Deployment.PublishAgentCoreRuntimeConfig
    {
        ConstructCfnRuntimeCallback = (construct, props) =>
        {
            props.RequestHeaderConfiguration = new CfnRuntime.RequestHeaderConfigurationProperty
            {
                RequestHeaderAllowlist = new string[] { "X-Custom-Header" }
            };
        }
    })
    .WithAgentCoreStreaming()
    .WithAgentCoreMemory();

Testing package

The AWS.AgentCore.Testing package provides the same emulator infrastructure that powers the Aspire integration, available as standalone servers for your integration tests. The runtime emulator bridges your test code and your agent, forwarding requests to your agent the same way the AgentCore Runtime does in production.

The following example shows how the pieces fit together in an integration test:

public class AgentIntegrationTest : IAsyncLifetime
{
    private WebApplication _agentApp;
    private WebApplication _runtimeEmulator;

    public async Task InitializeAsync()
    {
        // 1. Start your agent
        var builder = WebApplication.CreateBuilder();
        builder.AddAgentCore(options => { options.ModelId = "global.anthropic.claude-sonnet-4-7"; });
        _agentApp = builder.Build();
        _agentApp.MapAgentCore<PromptRequest>(async (PromptRequest req, AIAgent agent, CancellationToken ct) =>
        {
            var session = await agent.CreateSessionAsync(cancellationToken: ct);
            return (await agent.RunAsync(req.Prompt!, session: session, cancellationToken: ct)).ToString();
        });
        await _agentApp.StartAsync();

        // 2. Start the runtime emulator pointing at the agent
        var agentUrl = _agentApp.Urls.First();
        _runtimeEmulator = RuntimeEmulatorServer.Create(agentUrl, port: 0);
        await _runtimeEmulator.StartAsync();
    }

    [Fact]
    public async Task Agent_RespondsToPrompt()
    {
        // 3. Invoke through the emulator, same path as production
        var runtimeUrl = _runtimeEmulator.Urls.First();
        using var client = new HttpClient();
        var response = await client.PostAsJsonAsync($"{runtimeUrl}/invoke",
            new { prompt = "What is 2+2? Reply with just the number." });

        var body = await response.Content.ReadAsStringAsync();
        Assert.Contains("4", body);
    }

    public async Task DisposeAsync()
    {
        await _runtimeEmulator.StopAsync();
        await _agentApp.StopAsync();
    }
}

The preceding example lets you verify your agent’s behavior end-to-end without deploying to AWS.

Native AOT support

For minimal cold start times, deploy your agent as a Native AOT binary. Dependency injection parameter binding relies on reflection to resolve parameters at runtime, which isn’t available under Native AOT. For Native AOT, use the overload of MapAgentCore with a fixed handler signature, (TRequest, AgentCoreRuntimeContext, IServiceProvider, CancellationToken), instead of the flexible DI parameter binding from earlier sections. Your code can resolve services manually from IServiceProvider, and you pass a JsonSerializerContext so requests can be deserialized without reflection (Native AOT requires source-generated JSON serialization):

app.MapAgentCore<PromptRequest>(
    async (request, context, services, ct) =>
    {
        var agent = services.GetRequiredService<AIAgent>();
        var session = await agent.CreateSessionAsync(cancellationToken: ct);
        var response = await agent.RunAsync(
            request.Prompt ?? "Hello!", session: session, cancellationToken: ct);
        return response.ToString();
    },
    AppJsonContext.Default);

[JsonSerializable(typeof(PromptRequest))]
internal partial class AppJsonContext : JsonSerializerContext { }

If you prefer dependency injection similar to the source generator experience, the source generator annotations ([AgentCoreStartup], [AgentCoreHandler]) are Native AOT-compatible and handle the binding for you at compile time.

Deploying to AWS

Once your agent handles orders, streams responses, remembers context, and passes your integration tests, it’s ready for production. The AWS .NET deployment tool detects projects referencing AWS.AgentCore.Hosting and recommends deploying to Amazon Bedrock AgentCore Runtime:

dotnet aws deploy

The tool then recommends the Bedrock AgentCore Runtime deployment option:

Recommended Deployment Option
-----------------------------
1: ASP.NET Core App to Amazon Bedrock AgentCore Runtime (Experimental)

This deployment option handles:

Building an arm64 container image and pushing to Amazon Elastic Container Registry (Amazon ECR)
Provisioning the AgentCore Runtime
Optionally creating an AgentCore Memory resource
Configuring Amazon Virtual Private Cloud (Amazon VPC) networking and security groups for agents that need to access private resources
Displaying the runtime ARN after deployment

Next steps

Now that you’ve built, tested, and deployed a customer support agent, you can explore the samples and documentation to go further:

Try the sample apps covering annotations, streaming, Native AOT, and Aspire integration
Set up local development with Aspire.Hosting.AWS
Deploy with dotnet aws deploy or integrate with your CI/CD pipeline
Read the full documentation
File issues or contribute at github.com/aws/aws-dotnet-ai

AWS Tools Installer V2 is Now Generally Available

Jonathan Nunn — Wed, 05 Aug 2026 00:01:47 +0000

If you’ve been managing multiple AWS Tools for PowerShell modules individually, you know how time-consuming installations and updates can be. In this post, we announce the general availability of AWS Tools Installer V2. It minimizes installation time by downloading a single zip file and extracting modules in parallel.

In February 2026, we announced the preview of AWS Tools Installer V2.

V2 improvements

AWS Tools Installer V2 downloads a single zip file from Amazon CloudFront and extracts modules in parallel. This eliminates the need to install hundreds of individually packaged modules.

Installer V2 installs modules by default, so commands are available for immediate use. This also helps avoid module import conflicts that can occur when modules are not all on the same version.

The following example shows how to install all AWS Tools for PowerShell modules by running Install-AWSToolsModule. To reduce the risk of breaking changes, add the -Version parameter. It limits updates to minor versions of V5 of AWS Tools for PowerShell.

Install-AWSToolsModule -Version 5.*

AWS Tools Installer V2 also introduces the self-update commands Install-AWSToolsInstaller and Uninstall-AWSToolsInstaller so you can update the installer module directly without manual steps.

The following example installs the latest minor version updates for AWS Tools Installer V2. Staying on minor versions helps you maintain a stable environment.

Install-AWSToolsInstaller -Version 2.*

Bugs fixed

V2 resolves two key issues:

Previously, latest modules were not installed on systems with discontinued modules. V2 now successfully updates modules that are not discontinued.
During the daily release window, installations sometimes failed because some modules were still being published. V2 avoids this by installing only the module versions that have completed publishing.

New features

Support for Offline Installation: The new -SourceZipPath parameter allows installation from locally staged files in offline or air-gapped environments.
Support for Prerelease Installation: A new parameter called -Prerelease allows installation of preview builds of AWS Tools for PowerShell and AWS Tools Installer.
Installer Update Notifications: When you import AWS Tools Installer, it displays a message notifying you if a new version is available.
Support for Standard Module Removal: AWS Tools Installer now adds metadata so you can remove modules using standard PowerShell commands (Uninstall-Module and Uninstall-PSResource).
Removal of Legacy Modules: AWS Tools Installer V2 supports uninstalling the legacy AWSPowerShell and AWSPowerShell.NetCore modules from the paths listed in the PSModulePath environment variable.

Uninstall-AWSToolsModule -CleanUpLegacyScope 'CurrentUser'
Install-AWSToolsModule -CleanUpLegacyScope 'CurrentUser'

Breaking changes

You must plan for the following potential issues when upgrading:

New download endpoint: AWS Tools Installer V2 uses following endpoint to download zip files: https://sdk-for-net.amazonwebservices.com/ps/. You might need to update your firewall rules to allow access to this endpoint.
Proxy parameters ignored: The -Proxy and -ProxyCredential parameters are now ignored and have no effect. They are still accepted for backward compatibility. To configure proxy settings for your environment, see the PowerShell environment variables documentation. On Windows PowerShell 5.1, downloads use your system proxy settings.
Force parameter behavior change: The -Force parameter is now deprecated and ignored for Uninstall-AWSToolsModule. When running Install-AWSToolsModule -Force, the existing module is overwritten even if the name and version match. To skip interactive confirmation prompts, add -Confirm:$false to the command.
Ignored parameters: The -SkipUpdate, -SkipPublisherCheck, and -AllowClobber parameters are accepted for backward compatibility but no longer have any effect. If your scripts relied on -SkipUpdate to prevent updates, installed modules will now be updated.

Note: The original V1 command behavior is preserved in these additional commands: Install-AWSToolsModuleV1, Uninstall-AWSToolsModuleV1, and Update-AWSToolsModuleV1. You can define an alias for each command to map legacy scripts back to the original functionality after upgrading to V2. For example:

Set-Alias -Name Install-AWSToolsModule -Value Install-AWSToolsModuleV1

Getting started

For prerequisites and full setup details, see Installing the AWS Tools for PowerShell.

Install the latest version of AWS Tools Installer V2 from the PowerShell Gallery (PSGallery) by running the following command:

Install-Module -Name AWS.Tools.Installer -MinimumVersion 2.0.0 -MaximumVersion 2.9.999 -Repository PSGallery

View help documentation

Once installed, run the following command to list the available AWS Tools Installer commands:

Get-Command -Module AWS.Tools.Installer

Run Get-Help to view documentation for any AWS Tools Installer command. For example:

Get-Help Install-AWSToolsModule -Full

Conclusion

AWS Tools Installer V2 is now generally available with faster installation, parallel extraction, and improved reliability. To get started, install V2 from PSGallery using the commands in this post.

Learn more on the AWS Tools for PowerShell product page
Read the AWS Tools for PowerShell documentation

Provide feedback

We’re looking forward to hearing what you think about the new version of AWS Tools Installer. Please share any feedback you have at the AWS Tools for PowerShell GitHub repository.

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.

AWS Developer Tools Blog

Get started with the Agent Toolkit for AWS in the AWS CLI

What’s in the Agent Toolkit for AWS?

Prerequisites

Set up the Agent Toolkit

Extend as your project grows

Conclusion

Announcing response streaming for .NET on AWS Lambda

Why response streaming?

Getting started with response streaming

Streaming an LLM response with Microsoft.Extensions.AI

Response streaming with API Gateway REST API

Response streaming with ASP.NET Core

Conclusion

Building and Deploying .NET AI Agents with Amazon Bedrock AgentCore

What is a .NET Bedrock AgentCore application?

Write your agent handler

Source generator

Extension methods

Select different models

Resolve services with automatic DI

Stream responses

Add conversation memory

Add logging and guardrails with middleware

Aspire integration

Local development

Deploying with Aspire

Testing package

Native AOT support

Deploying to AWS

Next steps

AWS Tools Installer V2 is Now Generally Available

V2 improvements

Bugs fixed

New features

Breaking changes

Getting started

View help documentation

Conclusion

Provide feedback

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)

`updateItem` and update expressions DSL