Publicado el Deja un comentario

Amazon ElastiCache for Valkey now supports durability

Today, AWS announces durability support for Amazon ElastiCache. Durability enables you to use ElastiCache for workloads that require microsecond read latency but cannot tolerate data loss. With durability support, ElastiCache now stores data durably across multiple Availability Zones (AZs) using a Multi-AZ transactional log to enable fast failover, database recovery, and node restarts to prevent data loss in the unlikely event of a failure.

You can choose between two durability options: synchronous and asynchronous writes. Synchronous writes persist data across at least two AZs before responding to the client, designed for zero data loss at single-digit millisecond write latency. Asynchronous writes persist data after responding to the client, maintaining microsecond write latency at no additional cost. However, up to 10 seconds of uncommitted data could be lost in the rare event of a failure. Both options maintain microsecond read latency. You can now use ElastiCache for a broader set of use cases beyond caching where data loss is unacceptable such as AI agent long-term memory, AI agent workflow state, knowledge bases for RAG applications, payment tokenization, and real-time inventory management.

Durability for ElastiCache is available in all AWS commercial Regions, AWS China Regions, and AWS GovCloud (US) Regions starting with Valkey 9.0. To get started, create a new ElastiCache cluster and select your preferred durability option using the AWS Management Console, AWS Software Development Kit (SDK), or AWS Command Line Interface (CLI). For pricing details, visit the Amazon ElastiCache pricing page. To learn more, visit the ElastiCache documentation and blog.  

 

​Today, AWS announces durability support for Amazon ElastiCache. Durability enables you to use ElastiCache for workloads that require microsecond read latency but cannot tolerate data loss. With durability support, ElastiCache now stores data durably across multiple Availability Zones (AZs) using a Multi-AZ transactional log to enable fast failover, database recovery, and node restarts to prevent data loss in the unlikely event of a failure.
You can choose between two durability options: synchronous and asynchronous writes. Synchronous writes persist data across at least two AZs before responding to the client, designed for zero data loss at single-digit millisecond write latency. Asynchronous writes persist data after responding to the client, maintaining microsecond write latency at no additional cost. However, up to 10 seconds of uncommitted data could be lost in the rare event of a failure. Both options maintain microsecond read latency. You can now use ElastiCache for a broader set of use cases beyond caching where data loss is unacceptable such as AI agent long-term memory, AI agent workflow state, knowledge bases for RAG applications, payment tokenization, and real-time inventory management.
Durability for ElastiCache is available in all AWS commercial Regions, AWS China Regions, and AWS GovCloud (US) Regions starting with Valkey 9.0. To get started, create a new ElastiCache cluster and select your preferred durability option using the AWS Management Console, AWS Software Development Kit (SDK), or AWS Command Line Interface (CLI). For pricing details, visit the Amazon ElastiCache pricing page. To learn more, visit the ElastiCache documentation and blog.    

Publicado el Deja un comentario

AWS Cost and Usage Report 2.0 now supports Athena and Redshift integration

AWS today announced that AWS Cost and Usage Report 2.0 (CUR 2.0) provides new integration options with AWS Athena and AWS Redshift. This capability allows customers to analyze the data from their AWS CUR 2.0 in Amazon Simple Storage Service (Amazon S3) using standard SQL without building custom data warehouse solutions, bringing feature parity with CUR 1.0 integration options.

With this launch, when customers select Athena or Redshift integration, CUR 2.0 exports are automatically delivered in the optimal format (Parquet, GZIP) for the chosen query engine. Each export includes the supporting metadata and automation resources needed to get started quickly, such as infrastructure templates, table definitions, and data loading instructions, so customers can begin querying their cost data without manual configuration. As CUR 2.0 data refreshes periodically, updates are automatically reflected in the Athena or Redshift tables with no additional ETL required.

This feature is available in all commercial AWS Regions, except the AWS GovCloud (US) Regions and the China Regions.

To learn more about this feature, see AWS Data Exports and AWS Billing and Cost Management in the AWS Cost Management User Guide.

 

​AWS today announced that AWS Cost and Usage Report 2.0 (CUR 2.0) provides new integration options with AWS Athena and AWS Redshift. This capability allows customers to analyze the data from their AWS CUR 2.0 in Amazon Simple Storage Service (Amazon S3) using standard SQL without building custom data warehouse solutions, bringing feature parity with CUR 1.0 integration options. With this launch, when customers select Athena or Redshift integration, CUR 2.0 exports are automatically delivered in the optimal format (Parquet, GZIP) for the chosen query engine. Each export includes the supporting metadata and automation resources needed to get started quickly, such as infrastructure templates, table definitions, and data loading instructions, so customers can begin querying their cost data without manual configuration. As CUR 2.0 data refreshes periodically, updates are automatically reflected in the Athena or Redshift tables with no additional ETL required. This feature is available in all commercial AWS Regions, except the AWS GovCloud (US) Regions and the China Regions. To learn more about this feature, see AWS Data Exports and AWS Billing and Cost Management in the AWS Cost Management User Guide.  

Publicado el Deja un comentario

Amazon RDS for SQL Server supports Bring Your Own Media

Amazon Relational Database Service (Amazon RDS) for SQL Server launches Bring Your Own Media (BYOM) for Microsoft SQL Server. With BYOM, customers who migrate SQL Server applications from on-premises environments can adopt a managed database service on AWS and reuse their existing Microsoft SQL Server licenses, including Software Assurance, through Microsoft’s License Mobility program.

Amazon RDS provides a managed SQL Server database service that lowers operating costs with features such as high availability, automated backups and monitoring. BYOM helps customers who currently run Microsoft SQL Server on-premises, on other clouds, or as self-managed SQL Server on Amazon EC2, and want to adopt Amazon RDS and reuse their existing Microsoft SQL Server licenses. They no longer have to incur the cost of additional Microsoft SQL Server licenses, or wait for existing license agreements to expire to adopt RDS. Amazon RDS for SQL Server BYOM is integrated with AWS License Manager so customers can track their Microsoft SQL Server license usage across their AWS environment for licensing compliance.

To learn more about how to set up RDS SQL Server database instances with BYOM, visit the Amazon RDS SQL Server User Guide. For BYOM pricing and regional availability, visit the Amazon RDS for SQL Server pricing page

 

