Amazon Managed Service for Apache Flink now supports Apache Flink version 2.3. This release includes adaptive partition selection for improved backpressure handling, so applications run more smoothly under uneven load. It also introduces better handling of out-of-order updates in change data capture (CDC) pipelines that improves data correctness, and new SQL functions make it easier to convert between changelog and standard streams. For a full list of improvements, see the Amazon Managed Service for Apache Flink release notes.

Amazon Managed Service for Apache Flink makes it easier to transform and analyze streaming data in real time, by simplifying the setup, operation, and scaling of Apache Flink applications. Developers and data engineers can focus on building and running their streaming applications without managing the underlying infrastructure.

To get started, create a new application on Apache Flink 2.3, or use in-place version upgrades to move compatible applications to the Flink 2.3 runtime for a simpler and faster upgrade. Apache Flink 2.3 is available across all AWS Regions where Amazon Managed Service for Apache Flink is offered. To learn more, see the Amazon Managed Service for Apache Flink Developer Guide.

 

​Amazon Managed Service for Apache Flink now supports Apache Flink version 2.3. This release includes adaptive partition selection for improved backpressure handling, so applications run more smoothly under uneven load. It also introduces better handling of out-of-order updates in change data capture (CDC) pipelines that improves data correctness, and new SQL functions make it easier to convert between changelog and standard streams. For a full list of improvements, see the Amazon Managed Service for Apache Flink release notes. Amazon Managed Service for Apache Flink makes it easier to transform and analyze streaming data in real time, by simplifying the setup, operation, and scaling of Apache Flink applications. Developers and data engineers can focus on building and running their streaming applications without managing the underlying infrastructure. To get started, create a new application on Apache Flink 2.3, or use in-place version upgrades to move compatible applications to the Flink 2.3 runtime for a simpler and faster upgrade. Apache Flink 2.3 is available across all AWS Regions where Amazon Managed Service for Apache Flink is offered. To learn more, see the Amazon Managed Service for Apache Flink Developer Guide.  

Today, AWS announces the availability of KNFSD File Cache, an open-source, Apache-2.0 licensed solution for deploying a scalable, high-speed Network File System (NFS) cache on AWS. KNFSD File Cache mounts exports from one or more source NFS servers, whether on-premises, in another AWS Availability Zone or Region, or in another cloud over AWS Interconnect – multicloud, and re-exports them to NFS clients in AWS. You can front multiple on-premises filers, in-cloud file systems such as Amazon FSx for OpenZFS and Amazon FSx for NetApp ONTAP, and any other NFS v3, v4.1, or v4.2 compliant filer. Frequently read data is cached in memory and on local NVMe storage, so files cross the high-latency link to the source once and are then served to large compute fleets at local VPC speed. The solution is designed for read-heavy burst compute workloads such as visual effects rendering, simulation, financial services, health and life sciences, microprocessor design, weather forecasting, and energy.

KNFSD File Cache builds on standard Linux kernel technology: nfs-kernel-server provides NFS re-export, and FS-Cache provides the persistent disk cache. Because it uses the native NFS stack, it fully supports the NFS client-server protocol, including byte-range reads and writes, synchronous and asynchronous writes, and both write-through and write-around modes. You build the cache Amazon Machine Image (AMI) with Packer, then deploy the cluster with the included Terraform module. Cache nodes run in an Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling group on AMD, Intel, or AWS Graviton instances, with client traffic distributed by DNS round-robin or a Network Load Balancer, and optional automatic scaling based on the number of active NFS client connections. An Amazon CloudWatch dashboard provides more than 70 metrics through an OpenTelemetry-based agent, which can also publish to third-party tools such as Prometheus and Grafana.

KNFSD File Cache (preview) is available in all AWS Regions. There are no licensing costs; you pay only for the AWS resources you consume.

To get started, visit the KNFSD File Cache GitHub repository, launch blog, and AWS Solutions Guidance. For detailed deployment and configuration guidance, see the GitHub documentation.

 

