AWS Developer Tools Blog

Smithy Java client framework is now generally available

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

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

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

How it works

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

Model-driven development

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

namespace com.example

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

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

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

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

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

Generated clients

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

The following is an example of a generated Java client:

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

var menu = client.getMenu();

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

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

Key capabilities

Protocol flexibility

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

Dynamic client

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

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

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

Shape code generation independent of services

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

Built on Java virtual threads

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

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

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

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

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

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

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

Conclusion

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

About the author

Smithy Kotlin client code generation now generally available

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

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

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

How it works

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

Model-driven development

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

namespace com.example

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

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

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

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

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

Clients

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

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

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

What does general availability mean?

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

Conclusion

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

About the author

Upgrading AWS CLI From v1 to v2 Using the Migration Tool

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

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

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

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

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

Prerequisites

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

Getting Started

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

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

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

Step 2: Lint a bash script using interactive mode

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

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

#!/bin/bash
set -e

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

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

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

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

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

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

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

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

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

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

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

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

The following output snippet shows another finding:

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

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

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

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

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

The following output snippet shows another finding:

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

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

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

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

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

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

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

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

Step 3: Upgrade to AWS CLI v2

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

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

Step 4: Uninstall migration tool if no longer needed

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

Important Considerations

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

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

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

Conclusion

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

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

Transfer Manager Directory Support for AWS SDK for Ruby

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

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

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

Getting started

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

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

Initialize the Transfer Manager

To initialize a Transfer Manager with a default S3 client:

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

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

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

Upload a directory

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

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

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

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

Download a directory

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

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

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

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

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

Filtering contents

You can also filter transfers by using filter_callback:

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

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

Handling results

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

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

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

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

Conclusion

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

Key takeaways:

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

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

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

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

About the author

Upgrade AWS CLI from v1 to v2 using upgrade debug mode

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

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

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

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

Getting Started

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

AWS CLI v1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

aws configure set cli_binary_format raw-in-base64-out

Step 4: Verify resolution of warnings

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

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

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

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

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

Step 5: Manually review for breaking changes

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

Step 6: Upgrade to AWS CLI v2

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

Limitations

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

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

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

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

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

Conclusion

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

AWS SDK for .NET V3 Maintenance Mode Announcement

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

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

Support Timeline

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

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

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

Next Steps

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

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

Conclusion

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

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

GA Release of the AWS SDK Java 2.x HTTP Client built on Apache HttpClient 5.6

Dongie Agnir — Mon, 02 Mar 2026 19:24:38 +0000

If you’re using the Apache HttpClient 4.5.x with the AWS SDK for Java 2.x, you may have encountered dependency alerts for Jakarta Commons Logging (JCL) dependencies, concerns about long-term maintenance support, or compatibility issues with Java 21’s virtual threads. The new Apache 5 HTTP client solves these problems.

In this post, you’ll learn how to add the Apache 5 HTTP client to your project, configure it for your needs, and migrate from the 4.5.x version.

What’s new

Modern logging: Replaces the outdated JCL dependency with Simple Logging Facade for Java (SLF4J), giving you better compatibility with modern logging frameworks like Logback and Log4j2
Virtual thread support: Full compatibility with Java 21’s virtual threads for improved concurrency
Active maintenance: Apache HttpClient 5.x receives regular security updates and bug fixes

This client is available alongside the existing SDK HTTP clients: Apache HttpClient 4.5.x, Netty, URL Connection, and AWS CRT HTTP client. The new apache5-client Maven artifact lets you use both Apache versions in the same project without conflicts.

Getting started

Using the Apache 5 HTTP client in your SDK can require as little as a single step. If you’re coming from the Apache 4 client and want to set specific configurations, the new Apache 5 client offers identical options.

Add the Apache 5 client dependency

To begin using the Apache 5 HTTP client implementation, add the following dependency to your project:

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>apache5-client</artifactId>
    <version>2.41.26</version>
</dependency>

If you just want to use all the default configurations, then you do not need to configure anything else; your sync clients will use the Apache5 client under the hood.

S3Client s3Client = S3Client.create();

Advanced configuration example

If you want to configure certain options on the client, then just like with all of our clients, you can use Apache5HttpClient.builder() to obtain a builder and set the options you would like to:

Apache5HttpClient httpClient = Apache5HttpClient.builder()
    .connectionTimeout(Duration.ofSeconds(30))
    .maxConnections(100)
    .build();

DynamoDbClient dynamoDbClient = DynamoDbClient.builder()
    .httpClient(httpClient)
    .build();

Migrate from Apache 4.5.x

If you’re using the default Apache HTTP client, migration is straightforward:

Add the apache5-client dependency shown above
Update any explicit ApacheHttpClient references to Apache5HttpClient

The API remains consistent with other HTTP client implementations in the SDK. Note that like the 4.5.x client, this implementation supports synchronous service clients only.

Cleaning up

When you’re done with a service client, close it to release resources:


s3Client.close();

If you created a shared Apache5HttpClient instance, close it separately after closing the service clients that use it.

Conclusion

In this blog post, we showed you how to get started with the new Apache 5 HTTP client in the AWS SDK for Java 2.x, which uses Apache HttpClient 5.6.x. Please share your experience and any feature requests by opening a GitHub issue.

Announcing new output formats in AWS CLI v2

Andrew Asseily — Sat, 28 Feb 2026 02:22:30 +0000

Amazon Web Services (AWS) is announcing two new features for the AWS Command Line Interface (AWS CLI) v2: structured error output and the “off” output format.

Structured error output

Errors returned from AWS service APIs often include useful details beyond the code and message—bucket names, validation reasons, resource IDs—that were previously hidden unless you used --debug. Now, you can see this error information directly in your error output.

Starting with AWS CLI v2 version 2.34.0, any additional error details returned from service APIs will now be shown in the stderr output. Additionally, you can configure the AWS CLI to output your errors in alternative structured formats. Control how errors are displayed using the new --cli-error-format CLI flag, the cli_error_format configuration setting, or the AWS_CLI_ERROR_FORMAT environment variable.

Supported formats for the error format parameter:

enhanced (default) – Error message with additional details displayed inline
json – JSON structure with all error fields
yaml – YAML structure with all error fields
text – Tab-delimited error fields
table – ASCII table format
legacy – Original error format

Accessibility enhancements

Since September 2025, AWS CLI errors started including the aws: [ERROR]: prefix for some exceptions. This prefix signals that an error has occurred and supports accessibility best practices and automation use cases. This release ensures the prefix is consistently included for all errors in the enhanced and legacy formats.

Example: Using enhanced output error format

$ aws s3api get-object \
    --bucket amzn-s3-demo-bucket \
    --key file.txt out.txt \
    --cli-error-format enhanced

aws: [ERROR]: An error occurred (NoSuchBucket) when calling the GetObject operation: The specified bucket does not exist

Additional error details:

BucketName: amzn-s3-demo-bucket

Example: Using json output error format

$ aws s3api get-object \
    --bucket amzn-s3-demo-bucket \
    --key file.txt out.txt \
    --cli-error-format json
{
  "Code": "NoSuchBucket",
  "Message": "The specified bucket does not exist",
  "BucketName": "amzn-s3-demo-bucket"
}

Example: Using legacy output error format

$ aws s3api get-object \
    --bucket amzn-s3-demo-bucket \
    --key file.txt out.txt \
    --cli-error-format legacy

aws: [ERROR]: An error occurred (NoSuchBucket) when calling the GetObject operation: The specified bucket does not exist

Turning off CLI output

Sometimes, you might want to hide the AWS CLI command output, such as when using a command that may output sensitive information. The off format suppresses stdout while still preserving errors on stderr.

For example, you can create an AWS Secrets Manager secret without writing the secret ARN or version information to logs:

$ aws secretsmanager create-secret \
    --name my-secret \
    --secret-string "password123" \
    --output off
$ echo $?
0

You can set this using the--output off CLI flag, setting output = off in your configuration file, or the AWS_DEFAULT_OUTPUT=off environment variable.

Next Steps

To take advantage of these new output features, upgrade your version of the AWS CLI to 2.34.0. For more information, see the Structured error output and Output format guides. Please share your questions, comments, and issues with us on GitHub.

AWS Tools for PowerShell v4 Maintenance Mode Announcement

Sanket Tangade — Fri, 27 Feb 2026 18:25:37 +0000

In alignment with our previous announcement in August 2025 and SDKs and Tools Maintenance Policy, version 4 of the AWS Tools for PowerShell (AWS Tools for PowerShell v4.x) will enter maintenance mode on March 1, 2026 and reach end-of-support on June 1, 2026.

Beginning March 1, 2026, AWS Tools for PowerShell v4.x will enter maintenance mode and will only receive critical bug fixes and security updates. We will not update it to support new AWS services, new service features, or changes to existing services. Existing applications that use AWS Tools for PowerShell v4.x will continue to function as intended unless there is a fundamental change to how an AWS service works. This is uncommon, and we will announce it broadly if it happens. After June 1, 2026, when AWS Tools for PowerShell v4.x reaches end-of-support, it will no longer receive any updates or releases.

End of Support Timeline for Version 4

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

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

Conclusion

We recommend upgrading to the latest major version of AWS Tools for PowerShell v5.x by using the migration guide. This major version includes, but is not limited to, performance enhancements, bug fixes, modern .NET libraries and frameworks, and the latest AWS service updates. Upgrading enables you to leverage the latest services and innovations from AWS.

To learn more, refer to the following resources:

The AWS Tools for PowerShell landing page contains links to the getting started guide, key features, examples, and links to additional resources.
The Migrating to version 5 of the AWS Tools for PowerShell guide provides instructions for migrating and explains the changes between the two versions.
The AWS Tools for PowerShell v5.x GA blog post outlines the motivation for launching AWS Tools for PowerShell v5.x and includes the benefits over AWS Tools for PowerShell v4.x.
AWS Tools for PowerShell Code Examples provide code examples to help you use v5.x.

Feedback

If you need assistance or have feedback, reach out to your usual AWS support contacts. You can also open a discussion or issue on GitHub. Thank you for using AWS Tools for PowerShell.

Automate Custom CI/CD Pipelines for Landing Zone Accelerator on AWS

Anwaar Hussain — Tue, 24 Feb 2026 21:29:00 +0000