​Amazon Relational Database Service (Amazon RDS) for SQL Server launches Bring Your Own Media (BYOM) for Microsoft SQL Server. With BYOM, customers who migrate SQL Server applications from on-premises environments can adopt a managed database service on AWS and reuse their existing Microsoft SQL Server licenses, including Software Assurance, through Microsoft’s License Mobility program. Amazon RDS provides a managed SQL Server database service that lowers operating costs with features such as high availability, automated backups and monitoring. BYOM helps customers who currently run Microsoft SQL Server on-premises, on other clouds, or as self-managed SQL Server on Amazon EC2, and want to adopt Amazon RDS and reuse their existing Microsoft SQL Server licenses. They no longer have to incur the cost of additional Microsoft SQL Server licenses, or wait for existing license agreements to expire to adopt RDS. Amazon RDS for SQL Server BYOM is integrated with AWS License Manager so customers can track their Microsoft SQL Server license usage across their AWS environment for licensing compliance. To learn more about how to set up RDS SQL Server database instances with BYOM, visit the Amazon RDS SQL Server User Guide. For BYOM pricing and regional availability, visit the Amazon RDS for SQL Server pricing page.   

Publicado el Deja un comentario

AWS HealthOmics now supports Nextflow version pinning at run time

AWS HealthOmics now allows customers to specify the Nextflow engine version at run time via the StartRun API, enabling customers to pin runs to a specific Nextflow version for controlled migration. With this launch, customers can select from supported Nextflow versions (22.04, 23.10, 24.10, 25.10, 26.04) through the new engine-settings parameter, giving explicit control at the point of execution. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.

Nextflow version pinning gives customers full control over when and how they adopt new engine versions. The run-time version override ensures that even when a workflow definition specifies a version via manifest.nextflowVersion in its config or profile, the StartRun API parameter takes precedence, enabling customers to test the same workflow across multiple engine versions without modifying workflow source code. Production workflows can remain on a validated engine version while development teams test newer versions in parallel, reducing the risk of unexpected behavior changes. This is valuable for regulated environments where pipeline validation is required before upgrading to a new engine version.

Nextflow version pinning at run time is now available for Nextflow workflow runs in all AWS HealthOmics regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the Nextflow engine settings documentation.

 

​AWS HealthOmics now allows customers to specify the Nextflow engine version at run time via the StartRun API, enabling customers to pin runs to a specific Nextflow version for controlled migration. With this launch, customers can select from supported Nextflow versions (22.04, 23.10, 24.10, 25.10, 26.04) through the new engine-settings parameter, giving explicit control at the point of execution. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
Nextflow version pinning gives customers full control over when and how they adopt new engine versions. The run-time version override ensures that even when a workflow definition specifies a version via manifest.nextflowVersion in its config or profile, the StartRun API parameter takes precedence, enabling customers to test the same workflow across multiple engine versions without modifying workflow source code. Production workflows can remain on a validated engine version while development teams test newer versions in parallel, reducing the risk of unexpected behavior changes. This is valuable for regulated environments where pipeline validation is required before upgrading to a new engine version.
Nextflow version pinning at run time is now available for Nextflow workflow runs in all AWS HealthOmics regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the Nextflow engine settings documentation.  

Publicado el Deja un comentario

AWS HealthOmics now supports Nextflow version 26.04

AWS HealthOmics now supports Nextflow version 26.04, enabling customers to take advantage of new Nextflow features and enhancements: record types, the strict syntax parser, workflow output summaries, and agent logging mode. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.

The strict syntax parser, now enabled by default in Nextflow v26.04, helps customers save compute time and costs by enforcing strict linting, consistent block structures, and unambiguous scoping, catching issues during pipeline initialization rather than hours into workflows. Record types allow workflow developers to write workflows with meaningful data names rather than keeping track of order of tuple elements, making workflows more readable, and less error-prone. Workflow output summary in JSON format simplifies integration with downstream tooling. Agent logging mode provides structured, minimal output optimized for AI-assisted workflow debugging and development.

Nextflow v26.04 is now available in all AWS HealthOmics regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the AWS HealthOmics Nextflow workflow definition specifics documentation.

 

​AWS HealthOmics now supports Nextflow version 26.04, enabling customers to take advantage of new Nextflow features and enhancements: record types, the strict syntax parser, workflow output summaries, and agent logging mode. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
The strict syntax parser, now enabled by default in Nextflow v26.04, helps customers save compute time and costs by enforcing strict linting, consistent block structures, and unambiguous scoping, catching issues during pipeline initialization rather than hours into workflows. Record types allow workflow developers to write workflows with meaningful data names rather than keeping track of order of tuple elements, making workflows more readable, and less error-prone. Workflow output summary in JSON format simplifies integration with downstream tooling. Agent logging mode provides structured, minimal output optimized for AI-assisted workflow debugging and development.
Nextflow v26.04 is now available in all AWS HealthOmics regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul). To learn more, visit the AWS HealthOmics Nextflow workflow definition specifics documentation.  

Publicado el Deja un comentario

Amazon Quick now supports VPC connectivity for MCP connections

Amazon Quick now enables enterprise customers to connect their privately hosted Model Context Protocol (MCP) servers to Quick through Amazon Virtual Private Cloud (VPC). Amazon Quick is an AI assistant that turns questions into answers, answers into actions, and actions into outcomes for you and your entire team. Previously, Quick’s MCP support was limited to third-party hosted servers accessible over the public internet. With VPC support, organizations that host MCP servers on private networks for proprietary applications, custom data sources, and internal tools can now securely extend those capabilities to AI workflows in Quick.

With VPC connectivity for MCP, you can connect Quick to MCP servers running on Amazon EC2, AWS Fargate, AWS Agentcore, or other compute within your private network without exposing them to the internet. During MCP connector creation, select your VPC connection and provide your MCP server URL. Once connected, your team interacts with private MCP servers through natural language in Quick, with all traffic routed securely through your VPC.

VPC support for MCP servers is available in all AWS Regions where Amazon Quick is available.

Learn more about Amazon Quick and try for free. To learn more about connecting private MCP servers, visit the MCP documentation and the VPC connectivity guide.

 

