Amazon Aurora PostgreSQL-Compatible Edition has added support for PostgreSQL versions 17.6, 16.10, 15.14, 14.19, and 13.22. The update includes the PostgreSQL community’s product improvements and bug fixes, and also includes Aurora-specific enhancements.
Dynamic Data Masking (DDM) (16.10 and 17.6 only) is a new database-level security feature that protects sensitive data like personally identifiable information by masking column values dynamically at query time based on role-based policies, without altering the actual stored data. This release also includes a shared plan cache, improved performance and recovery-time-objective (RTO) and improvement for Global Database switchovers.
To use the new versions, create a new Aurora PostgreSQL-compatible database with just a few clicks in the Amazon RDS Management Console. You can also upgrade your existing database. Please review the Aurora documentation to learn more about upgrading. Refer to the Aurora version policy to help you to decide how often to upgrade and how to plan your upgrade process. These releases are available in all commercial AWS Regions and the AWS GovCloud (US) Regions.
Amazon Aurora is designed for unparalleled high performance and availability at global scale with full MySQL and PostgreSQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.
Amazon Aurora PostgreSQL-Compatible Edition has added support for PostgreSQL versions 17.6, 16.10, 15.14, 14.19, and 13.22. The update includes the PostgreSQL community’s product improvements and bug fixes, and also includes Aurora-specific enhancements.
Dynamic Data Masking (DDM) (16.10 and 17.6 only) is a new database-level security feature that protects sensitive data like personally identifiable information by masking column values dynamically at query time based on role-based policies, without altering the actual stored data. This release also includes a shared plan cache, improved performance and recovery-time-objective (RTO) and improvement for Global Database switchovers. To use the new versions, create a new Aurora PostgreSQL-compatible database with just a few clicks in the Amazon RDS Management Console. You can also upgrade your existing database. Please review the Aurora documentation to learn more about upgrading. Refer to the Aurora version policy to help you to decide how often to upgrade and how to plan your upgrade process. These releases are available in all commercial AWS Regions and the AWS GovCloud (US) Regions. Amazon Aurora is designed for unparalleled high performance and availability at global scale with full MySQL and PostgreSQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.
AWS now supports deletion vectors and row lineage as defined in the Apache Iceberg Version 3 (V3) specification. These new features are available with Apache Spark on Amazon EMR 7.12, AWS Glue, Amazon SageMaker notebooks, Amazon S3 Tables, and the AWS Glue Data Catalog.
These Iceberg V3 capabilities help customers build petabyte-scale data lakes with improved performance for data modifications and functionality to easily track changed records. Deletion vectors write optimized delete files that speed up data pipelines and reduce data compaction costs. Row lineage provides metadata fields on each record to track changes with a simple SQL query, eliminating the computational expense of finding small changes in large tables.
Get started creating V3 tables by setting the table property to ‘format-version = 3’ in the CREATE TABLE command in Spark or a SageMaker notebook. To upgrade existing tables, simply update the table property in metadata with the new format version. When you do this, AWS query engines that support V3 will automatically begin to use deletion vectors and row lineage.
Iceberg V3 deletion vectors and row lineage are now available in all AWS Regions where each respective service/feature—Amazon EMR, AWS Glue, SageMaker notebooks, S3 Tables, and AWS Glue Data Catalog—is supported. To learn more about AWS support for Iceberg V3, visit Apache Iceberg V3 on AWS, and read the blog post.
AWS now supports deletion vectors and row lineage as defined in the Apache Iceberg Version 3 (V3) specification. These new features are available with Apache Spark on Amazon EMR 7.12, AWS Glue, Amazon SageMaker notebooks, Amazon S3 Tables, and the AWS Glue Data Catalog. These Iceberg V3 capabilities help customers build petabyte-scale data lakes with improved performance for data modifications and functionality to easily track changed records. Deletion vectors write optimized delete files that speed up data pipelines and reduce data compaction costs. Row lineage provides metadata fields on each record to track changes with a simple SQL query, eliminating the computational expense of finding small changes in large tables. Get started creating V3 tables by setting the table property to ‘format-version = 3’ in the CREATE TABLE command in Spark or a SageMaker notebook. To upgrade existing tables, simply update the table property in metadata with the new format version. When you do this, AWS query engines that support V3 will automatically begin to use deletion vectors and row lineage. Iceberg V3 deletion vectors and row lineage are now available in all AWS Regions where each respective service/feature—Amazon EMR, AWS Glue, SageMaker notebooks, S3 Tables, and AWS Glue Data Catalog—is supported. To learn more about AWS support for Iceberg V3, visit Apache Iceberg V3 on AWS, and read the blog post.
AWS announces a new warm storage tier for Amazon Kinesis Video Streams (Amazon KVS), delivering cost-effective storage for extended media retention. The standard Amazon KVS storage tier, now designated as the hot tier, remains optimized for real-time data access and short-term storage. The new warm tier enables long-term media retention with sub-second access latency at reduced storage costs.
The warm storage tier enables developers of home security and enterprise video monitoring solutions to cost-effectively stream data from devices, cameras, and mobile phones while maintaining extended retention periods for video analytics and regulatory compliance. Moreover, developers now have the flexibility to configure fragment sizes based on their specific requirements — selecting smaller fragments for lower latency use cases or larger fragments to reduce ingestion costs. Both hot and warm storage tiers integrate seamlessly with Amazon Rekognition Video and Amazon SageMaker, enabling continuous data processing to support the creation of computer vision and video analytics applications.
Amazon Kinesis Video Streams with the new warm storage tier is available in all regions where Amazon Kinesis Video Streams is available, except the AWS GovCloud (US) Regions.
AWS announces a new warm storage tier for Amazon Kinesis Video Streams (Amazon KVS), delivering cost-effective storage for extended media retention. The standard Amazon KVS storage tier, now designated as the hot tier, remains optimized for real-time data access and short-term storage. The new warm tier enables long-term media retention with sub-second access latency at reduced storage costs. The warm storage tier enables developers of home security and enterprise video monitoring solutions to cost-effectively stream data from devices, cameras, and mobile phones while maintaining extended retention periods for video analytics and regulatory compliance. Moreover, developers now have the flexibility to configure fragment sizes based on their specific requirements — selecting smaller fragments for lower latency use cases or larger fragments to reduce ingestion costs. Both hot and warm storage tiers integrate seamlessly with Amazon Rekognition Video and Amazon SageMaker, enabling continuous data processing to support the creation of computer vision and video analytics applications. Amazon Kinesis Video Streams with the new warm storage tier is available in all regions where Amazon Kinesis Video Streams is available, except the AWS GovCloud (US) Regions. To learn more, refer to the getting started guide.
AWS announces the availability of the AWS API MCP Server on AWS Marketplace, enabling customers to deploy the Model Context Protocol (MCP) server to Amazon Bedrock AgentCore. The marketplace entry includes step-by-step configuration and deployment instructions for deploying the AWS API MCP Server as a managed service with built-in authentication and session isolation to Bedrock Agent Core Runtime.
The AWS Marketplace deployment simplifies container management while providing enterprise-grade security, scalability, and session isolation through Amazon Bedrock AgentCore Runtime. Customers can deploy the AWS API MCP Server with configurable authentication methods (SigV4 or JWT), implement least-privilege IAM policies, and leverage AgentCore’s built-in logging and monitoring capabilities. The deployment lets customers configure IAM roles, authentication methods, and network settings according to their security requirements.
The AWS API MCP Server can now be deployed from AWS Marketplace in all AWS Regions where Amazon Bedrock AgentCore is supported.
AWS announces the availability of the AWS API MCP Server on AWS Marketplace, enabling customers to deploy the Model Context Protocol (MCP) server to Amazon Bedrock AgentCore. The marketplace entry includes step-by-step configuration and deployment instructions for deploying the AWS API MCP Server as a managed service with built-in authentication and session isolation to Bedrock Agent Core Runtime. The AWS Marketplace deployment simplifies container management while providing enterprise-grade security, scalability, and session isolation through Amazon Bedrock AgentCore Runtime. Customers can deploy the AWS API MCP Server with configurable authentication methods (SigV4 or JWT), implement least-privilege IAM policies, and leverage AgentCore’s built-in logging and monitoring capabilities. The deployment lets customers configure IAM roles, authentication methods, and network settings according to their security requirements. The AWS API MCP Server can now be deployed from AWS Marketplace in all AWS Regions where Amazon Bedrock AgentCore is supported. Get started by visiting the AWS API MCP Server listing on AWS Marketplace or explore the deployment guide on AWS Labs GitHub repository. Learn more about Amazon Bedrock AgentCore in the AWS documentation.
Today, Amazon SageMaker HyperPod announces the general availability of new APIs that enable programmatic rebooting and replacement of SageMaker HyperPod cluster nodes. SageMaker HyperPod helps you provision resilient clusters for running machine learning (ML) workloads and developing state-of-the-art models such as large language models (LLMs), diffusion models, and foundation models (FMs). The new BatchRebootClusterNodes and BatchReplaceClusterNodes APIs enable customers to programmatically reboot or replace unresponsive or degraded cluster nodes, providing a consistent, orchestrator agnostic approach to node recovery operations.
The new APIs enhance node management capabilities for both Slurm and EKS orchestrated clusters complementing existing node reboot and replacement workflows. Existing orchestrator-specific methods, such as Kubernetes labels for EKS clusters and Slurm commands for Slurm clusters, remain available alongside the newly introduced programmatic capabilities for reboot and replace operations through these purpose-built APIs. When cluster nodes become unresponsive due to issues such as memory overruns or hardware degradation, recovery operations such as node reboots and replacements maybe be necessary and can be initiated through these new APIs. These capabilities are particularly valuable when running time-sensitive workloads. For instance, when a Slurm controller, login or compute node becomes unresponsive, administrators can trigger a reboot operation using the API and monitor its progress to get nodes back to operational status. Similarly, EKS cluster administrators can replace degraded worker nodes programmatically. Each API supports batch operations of up to 25 instances, enabling efficient management of large-scale recovery scenarios.
The reboot and replace APIs are currently supported in three AWS regions where SageMaker HyperPod is available: US East (Ohio), Asia Pacific (Mumbai), and Asia Pacific (Tokyo).The APIs can be accessed through the AWS CLI, SDK, or API calls. For more information, see the Amazon SageMaker HyperPod documentation for BatchRebootClusterNodes and BatchReplaceClusterNodes.
Today, Amazon SageMaker HyperPod announces the general availability of new APIs that enable programmatic rebooting and replacement of SageMaker HyperPod cluster nodes. SageMaker HyperPod helps you provision resilient clusters for running machine learning (ML) workloads and developing state-of-the-art models such as large language models (LLMs), diffusion models, and foundation models (FMs). The new BatchRebootClusterNodes and BatchReplaceClusterNodes APIs enable customers to programmatically reboot or replace unresponsive or degraded cluster nodes, providing a consistent, orchestrator agnostic approach to node recovery operations. The new APIs enhance node management capabilities for both Slurm and EKS orchestrated clusters complementing existing node reboot and replacement workflows. Existing orchestrator-specific methods, such as Kubernetes labels for EKS clusters and Slurm commands for Slurm clusters, remain available alongside the newly introduced programmatic capabilities for reboot and replace operations through these purpose-built APIs. When cluster nodes become unresponsive due to issues such as memory overruns or hardware degradation, recovery operations such as node reboots and replacements maybe be necessary and can be initiated through these new APIs. These capabilities are particularly valuable when running time-sensitive workloads. For instance, when a Slurm controller, login or compute node becomes unresponsive, administrators can trigger a reboot operation using the API and monitor its progress to get nodes back to operational status. Similarly, EKS cluster administrators can replace degraded worker nodes programmatically. Each API supports batch operations of up to 25 instances, enabling efficient management of large-scale recovery scenarios. The reboot and replace APIs are currently supported in three AWS regions where SageMaker HyperPod is available: US East (Ohio), Asia Pacific (Mumbai), and Asia Pacific (Tokyo).The APIs can be accessed through the AWS CLI, SDK, or API calls. For more information, see the Amazon SageMaker HyperPod documentation for BatchRebootClusterNodes and BatchReplaceClusterNodes.
Los investigadores encuentran —y ayudan a solucionar— una amenaza oculta de bioseguridad
Por: Samantha Kubota, escritora de Microsoft.
Las proteínas son los motores y los bloques básicos de la biología, impulsan cómo los organismos se adaptan, piensan y funcionan. La IA ayuda a los científicos a diseñar nuevas estructuras proteicas a partir de secuencias de aminoácidos, lo que abre puertas a nuevas terapias y curas.
Pero con ese poder también viene una responsabilidad seria: muchas de estas herramientas son de código abierto y podrían ser susceptibles a un mal uso.
Para comprender el riesgo, científicos de Microsoft demostraron cómo las herramientas de diseño de proteínas de IA (AIPD, por sus siglas en inglés) de código abierto pueden aprovecharse para generar miles de versiones sintéticas de una toxina específica — al alternar su secuencia de aminoácidos mientras se preserva su estructura y, de manera potencial, su función. El experimento, realizado mediante simulación por ordenador, reveló que la mayoría de estas toxinas rediseñadas podrían evadir los sistemas de cribado utilizados por las empresas de síntesis de ADN.
Ese descubrimiento expuso un punto ciego en la bioseguridad y, en última instancia, llevó a la creación de un esfuerzo colaborativo intersectorial dedicado a hacer que los sistemas de cribado de ADN sean más resistentes a los avances de la IA. Durante 10 meses, el equipo trabajó de forma discreta y rápida para abordar el riesgo, a través de formular y aplicar nuevos procesos de «red-teaming» en bioseguridad para desarrollar un «parche» que se distribuyó a nivel global a empresas de síntesis de ADN. Su artículo revisado por pares, publicado en Science el 2 de octubre, detalla sus hallazgos iniciales y las acciones posteriores que reforzaron las salvaguardas globales de bioseguridad.
Eric Horvitz, director científico de Microsoft y líder del proyecto, explica más sobre lo que todo esto significa:
En términos sencillos, ¿qué pregunta planteó tu estudio y qué encontraste?
Me propuse con Bruce Wittmann, un biocientífico aplicado senior de mi equipo, responder a la pregunta: «¿Podrían las herramientas de diseño de proteínas de IA de última generación de hoy usarse para rediseñar proteínas tóxicas y preservar su estructura —y de manera potencial su función— mientras evaden la detección por las herramientas de cribado actuales?» La respuesta a esa pregunta era sí, podrían.
La segunda pregunta fue: «¿Podríamos diseñar métodos y un estudio sistemático que nos permita trabajar de manera rápida y discreta con los principales actores para actualizar o parchear esas herramientas de cribado y hacerlas más resilientes a la IA?» Gracias al estudio y al esfuerzo de colaboradores dedicados, ahora podemos decir que sí.
¿Qué revela su investigación sobre las limitaciones de los sistemas actuales de bioseguridad y cuán vulnerables somos hoy en día?
Descubrimos que el software y los procesos de cribado eran insuficientes para detectar una versión «parafraseada» de secuencias proteicas preocupantes. El diseño de proteínas impulsado por IA es una de las áreas más emocionantes y dinámicas de la IA en este momento, pero esa velocidad también genera preocupación sobre posibles usos malévolos de las herramientas AIPD. Tras el lanzamiento del Proyecto Paraphrase, creemos que hemos avanzado bastante en caracterizar y abordar las preocupaciones iniciales en un periodo más o menos corto.
Existen múltiples formas en que la IA podría ser mal utilizada para diseñar la biología, incluidas áreas más allá de las proteínas. Esperamos que estos desafíos persistan, por lo que habrá una necesidad continua de identificar y abordar las vulnerabilidades emergentes. Esperamos que nuestro estudio ofrezca orientación sobre métodos y mejores prácticas que otros puedan adaptar o sobre las que puedan construir. Esto incluye adaptar métodos de escenarios de respuesta a emergencias en ciberseguridad y desarrollar técnicas para el «red-teaming» de la IA en biología — para simular tanto los roles del atacante como del defensor para probar de manera iterativa, evadir y mejorar la detección de amenazas generadas por IA.
¿Qué fue lo que más te sorprendió de tus hallazgos?
Hubo varias sorpresas por el camino. Fue sorprendente ver la manera tan eficaz en que un equipo intersectorial podía reunirse de manera tan rápida y colaborar de manera estrecha y a gran velocidad, para formar un grupo cohesionado que se reunía con regularidad durante meses. Reconocimos los riesgos, alineamos el enfoque, nos adaptamos a una serie de hallazgos y nos comprometimos con el proceso y el esfuerzo hasta desarrollar y distribuir una solución.
También nos sorprendió —e inspiró— el poder de las herramientas de DIAPD, disponibles de manera amplia en las ciencias biológicas, no solo para predecir la estructura de las proteínas, sino para permitir el diseño personalizado de proteínas. Las herramientas de diseño de proteínas con IA hacen que este trabajo sea más fácil y accesible. Esa accesibilidad reduce la barrera de especialización necesaria, lo que acelera el progreso en biología y medicina — pero también puede aumentar el riesgo de mal uso. Espero que algunos de los mayores logros de la IA lleguen a las ciencias de la vida y la salud, pero nuestro estudio destaca por qué debemos mantenernos proactivos, diligentes y creativos en la gestión de riesgos.
Eric Horvitz, director científico de Microsoft y líder del proyecto.
¿Puedes explicar por qué a la gente común le debería importar que la IA se use en biología? ¿Cuáles son los beneficios y cuáles son los riesgos reales?
Creo que es importante que todos comprendan el poder y el potencial de estas herramientas de IA, al tener en cuenta tanto su increíble potencial para lograr avances revolucionarios en biología y medicina como nuestra responsabilidad colectiva de garantizar que beneficien a la sociedad y no causen daño.
Ser capaz de identificar y diseñar nuevas estructuras proteicas abre caminos para comprender la biología en profundidad: cómo operan nuestras células en los cimientos de la salud, el bienestar y la enfermedad — y cómo desarrollar nuevas curas y terapias. Algunas de las primeras aplicaciones implicaban proteínas añadidas a detergentes para la ropa, optimizadas para eliminar manchas. De manera más reciente, el progreso se ha desplazado hacia esfuerzos sofisticados para construir proteínas personalizadas para funciones biológicas específicas, como nuevos antídotos para contrarrestar el veneno de serpiente.
Estos avances revolucionarios tal vez conducirán, en nuestra vida, a avances como ralentizar o curar los cánceres, abordar enfermedades inmunitarias, mejorar terapias, desvelar misterios biológicos y detectar y mitigar amenazas sanitarias antes de que se propaguen. Al mismo tiempo, estas herramientas pueden ser explotadas de manera perjudicial. Por eso es fundamental combinar la innovación con salvaguardias: avances técnicos proactivos en la forma en la que nos centramos en nuestro trabajo, supervisión regulatoria y ciudadanos informados.
¿Qué quieres que el público general se lleve de tu estudio? ¿Deberíamos preocuparnos, ser optimistas o ambas cosas?
Casi todos los grandes avances científicos son de «doble uso»: ofrecen beneficios profundos pero también conllevan riesgos. Es importante protegerse contra los peligros mientras se aprovechan los beneficios — en especial en IA para biología y medicina, donde el potencial de progreso en salud es enorme.
Nuestro estudio demuestra que es posible invertir de manera simultánea en innovación y salvaguardias. Al construir barreras de seguridad, políticas y defensas técnicas, podemos ayudar a garantizar que las personas y la sociedad se beneficien de la promesa de la IA, para reducir al mismo tiempo el riesgo de un uso indebido dañino. Este enfoque dual no se aplica solo a la biología: es un marco para cómo la humanidad debería invertir en gestionar los avances de la IA a través de disciplinas y dominios.
Imagen principal: Los investigadores descubrieron que era posible preservar los sitios activos de la proteína (ilustrados por las letras K E S), mientras se reescribía la secuencia de aminoácidos.
Amazon EMR and AWS Glue now provide comprehensive audit context support for AWS Lake Formation credential vending APIs and AWS Glue Data Catalog GetTable and GetTables API calls. This auditing capability helps you maintain compliance with regulatory frameworks, including the Digital Markets Act (DMA) and data protection regulations. The feature is enabled by default, offering seamless integration into existing workflows while strengthening security and compliance monitoring across your data lake infrastructure.
You can view this audit context information in AWS CloudTrail logs, enabling enhanced security auditing, regulatory compliance, and improved troubleshooting for EMR for Apache Spark native fine-grained access control (FGAC) and full table access jobs. The audit logging feature automatically records the platform type (EMR-EC2, EMR on EKS, EMR Serverless, or AWS Glue) and its corresponding identifiers like such as Cluster ID, Step ID, Job Run ID, and Virtual Cluster ID. This enables security teams to track and correlate API calls from individual Spark jobs, streamline compliance reporting, and analyze historical data access patterns. Additionally, data engineers can quickly troubleshoot access-related issues by connecting them to specific job executions, resolve FGAC permission challenges, and monitor access patterns across different compute platforms.
This feature is available in all AWS Regions that support Amazon EMR, AWS Glue, and AWS Lake Formation, requiring EMR version 7.12+ or AWS Glue version 5.1+.
Amazon EMR and AWS Glue now provide comprehensive audit context support for AWS Lake Formation credential vending APIs and AWS Glue Data Catalog GetTable and GetTables API calls. This auditing capability helps you maintain compliance with regulatory frameworks, including the Digital Markets Act (DMA) and data protection regulations. The feature is enabled by default, offering seamless integration into existing workflows while strengthening security and compliance monitoring across your data lake infrastructure. You can view this audit context information in AWS CloudTrail logs, enabling enhanced security auditing, regulatory compliance, and improved troubleshooting for EMR for Apache Spark native fine-grained access control (FGAC) and full table access jobs. The audit logging feature automatically records the platform type (EMR-EC2, EMR on EKS, EMR Serverless, or AWS Glue) and its corresponding identifiers like such as Cluster ID, Step ID, Job Run ID, and Virtual Cluster ID. This enables security teams to track and correlate API calls from individual Spark jobs, streamline compliance reporting, and analyze historical data access patterns. Additionally, data engineers can quickly troubleshoot access-related issues by connecting them to specific job executions, resolve FGAC permission challenges, and monitor access patterns across different compute platforms. This feature is available in all AWS Regions that support Amazon EMR, AWS Glue, and AWS Lake Formation, requiring EMR version 7.12+ or AWS Glue version 5.1+.
Amazon SageMaker HyperPod now supports Managed Tiered KV Cache and Intelligent Routing for large language model (LLM) inference, enabling customers to optimize inference performance for long-context prompts and multi-turn conversations. Customers deploying production LLM applications need fast response times while processing lengthy documents or maintaining conversation context, but traditional inference approaches require recalculating attention mechanisms for all previous tokens with each new token generation, creating computational overhead and escalating costs. Managed Tiered KV Cache addresses this challenge by intelligently caching and reusing computed values, while Intelligent Routing directs requests to optimal instances.
These capabilities deliver up to 40% latency reduction, 25% throughput improvement, and 25% cost savings compared to baseline configurations. The Managed Tiered KV Cache feature uses a two-tier architecture combining local CPU memory (L1) with disaggregated cluster-wide storage (L2). AWS-native disaggregated tiered storage is the recommended backend, providing scalable terabyte-scale capacity and automatic tiering from CPU memory to local SSD for optimal memory and storage utilization. We also offer Redis as an alternative L2 cache option. The architecture enables efficient reuse of previously computed key-value pairs across requests. The newly introduced Intelligent Routing maximizes cache utilization through three configurable strategies: prefix-aware routing for common prompt patterns, KV-aware routing for maximum cache efficiency with real-time cache tracking, and round-robin for stateless workloads. These features work seamlessly together. Intelligent routing directs requests to instances with relevant cached data, reducing time to first token in document analysis and maintaining natural conversation flow in multi-turn dialogues. Built-in observability integration with Amazon Managed Grafana provides metrics for monitoring performance. You can enable these features through InferenceEndpointConfig or SageMaker JumpStart when deploying models via the HyperPod Inference Operator on EKS-orchestrated clusters.
These features are available in all regions where SageMaker HyperPod is available. To learn more, see the user guide.
Amazon SageMaker HyperPod now supports Managed Tiered KV Cache and Intelligent Routing for large language model (LLM) inference, enabling customers to optimize inference performance for long-context prompts and multi-turn conversations. Customers deploying production LLM applications need fast response times while processing lengthy documents or maintaining conversation context, but traditional inference approaches require recalculating attention mechanisms for all previous tokens with each new token generation, creating computational overhead and escalating costs. Managed Tiered KV Cache addresses this challenge by intelligently caching and reusing computed values, while Intelligent Routing directs requests to optimal instances. These capabilities deliver up to 40% latency reduction, 25% throughput improvement, and 25% cost savings compared to baseline configurations. The Managed Tiered KV Cache feature uses a two-tier architecture combining local CPU memory (L1) with disaggregated cluster-wide storage (L2). AWS-native disaggregated tiered storage is the recommended backend, providing scalable terabyte-scale capacity and automatic tiering from CPU memory to local SSD for optimal memory and storage utilization. We also offer Redis as an alternative L2 cache option. The architecture enables efficient reuse of previously computed key-value pairs across requests. The newly introduced Intelligent Routing maximizes cache utilization through three configurable strategies: prefix-aware routing for common prompt patterns, KV-aware routing for maximum cache efficiency with real-time cache tracking, and round-robin for stateless workloads. These features work seamlessly together. Intelligent routing directs requests to instances with relevant cached data, reducing time to first token in document analysis and maintaining natural conversation flow in multi-turn dialogues. Built-in observability integration with Amazon Managed Grafana provides metrics for monitoring performance. You can enable these features through InferenceEndpointConfig or SageMaker JumpStart when deploying models via the HyperPod Inference Operator on EKS-orchestrated clusters. These features are available in all regions where SageMaker HyperPod is available. To learn more, see the user guide.
Amazon SageMaker HyperPod now supports custom Kubernetes labels and taints, enabling customers to control pod scheduling and integrate seamlessly with existing Kubernetes infrastructure. Customers deploying AI workloads on HyperPod clusters orcehstrated with EKS need precise control over workload placement to prevent expensive GPU resources from being consumed by system pods and non-AI workloads, while ensuring compatibility with custom device plugins such as EFA and NVIDIA GPU operators. Previously, customers had to manually apply labels and taints using kubectl and reapply them after every node replacement, scaling, or patching operation, creating significant operational overhead.
This capability allows you to configure labels and taints at the instance group level through the CreateCluster and UpdateCluster APIs, providing a managed approach to defining and maintaining scheduling policies across the entire node lifecycle. Using the new KubernetesConfig parameter, you can specify up to 50 labels and 50 taints per instance group. Labels enable resource organization and pod targeting through node selectors, while taints repel pods without matching tolerations to protect specialized nodes. For example, you can apply NoSchedule taints to GPU instance groups to ensure only AI training jobs with explicit tolerations consume high-cost compute resources, or add custom labels that enable device plugin pods to schedule correctly. HyperPod automatically applies these configurations during node creation and maintains them across replacement, scaling, and patching operations, eliminating manual intervention and reducing operational overhead.
This feature is available in all AWS Regions where Amazon SageMaker HyperPod is available. To learn more about custom labels and taints, see the user guide.
Amazon SageMaker HyperPod now supports custom Kubernetes labels and taints, enabling customers to control pod scheduling and integrate seamlessly with existing Kubernetes infrastructure. Customers deploying AI workloads on HyperPod clusters orcehstrated with EKS need precise control over workload placement to prevent expensive GPU resources from being consumed by system pods and non-AI workloads, while ensuring compatibility with custom device plugins such as EFA and NVIDIA GPU operators. Previously, customers had to manually apply labels and taints using kubectl and reapply them after every node replacement, scaling, or patching operation, creating significant operational overhead. This capability allows you to configure labels and taints at the instance group level through the CreateCluster and UpdateCluster APIs, providing a managed approach to defining and maintaining scheduling policies across the entire node lifecycle. Using the new KubernetesConfig parameter, you can specify up to 50 labels and 50 taints per instance group. Labels enable resource organization and pod targeting through node selectors, while taints repel pods without matching tolerations to protect specialized nodes. For example, you can apply NoSchedule taints to GPU instance groups to ensure only AI training jobs with explicit tolerations consume high-cost compute resources, or add custom labels that enable device plugin pods to schedule correctly. HyperPod automatically applies these configurations during node creation and maintains them across replacement, scaling, and patching operations, eliminating manual intervention and reducing operational overhead. This feature is available in all AWS Regions where Amazon SageMaker HyperPod is available. To learn more about custom labels and taints, see the user guide.
Today, AWS announces that AWS Compute Optimizer now supports idle resource recommendations for NAT Gateways. With this new recommendation type, you will be able to identify NAT Gateways that are unused, resulting in cost savings.
With the new unused NAT Gateway recommendation, you will be able to identify NAT Gateways that show no traffic activity over a 32-day analysis period. Compute Optimizer analyzes CloudWatch metrics including active connection count, incoming packets from source, and incoming packets from destination to validate if NAT Gateways are truly unused. To avoid recommending critical backup resources, Compute Optimizer also examines if the NAT Gateway resource is associated in any AWS Route Tables. You can view the total savings potential of these unused NAT Gateways and access detailed utilization metrics to verify unused conditions before taking action.
This new feature is available in all AWS Regions where AWS Compute Optimizer is available except the AWS GovCloud (US) and the China Regions. To learn more about the new feature updates, please visit Compute Optimizer’s product page and user guide.
Today, AWS announces that AWS Compute Optimizer now supports idle resource recommendations for NAT Gateways. With this new recommendation type, you will be able to identify NAT Gateways that are unused, resulting in cost savings. With the new unused NAT Gateway recommendation, you will be able to identify NAT Gateways that show no traffic activity over a 32-day analysis period. Compute Optimizer analyzes CloudWatch metrics including active connection count, incoming packets from source, and incoming packets from destination to validate if NAT Gateways are truly unused. To avoid recommending critical backup resources, Compute Optimizer also examines if the NAT Gateway resource is associated in any AWS Route Tables. You can view the total savings potential of these unused NAT Gateways and access detailed utilization metrics to verify unused conditions before taking action. This new feature is available in all AWS Regions where AWS Compute Optimizer is available except the AWS GovCloud (US) and the China Regions. To learn more about the new feature updates, please visit Compute Optimizer’s product page and user guide.