​Today, AWS announces the availability of KNFSD File Cache, an open-source, Apache-2.0 licensed solution for deploying a scalable, high-speed Network File System (NFS) cache on AWS. KNFSD File Cache mounts exports from one or more source NFS servers, whether on-premises, in another AWS Availability Zone or Region, or in another cloud over AWS Interconnect – multicloud, and re-exports them to NFS clients in AWS. You can front multiple on-premises filers, in-cloud file systems such as Amazon FSx for OpenZFS and Amazon FSx for NetApp ONTAP, and any other NFS v3, v4.1, or v4.2 compliant filer. Frequently read data is cached in memory and on local NVMe storage, so files cross the high-latency link to the source once and are then served to large compute fleets at local VPC speed. The solution is designed for read-heavy burst compute workloads such as visual effects rendering, simulation, financial services, health and life sciences, microprocessor design, weather forecasting, and energy.
KNFSD File Cache builds on standard Linux kernel technology: nfs-kernel-server provides NFS re-export, and FS-Cache provides the persistent disk cache. Because it uses the native NFS stack, it fully supports the NFS client-server protocol, including byte-range reads and writes, synchronous and asynchronous writes, and both write-through and write-around modes. You build the cache Amazon Machine Image (AMI) with Packer, then deploy the cluster with the included Terraform module. Cache nodes run in an Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling group on AMD, Intel, or AWS Graviton instances, with client traffic distributed by DNS round-robin or a Network Load Balancer, and optional automatic scaling based on the number of active NFS client connections. An Amazon CloudWatch dashboard provides more than 70 metrics through an OpenTelemetry-based agent, which can also publish to third-party tools such as Prometheus and Grafana.
KNFSD File Cache (preview) is available in all AWS Regions. There are no licensing costs; you pay only for the AWS resources you consume.
To get started, visit the KNFSD File Cache GitHub repository, launch blog, and AWS Solutions Guidance. For detailed deployment and configuration guidance, see the GitHub documentation.  

Amazon CloudWatch Synthetics now supports customer managed AWS Key Management Service (KMS) keys for encrypting canary environment variables, giving you full control over the encryption of sensitive configuration data such as API keys, credentials, and tokens. Previously, environment variables were encrypted at rest using only an AWS owned key. Now, in addition to the default AWS owned key, you can specify your own symmetric KMS key for encryption at rest, and you can also encrypt individual values client-side before they are stored.

With encryption at rest, you specify a customer managed KMS key when creating or updating a canary, and CloudWatch Synthetics uses a grant on the key to handle encryption and decryption transparently. With client-side encryption, you encrypt values before storage, and your canary script decrypts them at runtime using the AWS KMS Decrypt API. This benefits teams in regulated industries that require organizational key management policies, auditability, or key rotation controls across all services.

Amazon CloudWatch Synthetics customer managed key encryption is available in all commercial AWS Regions. Multi-location canaries can use a different KMS key per replica Region.

To learn more, see Encrypting environment variables in the Amazon CloudWatch User Guide.

 

​Amazon CloudWatch Synthetics now supports customer managed AWS Key Management Service (KMS) keys for encrypting canary environment variables, giving you full control over the encryption of sensitive configuration data such as API keys, credentials, and tokens. Previously, environment variables were encrypted at rest using only an AWS owned key. Now, in addition to the default AWS owned key, you can specify your own symmetric KMS key for encryption at rest, and you can also encrypt individual values client-side before they are stored.
With encryption at rest, you specify a customer managed KMS key when creating or updating a canary, and CloudWatch Synthetics uses a grant on the key to handle encryption and decryption transparently. With client-side encryption, you encrypt values before storage, and your canary script decrypts them at runtime using the AWS KMS Decrypt API. This benefits teams in regulated industries that require organizational key management policies, auditability, or key rotation controls across all services.
Amazon CloudWatch Synthetics customer managed key encryption is available in all commercial AWS Regions. Multi-location canaries can use a different KMS key per replica Region.
To learn more, see Encrypting environment variables in the Amazon CloudWatch User Guide.  

Amazon CloudWatch announces the launch of coding agent insights, giving engineering leaders visibility into how AI coding tools are driving value across their organization. Coding Agent Insights integrates with Claude apps gateway for AWS to collect telemetry from Claude Code without additional instrumentation. Other supported coding agents include Codex and GitHub Copilot. 

As organizations scale AI coding agent adoption, they need to understand return on investment. Coding agent insights is built on OpenTelemetry metrics emitted by your coding agents and presents them alongside your existing CloudWatch operational data. This helps you answer questions like which teams would benefit from expanded access, where are agents accelerating delivery, and how can you right-size token budgets across departments. You can track spend trends, set proactive token billing alerts, correlate agent adoption with improvements in commit throughput and pull request velocity, or identify the models delivering the best cost-to-output ratio for your workloads.

CloudWatch coding agent insights is available in all AWS commercial regions except Middle East (UAE), Middle East (Bahrain), and Israel (Tel Aviv). Configure your Claude apps gateway to emit telemetry to CloudWatch using the setup guide and view the Coding Agent Insights dashboard in the CloudWatch console. Standard CloudWatch OpenTelemetry metric ingestion pricing applies — see metrics pricing for details. To learn more, see the documentation.

 

