Today, AWS Clean Rooms announces support for advanced configurations to improve the performance of Spark SQL queries. This launch enables you to customize Spark properties and compute sizes for SQL queries at runtime, offering increased flexibility to meet your performance, scale, and cost requirements.

With AWS Clean Rooms, you can configure Spark properties—such as shuffle partition settings for parallel processing and autoBroadcastJoinThreshold for optimizing join operations—to help you better control the behavior and tuning of SQL queries in a Clean Rooms collaboration. Additionally, you can choose to cache an existing table’s data containing results from a SQL query or create and cache a new table, which help improve the performance and reduce costs for complex queries using large datasets. For example, an advertiser running lift analysis on their advertising campaigns can specify a custom number of workers for an instance type and configure Spark properties—without editing their SQL query—to optimize costs.

With AWS Clean Rooms, customers can create a secure data clean room in minutes and collaborate with any company on AWS or Snowflake to generate unique insights about advertising campaigns, investment decisions, and research and development. For more information about the AWS Regions where AWS Clean Rooms is available, see the AWS Regions table. To learn more about collaborating with AWS Clean Rooms, visit AWS Clean Rooms.

 

​Today, AWS Clean Rooms announces support for advanced configurations to improve the performance of Spark SQL queries. This launch enables you to customize Spark properties and compute sizes for SQL queries at runtime, offering increased flexibility to meet your performance, scale, and cost requirements. With AWS Clean Rooms, you can configure Spark properties—such as shuffle partition settings for parallel processing and autoBroadcastJoinThreshold for optimizing join operations—to help you better control the behavior and tuning of SQL queries in a Clean Rooms collaboration. Additionally, you can choose to cache an existing table’s data containing results from a SQL query or create and cache a new table, which help improve the performance and reduce costs for complex queries using large datasets. For example, an advertiser running lift analysis on their advertising campaigns can specify a custom number of workers for an instance type and configure Spark properties—without editing their SQL query—to optimize costs. With AWS Clean Rooms, customers can create a secure data clean room in minutes and collaborate with any company on AWS or Snowflake to generate unique insights about advertising campaigns, investment decisions, and research and development. For more information about the AWS Regions where AWS Clean Rooms is available, see the AWS Regions table. To learn more about collaborating with AWS Clean Rooms, visit AWS Clean Rooms.  

AWS Step Functions announces improved observability with a new metrics dashboard, giving you visibility into your workflow operations at both the account and state machine levels. AWS Step Functions is a visual workflow service capable of orchestrating over 14,000+ API actions from over 220 AWS services to build distributed applications and data processing workloads.

With this launch, you can now view usage and billing metrics in one dashboard on the AWS Step Functions console. Metrics are available at both account and state-machine level. You can now view these metrics for both standard and express workflows. In addition, existing metrics, such as ApproximateOpenMapRunCount, are available on the metrics dashboard.

New dashboard and metrics are available in all AWS Regions where AWS Step Functions is available. To get started, open a dashboard today in the AWS Step Functions console. To learn more, visit the Step Functions developer guide.

 

​AWS Step Functions announces improved observability with a new metrics dashboard, giving you visibility into your workflow operations at both the account and state machine levels. AWS Step Functions is a visual workflow service capable of orchestrating over 14,000+ API actions from over 220 AWS services to build distributed applications and data processing workloads. With this launch, you can now view usage and billing metrics in one dashboard on the AWS Step Functions console. Metrics are available at both account and state-machine level. You can now view these metrics for both standard and express workflows. In addition, existing metrics, such as ApproximateOpenMapRunCount, are available on the metrics dashboard. New dashboard and metrics are available in all AWS Regions where AWS Step Functions is available. To get started, open a dashboard today in the AWS Step Functions console. To learn more, visit the Step Functions developer guide.  

Today, Amazon GameLift Servers launched the addition of built-in telemetry metrics across all server SDKs and game engine plugins. Built on OpenTelemetry, an open source framework, Amazon GameLift Servers telemetry metrics enable game developers to generate, collect, and export critical client-side metrics for game-specific insights.

With this release, Amazon GameLift Servers can now be configured to collect and publish telemetry metrics for game servers running on managed Amazon EC2 and container fleets. Customers can leverage both pre-defined metrics and custom metrics, publishing them to Amazon Managed Service for Prometheus or Amazon CloudWatch. This data can be visualized through ready-to-use dashboards (via Amazon Managed Grafana or Amazon CloudWatch) to help game developers optimize resource utilization, improve player experience, and identify and resolve potential operational issues.