Managing infrastructure deployments across multiple AWS accounts and maintaining governance controls present a significant challenge for organizations. Manual deployment processes create bottlenecks that slow delivery, introduce human error, and make it difficult to maintain consistent security and compliance standards across environments. Landing Zone Accelerator on AWS (LZA) provides foundational governance and baseline infrastructure across your AWS environment, but organizations often need to deploy workload-specific resources—such as Amazon Virtual Private Cloud (Amazon VPC) resources, AWS Lambda functions, or AWS Glue jobs—that fall outside LZA’s core scope. When you’re using LZA for provisioning workload infrastructure, deployments can typically take 45–90 minutes.

This blog post shows you how to extend LZA with continuous integration and continuous deployment (CI/CD) pipelines that maintain your governance controls and accelerate workload deployments, offering rapid deployment of both Terraform and AWS CloudFormation across multiple accounts. You’ll build automated infrastructure deployment workflows that run in parallel with LZA’s baseline orchestration to help maintain your enterprise governance and compliance control requirements. You will implement built-in validation, security scanning, and cross-account deployment capabilities to help address Public Sector use cases that demand strict compliance and security requirements.

In this post, you’ll learn how to configure cross-account deployment workflows that integrate seamlessly with your existing LZA environment through customizations, implement security controls including automated validation and scanning, and maintain centralized governance as teams deploy workload-specific infrastructure independently across multiple accounts.

Prerequisites

Before implementing this automated deployment solution, verify that your environment meets requirements across three key areas:

LZA Requirements

You need an LZA environment version 1.14.2 or later with AWS Organizations enabled and Organizational Units (OUs) such as Root, Security, and Infrastructure configured.

AWS Account Requirements

You’ll need appropriate AWS Identity and Access Management (IAM) permissions to create and manage AWS CodePipeline, AWS CodeBuild, Amazon Simple Storage Service (Amazon S3), AWS Key Management Service (KMS), Amazon DynamoDB (DynamoDB), IAM roles, and AWS Systems Manager (SSM) Parameter Store across multiple accounts.

Source Code and Repository Access

You’ll also need access to a GitHub repository with your infrastructure code and authorization to create AWS CodeConnections for secure source integration.

You can access complete implementation code, including CloudFormation templates and LZA configurations, in the aws-samples/sample-aws-lza-cicd-customizations repository on the GitHub website.

With these prerequisites in place, let’s examine how the solution components work together to deliver automated CI/CD capabilities.

Solution overview

You’ll extend LZA with automated deployment workflows by combining several AWS services. CodePipeline orchestrates your CI/CD workflow with automated triggers from GitHub. CodeBuild executes validation, security scanning, and deployment tasks. CodeConnections integrates your workflows with GitHub repositories, and cross-account IAM roles provide secure multi-account deployments. S3 and KMS provide encrypted artifact storage, and DynamoDB manages Terraform state locking.

Your architecture supports both CloudFormation and Terraform deployments, with automated validation using cfn-lint, cfn-nag, tflint, and tfsec. Manual approval gates help control production changes, and centralized audit logging provides visibility into deployment activities.

Note: Third-party open-source tools (cfn-lint, cfn-nag, tflint, and tfsec) are subject to their respective licenses. AWS does not endorse or support these third-party tools. Verify license compliance and evaluate tool capabilities for your specific use case.

Now that you understand the solution, let’s walk through the architecture that enables this automation.

Architecture

The solution spans three AWS accounts across three Organizational Units: Management (Root OU) manages the LZA control plane, SharedServices (Infrastructure OU) hosts the CI/CD pipelines, and Sandbox (Sandbox OU) serves as the deployment target for workloads. As shown in Figure 1, your SharedServices account acts as the CI/CD hub, while the Sandbox account serves as the deployment target with appropriate IAM roles for cross-account access. This hub-and-spoke approach offers three key benefits: centralized governance with consistent security controls, simplified maintenance that reduces operational overhead, and clear separation of duties that maintains security boundaries between accounts.

Figure 1: hub-and-spoke CI/CD architecture with cross-account deployment

With the hub-and-spoke architecture established, let’s understand how infrastructure changes flow through the deployment pipelines.

CI/CD Pipeline Flow

The CloudFormation pipeline begins with the Source stage, pulling from GitHub when changes occur to a CloudFormation template. The Validate stage runs CodeBuild to execute cfn-lint for syntax checking and cfn-nag for security analysis. Next, the CreateChangeSet stage creates a ChangeSet in the Sandbox account. The Manual Approval stage pauses execution for your review. Finally, the ExecuteChangeSet stage deploys the infrastructure.

For Terraform deployments, the pipeline follows a similar pattern with different validation tools. The Source stage is configured to pull from GitHub when changes are detected in the Terraform directory. The Plan stage runs CodeBuild to execute Terraform fmt, validate, tflint, and tfsec, then generates a Terraform plan. The Manual Approval stage pauses for your review. The Apply stage executes Terraform apply to deploy infrastructure to the Sandbox account.

Figure 2: CloudFormation and Terraform pipeline deployment flows

Both workflows shown in Figure 2 provide automated validation and manual approval for infrastructure changes before reaching target accounts. These workflows maintain governance and compliance controls throughout the deployment lifecycle.

Key Security Features

Security remains critical when automating infrastructure deployments across multiple AWS accounts. Your CI/CD extension to LZA implements a security framework that protects your infrastructure through multiple defensive layers. This approach verifies that automated deployments maintain the same security standards as manual processes while reducing the risk of human error. The security model centers on three core principles: least-privilege access through carefully scoped IAM roles, defense-in-depth controls that protect data and operations at multiple layers, and automated validation that catches security issues before they reach production environments.

Cross-Account IAM Architecture

Your secure cross-account deployment capability start with a carefully designed IAM architecture. The solution implements a three-tier IAM security model where each component has precisely the permissions it needs and no more. You’ll deploy specialized roles for Terraform operations that manage infrastructure state and execute plans, CloudFormation deployment roles that handle stack operations and resource management, and cross-account orchestration roles that are used to coordinate activities between your SharedServices and target accounts.

Each role receives permissions scoped only to the specific AWS services and operations required for their deployment tasks. For example, your Terraform role can access S3 for state management and DynamoDB for locking, but cannot create IAM users or modify AWS Organizations settings. This granular approach is designed to reduce your attack surface, enhancing operational functionality. The complete IAM configuration details are available in LZA’s iam-config.yaml for your review and customization.

Security Controls

Your deployment workflow implements defense-in-depth security across multiple layers to protect infrastructure deployments and maintain compliance standards. Rather than relying on a single security control, this approach creates overlapping protections that guard against various threat vectors.

Data Protection and Encryption The solution encrypts data at rest and in transit. S3 buckets use KMS customer-managed keys that you control. Terraform state files are encrypted to protect sensitive infrastructure details. Transport Layer Security (TLS) 1.2 or higher protects data transmission. Cross-account KMS key policies confirm that only authorized roles in specific accounts can decrypt build artifacts and deployment packages.

Compliance and Audit Controls Automated governance and audit trails provide continuous oversight throughout the deployment lifecycle. Resource tagging adds custom markers for identifying and managing data processing activities. AWS CloudTrail tracks all deployment actions, creating an immutable record of operations.

Automated Security Validation Your pipelines include multiple automated security checks that identify misconfigurations before they reach production environments. CloudFormation templates undergo validation for syntax and best practices compliance, plus security analysis that identifies potential security issues in your resource configurations. Terraform configurations receive similar treatment through syntax verification, best practices enforcement, and security scanning that identifies common misconfigurations.

Governance and Oversight Manual approval gates provide human oversight for critical deployment decisions to maintain automated efficiency for routine operations. These approval points integrate with CloudTrail logging to create accountability records showing who approved which deployments. Your team can review Terraform plans and CloudFormation ChangeSets before execution, ensuring that automated systems implement exactly the changes you expect.

Solution Walkthrough

Now that you understand the architecture components, let’s walk through how you’ll implement this automated CI/CD solution. The deployment follows a foundation-first approach: you’ll start with Stage 1 to establish your shared infrastructure, then deploy Stages 2 and 3 to create your specific deployment pipelines. After completing the foundation stage, you can deploy the CloudFormation and Terraform pipelines in either order since they operate independently.

Stage 1: Foundation Resources

You’ll begin by deploying the CICD-Pipeline-Foundation stack to your SharedServices account. This stage creates the shared infrastructure that both CloudFormation and Terraform pipelines depend on for secure, cross-account operations.

The foundation stage establishes your artifact storage with S3 buckets for build artifacts and Terraform state storage. You’ll also get a KMS customer-managed key for encryption that includes cross-account access policies, supporting secure operations across your account boundaries. For source code integration, the stack creates CodeConnections that provide secure, token-based access to your repositories. Additionally, you’ll deploy a DynamoDB table for Terraform state locking to prevent concurrent modifications, plus SSM Parameter Store values that enable cross-stack references between your pipeline components.

Deployment Time: Estimated 10-15 minutes

Stage 2: CloudFormation Pipeline

Once your foundation is ready, you’ll deploy the CloudFormation-Workload-Deployment-Pipeline stack to your SharedServices account. This creates a complete CI/CD pipeline specifically designed for CloudFormation-based infrastructure deployments across multiple accounts.Your CloudFormation pipeline includes a CodePipeline that integrates with GitHub for source code management, performs automated validation to catch issues early, includes manual approval gates for governance compliance, and handles cross-account deployment stages. The pipeline uses a CodeBuild project configured with cfn-lint for syntax validation and cfn-nag for security analysis, ensuring your templates meet both technical and security standards before deployment. The cross-account deployment configuration targets your Sandbox account with appropriate IAM role assumptions, providing secure access without permanent credentials.

Deployment Time: Estimated 5-10 minutes

Stage 3: Terraform Pipeline

Your final deployment creates the Terraform-Pipeline stack, also in the SharedServices account. This pipeline facilitates Terraform-based infrastructure deployments with integrated planning, approval, and deployment workflows. The Terraform workflow includes a CodePipeline with GitHub source integration for version control, Terraform planning stages that show you exactly what changes will be made, manual approval workflows that maintain governance oversight, and automated apply stages for consistent deployments. You’ll get CodeBuild projects specifically optimized for Terraform plan generation and infrastructure deployment, plus integrated validation, formatting and security scanning tools for Terraform. Like the CloudFormation pipeline, this includes cross-account role assumption capabilities for secure deployments to your Sandbox account.