​Amazon CloudWatch announces the launch of coding agent insights, giving engineering leaders visibility into how AI coding tools are driving value across their organization. Coding Agent Insights integrates with Claude apps gateway for AWS to collect telemetry from Claude Code without additional instrumentation. Other supported coding agents include Codex and GitHub Copilot. 
As organizations scale AI coding agent adoption, they need to understand return on investment. Coding agent insights is built on OpenTelemetry metrics emitted by your coding agents and presents them alongside your existing CloudWatch operational data. This helps you answer questions like which teams would benefit from expanded access, where are agents accelerating delivery, and how can you right-size token budgets across departments. You can track spend trends, set proactive token billing alerts, correlate agent adoption with improvements in commit throughput and pull request velocity, or identify the models delivering the best cost-to-output ratio for your workloads.
CloudWatch coding agent insights is available in all AWS commercial regions except Middle East (UAE), Middle East (Bahrain), and Israel (Tel Aviv). Configure your Claude apps gateway to emit telemetry to CloudWatch using the setup guide and view the Coding Agent Insights dashboard in the CloudWatch console. Standard CloudWatch OpenTelemetry metric ingestion pricing applies — see metrics pricing for details. To learn more, see the documentation.  

Amazon SageMaker HyperPod now supports network topology configuration at the partition level for Slurm orchestrated clusters. A single cluster can now run tree topology in one partition and block topology in another, with each partition using the topology best suited to its instance types. This improves distributed training performance by keeping job placement aligned with the interconnect characteristics of each instance type, so GPU-to-GPU communication is faster, NCCL collective operations are more efficient, and training throughput improves.

HyperPod determines the topology for each partition based on the instance types of its compute instance groups. Partitions with Amazon EC2 UltraServer instance types such as ml.p6e-gb200.36xlarge use block topology, and those with hierarchical-interconnect instance types such as ml.p5.48xlarge, ml.p5e.48xlarge, and ml.p5en.48xlarge use tree topology, while partitions with instance types that don’t provide network topology information remain fully schedulable. HyperPod maintains this configuration automatically as the cluster changes through scale-up, scale-down, and node replacement events, so each partition’s topology always reflects the current state of the cluster.

To get started, create or update a SageMaker HyperPod Slurm cluster running Slurm 25.11 or later with supported GPU instance types. Topology-aware scheduling is enabled by default and requires no configuration. This feature is available in all AWS Regions where Amazon SageMaker HyperPod is supported. To learn more, see Using topology-aware scheduling in Amazon SageMaker HyperPod.

 

​Amazon SageMaker HyperPod now supports network topology configuration at the partition level for Slurm orchestrated clusters. A single cluster can now run tree topology in one partition and block topology in another, with each partition using the topology best suited to its instance types. This improves distributed training performance by keeping job placement aligned with the interconnect characteristics of each instance type, so GPU-to-GPU communication is faster, NCCL collective operations are more efficient, and training throughput improves. HyperPod determines the topology for each partition based on the instance types of its compute instance groups. Partitions with Amazon EC2 UltraServer instance types such as ml.p6e-gb200.36xlarge use block topology, and those with hierarchical-interconnect instance types such as ml.p5.48xlarge, ml.p5e.48xlarge, and ml.p5en.48xlarge use tree topology, while partitions with instance types that don’t provide network topology information remain fully schedulable. HyperPod maintains this configuration automatically as the cluster changes through scale-up, scale-down, and node replacement events, so each partition’s topology always reflects the current state of the cluster. To get started, create or update a SageMaker HyperPod Slurm cluster running Slurm 25.11 or later with supported GPU instance types. Topology-aware scheduling is enabled by default and requires no configuration. This feature is available in all AWS Regions where Amazon SageMaker HyperPod is supported. To learn more, see Using topology-aware scheduling in Amazon SageMaker HyperPod.  

Amazon GameLift Streams now supports assigning an IAM role to a stream session, enabling your application to securely access resources in your AWS account, such as Amazon S3 buckets and DynamoDB tables. With this launch, you can pass a RoleArn parameter when starting a stream session, and your application automatically receives short-lived, auto-refreshing AWS credentials through the standard AWS SDK credential resolution chain — no application code changes required.

Previously, customers who needed their streamed applications to access AWS services had to embed long-lived access keys in application bundles or pass them as environment variables, creating security and operational challenges. Now, Amazon GameLift Streams handles credential vending and automatic refresh using the same container credential provider mechanism trusted by Amazon ECS task roles and Amazon EKS Pod Identity. Role misconfigurations are validated at session start, surfacing clear errors immediately rather than during runtime.

