We’re excited to announce that Amazon Simple Notification Service (Amazon SNS) has expanded its cross-Region delivery capabilities, providing more flexibility for customers using opt-in Regions. This update brings three improvements:

1. Amazon SNS to Amazon SQS delivery between opt-in Regions: You can now deliver messages from an Amazon SNS topic in one opt-in Region to an Amazon SQS queue in another opt-in Region.
2. Amazon SNS to AWS Lambda delivery between opt-in Regions: Message delivery from an Amazon SNS topic in one opt-in Region to an AWS Lambda function in another opt-in Region is now supported.
3. Amazon SNS to AWS Lambda delivery from default to opt-in Regions: You can now deliver messages from an Amazon SNS topic in a default-enabled Region to an AWS Lambda function in an opt-in Region.

These enhancements provide greater flexibility in designing distributed systems across AWS Regions, making it easier to leverage opt-in Regions in your architectures.

To use these new capabilities, ensure that you’ve enabled the required opt-in Regions for your account. When configuring cross-region subscriptions involving opt-in Regions, remember to use the Region-specific service principal (sns.<opt-in-region>.amazonaws.com) in your resource policies.

For more information on working with opt-in Regions refer to AWS Account Management documentation. To learn more about Amazon SNS cross-Region deliveries, please refer to Amazon SNS documentation.

 

​We’re excited to announce that Amazon Simple Notification Service (Amazon SNS) has expanded its cross-Region delivery capabilities, providing more flexibility for customers using opt-in Regions. This update brings three improvements:

Amazon SNS to Amazon SQS delivery between opt-in Regions: You can now deliver messages from an Amazon SNS topic in one opt-in Region to an Amazon SQS queue in another opt-in Region.
Amazon SNS to AWS Lambda delivery between opt-in Regions: Message delivery from an Amazon SNS topic in one opt-in Region to an AWS Lambda function in another opt-in Region is now supported.
Amazon SNS to AWS Lambda delivery from default to opt-in Regions: You can now deliver messages from an Amazon SNS topic in a default-enabled Region to an AWS Lambda function in an opt-in Region.

These enhancements provide greater flexibility in designing distributed systems across AWS Regions, making it easier to leverage opt-in Regions in your architectures. To use these new capabilities, ensure that you’ve enabled the required opt-in Regions for your account. When configuring cross-region subscriptions involving opt-in Regions, remember to use the Region-specific service principal (sns.<opt-in-region>.amazonaws.com) in your resource policies. For more information on working with opt-in Regions refer to AWS Account Management documentation. To learn more about Amazon SNS cross-Region deliveries, please refer to Amazon SNS documentation.  

Starting today, AWS Clean Rooms now supports training custom ML models on data in Parquet file format. Parquet is a free and open-source column-oriented data storage format that provides efficient data compression and encoding schemes with enhanced performance.

With AWS Clean Rooms ML custom modeling, you and your partners can train a custom ML model using collective datasets at scale without having to share sensitive intellectual property. By creating ML input channels in Parquet file format, you can process large volumes of data more efficiently and encode non-text based data allowing you to train on images, and other binary encoded datatypes.

AWS Clean Rooms ML helps you and your partners apply privacy-enhancing controls to safeguard your proprietary data and ML models while generating predictive insights—all without sharing or copying one another’s raw data or models. For more information about the AWS Regions where AWS Clean Rooms ML is available, see the AWS Regions table. To learn more, visit AWS Clean Rooms ML.

 

​Starting today, AWS Clean Rooms now supports training custom ML models on data in Parquet file format. Parquet is a free and open-source column-oriented data storage format that provides efficient data compression and encoding schemes with enhanced performance. With AWS Clean Rooms ML custom modeling, you and your partners can train a custom ML model using collective datasets at scale without having to share sensitive intellectual property. By creating ML input channels in Parquet file format, you can process large volumes of data more efficiently and encode non-text based data allowing you to train on images, and other binary encoded datatypes. AWS Clean Rooms ML helps you and your partners apply privacy-enhancing controls to safeguard your proprietary data and ML models while generating predictive insights—all without sharing or copying one another’s raw data or models. For more information about the AWS Regions where AWS Clean Rooms ML is available, see the AWS Regions table. To learn more, visit AWS Clean Rooms ML.  