Deployment Time: Estimated 5-10 minutes

Figure 3: CodePipeline dashboard showing deployed CI/CD pipelines

Cost considerations

Operating costs for this CI/CD solution depend on deployment frequency, build duration, and artifact storage requirements.

Small applications (20 deployments/month): $5–7/month

CodePipeline: $2.00 (two active pipelines)
CodeBuild: $1.50
S3 storage: $0.23
DynamoDB: $0.37
KMS: $1.30
CloudWatch Logs: $0.50

Production environments (100+ deployments/month): $30–40/month

The increase is driven primarily by additional build minutes and artifact storage requirements.

Cost disclaimer: These estimates are examples based on January 19, 2025 AWS pricing in US East (N. Virginia). Actual costs vary by usage patterns and region.

Best Practices

Following these recommendations will help you optimize your CI/CD pipeline operations, reduce costs, and maintain security compliance.

Environment Management and Security

Implement proper environment separation using distinct AWS accounts for development, staging, and production deployments. This approach maintains isolation and prevents accidental changes to production infrastructure. Complement this with regular IAM policy reviews, restricting permissions following least-privilege principles to reduce security risks and maintain compliance requirements.

Monitoring and Troubleshooting

Configure monitoring by enabling CloudWatch logging for CodeBuild across regions and setting up alarms for pipeline failures. This visibility into deployment issues supports rapid troubleshooting when problems occur. Additionally, run validation tools locally before pushing to GitHub—this practice catches issues early, reduces feedback time compared to pipeline-based validation, and conserves CodeBuild minutes.

State and Artifact Management

Use DynamoDB for Terraform state locking to prevent concurrent modifications. Without proper locking, simultaneous Terraform apply operations can corrupt state files, causing infrastructure drift and deployment failures.

Security Validation

Make security scanning a priority by reviewing security findings before approval. Automated scanning catches misconfigurations early, reducing security vulnerabilities in production environments and enhancing your overall security posture.

Clean Up

To avoid ongoing charges, remove the deployed resources when you no longer need them. Follow these steps in order to prevent deletion conflicts:

Remove Deployed Infrastructure

Begin by removing workload infrastructure deployed through the pipelines in the Sandbox account. Use the AWS Management Console or AWS CLI to erase these resources, ensuring no dependencies remain before proceeding to the next step.

Delete CI/CD Pipeline Stacks

Remove the CI/CD pipeline stacks from the SharedServices account in reverse order of their creation. Start with the Terraform-Pipeline stack, followed by the CloudFormation-Workload-Deployment-Pipeline stack, and finally the CICD-Pipeline-Foundation stack. This sequence prevents dependency conflicts during deletion.

Clear S3 Storage

Before deleting the foundation stack, manually empty the S3 buckets containing artifacts and Terraform state files. CloudFormation cannot delete non-empty buckets, so this step prevents stack deletion failures.

Confirm Resource Removal

Check that resources have been successfully removed by reviewing CloudFormation stacks, S3 buckets, DynamoDB tables, and CodePipeline pipelines in the AWS Management Console. This verification step helps identify remaining resources that could generate ongoing charges.

Conclusion

In this post, we demonstrated how to extend AWS Landing Zone Accelerator with automated CI/CD pipelines supporting both Terraform and CloudFormation deployments across multiple accounts. By using LZA’s customizations feature alongside AWS native services like CodePipeline and CodeBuild, you can achieve consistent infrastructure deployment while preserving the security, governance, and compliance controls your organization requires.The hub-and-spoke architecture centralizes CI/CD operations in the SharedServices account, which standardizes deployment workflows, provides audit trails, and maintains security boundaries between target accounts. With automated validation, security scanning capabilities, and manual approval gates, this solution provides controls suitable for production environments managing complex multi-account AWS infrastructures.

Getting Started

Deploy the solution using the provided LZA configuration files:

Clone the Repository: Access the complete implementation from the aws-samples/sample-aws-lza-cicd-customizations GitHub repository
Configure LZA: Update the customizations-config.yaml file with your GitHub repository details
Deploy configuration: Commit and push changes to your LZA configuration repository
Activate GitHub connection: Manually authorize the CodeConnections integration in the AWS Management Console
Verify deployment: Check AWS CloudFormation stacks, CodePipeline creation, and SSM Parameter Store values

You can find complete deployment instructions, configuration examples, and troubleshooting guides in the repository README.

Additional Resources

AWS Documentation:

Need help? Contact your AWS Solutions Architect or visit AWS Support to discuss implementation strategies for your specific multi-account requirements.

Ready to automate your multi-account infrastructure deployments? Access the complete solution code and extend your Landing Zone Accelerator on AWS with custom CI/CD pipelines today!

Introducing Agent Plugins for AWS

Anita Lewis — Tue, 17 Feb 2026 19:13:25 +0000

Deploying applications to AWS typically involves researching service options, estimating costs, and writing infrastructure-as-code tasks that can slow down development workflows. Agent plugins extend coding agents with specialized skills, enabling them to handle these AWS-specific tasks directly within your development environment.

Today, we’re announcing Agent Plugins for AWS (Agent Plugins), an open source repository of agent plugins that provide coding agents with the agent skills to architect, deploy, and operate on AWS.

Today’s launch includes an initial deploy-on-aws agent plugin, which lets developers enter deploy to AWS and have their coding agent generate AWS architecture recommendations, AWS service cost estimates, and AWS infrastructure-as-code to deploy the application to AWS. We will add additional agent skills and agent plugins in the coming weeks.

Agent plugins are currently supported in Claude Code and Cursor (announced February 17). In this post, we’ll show you how to get started with Agent Plugins for AWS, explore the deploy-on-aws plugin in detail, and demonstrate how it transforms the deployment experience from hours of configuration to a simple conversation.

Why agent plugins

AI coding agents are increasingly used in software development, helping developers write, review, and deploy code more efficiently. Agent skills and the broader agent plugin packaging model are emerging as best practices for steering coding agents toward reliable outcomes without bloating model context. Instead of repeatedly pasting long AWS guidance into prompts, developers can now encode that guidance as reusable, versioned capabilities that agents invoke when relevant. This improves determinism, reduces context overhead, and makes agent behavior easier to standardize across teams. Agent plugins act as containers that package different types of expertise artifacts together. A single agent plugin can include:

Agent skills – Structured workflows and best-practice playbooks that guide AI through complex tasks like deployment, code review, or architecture planning. Agent skills encode domain expertise as step-by-step processes.
MCP servers – Connections to external services, data sources, and APIs. MCP servers give your assistant access to live documentation, pricing data, and other resources at runtime. Learn more about AWS MCP servers.
Hooks – Automation and guardrails that run on developer actions. Hooks can validate changes, enforce standards, or trigger workflows automatically.
References – Documentation, configuration defaults, and knowledge that the agent skill can consult. References make agent skills smarter without bloating the prompt.

As new types of expertise artifacts emerge in this space, they can be packaged into agent plugins, making the evolution transparent to developers.

The deploy-on-aws plugin

The initial release includes the deploy-on-aws plugin, which gives coding agents the knowledge to deploy applications to AWS with architecture recommendations, cost estimates, and infrastructure-as-code generation.

The agent plugin provides AI coding agents with a structured workflow:

Analyze – Scan your codebase for framework, database, and dependencies.
Recommend – Select optimal AWS services with concise rationale.
Estimate – Show projected monthly cost before committing.
Generate – Write CDK or CloudFormation infrastructure code.
Deploy – Execute your confirmation.

The initial plugin uses three MCP servers for AWS to provide comprehensive guidance:

MCP server	Purpose
AWS Knowledge	Documentation, architecture guidance, and best practices
AWS Pricing	Real-time service pricing for cost estimates
AWS IaC	Best practices for AWS Cloud Formation Kit (AWS CDK) and AWS CloudFormation

Agent plugins for AWS in action

Here’s how Agent plugins for AWS transform the software development experience:

A full-stack developer has built an Express.js REST API on their local machine. The application connects to a PostgreSQL database and serves a React frontend. The developer is ready to deploy to AWS but isn’t sure about the best architecture.

Using Cursor or Claude Code with the deploy-on-aws plugin installed, the developer enters:

Deploy this Express app to AWS

The plugin immediately springs into action:

Step 1: Analyze – The agent scans the codebase and identifies:

Express.js framework (Node.js 20.x)
PostgreSQL database dependency
Static React build in /public
Environment variables for database connection
Current traffic: ~1000 requests/day expected

Step 2: Recommend – Based on the analysis, the agent recommends:

AWS App Runner for the Express.js backend (auto-scaling, managed container service)
Amazon RDS PostgreSQL for the database (managed, automated backups)
Amazon CloudFront + S3 for the React frontend (global CDN, cost-effective static hosting)
AWS Secrets Manager for database credentials

Step 3: Estimate – The agent provides a cost estimate using real-time pricing data from the AWS Pricing MCP server, giving you visibility into projected monthly costs before you commit to any infrastructure.

Step 4: Generate The developer reviews the estimate and confirms. The agent generates:

AWS CDK infrastructure code in TypeScript
Dockerfile for the Express app
Database migration scripts
Environment configuration
GitHub Actions workflow for CI/CD

Step 5: Deploy The developer reviews the generated code, makes minor adjustments to database schema, and confirms deployment. The agent:

Provisions all AWS resources via CDK
Builds and deploys the container to App Runner
Creates the Amazon RDS database and runs migrations
Uploads the React build to S3 and configures CloudFront
Stores credentials in Secrets Manager

Within minutes, the developer’s application is live at a custom App Runner URL, with the React frontend served globally via CloudFront. The agent provides:

Application URLs (backend and frontend)
Database connection details
CloudWatch dashboard links for monitoring
Cost tracking setup

What would have taken hours of reading documentation, comparing services, and writing infrastructure code took less than 10 minutes with the deploy-on-aws plugin. Developers can now focus on building features instead of wrestling with cloud deployment complexity.

Getting started with Agent Plugins for AWS

Prerequisites

To get started, you need:

An agent plugin compatible AI coding tool (Claude Code, Cursor, or other compatible tools)
AWS CLI configured with appropriate credentials

Installation

Claude Code

Add the Agent Plugins for AWS marketplace to Claude Code:/plugin marketplace add awslabs/agent-plugins