​Amazon Quick now enables enterprise customers to connect their privately hosted Model Context Protocol (MCP) servers to Quick through Amazon Virtual Private Cloud (VPC). Amazon Quick is an AI assistant that turns questions into answers, answers into actions, and actions into outcomes for you and your entire team. Previously, Quick’s MCP support was limited to third-party hosted servers accessible over the public internet. With VPC support, organizations that host MCP servers on private networks for proprietary applications, custom data sources, and internal tools can now securely extend those capabilities to AI workflows in Quick. With VPC connectivity for MCP, you can connect Quick to MCP servers running on Amazon EC2, AWS Fargate, AWS Agentcore, or other compute within your private network without exposing them to the internet. During MCP connector creation, select your VPC connection and provide your MCP server URL. Once connected, your team interacts with private MCP servers through natural language in Quick, with all traffic routed securely through your VPC. VPC support for MCP servers is available in all AWS Regions where Amazon Quick is available. Learn more about Amazon Quick and try for free. To learn more about connecting private MCP servers, visit the MCP documentation and the VPC connectivity guide.  

Publicado el Deja un comentario

Quick Research now supports customer managed keys

Amazon Quick Research now enables customers to encrypt their data using customer-managed keys (CMK) through AWS Key Management Service (KMS).

This enhancement allows organizations with strict security and compliance requirements to manage their own encryption keys. With customer-managed keys, you gain enhanced security control and comprehensive audit capabilities through AWS CloudTrail integration. You can encrypt your data with your own KMS keys, trace all data access for security auditing, and revoke access to compromised keys within 15 minutes during security incidents. This feature supports multiple CMKs with one default key per AWS account per region, providing the flexibility to manage encryption across different datasets while maintaining granular control over your sensitive business intelligence data.

Customer-managed keys must be created in the same AWS account and region as your Quick resources, and only symmetric AWS KMS keys are supported.

This feature is generally available in all AWS Regions where Amazon Quick is available. To learn more, visit the Amazon Quick Research detail page.

 

​Amazon Quick Research now enables customers to encrypt their data using customer-managed keys (CMK) through AWS Key Management Service (KMS).
This enhancement allows organizations with strict security and compliance requirements to manage their own encryption keys. With customer-managed keys, you gain enhanced security control and comprehensive audit capabilities through AWS CloudTrail integration. You can encrypt your data with your own KMS keys, trace all data access for security auditing, and revoke access to compromised keys within 15 minutes during security incidents. This feature supports multiple CMKs with one default key per AWS account per region, providing the flexibility to manage encryption across different datasets while maintaining granular control over your sensitive business intelligence data.
Customer-managed keys must be created in the same AWS account and region as your Quick resources, and only symmetric AWS KMS keys are supported.
This feature is generally available in all AWS Regions where Amazon Quick is available. To learn more, visit the Amazon Quick Research detail page.  

Publicado el Deja un comentario

Amazon SageMaker adds permissions boundaries for SCP compliance

Amazon SageMaker Unified Studio now supports custom IAM permissions boundaries, so organizations that enforce Service Control Policies (SCPs) requiring permissions boundaries on all IAM roles can adopt SageMaker Unified Studio without modifying their security posture.

When a user creates a project, SageMaker Unified Studio provisions three IAM roles: a project user role, an Amazon Bedrock service role, and a Bedrock Lambda execution role. With this launch, administrators can specify a permissions boundary in the Tooling blueprint configuration, and all three roles are created with that permissions boundary attached. This satisfies SCP requirements at creation time, and project provisioning succeeds without administrator intervention. The permissions boundary also limits what the provisioned roles can do, so administrators retain control over project-level permissions even as new projects are created. Because the permissions boundary is set at the blueprint level, it applies to every new project automatically.

This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, visit the Manage Tooling blueprint parameters documentation.

 

​Amazon SageMaker Unified Studio now supports custom IAM permissions boundaries, so organizations that enforce Service Control Policies (SCPs) requiring permissions boundaries on all IAM roles can adopt SageMaker Unified Studio without modifying their security posture. When a user creates a project, SageMaker Unified Studio provisions three IAM roles: a project user role, an Amazon Bedrock service role, and a Bedrock Lambda execution role. With this launch, administrators can specify a permissions boundary in the Tooling blueprint configuration, and all three roles are created with that permissions boundary attached. This satisfies SCP requirements at creation time, and project provisioning succeeds without administrator intervention. The permissions boundary also limits what the provisioned roles can do, so administrators retain control over project-level permissions even as new projects are created. Because the permissions boundary is set at the blueprint level, it applies to every new project automatically. This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, visit the Manage Tooling blueprint parameters documentation.  

Publicado el Deja un comentario

Defensa a velocidad de IA: El nuevo sistema de seguridad agéntica multimodelo de Microsoft encabeza el referente del sector

Defensa a velocidad de IA: El nuevo sistema de seguridad agéntica multimodelo de Microsoft encabeza el referente del sector

Ícono de candado sobre un fondo con degradado en tonos verde y amarillo.

Por: Taesoo Kim, vicepresidente, Agentic Security, Microsoft.

Hoy Microsoft ha anunciado un gran avance en la defensa cibernética impulsada por IA: nuestro nuevo sistema de seguridad agéntica ayudó a los investigadores a encontrar 16 nuevas vulnerabilidades en la pila de redes y autenticación de Windows, incluidos cuatro fallos críticos en la ejecución remota de código en componentes como la pila TCP/IP del núcleo de Windows y el servicio IKEv2. Utilizaron el nuevo arnés de escaneo agéntico multimodelo de Microsoft Security (nombre en clave MDASH), que fue desarrollado por el equipo de Seguridad de Código Autónomo de Microsoft. A diferencia de los enfoques de modelo único, el arnés orquesta más de 100 agentes de IA especializados a través de un conjunto de modelos fronterizos y destilados para descubrir, debatir y demostrar fallos explotables de principio a fin.

Conozcan más y regístrense para unirse a la vista previa privada

Tabla con los mejores agentes

Los resultados hablan por sí mismos: 21 de 21 vulnerabilidades plantadas encontradas con cero falsos positivos en un piloto de pruebas privado; el 96% de la llamada de registro frente a cinco años de casos confirmados del Microsoft Security Response Center (MSRC) en clfs.sys y del 100% en tcpip.sys; y una puntuación líder del sector del 88,45% en el índice público CyberGym de 1.507 vulnerabilidades del mundo real—la puntuación más alta en la clasificación, alrededor de cinco puntos por delante de la siguiente entrada.

Gráfico con ranking de agentes