You can also configure IAM roles directly in the Amazon GameLift Streams console, which provides a pre-filled trust policy template to simplify role setup.

IAM role support for stream sessions is available in all AWS Regions where Amazon GameLift Streams is available.

To learn more, see Session Credentials Setup in the Amazon GameLift Streams Developer Guide: https://docs.aws.amazon.com/gameliftstreams/latest/developerguide/session-credentials-setup.html 

 

​Amazon GameLift Streams now supports assigning an IAM role to a stream session, enabling your application to securely access resources in your AWS account, such as Amazon S3 buckets and DynamoDB tables. With this launch, you can pass a RoleArn parameter when starting a stream session, and your application automatically receives short-lived, auto-refreshing AWS credentials through the standard AWS SDK credential resolution chain — no application code changes required.
Previously, customers who needed their streamed applications to access AWS services had to embed long-lived access keys in application bundles or pass them as environment variables, creating security and operational challenges. Now, Amazon GameLift Streams handles credential vending and automatic refresh using the same container credential provider mechanism trusted by Amazon ECS task roles and Amazon EKS Pod Identity. Role misconfigurations are validated at session start, surfacing clear errors immediately rather than during runtime.
You can also configure IAM roles directly in the Amazon GameLift Streams console, which provides a pre-filled trust policy template to simplify role setup.
IAM role support for stream sessions is available in all AWS Regions where Amazon GameLift Streams is available.
To learn more, see Session Credentials Setup in the Amazon GameLift Streams Developer Guide: https://docs.aws.amazon.com/gameliftstreams/latest/developerguide/session-credentials-setup.html   

Amazon OpenSearch Service now supports one-click migration from legacy OpenSearch Dashboards to OpenSearch UI, for both OpenSearch domains and serverless collections. OpenSearch UI is the new, zero-downtime, serverless interface for search and unified observability across multiple data sources. With this launch, the multiple tenants and thousands of saved objects you created in legacy OpenSearch Dashboards become reusable in your OpenSearch UI applications, reducing the operational complexity of moving between interfaces.

With one-click migration, you can move your existing tenants and saved objects into OpenSearch UI workspaces without recreating them manually. The mechanism works for OpenSearch Dashboards created under Amazon OpenSearch Service domains and serverless collections. You can migrate everything into a new workspace or into an existing one. If you have created multiple tenants in your OpenSearch Dashboard, you have the option to either convert them into a single workspace or keep them separate for different teams.  

This feature is available in all AWS Regions where OpenSearch UI is available. To get started, see Using OpenSearch UI in the Amazon OpenSearch Service Developer Guide. Visit the OpenSearch UI Help page for detailed feature tutorials. To learn more about the service, see the Amazon OpenSearch Service product page.

 

​Amazon OpenSearch Service now supports one-click migration from legacy OpenSearch Dashboards to OpenSearch UI, for both OpenSearch domains and serverless collections. OpenSearch UI is the new, zero-downtime, serverless interface for search and unified observability across multiple data sources. With this launch, the multiple tenants and thousands of saved objects you created in legacy OpenSearch Dashboards become reusable in your OpenSearch UI applications, reducing the operational complexity of moving between interfaces.
With one-click migration, you can move your existing tenants and saved objects into OpenSearch UI workspaces without recreating them manually. The mechanism works for OpenSearch Dashboards created under Amazon OpenSearch Service domains and serverless collections. You can migrate everything into a new workspace or into an existing one. If you have created multiple tenants in your OpenSearch Dashboard, you have the option to either convert them into a single workspace or keep them separate for different teams.  
This feature is available in all AWS Regions where OpenSearch UI is available. To get started, see Using OpenSearch UI in the Amazon OpenSearch Service Developer Guide. Visit the OpenSearch UI Help page for detailed feature tutorials. To learn more about the service, see the Amazon OpenSearch Service product page.  

Today, AWS Billing and Cost Management (BCM) announces support for Cost Efficiency widget in BCM Dashboards. You can now view cost efficiency trends alongside Cost Explorer, Budgets, and reports for Savings Plans and Reserved Instance coverage and utilization reports. This provides a unified view of your spending, commitments, and optimization performance in a single, tailored dashboard.

The Cost Efficiency widget displays your efficiency score over time, showing how your efficiency across your AWS environment changes over time. You can view efficiency by AWS account, region, or overall, and adjust granularity to analyze trends at the level that matters most to your team. By adding one or more Cost Efficiency widget to a BCM Dashboard, you can monitor your optimization performance from your existing cost management workflows. The widget links directly to the Cost Optimization Hub console so you can easily take actions when you have recommendations for savings opportunities.