Install the deploy-on-aws plugin:

/plugin install deploy-on-aws@awslabs-agent-plugins

Cursor

Cursor announced support for agent plugins on February 17. You can install the deploy-on-aws plugin directly from the Cursor Marketplace, or manually in Cursor by:

Open Cursor Settings
Navigate to Plugins, and in the search bar type aws
Select the plugin you want to install, and Click add to cursor, then select the scope
Now the plugin should appear under Plugins, installed

Learn more in the Cursor Marketplace announcement.

Skill triggers

The deploy-on-aws plugin responds to natural language requests like:

“Deploy to AWS”
“Host on AWS”
“Run this on AWS”
“AWS architecture for this app”
“Estimate AWS cost”
“Generate infrastructure”

Best practices for plugin-assisted development

To maximize the benefits of plugin-assisted development while maintaining security and code quality, follow these essential guidelines:

Always review generated code before deployment (for example, against your constraints for security, cost, resilience)
Use plugins as accelerators, not replacements for developer judgment and expertise.
Keep plugins updated to benefit from the latest AWS best practices.
Follow the principle of least privilege when configuring AWS credentials.
Run security scanning tools on generated infrastructure code.

Conclusion

In this post, we showed how Agent Plugins for AWS extend coding agents with skills for deploying applications to AWS. Using the deploy-on-aws plugin, you can generate architecture recommendations, cost estimates, and infrastructure-as-code directly from your coding agent.

Beyond deployments, agent plugins can help with other AWS workflows; more agent plugins for AWS are launching soon. You can also use AWS MCP servers to give your coding agent access to specialized tools to build on AWS.

Visit the Agent Plugins for AWS repository to install and configure your agent plugins
Install the deploy-on-aws plugin from the Cursor Marketplace and start deploying from your editor

About the authors

AWS Tools Installer V2 Preview

Jonathan Nunn — Tue, 17 Feb 2026 00:28:42 +0000

If you’ve been managing multiple AWS Tools for PowerShell modules individually, you know how time-consuming installations and updates can be. Today, we’re excited to announce AWS Tools Installer V2, which provides performance improvements and additional guidance.

Improvements in V2

Standard PowerShell installation commands like Install-Module and Install-PSResource download modules that are packaged individually. To maximize performance when installing hundreds of modules, AWS Tools Installer V2 installs modules that are packaged together from Amazon CloudFront. We recommend installing all AWS Tools for PowerShell modules together as a complete set so that commands are available for immediate use and to avoid module import conflicts that arise when all modules have not been updated to the same version.

The following example shows how to install all AWS Tools for PowerShell modules at once by running Install-AWSToolsModule. Use the -Version parameter to limit updates to minor versions of V5 of AWS Tools for PowerShell to reduce the risk of breaking changes.

Install-AWSToolsModule -Version 5.*

AWS Tools Installer V2 also introduces the self-update commands Install-AWSToolsInstaller and Uninstall-AWSToolsInstaller so that the installer module itself is easier to update.

The following example shows how to install the latest minor version updates for AWS Tools Installer V2 to reduce the risk of breaking changes.

Install-AWSToolsInstaller -Version 2.*

Bugs Fixed

V2 resolves two key issues:

Previously, latest modules would no longer be installed on systems where discontinued modules were installed. V2 now successfully updates all modules that are not discontinued.
During the daily release window, installations sometimes failed because modules were still being published. V2 avoids this by only installing versions of modules that have completed the publishing process.

New Features

Support for Offline Installation: A new parameter called -SourceZipPath enables installation from locally-staged files in offline or air-gapped environments.
Support for Prerelease Installation: A new parameter called -Prerelease enables installation of preview builds of AWS Tools for PowerShell and AWS Tools Installer.
Installer Update Notifications: When importing AWS Tools Installer, it writes a message to the host to notify users if a new version is available.
Support for Standard Removal of PowerShell Module: AWS Tools Installer now adds metadata to enable module removal through 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 your PSModulePaths. Unlike these legacy modules, which load everything at once, AWS Tools for PowerShell modules import quickly and automatically as needed.

Uninstall-AWSToolsModule -CleanUpLegacyScope 'CurrentUser'

Install-AWSToolsModule -CleanUpLegacyScope 'CurrentUser'

Breaking Changes

You must plan for the following potential issues when upgrading:

AWS Tools Installer V2 uses the endpoint https://sdk-for-net.amazonwebservices.com/ps/ to download zip files. You might need to update your firewall rules to allow access to this endpoint.
The parameters -Proxy and -ProxyCredential have been removed. Please configure proxy settings for your environment if necessary.
The -Force parameter has been removed for Uninstall-AWSToolsModule. Using Install-AWSToolsModule -Force will confirm that any existing module will be overwritten even if it has the same name and version compared to the module that was downloaded. To skip interactive confirmation prompts when using cmdlets, use the following syntax: -Confirm:$false.
The parameters -SkipUpdate, -SkipPublisherCheck, and -AllowClobber are now ignored and have no effect. While these parameters are still accepted for backward compatibility, they no longer perform any function. Scripts relying on -SkipUpdate to prevent updates of other installed modules will now have all installed modules updated.

Note: The original behavior of cmdlets from V1 is preserved in the additional cmdlets: Install-AWSToolsModuleV1, Uninstall-AWSToolsModuleV1, and Update-AWSToolsModuleV1. An alias can be defined for each cmdlet so that all legacy scripts running on a system map back to the original functionality after upgrading to V2, for example:

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

Getting Started

To obtain the preview build of AWS Tools Installer V2 you can install from PSGallery using Install-Module:

Install-Module -Name AWS.Tools.Installer -MinimumVersion 2.0.0 -AllowPrerelease

Please note that this a preview build and is not intended for use in production environments.

Review Help Documentation

Once installed, run the following PowerShell command to list AWS Tools Installer commands.

Get-Command -Module AWS.Tools.Installer

Use the Get-Help command to view the documentation for a particular AWS Tools Installer command. For example:

Get-Help Install-AWSToolsModule -Full

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 on the AWS Tools Installer V2 Preview Tracker at the AWS Tools for PowerShell GitHub repository.

GA Release Following Preview

We are planning to release V2 for general availability once we’ve had an opportunity to collect feedback. To avoid breaking changes, please make sure that your production workloads are configured to NOT install major version updates:

Install-Module -Name AWS.Tools.Installer -MaximumVersion '1.9.999'

Introducing Multipart Download Support for AWS SDK for .NET Transfer Manager

Garrett Beatty — Mon, 09 Feb 2026 16:27:06 +0000

The new multipart download support in AWS SDK for .NET Transfer Manager improves the performance of downloading large objects from Amazon Simple Storage Service (Amazon S3). Customers are looking for better performance and parallelization of their downloads, especially when working with large files or datasets. The AWS SDK for .NET Transfer Manager (version 4 only) now delivers faster download speeds through automatic multipart coordination, eliminating the need for complex code to manage concurrent connections, handle retries, and coordinate multiple download streams.

In this post, we’ll show you how to configure and use these new multipart download capabilities, including downloading objects to files and streams, managing memory usage for large transfers, and migrating from existing download methods.

Parallel download using part numbers and byte-ranges

For download operations, the Transfer Manager now supports both part number and byte-range fetches. Part number fetches download the object in parts, using the part number assigned to each object part during upload. Byte-range fetches download the object with byte ranges and work on all 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 numbers 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 enable greater parallelization when objects have large parts (for example, splitting a 5GB part into multiple 50MB range requests for concurrent transfer) and work with any S3 object regardless of how it was uploaded.

Keep in mind that smaller range sizes result in more S3 requests. Each API call incurs a 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 set up your development environment.

Getting started

To get started with multipart downloads in the AWS SDK for .NET Transfer Manager, follow these steps:

Add the dependency to your .NET project

Update your project to use the latest AWS SDK for .NET:

dotnet add package AWSSDK.S3 -v 4.0.17

Or add the PackageReference to your .csproj file:

<PackageReference Include="AWSSDK.S3" Version="4.0.17" />;

Initialize the Transfer Manager

You can initialize a Transfer Manager with default settings for typical use cases:

var s3Client = new AmazonS3Client(); 
var transferUtility = new TransferUtility(s3Client);

You can customize the following options:

// Create custom Transfer Manager configuration 
var config = new TransferUtilityConfig 
{ 
    ConcurrentServiceRequests = 20,  // Maximum number of concurrent HTTP requests 
    BufferSize = 8192  // Buffer size in bytes for file I/O and HTTP responses 
}; 
 
// Create Transfer Manager with custom configuration 
var transferUtility = new TransferUtility(s3Client, config);

Experiment with these values to find the optimal configuration for your use case. Factors like object size, available network bandwidth, and your application’s memory constraints will influence which settings work best. For more information about configuration options, please refer to the documentation on TransferUtilityConfig.

Download an object to file

To download an object from an Amazon S3 bucket to a local file, use the DownloadWithResponseAsync method. You must provide the source bucket, the S3 object key, and the destination file path.

// Download large file with multipart support (Part GET strategy) 
var downloadResponse = await transferUtility.DownloadWithResponseAsync( 
    new TransferUtilityDownloadRequest 
    { 
        BucketName = "amzn-s3-demo-bucket", 
        Key = "large-dataset.zip", 
        FilePath = @"C:\downloads\large-dataset.zip", 
        MultipartDownloadType = MultipartDownloadType.PART  // Default - uses S3 part numbers 
    });

// Download using Range GET strategy (works with any S3 object) 
var downloadResponse = await transferUtility.DownloadWithResponseAsync( 
    new TransferUtilityDownloadRequest 
    { 
        BucketName = "amzn-s3-demo-bucket", 
        Key = "any-object.dat", 
        FilePath = @"C:\downloads\any-object.dat", 
        MultipartDownloadType = MultipartDownloadType.RANGE,  // Uses HTTP byte ranges 
        PartSize = 16 * 1024 * 1024  // 16MB parts (default is 8MB) 
    });

Download an object to stream

To download an object from Amazon S3 directly to a stream, use the OpenStreamWithResponseAsync method. This is useful when you want to process data as it downloads without saving it to disk first. You must provide the source bucket and the S3 object key. The OpenStreamWithResponseAsync method performs parallel downloads by buffering parts in memory until they are read from the stream. See the configuration options below for how to control memory consumption during buffering.

