AWS Developer Tools Blog

AWS CLI v1 maintenance mode: announcing changes to dependency updates

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

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

Background

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

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

What’s happening?

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

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

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

How you may be affected

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

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

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

Recommended actions

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

Conclusion

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

Feedback

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

Introducing Open-Source Skills for AWS SDK Best Practices

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

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

The problem

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

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

What’s in a skill

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

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

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

Common mistakes skills help prevent

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

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

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

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

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

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

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

Measuring the impact

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

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

Available skills

The following table summarizes the skills available at launch:

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

Get started

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

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

Replace <skill> with the one you want:

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

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

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

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

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

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

What’s New

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

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

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

Getting Started

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

Prerequisites

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

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

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

Use AWS IoT Shadow client

Step 1: Add the SDK dependency

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

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

Step 2: Create an MQTT 5 client

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

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

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

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

Step 3: Create the Shadow client

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

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

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

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

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

Step 4: Perform Shadow Operations

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

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

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

Known Limitations

The SDK has the following known limitations:

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

For updates on these limitations, see GitHub Discussions.

Conclusion

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

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

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

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

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

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

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

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

What this means for you

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

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

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

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

Migrating to V4

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

To help with your migration:

Review the Migration Guide to understand the breaking changes.

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

Conclusion

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

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

AWS Tools for PowerShell V4 end-of- support announcement

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

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

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

What this means for you

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

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

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

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

Migrating to V5

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

To help with your migration:

Review the Migration Guide to understand the breaking changes.

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

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

Conclusion

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

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

Introducing multipart download support for AWS Tools for PowerShell v5

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

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

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

Parallel download using part numbers and byte-ranges

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

Choosing between part number and byte-range strategies

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

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

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

Getting started

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

Update your module

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

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

# Or monolithic
PS> Update-Module AWSPowerShell.NetCore

# Or Windows PowerShell monolithic
PS> Update-Module AWSPowerShell

Download an object to file

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

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

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

You can customize the following options:

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

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

Download a directory

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

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

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

Using Copy-S3Object

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

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

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

New parameters at a glance

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

Migration path

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

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

For directory downloads:

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

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

Conclusion

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

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

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

Announcing updated retry behavior for AWS SDKs and Tools

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

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

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

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

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

What changed

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

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

Retry quota updates

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

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

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

Faster retries for transient errors

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

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

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

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

Amazon DynamoDB tuning

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

Long-polling operations

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

Does this impact me?

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

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

How to opt in

Set the following environment variable:

export AWS_NEW_RETRIES_2026=true

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

We recommend testing on a non-production workload first.

Where you might notice a difference

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

A few things to watch for:

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

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

How to revert

Remove or unset the opt-in environment variable:

unset AWS_NEW_RETRIES_2026

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

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

export AWS_RETRY_MODE=legacy

SDK availability and GitHub issues

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

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

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

Conclusion

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

Give us feedback

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

Learn more

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

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

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

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

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

Parallel upload via multipart upload

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

Parallel download via byte-ranges or part numbers

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

Getting Started

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

Add the dependency to your Xcode project

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

Add the dependency to your Swift package

Add the below to your package definition:

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

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

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

Initialize the S3 Transfer Manager

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

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

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

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

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

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

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

Upload an object

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

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

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

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

Download an object

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

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

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

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

Conclusion

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

About the authors

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

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

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

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

Use cases

Getting started with a new service

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

Testing SDK behavior

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

Troubleshooting SDK issues

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

Walkthrough

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

Prerequisites

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

Step 1: Run the CLI

$ npm create @aws-sdk/repro

Step 2: Select your environment

The CLI prompts for the JavaScript environment:

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

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

Step 3: Enter a project name

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

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

Step 4: Select an AWS service

? Select or search for AWS service: s3

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

Step 5: Wait for operation discovery

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

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

Step 6: Select an operation

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

Step 7: Select a Region

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

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

Step 8: Review the generated project

The tool creates a project directory with the following files:

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

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

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

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

Step 9: Run the generated project

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

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

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

Clean up

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

rm -rf aws-sdk-repro-a1b2c3d4

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

Conclusion

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

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

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

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

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

About the authors

Smithy Java client framework is now generally available

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

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

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

How it works

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

Model-driven development

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

namespace com.example

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

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

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

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

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

Generated clients

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

The following is an example of a generated Java client:

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

var menu = client.getMenu();

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

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

Key capabilities

Protocol flexibility

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

Dynamic client

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

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

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

Shape code generation independent of services

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

Built on Java virtual threads

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

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

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

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

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

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

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

Conclusion

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

About the author

Smithy Kotlin client code generation now generally available

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

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

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

How it works

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

Model-driven development

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

namespace com.example

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

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

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

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

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

Clients

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

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

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

What does general availability mean?

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

Conclusion

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

About the author

Upgrading AWS CLI From v1 to v2 Using the Migration Tool

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

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

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

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

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

Prerequisites

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

Getting Started

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

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

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

Step 2: Lint a bash script using interactive mode

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

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

#!/bin/bash
set -e

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

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

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

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

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

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

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

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

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

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

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

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

The following output snippet shows another finding:

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

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

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

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

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

The following output snippet shows another finding:

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

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

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

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

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

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

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

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

Step 3: Upgrade to AWS CLI v2

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

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

Step 4: Uninstall migration tool if no longer needed

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

Important Considerations

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

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

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

Conclusion

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

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

Transfer Manager Directory Support for AWS SDK for Ruby

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

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

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

Getting started

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

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

Initialize the Transfer Manager

To initialize a Transfer Manager with a default S3 client:

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

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

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

Upload a directory

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

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

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

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

Download a directory

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

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

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

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

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

Filtering contents

You can also filter transfers by using filter_callback:

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

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

Handling results

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

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

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

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

Conclusion

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

Key takeaways:

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

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

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

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

About the author

Upgrade AWS CLI from v1 to v2 using upgrade debug mode

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

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

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

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

Getting Started

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

AWS CLI v1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

aws configure set cli_binary_format raw-in-base64-out

Step 4: Verify resolution of warnings

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

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

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

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

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

Step 5: Manually review for breaking changes

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

Step 6: Upgrade to AWS CLI v2

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

Limitations

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

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

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

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

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

Conclusion

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

AWS SDK for .NET V3 Maintenance Mode Announcement

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

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

Support Timeline

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

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

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

Next Steps

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

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

Conclusion

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

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

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 lambda get-function \
  --function-name nonexistent-function-12345 \
  --cli-error-format enhanced

aws: [ERROR]: An error occurred (ResourceNotFoundException) when calling the GetFunction operation: Function not found: arn:aws:lambda:us-west-2:111122223333:function:nonexistent-function-12345

Additional error details:
Type: User

Example: Using json output error format

$ aws lambda get-function \
  --function-name nonexistent-function-12345 \
  --cli-error-format json
{
 "Code": "ResourceNotFoundException",
 "Message": "Function not found: arn:aws:lambda:us-west-2:111122223333:function:nonexistent-function-12345",
 "Type": "User"
}

Example: Using legacy output error format

$ aws lambda get-function \
  --function-name nonexistent-function-12345 \
  --cli-error-format legacy

aws: [ERROR]: An error occurred (ResourceNotFoundException) when calling the GetFunction operation: Function not found: arn:aws:lambda:us-west-2:111122223333:function:nonexistent-function-12345

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