Telemetry metrics are now available in all Amazon GameLift Servers supported regions, except AWS China. For more information on monitoring resources using telemetry metrics on Amazon GameLift Servers, please visit the Amazon GameLift Servers documentation.

 

​Today, Amazon GameLift Servers launched the addition of built-in telemetry metrics across all server SDKs and game engine plugins. Built on OpenTelemetry, an open source framework, Amazon GameLift Servers telemetry metrics enable game developers to generate, collect, and export critical client-side metrics for game-specific insights. With this release, Amazon GameLift Servers can now be configured to collect and publish telemetry metrics for game servers running on managed Amazon EC2 and container fleets. Customers can leverage both pre-defined metrics and custom metrics, publishing them to Amazon Managed Service for Prometheus or Amazon CloudWatch. This data can be visualized through ready-to-use dashboards (via Amazon Managed Grafana or Amazon CloudWatch) to help game developers optimize resource utilization, improve player experience, and identify and resolve potential operational issues. Telemetry metrics are now available in all Amazon GameLift Servers supported regions, except AWS China. For more information on monitoring resources using telemetry metrics on Amazon GameLift Servers, please visit the Amazon GameLift Servers documentation.  

You can now create Amazon S3 Access Grants in the AWS Asia Pacific (Thailand) and AWS Mexico (Central) Regions.

Amazon S3 Access Grants map identities in directories such as Microsoft Entra ID, or AWS Identity and Access Management (IAM) principals, to datasets in S3. This helps you manage data permissions at scale by automatically granting S3 access to end users based on their corporate identity.

Visit the AWS Region Table for complete regional availability information. To learn more about Amazon S3 Access Grants, visit our product page.

 

​You can now create Amazon S3 Access Grants in the AWS Asia Pacific (Thailand) and AWS Mexico (Central) Regions. Amazon S3 Access Grants map identities in directories such as Microsoft Entra ID, or AWS Identity and Access Management (IAM) principals, to datasets in S3. This helps you manage data permissions at scale by automatically granting S3 access to end users based on their corporate identity. Visit the AWS Region Table for complete regional availability information. To learn more about Amazon S3 Access Grants, visit our product page.  

Amazon Elastic Container Service (Amazon ECS) Service Connect now supports Envoy access logs, providing deeper observability into request-level traffic patterns and service interactions. This new capability captures detailed per-request telemetry for end-to-end tracing, debugging, and compliance monitoring.

Amazon ECS Service Connect makes it simple to build secure, resilient service-to-service communication across clusters, VPCs, and AWS accounts. It integrates service discovery and service mesh capabilities by automatically injecting AWS-managed Envoy proxies as sidecars that handle traffic routing, load balancing, and inter-service connectivity. Envoy Access logs capture detailed traffic metadata enabling request-level visibility into service communication patterns. This enables you to perform network diagnostics, troubleshoot issues efficiently, and maintain audit trails for compliance requirements.

You can now configure access logs within ECS Service Connect by updating the ServiceConnectConfiguration to enable access logging. Query strings are redacted by default to protect sensitive data. Envoy access logs will output to the standard output (STDOUT) stream alongside application logs and flow through the existing ECS log pipeline without requiring additional infrastructure. This configuration supports all existing application protocols (HTTP, HTTP2, GRPC and TCP). This feature is available in all regions where Amazon ECS Service Connect is supported. To learn more, visit the Amazon ECS Developer Guide.

 

​Amazon Elastic Container Service (Amazon ECS) Service Connect now supports Envoy access logs, providing deeper observability into request-level traffic patterns and service interactions. This new capability captures detailed per-request telemetry for end-to-end tracing, debugging, and compliance monitoring. Amazon ECS Service Connect makes it simple to build secure, resilient service-to-service communication across clusters, VPCs, and AWS accounts. It integrates service discovery and service mesh capabilities by automatically injecting AWS-managed Envoy proxies as sidecars that handle traffic routing, load balancing, and inter-service connectivity. Envoy Access logs capture detailed traffic metadata enabling request-level visibility into service communication patterns. This enables you to perform network diagnostics, troubleshoot issues efficiently, and maintain audit trails for compliance requirements. You can now configure access logs within ECS Service Connect by updating the ServiceConnectConfiguration to enable access logging. Query strings are redacted by default to protect sensitive data. Envoy access logs will output to the standard output (STDOUT) stream alongside application logs and flow through the existing ECS log pipeline without requiring additional infrastructure. This configuration supports all existing application protocols (HTTP, HTTP2, GRPC and TCP). This feature is available in all regions where Amazon ECS Service Connect is supported. To learn more, visit the Amazon ECS Developer Guide.  