// Stream large file with multipart coordination and memory control 
var streamResponse = await transferUtility.OpenStreamWithResponseAsync( 
    new TransferUtilityOpenStreamRequest 
    { 
        BucketName = "amzn-s3-demo-bucket", 
        Key = "large-video.mp4", 
        MaxInMemoryParts = 512,  // Maximum number of parts buffered in memory  (default is 1024)
                                  // Total memory = MaxInMemoryParts × PartSize 
        MultipartDownloadType = MultipartDownloadType.PART,  // Uses S3 part numbers 
        ChunkBufferSize = 64 * 1024  // Size of individual memory chunks (64KB) 
                                      // allocated from ArrayPool for buffering. (default is 64KB) 
    }); 
 
using var stream = streamResponse.ResponseStream; 
// Process stream data as it downloads concurrently 
var buffer = new byte[8192]; 
int bytesRead = await stream.ReadAsync(buffer, 0, buffer.Length);

Memory management for streaming downloads: The MaxInMemoryParts parameter controls how many parts can be buffered simultaneously, and ChunkBufferSize determines the size of individual memory chunks allocated for buffering. You can experiment with different values for both parameters to find the optimal configuration for your specific use case.

Download a directory

To download multiple objects from an S3 bucket prefix to a local directory, use the DownloadDirectoryWithResponseAsync method. This method automatically applies multipart download to each individual object in the directory.

// Download entire directory with multipart support for large files 
await transferUtility.DownloadDirectoryWithResponseAsync( 
    new TransferUtilityDownloadDirectoryRequest 
    { 
        BucketName = "amzn-s3-demo-bucket", 
        S3Directory = "datasets/", 
        LocalDirectory = @"C:\data\" 
    });

Migration path

The new WithResponse methods provide both multipart performance and access to S3 response metadata. Here’s how to migrate your existing code:

For file downloads:

// Existing code (still works, but returns void) 
await transferUtility.DownloadAsync(downloadRequest); 
 
// Enhanced version (new capabilities + metadata access) 
var response = await transferUtility.DownloadWithResponseAsync(downloadRequest); 
Console.WriteLine($"Downloaded {response.ContentLength} bytes"); 
Console.WriteLine($"ETag: {response.ETag}");

For streaming downloads:

// Before: direct Stream return 
using var stream = await transferUtility.OpenStreamAsync(streamRequest); 
 
// After: access ResponseStream from response object 
var response = await transferUtility.OpenStreamWithResponseAsync(streamRequest); 
using var stream = response.ResponseStream; 
Console.WriteLine($"Content-Type: {response.ContentType}"); 
Console.WriteLine($"Last Modified: {response.LastModified}");

Conclusion

The multipart download support in the AWS SDK for .NET Transfer Manager provides performance improvements for downloading large objects from Amazon S3. By using parallel byte-range or part-number fetches, you can reduce transfer times.

Key takeaways from this post:

Use DownloadWithResponseAsync and OpenStreamWithResponseAsync for downloads with automatic multipart coordination
Choose between PART and RANGE download strategies based on your object’s structure
Customize configuration settings based on your specific environment (memory, network bandwidth, etc.)

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

To learn more about the AWS SDK for .NET Transfer Manager, visit the AWS SDK for .NET documentation. For questions or feedback about this feature, visit the GitHub issues page.

CLI v1 Maintenance Mode Announcement

Anna-Karin Salander — Thu, 15 Jan 2026 17:38:02 +0000

In alignment with our SDKs and Tools Maintenance Policy, version 1 of the AWS Command Line Interface (AWS CLI v1) will enter maintenance mode on July 15, 2026 and reach end-of-support on July 15, 2027.

Scripts and workflows made for AWS CLI v1 will continue working during this period, unless an AWS service makes fundamental changes. Such large changes are uncommon, and we will communicate them broadly. Between July 15, 2026 and end-of-support on July 15, 2027, AWS CLI v1 will only receive critical bug fixes and security updates. We will not add new features to the AWS CLI v1, including changes to AWS CLI v1 itself, new AWS services, existing services, or expansions of regions and endpoints.

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

SDK Lifecycle Phase	Start Date	End Date	Support Level
General Availability	11/19/2015	7/14/2026	During this phase, AWS CLI v1 is fully supported. AWS will provide regular releases that include support for new services, API updates for existing services, as well as bug and security fixes.
Maintenance mode	7/15/2026	7/14/2027	AWS will limit releases to address critical bug fixes and security issues only. The AWS CLI v1 will not receive API updates for new or existing services, or be updated to support new regions.
End-of-support	7/15/2027	N/A	AWS CLI v1 will no longer receive updates or releases. Previously published releases will continue to be available via public package managers and the code will remain on GitHub.

We recommend that customers of AWS CLI v1 migrate to AWS CLI v2. The AWS CLI v2 provides improved features, enhanced performance, and continued support from AWS. By adopting the latest version of the AWS CLI, developers ensure the security, compatibility, and stability of their solutions on AWS. Updating enables you to leverage the latest services and innovations from AWS. To learn more, refer to the following resources:

The AWS CLI landing page contains links to the getting started guide, key features, examples, and links to additional resources.
The Migration guide for the AWS CLI version 2 in the AWS CLI User Guide explains the changes between the two versions and instructions for migrating.
You can use CLI v1’s upgrade debug mode introduced in 1.44.0 to highlight features that have changed from v1 to v2 when executing your commands or scripts, as well as the AWS CLI v1-to-v2 Migration Tool to lint and upgrade scripts.
The AWS CLI Version 2 – General Availability announcement post in the AWS Developer Tools Blog outlines the motivation for launching AWS CLI v2 and includes the benefits over AWS CLI v1.

Additional features of AWS CLI v2

The AWS CLI v2 includes an embedded version of Python and no longer requires, or interacts with, your system-wide version of Python. A major theme for version 2 is the interactive features such as server-side command completion, auto-prompt, and wizards that guide you through constructing and running AWS CLI commands. V2 also supports simplified developer access with aws login, AWS IAM Identify Center authentication, and new commands under aws configure for managing profiles and credentials.

While we strived to keep the two versions of AWS CLI compatible, there are features introduced in version 2 that have not been back ported to version 1. The most notable are high-level DynamoDB commands, EC2 Instance Connect with an SSH client, and the interactive mode for CloudWatch Logs Live Tail.

Feedback

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

About the authors

AWS SDK for JavaScript aligns with Node.js release schedule

Trivikram Kamat — Mon, 08 Dec 2025 17:32:10 +0000

This post is about AWS SDK for JavaScript v3 announcing end of support for Node.js versions based on Node.js release schedule, and it is not about AWS Lambda. For the latter, refer to the Lambda runtime deprecation policy.

In the second week of January 2026, the AWS SDK for JavaScript v3 (JS SDK) will start following the Node.js release schedule for ending support for Node.js and ECMAScript versions. The JS SDK versions will be tested on all Long-Term Support (LTS) versions of Node.js, with an additional 8 months of support for the most recent end-of-life (EOL) version. When we drop support for specific Node.js EOL version, we will also drop support for equivalent ECMAScript version in browsers.

The Node.js release schedule states that LTS versions reach EOL in April, and there are three LTS versions supported at any point in time. For example, Node.js 18.x was supported until April 2025 (until Node.js 24.x was published), and Node.js 20.x will be supported until April 2026 (until the next LTS version of Node.js will be published). In accordance with the AWS SDKs and Tools maintenance policy for language runtimes, the JS SDK will support each Node.js major version for an additional 8 months past the Node.js EOL date. (AWS reserves the right to drop support for unsupported Node.js versions earlier to address critical security issues.)

Along with dropping support for the Node.js EOL version, the JS SDK will also drop support for the equivalent ECMAScript version in browsers. The following table summarizes the upcoming dates.

Node.js Version	Release Date	Node.js End of Life	JS SDK End of Support
18.x	April 2022	April 2025	January 2026: Migrate to 20.x+ and ES2023+
20.x	April 2023	April 2026*	January 2027*: Migrate to 22.x+ and ES2024+
22.x	April 2024	April 2027*	January 2028*: Migrate to 24.x+ and ES2025+
24.x	April 2025	April 2028*	January 2029*: Migrate to 26.x+ and ES2026+

* These dates are speculative based on Node.js release schedule.

Benefits of upgrading Node.js versions

Your applications’ security depends on staying current with the JavaScript ecosystem. When Node.js versions reach EOL, they no longer receive security patches or bug fixes, exposing your applications to vulnerabilities.

By aligning with the Node.js release schedule, you can make sure you have access to the following:

A secure, up-to-date runtime that protects your applications from known vulnerabilities.
Ongoing performance improvements that keep your applications running optimally.
Predictable support timelines to plan future upgrades without disruption.

We strongly recommend upgrading to a supported Node.js version—preferably the latest LTS.

What to expect

If you’re using the latest JS SDK version with the Node.js LTS version that is EOL, the following message will be shown when you create an instance of any client:

// test.mjs or test.js with type:module
import { DynamoDB } from "@aws-sdk/client-dynamodb";

const client = new DynamoDB({});

$ node test.mjs
...
NodeDeprecationWarning: The AWS SDK for JavaScript (v3) will
no longer support Node.js v18.20.8 in January 2026.

To continue receiving updates to AWS services, bug fixes, and security
updates please upgrade to supported version of Node.js.

More information can be found at: https://a.co/c895JFp
...

In the second week of January, the GitHub and npm releases for the JS SDK will contain release notes stating the end of support for the Node.js EOL version. The exact SDK version will be included in the same release notes.

If you are using the Node.js EOL version, installing the later versions of the SDK will cause an engine deprecation warning to appear. If you have set engine-strict=true, an npm installation error with code ENOTSUP will occur as follows:

$ node --version
v18.20.8

$ npm install @aws-sdk/client-s3
...
npm ERR! code ENOTSUPnpm ERR! notsup Unsupported engine for @aws-sdk/client-s3@<version>: wanted: {"node":">=20.0.0"} (current: {"node":"18.20.8","npm":"10.8.2"})
...

The JS SDK versions released in the second week of January may continue to work on the Node.js EOL version. This does not imply a continuation of support. You can continue to use older versions of the JS SDK released before the second week of January with the Node.js EOL version.