AWS Lambda now supports remote debugging in Visual Studio Code (VS Code), enabling developers to debug their Lambda functions running in the cloud directly from their local IDE. With this new capability, developers can use familiar debugging tools like breakpoints, variable inspection, and step-through debugging with functions deployed in the cloud without modifying their existing development workflow, thus accelerating their serverless development process.

Developers building serverless applications with Lambda often need to test and debug cross-service integrations involving multiple AWS services that may be attached to Amazon Virtual Private Cloud (VPC) or require specific AWS Identity and Access Management (IAM) permissions. Previously, in absence of tools to fully replicate the Lambda runtime environment and its interactions with other AWS services locally, developers had to rely on print statements, logs, and multiple iterative deployments to diagnose and resolve issues. With remote debugging in VS Code, developers can now debug the execution environment of the function running in the cloud with complete access to VPC resources and IAM roles and trace execution through entire service flows in the cloud. Developers can also quickly make updates to their function and test the changes. This launch eliminates the need for complex local debugging setups and repeated deployments, reducing the time to identify and fix issues from hours to minutes.

This feature is now available to all developers with the AWS Toolkit (v3.69.0 or later) installed on their VS Code, at no additonal cost. To get started, select a Lambda function in VS Code IDE and click “Invoke Remotely”. You can then start a remote debugging session with a single click. The AWS Toolkit will automatically download the function code, establish a secure debugging connection, and enable breakpoint setting. To learn more, visit the AWS News blog post, AWS Toolkit documentation, and Lambda developer guide. 

 

​AWS Lambda now supports remote debugging in Visual Studio Code (VS Code), enabling developers to debug their Lambda functions running in the cloud directly from their local IDE. With this new capability, developers can use familiar debugging tools like breakpoints, variable inspection, and step-through debugging with functions deployed in the cloud without modifying their existing development workflow, thus accelerating their serverless development process. Developers building serverless applications with Lambda often need to test and debug cross-service integrations involving multiple AWS services that may be attached to Amazon Virtual Private Cloud (VPC) or require specific AWS Identity and Access Management (IAM) permissions. Previously, in absence of tools to fully replicate the Lambda runtime environment and its interactions with other AWS services locally, developers had to rely on print statements, logs, and multiple iterative deployments to diagnose and resolve issues. With remote debugging in VS Code, developers can now debug the execution environment of the function running in the cloud with complete access to VPC resources and IAM roles and trace execution through entire service flows in the cloud. Developers can also quickly make updates to their function and test the changes. This launch eliminates the need for complex local debugging setups and repeated deployments, reducing the time to identify and fix issues from hours to minutes. This feature is now available to all developers with the AWS Toolkit (v3.69.0 or later) installed on their VS Code, at no additonal cost. To get started, select a Lambda function in VS Code IDE and click “Invoke Remotely”. You can then start a remote debugging session with a single click. The AWS Toolkit will automatically download the function code, establish a secure debugging connection, and enable breakpoint setting. To learn more, visit the AWS News blog post, AWS Toolkit documentation, and Lambda developer guide.   

AWS Lambda now enables seamless transition from console to Visual Studio Code (VS Code) IDE. This new console-to-IDE integration eliminates the friction between cloud and local development environments for serverless applications.

Developers starting in the console require more sophisticated development capabilities of local IDE as applications evolve in complexity. Previously, they had to manually configure their local development environment which included IDE installation, copying function code, configurations, and integration settings before they could begin development. This was time-consuming and interrupted development workflow. With the new console-to-IDE integration, developers can now transition their Lambda functions to VS Code with a single click, preserving code and configurations. This enables developers to use advanced IDE capabilities like external dependency management (using package managers like npm and pip), using development tools like linters and formatters, etc., without the setup overhead. This launch also introduces a new capability in VS Code IDE which enables developers to easily convert their applications to an AWS Serverless Application Model (AWS SAM) templates, simplifying their Infrastructure as Code (IaC) practices and CI/CD pipeline integration.