La implicación estratégica es clara: el descubrimiento de vulnerabilidades en IA ha pasado de la curiosidad investigadora a la defensa de calidad de producción a escala empresarial, y la ventaja duradera reside en el sistema agéntico alrededor del modelo y no en un modelo individual. El nombre en clave MDASH es utilizado por equipos de ingeniería de seguridad de Microsoft y probado por un pequeño grupo de clientes como parte de una vista previa privada limitada.

Esta publicación explica cómo funciona el nombre en clave MDASH, qué hemos lanzado, qué hemos aprendido en el camino y cómo pueden inscribirse en la vista previa privada.

Descubrimiento de vulnerabilidades impulsado por IA a hiperescala

El equipo de Microsoft Autonomous Code Security (ACS) se formó para llevar la investigación de vulnerabilidades impulsada por IA de una curiosidad investigadora a la ingeniería de producción a escala empresarial. Varios miembros de este equipo llegaron a Microsoft desde Team Atlanta, el equipo que ganó el Desafío Cibernético de IA de DARPA de 29,5 millones de dólares al construir un sistema autónomo de razonamiento cibernético que detectaba y parceaba errores reales en proyectos complejos de código abierto. Las lecciones de ese trabajo, en especial el nivel de ingeniería necesario para que los modelos de lenguaje de vanguardia realicen auditorías de seguridad a nivel profesional, son en torno a lo que se basa nuestro nuevo arnés de escaneo agente multimodelo (nombre en clave MDASH).

La base de código de Microsoft es un reto para auditorías de seguridad por varias razones:

  • Superficie propietaria enorme. Windows, Hyper-V, Azure y los ecosistemas de controladores de dispositivo y servicios que los rodean son bases de código privadas de Microsoft—no forman parte del corpus de entrenamiento de ningún modelo de lenguaje convencional, y en verdad difíciles de razonar: las convenciones de llamada al kernel, los invariantes IRP y bloqueos, los límites de confianza del IPC y los modismos internos de componentes no ceden ante la coincidencia de patrones. En esta superficie, un modelo tiene que razonar realmente. 
  • DevSecOps a gran escala. Cada hallazgo tiene un dueño real, un proceso de triaje y un martes de parches para aterrizar. No hay un cajón silencioso para hallazgos especulativos; si una herramienta produce ruido, el ruido es problema de todos. 
  • Objetivos de alto valor. Windows, Hyper-V, Xbox y Azure sirven a miles de millones de usuarios. La recompensa por encontrar un único error duro es, de manera inusual, alta, y también lo es el coste de un falso positivo en un componente de primer nivel. 

Los hallazgos de esta publicación son el resultado de una estrecha colaboración entre ACS, Microsoft Offensive Research & Security Engineering (MORSE) y Microsoft Windows Attack Research and Protection (WARP). WARP y MORSE son los dueños de la parte profunda y dura de la investigación ofensiva de Windows; ACS aporta la cadena de descubrimiento y validación impulsada por IA. Juntos, los equipos han colaborado para construir un arnés maduro.

Nombre en clave: MDASH—El nuevo arnés de escaneo agéntico multimodelo de Microsoft Security

El nombre en clave MDASH es, en esencia, un sistema agéntico de detección y remediación de vulnerabilidades. El modelo es una entrada. El sistema es el producto.

Diagrama de un flujo automatizado de seguridad de código que muestra etapas desde el análisis del repositorio y el escaneo de código hasta la priorización de bugs, la generación de pruebas de concepto y la creación y validación automatizada de parches.

Un modelo mental útil es pensarlo como una tubería estructurada que toma una base de código y emite hallazgos validados y probados:

  • Etapa de preparación: Ingiere el objetivo original, construye índices conscientes del idioma y luego dibuja la superficie de ataque y los modelos de amenaza analizando los compromisos anteriores.
  • Etapa de escaneo: Ejecuta agentes auditores especializados sobre rutas de código candidato, para emitir hallazgos candidatos con hipótesis y pruebas.
  • Etapa de validación: Ejecuta una segunda cohorte de agentes—debatientes—que argumentan a favor y en contra de la alcance y explotabilidad de cada hallazgo.
  • Etapa de deduplicación: Colapsa hallazgos equivalentes a nivel semántico (por ejemplo, agrupación basada en parches).
  • Etapa de prueba: Construye y ejecuta entradas activadoras donde la clase de error las admite. La etapa de demostración valida de manera dinámica la precondición y formula las entradas que activan el error para demostrar la existencia de vulnerabilidad (por ejemplo, ASan en C/C++). 

Tres entidades hacen que esto funcione en la práctica:

  1. Un conjunto de modelos diversos que se gestionan de manera eficaz bajo el nombre en clave MDASH. Ningún modelo es el mejor en todas las etapas. El arnés de escaneo agéntico multimodelo ejecuta un panel configurable de modelos. Eso incluye los modelos SOTA como razonador pesado, los modelos destilados como debatiente rentable para pases de alto volumen, y un segundo modelo SOTA separado como contrapunto independiente. El desacuerdo entre modelos es en sí mismo una señal: cuando un auditor señala algo como sospechoso y el debatiente no puede refutarlo, la credibilidad posterior de ese hallazgo aumenta.
  2. Agentes especializados. Un auditor no razona como un debatiente, que no razona como un proveedor. Cada etapa del oleoducto tiene su propio papel, régimen de puntuación, herramientas y criterios de parada. No esperamos que un solo prompt lo haga todo; no esperamos que un solo agente reconozca, valide y explote un error en una sola pasada. El nombre calve MDASH cuenta con más de 100 agentes especializados, construidos mediante una investigación profunda con vulnerabilidades y exposiciones comunes (CVEs, por sus siglas en inglés) pasadas y sus parches, para trabajar de manera independiente para descubrir los errores, y sus resultados de auditoría se recopilarán en un solo informe.
  3. Pipeline de extremo a extremo con plugins extensibles. El oleoducto es opinativo, pero no está cerrado. Los plugins permiten a expertos en el dominio inyectar contextos que los modelos fundacionales no pueden ver por sí solos: convenciones de llamada al kernel, reglas IRP, invariantes de bloqueo, límites de confianza IPC, máquinas de estados de códecs. El plugin de demostración CLFS que describimos a continuación es un ejemplo de ello: un plugin de dominio que sabe cómo construir un archivo de registro de disparo dado un hallazgo candidato. Por ejemplo, también se puede aprovechar el razonamiento extendido por equipos de Windows con base de datos de análisis de código personalizado, o la base de datos CodeQL. 