AWS Cloud Map now supports cross-account service discovery through integration with AWS Resource Access Manager (AWS RAM) in AWS GovCloud (US) Regions. This enhancement lets you seamlessly manage and discover cloud resources—such as Amazon ECS tasks, Amazon EC2 instances, and Amazon DynamoDB tables—across AWS accounts. By sharing your AWS Cloud Map namespace via AWS RAM, workloads in other accounts can discover and manage resources registered in that namespace. This enhancement simplifies resource sharing, reduces duplication, and promotes consistent service discovery across environments for organizations with multi-account architectures.

You can now share your AWS Cloud Map namespaces using AWS RAM with individual AWS accounts, specific Organizational Units (OUs), or your entire AWS Organization. To get started, create a resource share in AWS RAM, add the namespaces you want to share, and specify the principals (accounts, OUs, or the organization) that should have access. This enables platform engineers to maintain a centralized service registry—or a small set of registries—and share them across multiple accounts, simplifying service discovery. Application developers can then build services that rely on a consistent, shared registry without worrying about availability or synchronization across accounts. AWS Cloud Map’s cross-account service discovery support improves operational efficiency and makes it easier to scale service discovery as your organization grows by reducing duplication and streamlining access to namespaces.

This feature is available now in the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions via the AWS Management Console, API, SDK, CLI, and CloudFormation. To learn more, please refer to the AWS Cloud Map documentation.

 

​AWS Cloud Map now supports cross-account service discovery through integration with AWS Resource Access Manager (AWS RAM) in AWS GovCloud (US) Regions. This enhancement lets you seamlessly manage and discover cloud resources—such as Amazon ECS tasks, Amazon EC2 instances, and Amazon DynamoDB tables—across AWS accounts. By sharing your AWS Cloud Map namespace via AWS RAM, workloads in other accounts can discover and manage resources registered in that namespace. This enhancement simplifies resource sharing, reduces duplication, and promotes consistent service discovery across environments for organizations with multi-account architectures. You can now share your AWS Cloud Map namespaces using AWS RAM with individual AWS accounts, specific Organizational Units (OUs), or your entire AWS Organization. To get started, create a resource share in AWS RAM, add the namespaces you want to share, and specify the principals (accounts, OUs, or the organization) that should have access. This enables platform engineers to maintain a centralized service registry—or a small set of registries—and share them across multiple accounts, simplifying service discovery. Application developers can then build services that rely on a consistent, shared registry without worrying about availability or synchronization across accounts. AWS Cloud Map’s cross-account service discovery support improves operational efficiency and makes it easier to scale service discovery as your organization grows by reducing duplication and streamlining access to namespaces. This feature is available now in the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions via the AWS Management Console, API, SDK, CLI, and CloudFormation. To learn more, please refer to the AWS Cloud Map documentation.  

Amazon Elastic Container Service (Amazon ECS) announces support for linear and canary deployment strategies, giving you more flexibility and control when deploying containerized applications. These new strategies complement ECS built-in blue/green deployments, enabling you to choose the traffic shifting approach that best matches your application’s risk profile and validation requirements.

With linear deployments, you can gradually shift traffic from your current service revision to the new revision in equal percentage increments over a specified time period. You configure the step percentage (for example, 10%) to control how much traffic shifts at each increment, and set a step bake time to wait between each traffic shift for monitoring and validation. This allows you to validate your new application version at multiple stages with increasing amounts of production traffic. With canary deployments, you can route a small percentage of production traffic to your new service revision while the majority of traffic remains on the current stable version. You set a canary bake time to monitor the new revision’s performance, after which Amazon ECS shifts the remaining traffic to the new revision. Both strategies support a deployment bake time that waits after all production traffic has shifted to the new revision before terminating the old revision, enabling quick rollback without downtime if issues are detected. You can configure deployment lifecycle hooks to perform custom validation steps, and use Amazon CloudWatch alarms to automatically detect failures and trigger rollbacks.