To get started, click the «Open in Visual Studio Code» button in the Lambda console’s Code tab or the Getting Started popup when creating new functions. This will automatically open VS Code IDE on your local device or take you through a guided process to install required tools including VS Code and AWS Toolkit. To learn more about this experience, visit the AWS News blog post, Lambda developer guide, and AWS Toolkit for VS Code documentation.

This feature is available in all commercial AWS Regions where Lambda is available, except AWS GovCloud (US) Regions, at no additional cost.

 

​AWS Lambda now enables seamless transition from console to Visual Studio Code (VS Code) IDE. This new console-to-IDE integration eliminates the friction between cloud and local development environments for serverless applications. Developers starting in the console require more sophisticated development capabilities of local IDE as applications evolve in complexity. Previously, they had to manually configure their local development environment which included IDE installation, copying function code, configurations, and integration settings before they could begin development. This was time-consuming and interrupted development workflow. With the new console-to-IDE integration, developers can now transition their Lambda functions to VS Code with a single click, preserving code and configurations. This enables developers to use advanced IDE capabilities like external dependency management (using package managers like npm and pip), using development tools like linters and formatters, etc., without the setup overhead. This launch also introduces a new capability in VS Code IDE which enables developers to easily convert their applications to an AWS Serverless Application Model (AWS SAM) templates, simplifying their Infrastructure as Code (IaC) practices and CI/CD pipeline integration. To get started, click the «Open in Visual Studio Code» button in the Lambda console’s Code tab or the Getting Started popup when creating new functions. This will automatically open VS Code IDE on your local device or take you through a guided process to install required tools including VS Code and AWS Toolkit. To learn more about this experience, visit the AWS News blog post, Lambda developer guide, and AWS Toolkit for VS Code documentation. This feature is available in all commercial AWS Regions where Lambda is available, except AWS GovCloud (US) Regions, at no additional cost.  

Amazon DynamoDB Streams now supports a new ShardFilter parameter in the DescribeStream API to simplify and optimize the consumption of streaming data. You can use ShardFilter parameter to quickly discover child shards after a parent shard has been closed, significantly improving efficiency and responsiveness when processing data from DynamoDB Streams.

DynamoDB Streams is a serverless data streaming feature that makes it straightforward to track, process, and react to item-level changes in DynamoDB tables in near real time. DynamoDB Streams enables diverse change data capture use cases, including building event-driven applications, data replication, auditing, and implementing data analytics and machine learning capabilities. Applications consuming data from DynamoDB Streams can efficiently transition from reading a closed shard to its child shard using this optional ShardFilter parameter, avoiding repeated calls to the DescribeStream API to retrieve and traverse the shard map for all closed and open shards. This API enhancement helps ensure smoother transitions and lower latency when switching between shards, making your stream processing applications more responsive and cost-effective.

The new ShardFilter parameter is available in all AWS Regions. You can get started with the feature by using the AWS API, Kinesis Client Library (KCL) 3.0, or Apache Flink connector for DynamoDB Streams. Customers that use AWS Lambda to consume DynamoDB Streams will automatically benefit from this enhanced API experience.

For more information, refer to Working with DynamoDB Streams in the DynamoDB Developer Guide and API Reference for DescribeStream.

 