With the Cost Efficiency widget, you can create a unified view of your spending, commitments, budgets, and optimization performance. The widget is fully integrated with dashboard exports and can be included in scheduled email reports or downloaded as a CSV or PDF for offline analysis. They are also included with cross-account dashboard sharing.

The Cost Efficiency widget for BCM Dashboards is available in all AWS commercial Regions at no additional charge. To learn more, visit our User Guide.

 

​Today, AWS Billing and Cost Management (BCM) announces support for Cost Efficiency widget in BCM Dashboards. You can now view cost efficiency trends alongside Cost Explorer, Budgets, and reports for Savings Plans and Reserved Instance coverage and utilization reports. This provides a unified view of your spending, commitments, and optimization performance in a single, tailored dashboard.
The Cost Efficiency widget displays your efficiency score over time, showing how your efficiency across your AWS environment changes over time. You can view efficiency by AWS account, region, or overall, and adjust granularity to analyze trends at the level that matters most to your team. By adding one or more Cost Efficiency widget to a BCM Dashboard, you can monitor your optimization performance from your existing cost management workflows. The widget links directly to the Cost Optimization Hub console so you can easily take actions when you have recommendations for savings opportunities.
With the Cost Efficiency widget, you can create a unified view of your spending, commitments, budgets, and optimization performance. The widget is fully integrated with dashboard exports and can be included in scheduled email reports or downloaded as a CSV or PDF for offline analysis. They are also included with cross-account dashboard sharing.
The Cost Efficiency widget for BCM Dashboards is available in all AWS commercial Regions at no additional charge. To learn more, visit our User Guide.  

Amazon Managed Grafana is now a FedRAMP High authorized service in the AWS GovCloud (US-East) and AWS GovCloud (US-West) regions. Federal agencies, public sector organizations, and other enterprises with FedRAMP High compliance requirements can now use Amazon Managed Grafana to visualize, query, and alert on operational metrics across their AWS and hybrid environments while meeting their strict security and compliance requirements.

Amazon Managed Grafana is a fully managed service based on open-source Grafana that makes it easier for you to visualize and analyze your operational data at scale. The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program that delivers a standard approach to the security assessment, authorization, and continuous monitoring for cloud products and services. 

For more details about Amazon Managed Grafana in AWS GovCloud (US), visit the Amazon Managed Grafana GovCloud documentation or contact your AWS account team for more information. To learn more, visit the Amazon Managed Grafana product page.

 

​Amazon Managed Grafana is now a FedRAMP High authorized service in the AWS GovCloud (US-East) and AWS GovCloud (US-West) regions. Federal agencies, public sector organizations, and other enterprises with FedRAMP High compliance requirements can now use Amazon Managed Grafana to visualize, query, and alert on operational metrics across their AWS and hybrid environments while meeting their strict security and compliance requirements.
Amazon Managed Grafana is a fully managed service based on open-source Grafana that makes it easier for you to visualize and analyze your operational data at scale. The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program that delivers a standard approach to the security assessment, authorization, and continuous monitoring for cloud products and services. 
For more details about Amazon Managed Grafana in AWS GovCloud (US), visit the Amazon Managed Grafana GovCloud documentation or contact your AWS account team for more information. To learn more, visit the Amazon Managed Grafana product page.  

Customers can now view annual water withdrawals data associated with their AWS workloads in AWS Sustainability, alongside existing carbon emissions data. This enhancement helps organizations gain comprehensive visibility into their environmental impact across carbon and water.

Water withdrawals data is available by AWS Region, service, and AWS account on an annual basis through the AWS Sustainability console and API. The data represents the total volume of water withdrawn for data center operations, with efficiency improvements reflected as lower withdrawal volumes.

AWS Sustainability water withdrawals data is available at no additional charge in all AWS Regions where the service is available.

To get started visit the AWS Sustainability user guide. For more information, see the AWS Sustainability console page.

 

​Customers can now view annual water withdrawals data associated with their AWS workloads in AWS Sustainability, alongside existing carbon emissions data. This enhancement helps organizations gain comprehensive visibility into their environmental impact across carbon and water.
Water withdrawals data is available by AWS Region, service, and AWS account on an annual basis through the AWS Sustainability console and API. The data represents the total volume of water withdrawn for data center operations, with efficiency improvements reflected as lower withdrawal volumes.
AWS Sustainability water withdrawals data is available at no additional charge in all AWS Regions where the service is available.
To get started visit the AWS Sustainability user guide. For more information, see the AWS Sustainability console page.