Along with dropping support for the Node.js EOL version, we will also drop support for the equivalent ECMAScript version in browsers. This doesn’t impact most applications because new versions of browsers are released at a much faster pace (usually every 4–6 weeks), and they are automatically updated. Also, most browser applications use bundlers, where the ECMAScript version is specified in the application bundler configuration and the bundler will transpile all dependencies to that target. For applications that need to support very old browsers, you must provide polyfills.

Maintenance policies

We followed the Node.js release schedule and AWS SDKs and Tools maintenance policy to arrive at the end-of-support cadence for Node.js and equivalent ECMAScript version in browsers.

Node.js Release Schedule

Refer to the Node.js release schedule for a complete list of Node.js versions and their maintenance status.

The new even-numbered versions (e.g. v20.x, v22.x, v24.x, and so on) are released in April, whereas odd-numbered versions (e.g. v21.x, v23.x) are released in October. When a new odd-numbered release is available, the previous even-numbered version transitions to LTS.

AWS SDKs and Tools

For more information regarding maintenance and deprecation for AWS SDKs, see the AWS SDKs and Tools maintenance policy. Our policy is to continue supporting SDK dependencies for at least 6 months after the community or vendor ends support for the dependency.

Feedback

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.

Introducing Amazon S3 Transfer Manager for Swift (Developer Preview)

Chan Yoo — Fri, 21 Nov 2025 21:02:48 +0000

We are pleased to announce the Developer Preview release of the Amazon S3 Transfer Manager for Swift —a high-level file and directory transfer utility for Amazon Simple Storage Service (Amazon S3) built with the AWS SDK for Swift.

By using the S3 Transfer Manager API, you can now perform accelerated uploads of local files and directories to Amazon S3 and accelerated downloads of objects and buckets from Amazon S3. The concurrent transfers of a set of small parts from a single object provide enhanced throughput and reliability. The S3 Transfer Manager is built on top of the AWS SDK for Swift and uses Amazon S3 multipart upload and byte-range or part-number fetches for parallel transfers. You can also track the progress of transfers in real-time.

In this post we’ll explain how to use Amazon S3 Transfer Manager for Swift.

Parallel upload using 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 using 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 choose your .xcodeproj file, located at the top of the file navigator on the left pane.
Choose the project name that appears on the left pane of the .xcodeproj file window.
Choose the Package Dependencies tab, and choose the + button.
In the 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: "0.1.0"
    )
],

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 S3 Transfer Manager instance with all-default settings with the following:

// 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 the S3 Transfer Manager instance, for example:

// Create the custom S3 client config that you want S3TM to use.
let customS3ClientConfig = try S3Client.S3ClientConfiguration(
    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 an Amazon S3 bucket, 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 the object being uploaded is bigger than the threshold configured by multipartUploadThresholdBytes (16MB default), the S3 Transfer Manager breaks them down into parts, each with the part size configured by targetPartSizeBytes (8MB default), and uploads them concurrently using the multipart upload feature from Amazon S3

// 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 an Amazon S3 bucket, 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 the object being downloaded is bigger than the size of a single part configured by targetPartSizeBytes (8MB default), the S3 Transfer Manager 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 S3 Transfer Manager today and let us know what you think via the GitHub issues page!

About the authors

What’s New in the AWS Deploy Tool for .NET

Philippe El Asmar — Tue, 14 Oct 2025 13:25:42 +0000

Version 2.0 of the AWS Deploy Tool for .NET is now available. This new major version introduces several foundational upgrades to improve the deployment experience for .NET applications on AWS.

The tool comes with new minimum runtime requirements. We have upgraded it to require .NET 8 because the predecessor, .NET 6, is now out of official support from Microsoft. The tool also requires Node.js 18.x or later because this version of Node.js is the new minimum version that the AWS Cloud Development Kit (CDK) supports, which is a dependency.

Outside of these prerequisites, there are no other breaking changes to the tool’s commands or your existing deployment configurations. We expect a smooth upgrade for most users. Let’s get into the details.

Breaking Changes

This section details the mandatory changes required to use version 2.0.

.NET 8 Runtime Requirement

The AWS Deploy Tool for .NET is now built on .NET 8, replacing the previous .NET 6 runtime. As noted in the introduction, we made this change because .NET 6 is now out of official support from Microsoft.

To use this new version, you must have the .NET 8 installed on your development machine. This mandatory upgrade ensures that the deploy tool itself remains on a secure, stable, and supported foundation for the future.

Node.js 18 Prerequisite

We also updated the minimum required Node.js version for the deploy tool to 18.x (from 14.x). This is necessary because Node.js 18 is the new minimum version for the CDK, which is one of the underlying dependencies for the deploy tool. Please ensure that you have Node.js 18 or later installed on your development machine.

New Features and Key Updates

Container engine flexibility with support for Podman

In addition to Docker, the deploy tool now includes support for Podman as a container engine. The deploy tool now automatically detects both Docker and Podman on your machine. To ensure a consistent experience for existing users, the tool defaults to Docker if it is running. If Docker is not running, the tool then checks for an available Podman installation and uses that as the container engine. This gives you more flexibility in your container workflow while maintaining predictable behavior.

.NET 10 deployment support

To ensure adoption of the latest .NET versions as they become available, this release adds support for deploying .NET 10 applications.

For deployment targets such as AWS Elastic Beanstalk that might not have a native .NET 10 managed runtime at the time of its release, the deploy tool automatically publishes your project as a self-contained deployment bundle. This bundle includes the .NET 10 runtime and all necessary dependencies alongside your application code. This approach allows your .NET 10 application to run on the target environment without requiring a pre-installed runtime, providing a smooth path forward as you upgrade your projects.

Other Notable Updates

This release also includes other important foundational and dependency updates:

Optimized Dockerfile Generation: When deploying to a container-based service such as Amazon Elastic Container Service (Amazon ECS), the deploy tool generates a Dockerfile if one doesn’t already exist. Previously, to run Single Page Applications (SPAs), the generated Dockerfile included steps to install Node.js in the container’s build stage. This is no longer the default behavior. By removing the Node.js installation from the build image, you will see improved container build times and a reduced number of dependencies to manage during the build process. If your application requires Node.js for its build (for example, an Angular or React frontend), you must now add the required installation steps to the generated Dockerfile.
Upgraded CLI Foundation: The command-line handling library has been switched to Spectre.CLI. This provides the foundation for future improvements like interactive guided deployments and enhanced output formatting.
AWS CDK: We’ve updated the AWS Cloud Development Kit (CDK) library to version 2.194.0 and the CDK CLI to 2.1013.0.
AWS SDK for .NET V4: The tool now leverages version 4 of the AWS SDK for .NET, bringing in the latest features in performance-optimized packages.
Microsoft Templating Engine: We also updated the engine that powers our project recipes from .NET 5 to .NET 8, improving the reliability of the templating experience.

How to Get the New Version

Ready to get started? The new version is available for both .NET CLI and Visual Studio.

For the .NET CLI:

To update to the latest version, simply run the following command:

dotnet tool update -g AWS.Deploy.Tools

If you’re a new user, use this command to install the tool:

dotnet tool install -g AWS.Deploy.Tools

For Visual Studio:

These deployment features are integrated into the AWS Toolkit for Visual Studio. To get the latest updates:

Open Visual Studio
Go to Extensions > Manage Extensions.
In the Updates tab on the left pane, find the AWS Toolkit for Visual Studio and choose Update.
You will need to close Visual Studio for the update to be installed.

If you don’t already have the AWS Toolkit installed, see the installation instructions.

What’s Next?

We will continue to expand the feature scope to make sure that deploying .NET applications to AWS is as easy as possible. Please install or upgrade to the latest version of this deployment tool (CLI or toolkit), try a few deployments, and let us know what you think by opening a GitHub issue.

To learn more, check out our Developer guide. The .NET CLI tooling is open source and our Github repo is a great place to provide feedback. Bug reports and feature requests are welcome!

General Availability Release of the Migration Tool for the AWS SDK for Java 2.x

David Ho — Fri, 26 Sep 2025 16:47:36 +0000

The AWS SDK for Java 1.x (v1) entered maintenance mode on July 31, 2024, and will reach end-of-support on December 31, 2025. We recommend that you migrate to the AWS SDK for Java 2.x (v2) to access new features, enhanced performance, and continued support from AWS. To help you migrate efficiently, we’ve created a migration tool that automates much of the transition process. This tool uses OpenRewrite, an open source automated code refactoring tool, to upgrade supported 1.x code to 2.x code.

You can now transform code for all service SDK clients as well as the Amazon Simple Storage Service (S3) TransferManager high-level library. The migration tool doesn’t support transforms for other high-level APIs such as DynamoDBMapper. These unsupported transforms require manual migration. For assistance with migration for those features, check out our migration guide.

In this blog post, we demonstrate the convenience of using the migration tool to begin migrating your application to 2.x, and call out limitations you may run into.

Getting started

Maven project

For a Maven project, we will use the OpenRewrite Maven plugin.

Step 1: navigate to your project directory

Open a terminal (command line) window and go to the root directory of your application.

Step 2: run the `rewrite` command

There are two modes you can choose: dryRun and run.

dryRun

In this mode, the plugin generates diff logs in the console and a patch file rewrite.patch in the target/rewrite folder. This mode does not modify the source code, so it is helpful to preview the changes that would be made.

mvn org.openrewrite.maven:rewrite-maven-plugin:${maven-plugin-version}*:dryRun \
  -Drewrite.recipeArtifactCoordinates=software.amazon.awssdk:v2-migration:${sdkversion}** \
  -Drewrite.activeRecipes=software.amazon.awssdk.v2migration.AwsSdkJavaV1ToV2

*Replace ${maven-plugin-version} with the latest SDK-tested version (6.17.0 at the time of GA release), as specified in the SDK Maven test configuration.
**Replace ${sdkversion} with SDK version 2.34.0 or newer. See Maven Central to find the latest version.

Your output will resemble the following:

[WARNING] These recipes would make changes to project/src/test/resources/maven/before/pom.xml:
[WARNING]     software.amazon.awssdk.v2migration.AwsSdkJavaV1ToV2
[WARNING]         software.amazon.awssdk.v2migration.UpgradeSdkDependencies
[WARNING]             org.openrewrite.java.dependencies.AddDependency: {groupId=software.amazon.awssdk, artifactId=apache-client, version=2.27.0, onlyIfUsing=com.amazonaws.ClientConfiguration}
[WARNING]             org.openrewrite.java.dependencies.AddDependency: {groupId=software.amazon.awssdk, artifactId=netty-nio-client, version=2.27.0, onlyIfUsing=com.amazonaws.ClientConfiguration}
[WARNING]             org.openrewrite.java.dependencies.ChangeDependency: {oldGroupId=com.amazonaws, oldArtifactId=aws-java-sdk-bom, newGroupId=software.amazon.awssdk, newArtifactId=bom, newVersion=2.27.0}
[WARNING]             org.openrewrite.java.dependencies.ChangeDependency: {oldGroupId=com.amazonaws, oldArtifactId=aws-java-sdk-s3, newGroupId=software.amazon.awssdk, newArtifactId=s3, newVersion=2.27.0}
[WARNING]             org.openrewrite.java.dependencies.ChangeDependency: {oldGroupId=com.amazonaws, oldArtifactId=aws-java-sdk-sqs, newGroupId=software.amazon.awssdk, newArtifactId=sqs, newVersion=2.27.0}
[WARNING] These recipes would make changes to project/src/test/resources/maven/before/src/main/java/foo/bar/Application.java:
[WARNING]     software.amazon.awssdk.v2migration.AwsSdkJavaV1ToV2
[WARNING]         software.amazon.awssdk.v2migration.S3GetObjectConstructorToFluent
[WARNING]             software.amazon.awssdk.v2migration.ConstructorToFluent
[WARNING]         software.amazon.awssdk.v2migration.S3StreamingResponseToV2
[WARNING]         software.amazon.awssdk.v2migration.ChangeSdkType
[WARNING]         software.amazon.awssdk.v2migration.ChangeSdkCoreTypes
[WARNING]             software.amazon.awssdk.v2migration.ChangeExceptionTypes
[WARNING]                 org.openrewrite.java.ChangeType: {oldFullyQualifiedTypeName=com.amazonaws.AmazonClientException, newFullyQualifiedTypeName=software.amazon.awssdk.core.exception.SdkException}
[WARNING]                 org.openrewrite.java.ChangeMethodName: {methodPattern=com.amazonaws.AmazonServiceException getRequestId(), newMethodName=requestId}
[WARNING]                 org.openrewrite.java.ChangeMethodName: {methodPattern=com.amazonaws.AmazonServiceException getErrorCode(), newMethodName=awsErrorDetails().errorCode}
[WARNING]                 org.openrewrite.java.ChangeMethodName: {methodPattern=com.amazonaws.AmazonServiceException getServiceName(), newMethodName=awsErrorDetails().serviceName}
[WARNING]                 org.openrewrite.java.ChangeMethodName: {methodPattern=com.amazonaws.AmazonServiceException getErrorMessage(), newMethodName=awsErrorDetails().errorMessage}
[WARNING]                 org.openrewrite.java.ChangeMethodName: {methodPattern=com.amazonaws.AmazonServiceException getRawResponse(), newMethodName=awsErrorDetails().rawResponse().asByteArray}
[WARNING]                 org.openrewrite.java.ChangeMethodName: {methodPattern=com.amazonaws.AmazonServiceException getRawResponseContent(), newMethodName=awsErrorDetails().rawResponse().asUtf8String}
[WARNING]                 org.openrewrite.java.ChangeType: {oldFullyQualifiedTypeName=com.amazonaws.AmazonServiceException, newFullyQualifiedTypeName=software.amazon.awssdk.awscore.exception.AwsServiceException}
[WARNING]         software.amazon.awssdk.v2migration.NewClassToBuilderPattern
[WARNING]             software.amazon.awssdk.v2migration.NewClassToBuilder
[WARNING]             software.amazon.awssdk.v2migration.V1SetterToV2
[WARNING]         software.amazon.awssdk.v2migration.V1GetterToV2
...
[WARNING]         software.amazon.awssdk.v2migration.V1BuilderVariationsToV2Builder
[WARNING]         software.amazon.awssdk.v2migration.NewClassToBuilderPattern
[WARNING]             software.amazon.awssdk.v2migration.NewClassToBuilder
[WARNING]             software.amazon.awssdk.v2migration.V1SetterToV2
[WARNING]         software.amazon.awssdk.v2migration.HttpSettingsToHttpClient
[WARNING]         software.amazon.awssdk.v2migration.WrapSdkClientBuilderRegionStr
[WARNING] Patch file available:
[WARNING]     project/src/test/resources/maven/before/target/rewrite/rewrite.patch
[WARNING] Estimate time saved: 20m
[WARNING] Run 'mvn rewrite:run' to apply the recipes.

run

In this mode, the plugin modifies the source code on disk to apply the changes directly. Make sure you have a backup of the source code before running the command.

mvn org.openrewrite.maven:rewrite-maven-plugin:6.17.0:run \
-Drewrite.recipeArtifactCoordinates=software.amazon.awssdk:v2-migration:2.34.0 \
-Drewrite.activeRecipes=software.amazon.awssdk.v2migration.AwsSdkJavaV1ToV2

After you run the command, compile your application and run tests to verify the changes. Make manual changes as necessary for unsupported transforms. See the Limitations section below for further details.

Gradle project

For a Gradle project, we will use the OpenRewrite Gradle plugin.

Step 1: go to the project directory

Open a terminal (command line) window and go to the root directory of your application.

Step 2: create a Gradle init script

Create a init.gradle file with the following content in your root project directory:

initscript {
    repositories {
        maven { url "https://plugins.gradle.org/m2" }
    }
    dependencies {
        classpath("org.openrewrite:plugin:${gradle-plugin-version}*")
    }
}

rootProject {
    plugins.apply(org.openrewrite.gradle.RewritePlugin)
    dependencies {
        rewrite("software.amazon.awssdk:v2-migration:${sdkversion}")
    }

    afterEvaluate {
        if (repositories.isEmpty()) {
            repositories {
                mavenCentral()
            }
        }
    }
}

*Replace ${gradle-plugin-version} with with latest SDK-tested version (7.15.0 at the time of GA release), as specified in the SDK Gradle test configuration.

Step 3: run the rewrite command

As with the Maven plugin, you can perform dryRun or run.

dryRun

gradle rewriteDryRun --init-script init.gradle \
  -Drewrite.activeRecipes=software.amazon.awssdk.v2migration.AwsSdkJavaV1ToV2

run

gradle rewriteRun --init-script init.gradle \
  -Drewrite.activeRecipes=software.amazon.awssdk.v2migration.AwsSdkJavaV1ToV2

Limitations

While the majority of v1 code is supported by recipes that transform to the v2 equivalent, there are some classes and methods not covered by the migration tool. You should carefully review the transformed code after the tool applies the recipes. If your code does not compile after running the tool, follow the Step-by-step instructions to manually migrate the remaining v1 code.

Unsupported features

The following features are not covered by the migration tool and require manual migration:

Partially supported S3 transforms

The following S3 components are partially covered by the migration tool and may require manual migration:

Unsupported code patterns

There are common code patterns that the migration tool does not support, such as request object constructors with parameters, service client methods with individual parameters, request timeout methods, and service client constructors with parameters.

Example: Service client constructors with parameters

Empty service client constructors will be transformed to the v2 equivalent by the migration tool. However, service client constructors with parameters are not covered by the migration tool and require manual migration.

Before (original v1 code):

AWSCredentials awsCredentials = new BasicAWSCredentials("akid", "skid");
AmazonSQS sqs = new AmazonSQSClient(awsCredentials);

After (migration tool run):

AwsCredentials awsCredentials = AwsBasicCredentials.create("akid", "skid");
// Will not compile.
SqsClient sqs = new SqsClient(awsCredentials);

In this example, the majority of the v1 code (including imports) is correctly transformed to v2, with the exception of the SqsClient constructor, which requires manual updates to a Builder as shown in the following:

AwsCredentials awsCredentials = AwsBasicCredentials.create("akid", "skid");
// Proper v2 code - manually update.
SqsClient sqs = SqsClient.builder().credentialsProvider(StaticCredentialsProvider.create(awsCredentials));

Conclusion

In this blog post, we showed you how to get started with the migration tool and discussed its limitations. To learn more, visit our Developer Guide. We would love to hear your feedback! You can reach out to us by creating a GitHub issue.

Preview Release of the AWS SDK Java 2.x HTTP Client built on Apache HttpClient 5.5.x

John Viegas — Fri, 18 Jul 2025 03:36:05 +0000

The AWS SDK for Java 2.x introduces the Apache 5 SDK HTTP client which is built on Apache HttpClient 5.5.x. This new SDK HTTP client is available alongside our existing SDK HTTP clients: Apache HttpClient 4.5.x, Netty, URL Connection, and AWS CRT HttpClient. To differentiate the use of Apache HttpClient 4.5.x and Apache HttpClient 5.5.x, we introduced a new Apache 5 Maven package and classes for this release.

What’s new

Similar to our existing Apache 4.5.x based client, this new client supports only synchronous operations. This client implementation uses Apache HttpClient 5.5.x, bringing the following key improvements:

modern Java ecosystem compatibility including virtual thread support for Java 21
active maintenance with regular security updates
enhanced logging flexibility through SLF4J

These improvements address critical pain points with the Apache HttpClient 4.5.x based client. Specifically the move to Apache 5 addresses the 4.5.x client’s transition to maintenance mode, problematic JCL logging dependencies that trigger security tool alerts, and limited modern Java support.

Getting started

Add the Apache 5 client dependency

To begin using the Apache 5 HTTP client implementation, add the following dependency to your project:

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>apache5-client</artifactId>
    <version>2.32.0-PREVIEW</version>
</dependency>

Configure your AWS service client

You can easily configure any AWS service client to use the new AWS SDK Apache 5 HTTP client:

S3Client s3Client = S3Client.builder()
    .httpClient(Apache5HttpClient.create())
    .build();

Advanced configuration example

Apache5HttpClient httpClient = Apache5HttpClient.builder()
    .connectionTimeout(Duration.ofSeconds(30))
    .maxConnections(100)
    .build();

DynamoDbClient dynamoDbClient = DynamoDbClient.builder()
    .httpClient(httpClient)
    .build();

Migrate from Apache 4.5.x

If you’re currently using the default Apache HTTP Client (4.5.x), migration is straightforward – add the new dependency and update your client configuration with an Apache 5 HTTP client as shown above. The API remains consistent with other HTTP client implementations in the SDK. Note that like the existing Apache 4.5.x HTTP client, this implementation supports synchronous service clients only.

Developer Preview release

This is a Developer Preview release intended for evaluation and feedback purposes. While we tested the implementation, we recommend using it in development and testing environments before deploying to production. Your feedback during this preview period is invaluable in helping us refine the implementation before general availability.

Conclusion

In this blog post, we showed you how to get started with the new Apache 5 HTTP client in the AWS SDK for Java 2.x, which uses Apache HttpClient 5.5.x. We want your feedback on this new HTTP client during the Developer Preview phase. Please share your experience and any feature requests by opening a GitHub issue.

AWS .NET Distributed Cache Provider for Amazon DynamoDB now Generally Available

Garrett Beatty — Thu, 03 Jul 2025 13:49:25 +0000

Today, we are excited to announce the general availability of the AWS .NET Distributed Cache Provider for Amazon DynamoDB. This is a seamless, serverless caching solution that enables .NET developers to efficiently manage their caching needs across distributed systems.

Consistent caching is a difficult problem in distributed architectures, where maintaining data integrity and performance across multiple application instances can be complex. The AWS .NET Distributed Cache Provider for Amazon DynamoDB addresses this challenge by leveraging the robust and globally distributed infrastructure of DynamoDB to provide a reliable and scalable caching mechanism.

What is the AWS .NET Distributed Cache Provider for DynamoDB?

This provider implements the ASP.NET Core IDistributedCache interface, letting you integrate the fully managed and durable infrastructure of DynamoDB into your caching layer with minimal code changes. A distributed cache can improve the performance and scalability of an ASP.NET Core app, especially when the app is hosted by a cloud service or a server farm.

Using the Distributed Cache Provider

Consider a hypothetical ASP.NET Core web application that displays a local weather forecast. Generating the forecast might be computationally expensive relative to rendering the page, so you want to cache the current forecast for 24 hours and share the cached forecast across multiple servers that host your application.

To get started, install the AWS.AspNetCore.DistributedCacheProvider package from NuGet.org. Then configure the cache provider in your Program.cs file:

builder.Services.AddAWSDynamoDBDistributedCache(options =>
{
options.TableName = "weather_cache";
options.PartitionKeyName = "id";
options.TTLAttributeName = "cache_ttl";
});

In your webpage, leverage the injected IDistributedCache interface to retrieve an existing cached weather forecast. If no cached forecast exists, the application generates a new forecast and stores it in the cache for future use.


// WeatherForecast.razor
@page "/weatherforecast"
@inject IDistributedCache DistributedCache

<h1>Weather Forecast</h1>

@if (CurrentForecast != null)
{
    // Display your forecast data here
}

@code {
    private WeatherForecast CurrentForecast;

    protected override async Task OnInitializedAsync()
    {
        // Load the previous weather forecast from the cache
        var cachedForecastBytes = await DistributedCache.GetAsync("weatherForecast");
    
        // If there was a cache entry, convert it from the cached bytes
        if (cachedForecastBytes != null)
        {
            CurrentForecast = ForecastConverter.FromBytes(cachedForecastBytes);
        }
        else
        {
            // Compute a new forecast
            CurrentForecast = WeatherPredictor.GenerateNewForecast();
            
            var options = new DistributedCacheEntryOptions()
            {
                AbsoluteExpiration = DateTimeOffset.UtcNow.AddHours(24)
            };
            
            // Store the new forecast in the cache
            await DistributedCache.SetAsync("weatherForecast", 
                ForecastConverter.ToBytes(CurrentForecast), 
                options);    
        }
    }
}

After loading this page, you can see the DynamoDB item in the table. The value attribute contains the serialized weather forecast. The cache_ttl, ttl_deadline , and ttl_window attributes are used internally to support the various expiration settings that are available in the DistributedCacheEntryOptions object.

Figure 1: A screenshot showing the weatherForecast entry in the DynamoDB table.

Configuration

For production applications, we recommend configuring the cache provider with the following options:

TableName – The name of the DynamoDB table that is used to store the cache data.
PartitionKeyName – The name of the partition key of the DynamoDB table. If this option is not set, a DescribeTable service call is made at startup to determine the name of the partition key.
TTLAttributeName – The Time To Live (TTL) feature of DynamoDB is used to remove expired cache items from a table. The TTLAttributeName option specifies the attribute name that is used to store the TTL timestamp. If this option is not set, a DescribeTimeToLive service call is made to determine the name of the TTL attribute.

The table must use a partition key of type string and not use a sort key, otherwise an exception is thrown during the first cache operation. The Time to Live feature of DynamoDB must be enabled for the table, otherwise expired cached entries are not deleted.

The partition keys of cached items always start with ‘dc:’ and can be further prefixed with an additional configurable PartitionKeyPrefix. This can help to avoid collisions if the cache entries are mixed with other items in a table, and allows you to use IAM policy conditions for fine-grained access control to limit access to just the cache entries.

You can set CreateTableIfNotExists to true to allow the library to create a table automatically if it doesn’t already exist. This is recommended only for development or testing purposes because it requires additional permissions and adds latency to the first cache operation.

Refer to the Configuration section in the project README for the full set of options, and the Permissions section for the minimum required IAM permissions for different scenarios.

Using the Distributed Cache Provider with Hybrid Cache

What’s even more exciting is the ability to integrate this distributed cache provider with the new .NET 9 HybridCache, which provides a unified in-process and out-of-process caching solution for .NET applications.

Since computing weather forecasts can be resource-intensive, we want to cache the forecast for 15 minutes in DynamoDB. To optimize performance and reduce the load on DynamoDB, we’ll configure HybridCache to maintain a local in-memory cache for 1 minute on each server. Configure the cache provider and hybrid cache in your Program.cs file as follows:

builder.Services.AddHybridCache(options =>
{
    options.DefaultEntryOptions = new HybridCacheEntryOptions
    {
        // Sets the DDB TTL entry to expire in 15 minutes
        Expiration = TimeSpan.FromMinutes(15),
        // Local cache expires after 1 minute
        LocalCacheExpiration = TimeSpan.FromMinutes(1)
    };
});

builder.Services.AddAWSDynamoDBDistributedCache(options =>
{
    options.TableName = "weather_cache";
    options.PartitionKeyName = "id";
    options.TTLAttributeName = "cache_ttl";
});

In the page model, leverage the injected HybridCache to retrieve an existing cached weather forecast. If no cached forecast exists, the application generates a new forecast and stores it in the cache for future use.

// WeatherForecast.razor
@page "/weatherforecast"
@inject HybridCache Cache

<h1>Weather Forecast</h1>

@if (CurrentForecast != null)
{
    // Display your forecast data here
}

@code {
    private WeatherForecast CurrentForecast;

    protected override async Task OnInitializedAsync()
    {
        // Try to get the cached forecast from the HybridCache
        CurrentForecast = await Cache.GetOrCreateAsync(
            "weatherForecast",
            async (token) =>
            {
                // If the forecast is not cached, generate a new one
                return WeatherPredictor.GenerateNewForecast();
            },
            cancellationToken: CancellationToken.None
        );
    }
}

In this code snippet, we’re using HybridCache to efficiently manage our weather forecast data. When GetOrCreateAsync is called, it first checks the local in-memory cache (configured for 1-minute duration) for the fastest possible access. If the forecast isn’t found locally, it checks the distributed DynamoDB cache (configured for 15-minute duration). If the forecast isn’t found in either cache, the provided factory method generates a new forecast, which is then automatically stored in both the local and distributed caches. This tiered caching approach optimizes performance by reducing both API calls to generate new forecasts and DynamoDB requests, while ensuring that all application servers maintain reasonably fresh weather data.

Using the Distributed Cache Provider for ASP.NET Core Session State

A common application of an IDistributedCache implementation is to store session state in an ASP.NET Core application. Unlike the previous example, these cache entries are user-specific and tied to the session ID that is maintained by ASP.NET Core. In addition, the expiration timestamps for all of the cache entries are now controlled by the IdleTimeout option on the session configuration as opposed to creating a DistributedCacheEntryOptions object for each cache entry as is done in the previous example.

To get started, install the AWS.AspNetCore.DistributedCacheProvider package from NuGet.org. Then configure the cache provider and session state behavior in your Program.cs file:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAWSDynamoDBDistributedCache(options =>
{
    options.TableName = "session_cache_table";
    options.PartitionKeyName = "id";
    options.TTLAttributeName = "ttl_date";
});

builder.Services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromSeconds(90);
    options.Cookie.IsEssential = true;
});