La ventaja de esta arquitectura es la portabilidad entre generaciones de modelos. Las etapas de segmentación, validación, deduplicación y demostración de la tubería son agnósticas al modelo por construcción, lo que permite que el harness obtenga lo mejor de lo que cualquier modelo pueda ofrecer. Cuando un modelo nuevo aterriza, probarlo A/B contra el panel actual es un cambio de configuración. Cuando un modelo mejora, la inversión previa del cliente —archivos de alcance, plugins, configuraciones, calibraciones— se mantiene, lo que permite a los clientes navegar por la frontera del valor de seguridad.  

Uso del nombre en clave MDASH para investigación en seguridad

Para evaluar las capacidades de detección de errores del arnés de escaneo agéntico multimodelo, primero necesitan conectar con código que nunca ha sido visto por un modelo. Esto elimina la posibilidad de que un modelo «haya aprendido las respuestas del examen.» Escaneamos StorageDrive, un controlador de dispositivo de muestra utilizado en entrevistas de Microsoft para investigadores de seguridad ofensiva. El controlador contiene 21 vulnerabilidades inyectadas de manera deliberada, incluido el uso de los usuarios posteriores (UAF, por sus siglas en inglés) del kernel, problemas de gestión de enteros, lagunas en la validación de IOCTL y errores de bloqueo. Como StorageDrive es una base de código privada que nunca se ha publicado, podemos asumir con seguridad que no se incluyó en los datos de entrenamiento de los modelos de lenguaje modernos.

Ejecutamos el arnés en StorageDrive a través de su configuración predeterminada. Los resultados fueron llamativos: las 21 vulnerabilidades de la verdad en el terreno fueron identificadas correctamente, sin ningún falso positivo en esta ejecución.

Esta sencilla prueba muestra que las capacidades de razonamiento y detección de vulnerabilidades de un nombre en clave MDASH pueden aproximarse a las de investigadores ofensivos profesionales.

Luego usamos el arnés para realizar auditorías de seguridad de la parte más crítica de Windows, es decir, la pila de red TCP/IP.

La cohorte del Patch Tuesday del 12.5.2026

En toda la pila de red de Windows y servicios adyacentes, el Patch Tuesday de hoy incluye 16 CVEs que nuestros equipos de ingeniería encontraron usando el nombre en clave MDASH.

Componente Descripción CVE Gravedad Tipo
tcpip.sys Paquetes SSRR IPv4 sin autenticación remota que causan UAF CVE-2026-33827 Crítica Ejecución remota de código
tcpip.sys Deref NULL mediante cabeceras de extensión IPv6 diseñadas CVE-2026-40413 Importante Denegación de Servicio (DoS)
tcpip.sys DoS del núcleo mediante el subflujo de refcount ESP SA CVE-2026-40405 Importante Denegación de Servicio
ikeext.dll Disparadores IKEv2 SA_INIT doble libre LocalSystem RCE CVE-2026-33824 Crítica Ejecución remota de código
tcpip.sys Uso después de la liberación en Ipv4pReassembleDatagram que conduce a la divulgación CVE-2026-40406 Importante Divulgación de información
tcpip.sys Empalme de fragmentos cruzados IPsec mediante reensamblaje CVE-2026-35422 Importante Bypass de características de seguridad
tcpip.sys El RPC local no autenticado de la Plataforma de Filtrado de Windows (WFP) desactiva la caché de nombres CVE-2026-32209 Importante Bypass de características de seguridad
ikeext.dll Fuga de memoria CVE-2026-35424 Importante Denegación de Servicio
telnet.exe Lectura de Out-of-bounds (OOB) en FProcessSB mediante TO_AUTH malformada CVE-2026-35423 Importante Divulgación de información
tcpip.sys El paquete MDL-split IPv6+TCP activa NULL deref CVE-2026-40414 Importante Denegación de Servicio
tcpip.sys El paquete ICMPv6 activa NdisGetDataBuffer NULL
deref
CVE-2026-40401 Importante Denegación de Servicio
tcpip.sys UAF remoto pre-autenticación mediante doble decremento SA CVE-2026-40415 Importante Ejecución remota de código
http.sys Lectura OOB de flujo de control QUIC remoto sin autenticación CVE-2026-33096 Importante Denegación de Servicio
tcpip.sys Desbordamiento de búfer de pila del kernel mediante blob RPC CVE-2026-40399 Importante Elevación del privilegio
netlogon.dll Usuario CLDAP no autenticado= desbordamiento de pila de filtros CVE-2026-41089 Crítica Ejecución remota de código
dnsapi.dll Respuesta DNS UDP elaborada activa la OOB del heap CVE-2026-41096 Crítica Ejecución remota de código

Estas vulnerabilidades son 10 en modo kernel / 6 en modo usuario. La mayoría son accesibles desde un puesto en la red sin credenciales. Vamos a echar un vistazo más de cerca.

Dos inmersiones profundas

Los dos hallazgos a continuación son característicos de lo que puede hacer la nueva pipeline de arnés de escaneo agéntico multimodelo de Microsoft Security que un arnés de un solo modelo no puede. El primero es un uso después de la condición de raza del núcleo que requiere razonar sobre la vida útil del objeto a través de un flujo de control no trivial y tres caminos libres concurrentes independientes. El segundo es un aliasing doble-libre que abarca seis archivos fuente y solo es visible frente al contraste de un sitio gestionado de manera correcta en otra parte de la misma base de código.

CVE-2026-33827—UAF remoto no autenticado en tcpip.sys vía SSRR

La vulnerabilidad surge en la ruta de recepción IPv4 de Windows debido a una gestión inadecuada de la vida útil de un objeto de Path contado por referencias dentro de Ipv4pReceiveRoutingHeader. Tras invocar una consulta de enrutamiento, la función pierde su única referencia propia al Path mediante una operación de desreferencia, pero más tarde reutiliza el mismo puntero al manejar el procesamiento de Ruta Estricta de Fuente y Registro (SSRR, por sus siglas en inglés). Como el recuento de referencia del objeto puede llegar a cero en el punto de lanzamiento anterior, la memoria subyacente puede devolverse a un asignador de reubicación por procesador y reutilizarse posteriormente, convirtiendo el acceso posterior en un clásico uso después de liberar en el contexto del kernel.

