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.
AWS Glue 5.1 is now generally available, delivering improved performance, security updates, expanded Apache Iceberg capabilities, and AWS Lake Formation write support for data integration workloads.
AWS Glue is a serverless, scalable data integration service that simplifies discovering, preparing, moving, and integrating data from multiple sources. This release upgrades core engines to Apache Spark 3.5.6, Python 3.11, and Scala 2.12.18, bringing performance and security enhancements. It also updates support for open table format libraries, including Apache Hudi 1.0.2, Apache Iceberg 1.10.0, and Delta Lake 3.3.2.
AWS Glue 5.1 introduces support for Apache Iceberg format version 3.0, adding default column values, deletion vectors for merge-on-read tables, multi-argument transforms, and row lineage tracking. This release also extends AWS Lake Formation fine-grained access control to write operations (both DML and DDL) for Spark DataFrames and Spark SQL. Previously, this capability was limited to read operations only. AWS Glue 5.1 also adds full-table access control in Apache Spark for Apache Hudi and Delta Lake tables, providing more comprehensive security options for your data.
AWS Glue 5.1 is available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Stockholm), Europe (Frankfurt), Europe (Spain), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Malaysia), Asia Pacific (Thailand), Asia Pacific (Mumbai), and South America (São Paulo). Visit the AWS Glue documentation for more information.
AWS Glue 5.1 is now generally available, delivering improved performance, security updates, expanded Apache Iceberg capabilities, and AWS Lake Formation write support for data integration workloads.
AWS Glue is a serverless, scalable data integration service that simplifies discovering, preparing, moving, and integrating data from multiple sources. This release upgrades core engines to Apache Spark 3.5.6, Python 3.11, and Scala 2.12.18, bringing performance and security enhancements. It also updates support for open table format libraries, including Apache Hudi 1.0.2, Apache Iceberg 1.10.0, and Delta Lake 3.3.2.
AWS Glue 5.1 introduces support for Apache Iceberg format version 3.0, adding default column values, deletion vectors for merge-on-read tables, multi-argument transforms, and row lineage tracking. This release also extends AWS Lake Formation fine-grained access control to write operations (both DML and DDL) for Spark DataFrames and Spark SQL. Previously, this capability was limited to read operations only. AWS Glue 5.1 also adds full-table access control in Apache Spark for Apache Hudi and Delta Lake tables, providing more comprehensive security options for your data.
AWS Glue 5.1 is available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Stockholm), Europe (Frankfurt), Europe (Spain), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Malaysia), Asia Pacific (Thailand), Asia Pacific (Mumbai), and South America (São Paulo). Visit the AWS Glue documentation for more information.
AWS Glue now supports zero-ETL for self-managed database sources. Using Glue zero-ETL, you can now setup an integration to replicate data from Oracle, SQL Server, MySQL or PostgreSQL databases which are located on-premises or on AWS EC2 to Redshift with a simple experience that eliminates configuration complexity.
AWS zero-ETL for self-managed database sources will automatically create an integration for an on-going replication of data from your on-premises or EC2 databases through a simple, no-code interface. You can now replicate data from Oracle, SQL Server, MySQL and PostgreSQL databases into Redshift. This feature further reduces users’ operational burden and saves weeks of engineering effort needed to design, build, and test data pipelines to ingest data from self-managed databases to Redshift.
AWS Glue zero-ETL for self-managed database sources are available in the following AWS Regions: US East (Ohio), Europe (Stockholm), Europe (Ireland), Europe (Frankfurt), Canada West (Calgary), US West (Oregon), and Asia Pacific (Seoul) regions. To get started, sign into the AWS Management Console. For more information visit the AWS Glue page or review the AWS Glue zero-ETL documentation.
AWS Glue now supports zero-ETL for self-managed database sources. Using Glue zero-ETL, you can now setup an integration to replicate data from Oracle, SQL Server, MySQL or PostgreSQL databases which are located on-premises or on AWS EC2 to Redshift with a simple experience that eliminates configuration complexity. AWS zero-ETL for self-managed database sources will automatically create an integration for an on-going replication of data from your on-premises or EC2 databases through a simple, no-code interface. You can now replicate data from Oracle, SQL Server, MySQL and PostgreSQL databases into Redshift. This feature further reduces users’ operational burden and saves weeks of engineering effort needed to design, build, and test data pipelines to ingest data from self-managed databases to Redshift. AWS Glue zero-ETL for self-managed database sources are available in the following AWS Regions: US East (Ohio), Europe (Stockholm), Europe (Ireland), Europe (Frankfurt), Canada West (Calgary), US West (Oregon), and Asia Pacific (Seoul) regions. To get started, sign into the AWS Management Console. For more information visit the AWS Glue page or review the AWS Glue zero-ETL documentation.
Amazon CloudWatch now offers configuring deletion protection on your CloudWatch log groups, helping customers safeguard their critical logging data from accidental or unintended deletion. This feature provides an additional layer of protection for logs maintaining audit trails, compliance records, and operational logs that must be preserved.
With deletion protection enabled, administrators can prevent unintended deletions of their most important log groups. Once enabled, log groups cannot be deleted until the protection is explicitly turned off, helping safeguard critical operational, security, and compliance data. This protection is particularly valuable for preserving audit logs and production application logs needed for troubleshooting and analysis.
You can enable deletion protection during log group creation or on existing log groups using the Amazon CloudWatch console, AWS Command Line Interface (AWS CLI), AWS Cloud Development Kit (AWS CDK), and AWS SDKs. For more information, visit the Amazon CloudWatch Logs User Guide..
Amazon CloudWatch now offers configuring deletion protection on your CloudWatch log groups, helping customers safeguard their critical logging data from accidental or unintended deletion. This feature provides an additional layer of protection for logs maintaining audit trails, compliance records, and operational logs that must be preserved. With deletion protection enabled, administrators can prevent unintended deletions of their most important log groups. Once enabled, log groups cannot be deleted until the protection is explicitly turned off, helping safeguard critical operational, security, and compliance data. This protection is particularly valuable for preserving audit logs and production application logs needed for troubleshooting and analysis. Log group deletion protection is available in all AWS commercial Regions. You can enable deletion protection during log group creation or on existing log groups using the Amazon CloudWatch console, AWS Command Line Interface (AWS CLI), AWS Cloud Development Kit (AWS CDK), and AWS SDKs. For more information, visit the Amazon CloudWatch Logs User Guide..