​Amazon DynamoDB Streams now supports a new ShardFilter parameter in the DescribeStream API to simplify and optimize the consumption of streaming data. You can use ShardFilter parameter to quickly discover child shards after a parent shard has been closed, significantly improving efficiency and responsiveness when processing data from DynamoDB Streams. DynamoDB Streams is a serverless data streaming feature that makes it straightforward to track, process, and react to item-level changes in DynamoDB tables in near real time. DynamoDB Streams enables diverse change data capture use cases, including building event-driven applications, data replication, auditing, and implementing data analytics and machine learning capabilities. Applications consuming data from DynamoDB Streams can efficiently transition from reading a closed shard to its child shard using this optional ShardFilter parameter, avoiding repeated calls to the DescribeStream API to retrieve and traverse the shard map for all closed and open shards. This API enhancement helps ensure smoother transitions and lower latency when switching between shards, making your stream processing applications more responsive and cost-effective. The new ShardFilter parameter is available in all AWS Regions. You can get started with the feature by using the AWS API, Kinesis Client Library (KCL) 3.0, or Apache Flink connector for DynamoDB Streams. Customers that use AWS Lambda to consume DynamoDB Streams will automatically benefit from this enhanced API experience. For more information, refer to Working with DynamoDB Streams in the DynamoDB Developer Guide and API Reference for DescribeStream.  

Today, DynamoDB local, the downloadable version of Amazon DynamoDB, migrates to AWS SDK for Java 2.x. In alignment with our SDKs and Tools Maintenance Policy, this migration ensures DynamoDB local stays up-to-date in security, compatibility, and stability for developers developing and testing their DynamoDB applications locally. With the new DynamoDB local version 3.0.0, now you can fully remove the dependency on the AWS SDK for Java 1.x. You can upgrade your application utilizing previous DynamoDB local versions to DynamoDB local 3.0.0 by making these following updates to your codebase:

1. All import statements referencing the current com.amazonaws namespace needs to be updated to the new software.amazon.dynamodb namespace.
2. If running DynamoDB local as an Apache Maven dependency, reference the new DynamoDB Maven repository in your application’s Project Object Model (POM) file. See DynamoDB Local Sample Java Project.
3. If running DynamoDB local in embedded mode using client class name AmazonDynamoDB, reference Client Changes on how to migrate from AWS SDK version 1 to AWS SDK version 2.

To learn more about the AWS SDK for Java 2.x, see AWS SDK for Java 2.x. For more information about DynamoDB local, see Setting Up DynamoDB Local (Downloadable Version).

 

​Today, DynamoDB local, the downloadable version of Amazon DynamoDB, migrates to AWS SDK for Java 2.x. In alignment with our SDKs and Tools Maintenance Policy, this migration ensures DynamoDB local stays up-to-date in security, compatibility, and stability for developers developing and testing their DynamoDB applications locally. With the new DynamoDB local version 3.0.0, now you can fully remove the dependency on the AWS SDK for Java 1.x. You can upgrade your application utilizing previous DynamoDB local versions to DynamoDB local 3.0.0 by making these following updates to your codebase:

All import statements referencing the current com.amazonaws namespace needs to be updated to the new software.amazon.dynamodb namespace.
If running DynamoDB local as an Apache Maven dependency, reference the new DynamoDB Maven repository in your application’s Project Object Model (POM) file. See DynamoDB Local Sample Java Project.
If running DynamoDB local in embedded mode using client class name AmazonDynamoDB, reference Client Changes on how to migrate from AWS SDK version 1 to AWS SDK version 2.

To learn more about the AWS SDK for Java 2.x, see AWS SDK for Java 2.x. For more information about DynamoDB local, see Setting Up DynamoDB Local (Downloadable Version).  

Amazon Elastic Container Service (Amazon ECS) announces new features that make software updates for your containerized applications safer, allowing you to ship software faster and with high confidence, without needing to build custom deployment tooling. Amazon ECS now supports a built-in blue/green deployment strategy and deployment lifecycle hooks that allow you to test new application versions in production environments and quickly rollback failed deployments.

You can now deploy software updates to Amazon ECS services which serve traffic from an Application Load Balancer (ALB), Network Load Balancer (NLB), or ECS Service Connect with a blue/green deployment strategy. When you use a blue/green deployment strategy, Amazon ECS provisions the new application version alongside the old, and allows you to validate the new application version before routing production traffic to it. You can use deployment lifecycle hooks to perform custom validation steps, and block the deployment until validation succeeds. Furthermore, once production traffic has been shifted, you can let the new application bake for a pre-specified period, and rollback to the old version without incurring downtime if you detect a regression. To detect failures automatically, you can configure Amazon CloudWatch Alarms and ECS deployment circuit breaker to monitor your deployments. Together, these capabilities help make your software updates safer, allowing you to ship new capabilities faster.