Esto ocurre en una ruta activable por red que procesa metadatos de paquetes controlados por el atacante, lo que los hace accesibles a IRQL elevado dentro de la pila de red. El problema central se agrava por el modelo de concurrencia de la caché de rutas y las rutinas de limpieza asociadas. Una vez que el llamante renuncia a la propiedad, la vivacidad del objeto Path depende por completo de referencias externas que poseen las estructuras de datos compartidas. Múltiples subsistemas independientes —incluido el rastreador de caché de rutas, rutinas explícitas de vaciado y la recolección de basura basada en estado de la interfaz— pueden eliminar de manera simultánea el objeto y eliminar la referencia final. Estas operaciones no están sincronizadas con la ventana de ejecución del lado receptor en esta función, y no se tiene bloqueo para serializar el acceso. Como resultado, en sistemas SMP el objeto liberado puede ser recuperado y sobrescrito antes de la posterior desreferencia, lo que convierte un simple error de ordenación en un uso después de la carrera con viabilidad real de ejecución.

Desde el punto de vista de la explotación, la vulnerabilidad es accesible mediante un atacante remoto y no autenticado mediante paquetes IPv4 elaborados que contienen la opción SSRR y que superan las comprobaciones estándar de validación. La desreferencia del puntero obsoleto puede desencadenar una cadena de acceso a través de la memoria liberada, lo que puede llevar a lecturas controladas y a una primitiva de corrupción más fuerte si la asignación recuperada está influenciada por el atacante. Aunque la explotación requiere ganar una ventana de temporización estrecha y moldear la reutilización de asignadores, la combinación de accesibilidad remota, contexto de ejecución del núcleo y el potencial de manipulación controlada de la memoria eleva el problema a severidad crítica.

Por qué los sistemas de modelo único pasaron por alto este error

Un único arnés de modelo tiende a pasar por alto este error porque la violación de por vida no es visible a nivel local ni siquiera dentro de la misma función. La liberación de la referencia de Path y su posterior reutilización están separadas por un flujo de control no trivial—una rama alternativa, múltiples comprobaciones de validación y varias condiciones de caída temprana—que rompen el patrón sencillo de «soltar y luego usar» en el que confían la mayoría de los detectores. Sin rastrear la propiedad de referencia a través de estos estados intermedios, el modelo ve dos operaciones independientes en lugar de una dependencia temporal. Como resultado, la desreferencia no parece sospechosa de manera aislada, aunque la semántica del conteo de referencia garantiza que el puntero ya podría ser inválido.

La señal decisiva también vive fuera del contexto inmediato. La misma operación lógica aparece en otros lugares con el orden correcto; todos los datos necesarios se derivan del objeto antes de eliminar la referencia. Esto convierte este sitio de llamadas en una inconsistencia en lugar de un uso indebido evidente.

Detectar eso requiere razonamiento entre archivos: identificar patrones análogos, alinear su intención y notar la desviación. Además, la accesibilidad depende de componer múltiples condiciones: una entrada que establezca la bandera SSRR, la configuración por defecto que permite la ruta y subsistemas concurrentes que puedan recuperar el objeto durante la ventana expuesta. Un análisis de disparo único colapsa estos pasos y pierde la interacción entre ellos, mientras que un enfoque escalonado puede conectar la violación de la propiedad, el modelo de concurrencia y el disparador controlado a nivel externo en un camino de explotación coherente.

Divulgación. CVE-2026-33827, actualizado en abril del Patch Tuesday. 

CVE-2026-33824: SA_INIT IKEv2 no autenticado + fragmentación → doble libre → RCE LocalSystem

La vulnerabilidad residía en el servicio IKEEXT, el componente de Windows responsable de la claves IKE y AuthIP para IPsec, y era accesible mediante un atacante remoto y no autenticado a través de UDP/500 en cualquier host configurado como respondedor IKEv2 (RRAS VPN, DirectAccess, infraestructura Always-On VPN o cualquier máquina con una regla de seguridad de conexión entrante). Al enviar un IKE_SA_INIT elaborado que lleve la carga útil de identificador del proveedor «IPsec Security Realm Id» de Microsoft, seguido de un único fragmento IKEv2 (RFC 7383 SKF) que se reensamble de inmediato, un atacante podría desencadenar una asignación determinista de 16 bytes de heap libre de 16 bytes dentro del servicio.

Como IKEEXT se ejecuta como LocalSystem dentro de svchost.exe, esto representa una ruta remota de ejecución de código pre-autenticación hacia uno de los contextos de mayor privilegio del sistema. La causa raíz es un error típico de la propiedad. Cuando IKEEXT reinyecta un fragmento reensamblado a través de su pipeline de recepción, duplica el contexto de recepción del paquete con un memcpy plano. Esta es una copia superficial: clona los bytes del struct pero no las asignaciones del heap a las que apunta. Una de esas asignaciones es el identificador de reino de seguridad proporcionado por el atacante, y tras la copia, tanto el contexto en cola como el SA en Modo Principal en vivo contienen el mismo puntero, y ambos creen ser propietarios.

En el desmontaje, cada uno lo libera, lo que resulta en un doble libre. La secuencia de disparo es de dos paquetes UDP, sin carrera, sin sincronización especial. El servicio IKEEXT funciona como LocalSystem en svchost.exe. Un doble libre de un fragmento de heap de tamaño fijo es una primitiva de corrupción bien entendida en Windows moderno; no publicamos más detalles sobre explotación. La accesibilidad requiere que el host tenga una política de respuesta IKEv2 que acepte las transformaciones propuestas: el error es accesible en RRAS VPN, DirectAccess, Always-On VPN y las reglas de seguridad de conexión IPsec en sus configuraciones típicas, pero un IKEEXT de inicio de servicio sin política de respuesta no es vulnerable. El servicio IKEEXT es DEMAND_START por defecto; cuando existe una política de respondedor, BFE la iniciará en el primer paquete IKE entrante, por lo que el atacante no necesita que IKEEXT ya esté en ejecución.

Por qué los sistemas de modelo único pasaron por alto este error