The feature is available in all commercial AWS Regions where Amazon ECS is available. You can use linear and canary deployment strategies for new and existing Amazon ECS services that use Application Load Balancer (ALB) or ECS Service Connect, using the Console, SDK, CLI, CloudFormation, CDK, and Terraform. To learn more, see our documentation on Amazon ECS linear deployments and Amazon ECS canary deployments.

 

​Amazon Elastic Container Service (Amazon ECS) announces support for linear and canary deployment strategies, giving you more flexibility and control when deploying containerized applications. These new strategies complement ECS built-in blue/green deployments, enabling you to choose the traffic shifting approach that best matches your application’s risk profile and validation requirements.
With linear deployments, you can gradually shift traffic from your current service revision to the new revision in equal percentage increments over a specified time period. You configure the step percentage (for example, 10%) to control how much traffic shifts at each increment, and set a step bake time to wait between each traffic shift for monitoring and validation. This allows you to validate your new application version at multiple stages with increasing amounts of production traffic. With canary deployments, you can route a small percentage of production traffic to your new service revision while the majority of traffic remains on the current stable version. You set a canary bake time to monitor the new revision’s performance, after which Amazon ECS shifts the remaining traffic to the new revision. Both strategies support a deployment bake time that waits after all production traffic has shifted to the new revision before terminating the old revision, enabling quick rollback without downtime if issues are detected. You can configure deployment lifecycle hooks to perform custom validation steps, and use Amazon CloudWatch alarms to automatically detect failures and trigger rollbacks.
The feature is available in all commercial AWS Regions where Amazon ECS is available. You can use linear and canary deployment strategies for new and existing Amazon ECS services that use Application Load Balancer (ALB) or ECS Service Connect, using the Console, SDK, CLI, CloudFormation, CDK, and Terraform. To learn more, see our documentation on Amazon ECS linear deployments and Amazon ECS canary deployments.  

Amazon Managed Service for Prometheus, a fully managed Prometheus-compatible monitoring service now supports anomaly detection. Anomaly detection applies machine-learning algorithms to continuously analyze time series and surfaces anomalies with minimal user intervention. You can use anomaly detection to isolate and troubleshoot unexpected changes in your metric behavior.

Amazon Managed Service for Prometheus Anomaly Detection currently supports Random Cut Forest (RCF), an unsupervised algorithm for detecting anomalous data points within a time series. Once you create and configure an anomaly detector in an Amazon Managed Service for Prometheus workspace, it will create four new time series to represent resulting anomalies and confidence values along with them. Based on the resulting time series, you can create dynamic alerting rules in the Amazon Managed Service for Prometheus Alert manager, to notify you when anomalies occur, and you can also visualize the resulting time series alongside the input time series either in self-managed Grafana or Amazon Managed Grafana dashboards.

This feature is now available in all AWS regions where Amazon Managed Service for Prometheus is generally available. To configure anomaly detection use the AWS CLI, SDK, or APIs. Check out the Amazon Managed Service for Prometheus user guide for detailed documentation.

 

​Amazon Managed Service for Prometheus, a fully managed Prometheus-compatible monitoring service now supports anomaly detection. Anomaly detection applies machine-learning algorithms to continuously analyze time series and surfaces anomalies with minimal user intervention. You can use anomaly detection to isolate and troubleshoot unexpected changes in your metric behavior.
Amazon Managed Service for Prometheus Anomaly Detection currently supports Random Cut Forest (RCF), an unsupervised algorithm for detecting anomalous data points within a time series. Once you create and configure an anomaly detector in an Amazon Managed Service for Prometheus workspace, it will create four new time series to represent resulting anomalies and confidence values along with them. Based on the resulting time series, you can create dynamic alerting rules in the Amazon Managed Service for Prometheus Alert manager, to notify you when anomalies occur, and you can also visualize the resulting time series alongside the input time series either in self-managed Grafana or Amazon Managed Grafana dashboards.
This feature is now available in all AWS regions where Amazon Managed Service for Prometheus is generally available. To configure anomaly detection use the AWS CLI, SDK, or APIs. Check out the Amazon Managed Service for Prometheus user guide for detailed documentation.  