You can use blue/green deployments and deployment lifecycle hooks for new and existing Amazon ECS services in all commercial AWS Regions using the AWS Management Console, SDK, CLI, CloudFormation, CDK, and Terraform by following the steps on the blog. For more details, see our documentation.

 

​Amazon Elastic Container Service (Amazon ECS) announces new features that make software updates for your containerized applications safer, allowing you to ship software faster and with high confidence, without needing to build custom deployment tooling. Amazon ECS now supports a built-in blue/green deployment strategy and deployment lifecycle hooks that allow you to test new application versions in production environments and quickly rollback failed deployments. You can now deploy software updates to Amazon ECS services which serve traffic from an Application Load Balancer (ALB), Network Load Balancer (NLB), or ECS Service Connect with a blue/green deployment strategy. When you use a blue/green deployment strategy, Amazon ECS provisions the new application version alongside the old, and allows you to validate the new application version before routing production traffic to it. You can use deployment lifecycle hooks to perform custom validation steps, and block the deployment until validation succeeds. Furthermore, once production traffic has been shifted, you can let the new application bake for a pre-specified period, and rollback to the old version without incurring downtime if you detect a regression. To detect failures automatically, you can configure Amazon CloudWatch Alarms and ECS deployment circuit breaker to monitor your deployments. Together, these capabilities help make your software updates safer, allowing you to ship new capabilities faster.
You can use blue/green deployments and deployment lifecycle hooks for new and existing Amazon ECS services in all commercial AWS Regions using the AWS Management Console, SDK, CLI, CloudFormation, CDK, and Terraform by following the steps on the blog. For more details, see our documentation.  

Amazon S3 Multi-Region Access Points are now available in 12 additional AWS opt-in Regions: Asia Pacific (Jakarta, Hong Kong, Hyderabad, and Melbourne), Europe (Zurich, Spain, and Milan), Middle East (Bahrain and UAE), Canada West (Calgary), Africa (Cape Town) and Israel (Tel Aviv) Regions.

To get started, you need to first enable the AWS opt-in Region for your account by using the steps outlined here. Next, you can use the AWS CLI or AWS SDK to create an S3 Multi-Region Access Point in an AWS opt-in Region. For pricing information, visit the Amazon S3 pricing page. To learn more about S3 Multi-Region Access Points, visit the feature page, S3 User Guide, or S3 FAQs.

 

​Amazon S3 Multi-Region Access Points are now available in 12 additional AWS opt-in Regions: Asia Pacific (Jakarta, Hong Kong, Hyderabad, and Melbourne), Europe (Zurich, Spain, and Milan), Middle East (Bahrain and UAE), Canada West (Calgary), Africa (Cape Town) and Israel (Tel Aviv) Regions. To get started, you need to first enable the AWS opt-in Region for your account by using the steps outlined here. Next, you can use the AWS CLI or AWS SDK to create an S3 Multi-Region Access Point in an AWS opt-in Region. For pricing information, visit the Amazon S3 pricing page. To learn more about S3 Multi-Region Access Points, visit the feature page, S3 User Guide, or S3 FAQs.  

AWS Lambda now supports low latency (sub 100ms) event processing for Amazon Managed Streaming for Apache Kafka (Amazon MSK) and self-managed Apache Kafka event sources in Provisioned mode for Kafka ESM. Customers can now set their MaximumBatchingWindowInSeconds parameter to 0 in Kafka ESM configurations, enabling real-time processing of Kafka events. This enhancement significantly reduces end-to-end processing latency for time-sensitive business applications.