El error es un error del ciclo de vida de aliasing que abarca seis archivos: ike_A.c (el memcpy defectuoso), ike_B.c (el origen del alias y la primera copia local de la pila), ike_C.c (el free incorrecto), ike_D.c (tanto el patrón correcto como el segundo free), ike_E.c (donde el buffer se llena remotamente) y ike_F.c (el despachador IKEv2 y el sitio de lectura UAF que precede al segundo free). Ningún análisis en un solo archivo lo detecta. La prueba más sólida de que el error es real es la versión correcta del mismo patrón, en la misma base de código, en ike_D.c—inmediatamente después del memcpy del selector. Para detectarlo es necesario que el auditor reconozca el paso que falta en un lugar por referencia al paso actual en otro. Nuestros agentes auditores especializados están diseñados para mostrar justo estas comparaciones; el escenario del debate les obliga a levantarse bajo el contrainterrogatorio.

Divulgación. CVE-2026-33824, actualizado en el martes de parche de abril.   

¿Qué capacidad tiene el nombre en clave MDASH?

La cohorte Patch Tuesday y StorageDrive son señales de futuro. Dos benchmarks retrospectivos nos muestran cómo funciona el sistema en comparación con la verdad real en código real y bien valorado.

Retirada de casos históricos del MSRC. Volvimos a ejecutar el nombre en clave MDASH al comparar instantáneas previas al parche de dos componentes de Windows muy revisados y medimos si los errores históricos confirmados por MSRC habrían sido (re)descubiertos:

  • clfs.sys: 96% de recuerdos en 28 casos del MSRC en un periodo de cinco años.
  • tcpip.sys: Recordación del 100% de 7 casos del MSRC en un periodo de cinco años.

Estos son los datos internos más sólidos que publicamos, y son significativos por una razón específica: la base de datos de casos del MSRC es la verdad sobre lo que explotaron los atacantes reales, qué requirió un Patch Tuesday y a qué tuvieron que reaccionar los defensores. Un sistema que recupera el 96% de un atraso de cinco años de MSRC en un componente del núcleo muy revisado no encuentra debilidades teóricas; lo que importaba era encontrar los errores.

Somos deliberados sobre lo que dicen y no afirman estos números. Son benchmarks retrospectivos de recuerdo en código interno con un recuento de casos finito. Nos dicen que el sistema habría sido útil si hubiera existido en ese momento. No predicen, por sí solos, que los próximos 38 bugs en CLFS se encuentren al mismo ritmo. La señal de futuro es la propia cohorte del Patch Tuesday. 

La extensión de prueba de CLFS como ejemplo práctico. El número de retirada del 96% del CLFS es en parte una historia sobre la fase de prueba. Muchos hallazgos de CLFS parecen interesantes hasta que intentas construir un archivo de registro que desencadene; un hallazgo candidato sin una prueba es, en la práctica, una entrada en un retraso en el triaje. El plugin de demostración específico de CLFS que escribimos sabe cómo construir registros de disparo dado un hallazgo candidato: entiende el diseño del contenedor en disco, la secuencia de validación de bloques y la máquina de estados en memoria lo suficiente como para guiar un camino candidato hacia su sumidero. Para esto es justo para lo que sirve la extensibilidad de plugins: los modelos de fundación no internalicen ni deberían internalizar invariantes específicos del sistema de archivos de Microsoft. El plugin los incrusta, el modelo los usa y el resultado son errores que sobreviven a ser demostrados, no errores que se archivan y olvidan.

CyberGym. En el benchmark público de CyberGym —un corpus de 1.507 tareas reales de reproducción de vulnerabilidades extraídas de 188 proyectos OSS-Fuzz— el arnés de escaneo agéntico multimodelo de Microsoft Security alcanza una tasa de éxito del 88,45%, la puntuación más alta en la clasificación publicada por CyberGym en el momento de escribir esto y cerca de cinco puntos por encima de la siguiente entrada, 83,1%. Este resultado se obtuvo a través de la utilización de modelos disponibles en general. Los sólidos resultados sugieren que el sistema agente circundante contribuye de manera sustancial al rendimiento de extremo a extremo, más allá de la capacidad pura del modelo. Para evaluar, utilizamos la configuración predeterminada de CyberGym (nivel 1), que proporciona el código fuente vulnerable y una descripción de vulnerabilidad a alto nivel. Para integrar el protocolo de evaluación de CyberGym, ampliamos la fase de prueba de los arneses para enviar de forma autónoma entradas de prueba de concepto (PoC, por sus siglas en inglés) y recuperar las banderas.

Nuestro análisis de fallos del 12% restante revela dos patrones estructurales notables: entre los hallazgos que se dirigieron al área de código incorrecta, el 82% procedió de tareas con descripciones vagas que también carecían de identificadores de función o archivo, lo que sugiere que la calidad de las descripciones es un factor clave en la precisión del escaneo. También encontramos casos en los que el agente construyó entradas al estilo libFuzzer, pero la tarea de benchmark en realidad requería entradas en formato honggfuzz, lo que llevó a que las reproducciones de otro modo funcionaran en mal estado por desajuste entre el formato del arnés.

Qué significa todo esto

Estamos en un momento de la industria en el que el descubrimiento de vulnerabilidades impulsado por IA deja de ser especulativo y empieza a ser un problema de ingeniería. Los hallazgos de este Patch Tuesday y la revisión retrospectiva de cinco años de casos de CLFS MSRC son evidencia de que los hallazgos de vulnerabilidad a la IA pueden escalar.

Lo que hemos aprendido al construir MDASH y usándolo en Microsoft es más portátil: el arnés hace el trabajo y el modelo es una entrada.

Esto importa de tres maneras concretas.

Primero, el descubrimiento requiere una composición que ningún prompt individual puede lograr. Los bugs de esta publicación —la raza tcpip.sys, la cadena de alias ikeext.dll— no son visibles para un modelo que recibe una sola función. Son visibles para un sistema que puede secuenciar la comparación de patrones entre archivos, el análisis de alcance en varios pasos, el debate entre agentes especializados y la construcción de pruebas de extremo a extremo. Los arneses monomodelo ofrecían menos de lo que los modelos pueden hacer; Agentes individuales demasiado confiables superan lo que los modelos pueden hacer de forma fiable. El arte es el arnés alrededor del modelo, y el arnés es la mayor parte de la ingeniería.