We are excited to announce the Amazon OCSF Ready Specialization that recognizes AWS Partners who have technically validated their software solutions to integrate with OCSF-compatible Amazon services with proven customer success in production environments. The Open Cybersecurity Schema Framework (OCSF) is an open-source initiative that simplifies how security data is normalized and shared across your security tools. This validation ensures customers can confidently select solutions that will help them improve their security operations through standardized data formats, leading to efficient threat detection, vulnerability identification, and enhanced security analytics.

The AWS Service Ready Program provides customers with AWS Partner software solutions that work with AWS Services. This specialization helps you quickly find and deploy pre-validated AWS Partner solutions that work seamlessly with OCSF-compatible Amazon services, reducing the complexity of your security operations. Partners can participate in the Amazon OCSF Ready designation by either sending logs and security events in the OCSF schema, or receiving logs or security events from OCSF-compatible Amazon services. This standardization helps customers to collect, combine, and analyze security data reducing the time and effort needed for security operations.

Amazon OCSF Ready Partners receive AWS Specialization Program benefits, and have access to signature benefits, including private strategy sessions and AWS guest speaker support for virtual events. The Amazon OCSF specialization expands and replaces the Amazon Security Lake Specialization.

To learn more about how to become an Amazon OCSF Ready Partner, visit the AWS Service Ready Program webpage.

 

​We are excited to announce the Amazon OCSF Ready Specialization that recognizes AWS Partners who have technically validated their software solutions to integrate with OCSF-compatible Amazon services with proven customer success in production environments. The Open Cybersecurity Schema Framework (OCSF) is an open-source initiative that simplifies how security data is normalized and shared across your security tools. This validation ensures customers can confidently select solutions that will help them improve their security operations through standardized data formats, leading to efficient threat detection, vulnerability identification, and enhanced security analytics. The AWS Service Ready Program provides customers with AWS Partner software solutions that work with AWS Services. This specialization helps you quickly find and deploy pre-validated AWS Partner solutions that work seamlessly with OCSF-compatible Amazon services, reducing the complexity of your security operations. Partners can participate in the Amazon OCSF Ready designation by either sending logs and security events in the OCSF schema, or receiving logs or security events from OCSF-compatible Amazon services. This standardization helps customers to collect, combine, and analyze security data reducing the time and effort needed for security operations. Amazon OCSF Ready Partners receive AWS Specialization Program benefits, and have access to signature benefits, including private strategy sessions and AWS guest speaker support for virtual events. The Amazon OCSF specialization expands and replaces the Amazon Security Lake Specialization. To learn more about how to become an Amazon OCSF Ready Partner, visit the AWS Service Ready Program webpage.  

AWS announces the release of a new AI agent context package for accelerating edge device application development using AWS IoT Greengrass. AWS IoT Greengrass is an IoT edge runtime and cloud service that helps developers build, deploy, and manage device software at the edge. The context package includes ready-to-use instructions, examples, and templates – enabling developers to leverage generative AI tools and agents for faster software creation, testing and deployment.

Available as an open-source GitHub repository under the Creative Commons Attribution Share Alike 4.0 license, the AWS IoT Greengrass AI agent context package helps streamline development workflows. Developers can boost productivity by cloning the repository and integrating it with modern generative AI tools like Amazon Q to help accelerate cloud-connected edge application development while simplifying fleet-wide deployment and management.

This new capability is available in all AWS Regions where AWS IoT Greengrass is supported. To learn more about AWS IoT Greengrass and its new AI agent context pack, visit the AWS IoT Greengrass documentation. Follow the getting started guide for a quick introduction to AWS IoT Greengrass.

 

​AWS announces the release of a new AI agent context package for accelerating edge device application development using AWS IoT Greengrass. AWS IoT Greengrass is an IoT edge runtime and cloud service that helps developers build, deploy, and manage device software at the edge. The context package includes ready-to-use instructions, examples, and templates – enabling developers to leverage generative AI tools and agents for faster software creation, testing and deployment. Available as an open-source GitHub repository under the Creative Commons Attribution Share Alike 4.0 license, the AWS IoT Greengrass AI agent context package helps streamline development workflows. Developers can boost productivity by cloning the repository and integrating it with modern generative AI tools like Amazon Q to help accelerate cloud-connected edge application development while simplifying fleet-wide deployment and management. This new capability is available in all AWS Regions where AWS IoT Greengrass is supported. To learn more about AWS IoT Greengrass and its new AI agent context pack, visit the AWS IoT Greengrass documentation. Follow the getting started guide for a quick introduction to AWS IoT Greengrass.