Kafka customers increasingly build mission-critical applications that require consistent end-to-end latency of less than 100ms to meet stringent business requirements across industries. Examples include financial services firms processing market data feeds and executing algorithmic trades, e-commerce platforms providing real-time personalized recommendations, and gaming companies managing live player interactions. With today’s launch, Lambda natively supports low latency event processing with efficient optimization of polling and invoking Kafka events, allowing customers’ to build mission-critical or latency-sensitive Kafka applications on Lambda. With MaximumBatchingWindowInSeconds set to 0, Kafka ESM invokes the function with Kafka events immediately after the previous invocation completes. This configuration makes end-to-end latency solely dependent on function duration, thus potentially providing average 50ms end-to-end latencies for critical real-time applications.

This feature is generally available in all AWS Commercial Regions where AWS Lambda Kafka ESM is available, except Israel (Tel Aviv), Asia Pacific (Malaysia), and Canada West (Calgary).

To enable your Kafka ESM for low latency processing, set MaximumBatchingWindowInSeconds set to 0 and enable Provisioned mode for your new or existing Kafka ESM in the ESM API, AWS Console, AWS CLI, AWS SDK, AWS CloudFormation, and AWS SAM. To learn more, read Lambda ESM documentation and AWS Lambda pricing.

 

​AWS Lambda now supports low latency (sub 100ms) event processing for Amazon Managed Streaming for Apache Kafka (Amazon MSK) and self-managed Apache Kafka event sources in Provisioned mode for Kafka ESM. Customers can now set their MaximumBatchingWindowInSeconds parameter to 0 in Kafka ESM configurations, enabling real-time processing of Kafka events. This enhancement significantly reduces end-to-end processing latency for time-sensitive business applications. Kafka customers increasingly build mission-critical applications that require consistent end-to-end latency of less than 100ms to meet stringent business requirements across industries. Examples include financial services firms processing market data feeds and executing algorithmic trades, e-commerce platforms providing real-time personalized recommendations, and gaming companies managing live player interactions. With today’s launch, Lambda natively supports low latency event processing with efficient optimization of polling and invoking Kafka events, allowing customers’ to build mission-critical or latency-sensitive Kafka applications on Lambda. With MaximumBatchingWindowInSeconds set to 0, Kafka ESM invokes the function with Kafka events immediately after the previous invocation completes. This configuration makes end-to-end latency solely dependent on function duration, thus potentially providing average 50ms end-to-end latencies for critical real-time applications. This feature is generally available in all AWS Commercial Regions where AWS Lambda Kafka ESM is available, except Israel (Tel Aviv), Asia Pacific (Malaysia), and Canada West (Calgary). To enable your Kafka ESM for low latency processing, set MaximumBatchingWindowInSeconds set to 0 and enable Provisioned mode for your new or existing Kafka ESM in the ESM API, AWS Console, AWS CLI, AWS SDK, AWS CloudFormation, and AWS SAM. To learn more, read Lambda ESM documentation and AWS Lambda pricing.  

The Amazon Connect agent workspace now includes an out-of-box analytics dashboard that provides agents with insights into their individual performance, such as contacts handled and average handle time. The dashboard also show agents their assigned queue metrics, such as contacts in queue and longest wait time. These insights help agents improve their performance and make decisions that enhance customer experience. For example, agents can delay breaks when they observe high queue volumes, helping to reduce customer wait times.

Amazon Connect agent workspace analytics dashboard is available in the following AWS regions: US East (N. Virginia), US West (Oregon), Canada (Central), Africa (Cape Town), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (London). To learn more and get started, visit the webpage and documentation.

 

​The Amazon Connect agent workspace now includes an out-of-box analytics dashboard that provides agents with insights into their individual performance, such as contacts handled and average handle time. The dashboard also show agents their assigned queue metrics, such as contacts in queue and longest wait time. These insights help agents improve their performance and make decisions that enhance customer experience. For example, agents can delay breaks when they observe high queue volumes, helping to reduce customer wait times. Amazon Connect agent workspace analytics dashboard is available in the following AWS regions: US East (N. Virginia), US West (Oregon), Canada (Central), Africa (Cape Town), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (London). To learn more and get started, visit the webpage and documentation.