Segundo, la validación es la diferencia entre un hallazgo y una solución. Un escáner que detecta errores candidatos es un escáner que genera un retraso en el triaje. La cohorte del Patch Tuesday es lo que es porque el sistema que la produjo no se queda en el candidato: debate, dedula y demuestra. La validación no es una casilla para verificar; es su propio pipeline de agentes y plugins, y es donde termina la mayor parte de la ingeniería diaria.

Tercero, el sistema absorbe las mejoras del modelo, lo que lo hace duradero. Cuando un nuevo modelo funciona, las etapas de apuntado, debate, deduplicación y demostración no necesitan ser reescritas; cambiamos una configuración y volvemos a hacer una prueba A/B. La inversión del cliente—contexto por proyecto, plugins de escaneo, agentes de demostración—se traslada. Esta es la propiedad arquitectónica que más importa a largo plazo, porque la lotería del modelo va a seguir repitiéndose, y cualquier sistema cuyo valor esté limitado en un modelo concreto es un sistema que hay que reconstruir cada seis meses.

Para los defensores —a cualquier escala, en cualquier código que posean— la implicación es la misma. La pregunta correcta que hay que hacerle a una herramienta de vulnerabilidad de IA no es qué modelo utiliza. Pero, ¿qué hace con el modelo y qué sobrevive cuando llega el siguiente?

Conclusión

El arnés de escaneo agéntico multimodelo de Microsoft Security (nombre en clave MDASH) ayuda a nuestros equipos de ingeniería a mejorar de manera significativa los resultados de seguridad a través del a utilización de modelos de IA disponibles en general—hoy en día. También es probado por los clientes como parte de nuestra limitada vista previa privada. Para unirse a la vista previa privada, por favor suscríbanse aquí.

Muchas gracias a los equipos de Microsoft que trabajan para mejorar la seguridad de nuestros clientes, incluido el equipo de Seguridad de Código Autónomo, la Ingeniería de Investigación y Seguridad Ofensiva de Microsoft (MORSE, por sus siglas en inglés) y la Investigación y Protección contra Ataques de Microsoft Windows (WARP, por sus siglas en inglés), cuyo trabajo llevó a los hallazgos de esta publicación.

Esperamos compartir más novedades con los clientes y la industria mientras trabajamos para hacer del mundo un lugar más seguro para todos.

Regístrense para unirse a la vista previa privada

The post Defensa a velocidad de IA: El nuevo sistema de seguridad agéntica multimodelo de Microsoft encabeza el referente del sector appeared first on Source LATAM.

 

​The post Defensa a velocidad de IA: El nuevo sistema de seguridad agéntica multimodelo de Microsoft encabeza el referente del sector appeared first on Source LATAM.  

Publicado el Deja un comentario

Amazon SageMaker HyperPod now supports EFA-only network interfaces

Amazon SageMaker HyperPod now supports EFA-only network interfaces for cluster instance groups, enabling you to configure dedicated Elastic Fabric Adapter (EFA) devices without the traditional Elastic Network Adapter (ENA) for IP networking. SageMaker HyperPod is a purpose-built infrastructure for AI/ML model development that provides a resilient, high-performance environment with built-in fault tolerance and automated cluster recovery. Now with EFA-only, you can scale AI/ML clusters further without risking IP address exhaustion in your VPC.

When running large-scale distributed training workloads, inter-node communication bandwidth is critical to training performance. SageMaker HyperPod cluster instances support multiple EFA-capable network interfaces, but configuring them with the standard efa interface type attaches both an EFA device and an ENA device (for IP networking) to each interface — even when IP networking is only needed on a subset of interfaces within a node. The efa interface type inescapably consumes IP addresses in your subnet for each ENA device attached, which can lead to IP address exhaustion and limit the number of nodes you can deploy within a single subnet. With this launch, you can now set efa-only when configuring network interfaces for your HyperPod cluster instance groups. This option allocates the network interface exclusively for EFA traffic without attaching an ENA device, allowing you to maximize the number of EFA interfaces dedicated to low-latency, high-throughput inter-node communication. Because EFA-only interfaces do not require IP addresses, you can scale to larger clusters within the same subnets without encountering IP exhaustion. This configuration is particularly beneficial for large-scale distributed training jobs where inter-node communication bandwidth is critical and dedicated IP networking on every interface is not required.

To enable EFA-only, specify efa-only in the ClusterNetworkInterface configuration when creating or updating your HyperPod cluster via the CreateCluster/UpdateCluster API. EFA-only is available in all AWS Regions where Amazon SageMaker HyperPod is supported. To learn more, see ClusterNetworkInterface in the Amazon SageMaker API Reference.

 

​Amazon SageMaker HyperPod now supports EFA-only network interfaces for cluster instance groups, enabling you to configure dedicated Elastic Fabric Adapter (EFA) devices without the traditional Elastic Network Adapter (ENA) for IP networking. SageMaker HyperPod is a purpose-built infrastructure for AI/ML model development that provides a resilient, high-performance environment with built-in fault tolerance and automated cluster recovery. Now with EFA-only, you can scale AI/ML clusters further without risking IP address exhaustion in your VPC.
When running large-scale distributed training workloads, inter-node communication bandwidth is critical to training performance. SageMaker HyperPod cluster instances support multiple EFA-capable network interfaces, but configuring them with the standard efa interface type attaches both an EFA device and an ENA device (for IP networking) to each interface — even when IP networking is only needed on a subset of interfaces within a node. The efa interface type inescapably consumes IP addresses in your subnet for each ENA device attached, which can lead to IP address exhaustion and limit the number of nodes you can deploy within a single subnet. With this launch, you can now set efa-only when configuring network interfaces for your HyperPod cluster instance groups. This option allocates the network interface exclusively for EFA traffic without attaching an ENA device, allowing you to maximize the number of EFA interfaces dedicated to low-latency, high-throughput inter-node communication. Because EFA-only interfaces do not require IP addresses, you can scale to larger clusters within the same subnets without encountering IP exhaustion. This configuration is particularly beneficial for large-scale distributed training jobs where inter-node communication bandwidth is critical and dedicated IP networking on every interface is not required.
To enable EFA-only, specify efa-only in the ClusterNetworkInterface configuration when creating or updating your HyperPod cluster via the CreateCluster/UpdateCluster API. EFA-only is available in all AWS Regions where Amazon SageMaker HyperPod is supported. To learn more, see ClusterNetworkInterface in the Amazon SageMaker API Reference.