var app = builder.Build();
app.UseSession();
...
app.Run();

Now, method calls on the ISession interface that are accessible from the HttpContext such as Get/Set and GetString/SetString will load and save data to DynamoDB. The following is a hypothetical page that stores a user-specific page-hit counter:

// PageCount.razor
@page "/pagecount"
@inject IHttpContextAccessor HttpContextAccessor

<div class="text-center">
    Number of page views: @PageCount
</div>

@code {
    private int PageCount;
    private const string PageCountKey = "pageCount";

    protected override void OnInitialized()
    {
        // Load the old page count for this session, or start at 0
        // if there isn't an existing entry in the cache
        PageCount = HttpContextAccessor.HttpContext.Session.GetInt32(PageCountKey) ?? 0;

        PageCount += 1;

        // Save the incremented count in the cache
        HttpContextAccessor.HttpContext.Session.SetInt32(PageCountKey, PageCount);
    }
}

After loading this page once, you can see the DynamoDB item in the table. Unlike the first example shown earlier, the id and TTL attributes are managed by the session middleware of ASP.NET Core. You only need to set and get the value.

Figure 2: A screenshot showing the session state entry in the DynamoDB table.

Conclusion

In this post, we demonstrated how the AWS .NET Distributed Cache Provider for Amazon DynamoDB simplifies distributed caching for .NET developers. By leveraging the serverless infrastructure of DynamoDB, you can now easily implement high-performance, scalable caching across your applications.

Next steps:

Explore our sample applications on GitHub
Download the AWS.AspNetCore.DistributedCacheProvider package from NuGet.org to try it out, and refer to the README for more documentation.
Don’t hesitate to create an issue or a pull request if you have ideas for improvements.