Amazon Elastic Kubernetes Service (Amazon EKS) now supports Kubernetes version rollback, enabling you to revert to the previous Kubernetes minor version within 7 days if any issues arise after an upgrade. This provides an additional safety net for your upgrade workflow, allowing you to validate the new version under real production conditions and rollback if needed.
You can initiate a rollback using the Amazon EKS console, AWS CLI, or AWS SDKs. Before proceeding, Amazon EKS evaluates your cluster rollback readiness insights that include automated checks covering API compatibility, version skew, add-on compatibility, cluster health, and more. For clusters running EKS Auto Mode, EKS automatically manages the rollback of worker nodes before reverting the control plane, honoring your configured disruption controls.
Amazon EKS version rollback is available at no additional cost in all AWS Regions where Amazon EKS is available. To get started, see version rollback in the Amazon EKS User Guide.
Amazon Elastic Kubernetes Service (Amazon EKS) now supports Kubernetes version rollback, enabling you to revert to the previous Kubernetes minor version within 7 days if any issues arise after an upgrade. This provides an additional safety net for your upgrade workflow, allowing you to validate the new version under real production conditions and rollback if needed. You can initiate a rollback using the Amazon EKS console, AWS CLI, or AWS SDKs. Before proceeding, Amazon EKS evaluates your cluster rollback readiness insights that include automated checks covering API compatibility, version skew, add-on compatibility, cluster health, and more. For clusters running EKS Auto Mode, EKS automatically manages the rollback of worker nodes before reverting the control plane, honoring your configured disruption controls. Amazon EKS version rollback is available at no additional cost in all AWS Regions where Amazon EKS is available. To get started, see version rollback in the Amazon EKS User Guide.
Amazon Managed Service for Prometheus is now FedRAMP High and Department of Defense Cloud Computing Security Requirements Guide (DoD CC SRG) Impact Level (IL) 4 and 5 authorized in the AWS GovCloud (US) Regions.
Federal agencies, public sector organizations, and other enterprises with FedRAMP High and DoD CC SRG IL-4/5 compliance requirements can now use Amazon Managed Service for Prometheus to monitor and alert on their workloads with confidence that it meets the security and compliance standards required for sensitive environments.
Amazon Managed Service for Prometheus is a fully managed, Prometheus-compatible monitoring service that makes it easy to monitor and alert on operational metrics at scale. It automatically scales ingestion and storage for high-cardinality workloads, and integrates with AWS security services for fast, secure access to data.
Amazon Managed Service for Prometheus is now FedRAMP High and Department of Defense Cloud Computing Security Requirements Guide (DoD CC SRG) Impact Level (IL) 4 and 5 authorized in the AWS GovCloud (US) Regions.
Federal agencies, public sector organizations, and other enterprises with FedRAMP High and DoD CC SRG IL-4/5 compliance requirements can now use Amazon Managed Service for Prometheus to monitor and alert on their workloads with confidence that it meets the security and compliance standards required for sensitive environments.
Amazon Managed Service for Prometheus is a fully managed, Prometheus-compatible monitoring service that makes it easy to monitor and alert on operational metrics at scale. It automatically scales ingestion and storage for high-cardinality workloads, and integrates with AWS security services for fast, secure access to data.
For more details about Amazon Managed Service for Prometheus in AWS GovCloud (US), visit the Amazon Managed Service for Prometheus GovCloud documentation or contact your AWS account team for more information. To learn more, visit the Amazon Managed Service for Prometheus product page.
Starting today, AWS Security Agent (now part of AWS Continuum) is available in three additional AWS Regions: Asia Pacific (Mumbai), Asia Pacific (Singapore), and South America (São Paulo). Customers in these Regions can now access core capabilities of Security Agent to proactively secure their applications throughout the development lifecycle.
With this expansion, customers gain access to STRIDE-based threat modeling (preview) that analyzes design documents and source code to surface risks early in the development lifecycle. Full-repo and PR-level code reviews (preview) are available across GitHub, GitLab, GitHub Enterprise Server, Bitbucket, and Confluence, with managed compliance packs and custom security requirements. They can trigger threat modeling, code reviews, and remediation directly from Kiro or Claude Code through the new IDE plugins and MCP integration. On-demand penetration testing delivers validated findings with reproducible attack paths and ready-to-implement fixes, and retesting confirms that applied remediations are effective. Simulated validation remains available only in US East (N. Virginia).
AWS Security Agent scales security expertise across your applications to match development velocity while providing comprehensive security coverage. To learn more, visit the documentation or see our product page.
Starting today, AWS Security Agent (now part of AWS Continuum) is available in three additional AWS Regions: Asia Pacific (Mumbai), Asia Pacific (Singapore), and South America (São Paulo). Customers in these Regions can now access core capabilities of Security Agent to proactively secure their applications throughout the development lifecycle. With this expansion, customers gain access to STRIDE-based threat modeling (preview) that analyzes design documents and source code to surface risks early in the development lifecycle. Full-repo and PR-level code reviews (preview) are available across GitHub, GitLab, GitHub Enterprise Server, Bitbucket, and Confluence, with managed compliance packs and custom security requirements. They can trigger threat modeling, code reviews, and remediation directly from Kiro or Claude Code through the new IDE plugins and MCP integration. On-demand penetration testing delivers validated findings with reproducible attack paths and ready-to-implement fixes, and retesting confirms that applied remediations are effective. Simulated validation remains available only in US East (N. Virginia). AWS Security Agent scales security expertise across your applications to match development velocity while providing comprehensive security coverage. To learn more, visit the documentation or see our product page.
Comprender el cerebro con explicaciones y experimentos impulsados por IA
Resumen
Los modelos basados en LLM pueden predecir con gran precisión las respuestas del cerebro humano al lenguaje. Pero lo que impulsa ese rendimiento es en esencia ilegible: una vasta colección de parámetros aprendidos, no teorías científicas que cualquiera pueda leer.
Las pruebas causales generativas (GCT, por sus siglas en inglés), desarrolladas en colaboración entre Microsoft Research, la Universidad de California en Berkeley, la Universidad de California en San Francisco y la Universidad de Columbia, destilan estos modelos de predicción cerebral en breves explicaciones verbales de a qué responde cada parche de la corteza: frases como «preparación de alimentos» o «nombres de lugares».
GCT entonces cierra el ciclo: un LLM escribe nuevas historias diseñadas para activar una zona cerebral objetivo, los sujetos las escuchan en el escáner y la región solo se ilumina si la explicación es correcta.
En experimentos, la GCT confirmó la selectividad conocida, desglosó regiones vecinas de procesamiento de lugares que durante mucho tiempo se consideraban intercambiables y reveló diminutas «microregiones» prefrontales ajustadas a conceptos específicos como diálogo, tiempos de reloj y mediciones.
El problema de la explicabilidad en la neurociencia del lenguaje
En la última década, los LLMs se han convertido en las herramientas más precisas que tenemos para predecir cómo responde el cerebro humano al lenguaje. Si se alimenta a un LLM la misma historia que una persona escucha en un escáner de fMRI, las representaciones internas del modelo pueden predecir la actividad de parches individuales de la corteza con una fidelidad notable. Pero este éxito tiene una condición: nadie puede leer estos modelos. Son millones de parámetros inescrutables que no pueden traducirse de manera directa en interpretaciones. Un modelo que predice la actividad cerebral nos dice que una región responde al lenguaje, pero no a lo que realmente detecta, ya sea comida, lugares, números o cualquier otra cosa distinta. A medida que los modelos de caja negra se expanden, la brecha entre la predicción y la comprensión se ha convertido en uno de los problemas centrales de la neurociencia computacional.
Convertir las cajas negras en teorías comprobables
En un nuevo artículo aceptado en Nature Neuroscience, científicos de Microsoft Research, en colaboración con científicos de la Universidad de California, Berkeley, la Universidad de California, San Francisco y la Universidad de Columbia, presentan un marco para superar esta crisis de explicabilidad: las pruebas causales generativas (GCT, por sus siglas en inglés). GCT destila los modelos de predicción cerebral en relatos breves y legibles de a qué responde cada parche de la corteza, y luego pone a prueba esas afirmaciones. Un LLM escribe nuevas historias diseñadas para activar una zona cerebral específica, los sujetos las escuchan en el escáner y, si la explicación es correcta, la región objetivo se ilumina. El resultado es un método que traduce modelos predictivos ininterpretables de nuevo en la corriente de la ciencia: hipótesis concisas que pueden confirmarse o refutarse en un experimento de seguimiento. Un LLM escribe nuevas historias diseñadas para activar una zona cerebral específica, los sujetos las escuchan en el escáner y, si la explicación es correcta, la región objetivo se ilumina. El resultado es un método que traduce modelos predictivos ininterpretables de nuevo en la corriente de la ciencia: hipótesis concisas que pueden confirmarse o refutarse en un experimento de seguimiento.
Figura 1. Los dos pasos de la prueba causal generativa (GCT). En el Paso 1, las frases que más impulsan el modelo predictivo de una región cerebral se resumen en un LLM en una breve explicación candidata, como «preparación de alimentos». En el Paso 2, un LLM escribe nuevas historias diseñadas para coincidir con esa explicación, y la respuesta de la región a estas historias de «conducción» se mide en el escáner y se compara con la línea base.
Cómo funciona la GCT
GCT tiene dos pasos: explicación y luego verificación. Para generar una explicación, el método parte de un modelo predictivo para un solo vóxel o región e identifica las frases cortas que más impulsan su respuesta predicha. Un LLM resume entonces esas palabras en una explicación verbal concisa, a menudo una sola frase como «preparación de alimentos» o «nombres de lugares».
La crucial segunda etapa cierra el ciclo. Para generar confianza en la explicación, GCT utiliza un LLM para escribir nuevas historias en las que cada párrafo está construido de manera cuidadosa, para guiar una región cerebral según su explicación. Tres sujetos volvieron al escáner para leer estas historias sintéticas. Si la actividad de una región respecto a sus párrafos «impulsivos» era mucho mayor que respecto al texto base, la explicación superaba una prueba causal genuina, no solo correlacional.
En los tres temas, el enfoque central se mantuvo: las historias sintéticas hicieron que sus regiones objetivo superaran la línea base, lo que confirma que las breves explicaciones de GCT capturan algo a lo que la corteza responde de manera genuina. Las explicaciones también eran más fiables donde los modelos subyacentes de predicción cerebral eran más sólidos (cuanto más estable era el modelo, más fiable podía confirmarse su explicación en el escáner). Con el método validado en regiones cuya selectividad ya era conocida, los investigadores aplicaron la GCT a preguntas más difíciles.
Figura 2. La respuesta cerebral se relaciona con historias de GCT para diferentes temas. Algunos mapas recuperan hallazgos bien establecidos: la explicación «Ubicaciones» produce respuestas fuertes en las áreas de lugares RSC, OPA y PPA. Otros confirman de forma independiente hipótesis más recientes: la «preparación de alimentos» activa una región en la corteza occipital ventral cerca de la zona fusiforme de la cara (FFA, por sus siglas en inglés). Algunas, como («Birthdays»), no se corresponden de manera clara con ningún resultado conocido, lo que apunta a direcciones para futuras investigaciones.
La GCT también resultó con la suficiente agudez como para disipar ambigüedades de larga data. Tres regiones vecinas implicadas en los lugares de procesamiento han sido a menudo tratadas como similares a nivel funcional: la corteza retroesplénica (CSR, por sus siglas en inglés), el área del lugar parahipocampal (PPA, por sus siglas en inglés) y el área del lugar occipital (OPA, por sus siglas en inglés). Al principio, las historias escritas para una región también activaban las otras. Pero al generar estímulos diferenciales (historias diseñadas para encender una región mientras mantienen a sus vecinas en silencio), GCT diferenció a los tres. Por ejemplo, RSC responde con mayor fuerza a nombres de ubicación propios, como Tokio o Connecticut, en lugar de ubicación general. Este es el tipo de teoría matizada y específica de región que un modelo predictivo en bruto no puede proporcionar por sí solo.
Más allá de las regiones conocidas, los autores descubrieron nuevas «microregiones» prefrontales. Al escanear una cuadrícula de ubicaciones candidatas y mantener solo las más estables, GCT sacó a la luz estas regiones no cartografiadas de manera previa, ajustadas a conceptos específicos: una selectiva para el diálogo entre personas (palabras como «dijo» o «contó»), otra para menciones de tiempos de reloj («una en punto») y otra para mediciones numéricas («50 pies»). Son distinciones que nadie había buscado; surgieron porque el método podía proponer una hipótesis y ponerla a prueba de inmediato.
Implicaciones y mirar hacia adelante
La importancia de la GCT va mucho más allá de la neurociencia. Los investigadores se enfrentan cada vez más al mismo dilema: un modelo que predice de manera hermosa pero no explica nada. GCT muestra que un modelo basado en datos no tiene por qué ser el fin de la investigación; puede destilarse en una teoría legible y comprobable a nivel experimental, y esa teoría puede compararse con la realidad a través de la generación de nuevos experimentos bajo demanda.
En neurociencia en específico, GCT apunta a una forma más rápida y rica en hipótesis de mapear la corteza—una en la que un sistema de IA propone lo que una región cerebral podría codificar y un experimento en bucle cerrado lo confirma o rechaza dentro de un solo estudio. La misma filosofía de generar y verificar podría extenderse a otros ámbitos donde los potentes modelos predictivos han superado nuestra capacidad para entenderlos. La lección más amplia es esperanzadora: el auge de los modelos de caja negra en la ciencia no significa por necesidad el retroceso de la teoría legible para humanos. Con el marco adecuado, ambos pueden avanzar juntos.
Agradecimientos
Este trabajo fue una colaboración entre Microsoft Research, UC Berkeley (Alex Huth, Bin Yu, Sihang Guo y Aliyah Hsu), la Universidad de Columbia (RJ Antonello, co-líder) y UCSF (Shailee Jain). También agradecemos a los participantes del estudio y a la comunidad más amplia de neurociencia del lenguaje cuyas herramientas y conjuntos de datos hicieron posible esta investigación.
Lean el artículo: «Pruebas causales generativas para unir modelos basados en datos y teorías científicas en neurociencia del lenguaje», aceptado en Nature Neuroscience y el código en Github.
Amazon CloudWatch Logs now enriches log events with resource tags, making it easier to filter, search, and analyze logs by the metadata that matters most to your organization, such as team ownership, environment, cost center, or application name, without requiring changes to your logging instrumentation.
With tag enrichment, Amazon CloudWatch Logs adds resource tags directly to your log events at ingestion time. You can immediately use tags in log queries, to scope your analysis without building custom pipelines or manually adding context to your application logs. For example, you can quickly filter all logs from production resources owned by a specific team, or filter by cost center during an incident investigation.
Tag enrichment for logs is available in all commercial AWS Regions except Middle East (UAE), Middle East (Bahrain), and Israel (Tel Aviv). To get started, enable resource tags on telemetry in the Amazon CloudWatch Settings, or through the AWS Command Line Interface (AWS CLI), and AWS SDKs to use your existing AWS resource tags to enrich your log events. Tag enrichment is available for no additional cost. Learn more on the Amazon CloudWatch documentation page.
Amazon CloudWatch Logs now enriches log events with resource tags, making it easier to filter, search, and analyze logs by the metadata that matters most to your organization, such as team ownership, environment, cost center, or application name, without requiring changes to your logging instrumentation.
With tag enrichment, Amazon CloudWatch Logs adds resource tags directly to your log events at ingestion time. You can immediately use tags in log queries, to scope your analysis without building custom pipelines or manually adding context to your application logs. For example, you can quickly filter all logs from production resources owned by a specific team, or filter by cost center during an incident investigation.
Tag enrichment for logs is available in all commercial AWS Regions except Middle East (UAE), Middle East (Bahrain), and Israel (Tel Aviv). To get started, enable resource tags on telemetry in the Amazon CloudWatch Settings, or through the AWS Command Line Interface (AWS CLI), and AWS SDKs to use your existing AWS resource tags to enrich your log events. Tag enrichment is available for no additional cost. Learn more on the Amazon CloudWatch documentation page.
AWS CloudFormation and CDK express mode reduces deployment time by up to 4x for developers and AI agents building infrastructure, based on internal benchmarks. Express mode completes stack operations when CloudFormation confirms resource configuration is applied, rather than waiting for extended stabilization checks such as traffic readiness, region propagation, and resource cleanup. This enables faster iteration cycles for developers and AI agents building infrastructure.
When iterating on infrastructure in development environments, developers and AI agents need faster iteration cycles to build infrastructure incrementally. Previously, every deployment waited for full resource stabilization regardless of whether the workflow required it. For example, creating a CloudFront distribution required waiting 5-10 minutes for propagation to all edge locations before the deployment completed, even when the developer only needed the distribution domain name to continue. With express mode, deployments complete in seconds once configuration is applied, and propagation continues in the background. CloudFormation still processes resources in dependency order and handles dependent resource failures within the same stack. Express mode disables rollback by default, enabling immediate fix-and-retry without waiting for rollback operations.
To get started, set –deployment-config ‘{«mode»: «EXPRESS»}’ when creating, updating, and deleting stacks or creating a change set through the AWS CLI, AWS SDKs, or the AWS Management Console. For AWS CDK users, activate express mode with cdk deploy –express. No template changes are required. Express mode works with all existing CloudFormation templates, and nested stacks. Visit the CloudFormation Express mode documentation to learn more.
This feature is available in all AWS Regions where CloudFormation is supported. Refer to the AWS Region table for service availability details.
AWS CloudFormation and CDK express mode reduces deployment time by up to 4x for developers and AI agents building infrastructure, based on internal benchmarks. Express mode completes stack operations when CloudFormation confirms resource configuration is applied, rather than waiting for extended stabilization checks such as traffic readiness, region propagation, and resource cleanup. This enables faster iteration cycles for developers and AI agents building infrastructure. When iterating on infrastructure in development environments, developers and AI agents need faster iteration cycles to build infrastructure incrementally. Previously, every deployment waited for full resource stabilization regardless of whether the workflow required it. For example, creating a CloudFront distribution required waiting 5-10 minutes for propagation to all edge locations before the deployment completed, even when the developer only needed the distribution domain name to continue. With express mode, deployments complete in seconds once configuration is applied, and propagation continues in the background. CloudFormation still processes resources in dependency order and handles dependent resource failures within the same stack. Express mode disables rollback by default, enabling immediate fix-and-retry without waiting for rollback operations. To get started, set –deployment-config ‘{«mode»: «EXPRESS»}’ when creating, updating, and deleting stacks or creating a change set through the AWS CLI, AWS SDKs, or the AWS Management Console. For AWS CDK users, activate express mode with cdk deploy –express. No template changes are required. Express mode works with all existing CloudFormation templates, and nested stacks. Visit the CloudFormation Express mode documentation to learn more. This feature is available in all AWS Regions where CloudFormation is supported. Refer to the AWS Region table for service availability details.
AWS CloudFormation customers can now get immediate feedback on deployment errors in seconds, eliminating the need to wait through a full provision-and-rollback cycle to discover preventable failures. CloudFormation now runs pre-deployment validation on Create Stack and Update Stack operations, catching common deployment errors before resource provisioning begins. This accelerates development velocity across all deployment workflows, from manual iteration to CI/CD pipelines to AI agents provisioning infrastructure.
Previously, pre-deployment validation was available during change set creation, covering property syntax errors, resource name conflicts, and S3 bucket emptiness constraints. With this release, the same validations now run automatically on Create Stack and Update Stack operations. Additionally, three new validation checks are now available as warnings during change set creation. Service quota limits validation warns when creating resources would exceed your account’s service quotas. AWS Config Recorder conflict detection warns when your template adds Config rules to an account that does not have Config recording enabled, or defines a Config Recorder in an account where one is already active. ECR repository delete readiness validation warns when an ECR repository targeted for deletion still contains images. When validation detects an issue, you can view errors using the DescribeEvents API with the operation ID, or in the CloudFormation console by navigating to your stack’s Events tab and clicking the operation ID (or the link in the banner or status reason column) to open the Operation view page, which opens directly on the Deployment validations tab. Each error includes the logical resource ID and property path, so you can pinpoint and fix the problem before any resources are provisioned. In CDK, both cdk deploy and cdk validate surface validation results with construct-level tracing in a unified report, so AI agents and automation tools can parse structured responses and self-correct immediately.
Pre-deployment validation is enabled by default on all stack operations with no configuration required. If you need to skip validation for a specific operation, use the new DisableValidation parameter on CreateStack, UpdateStack and CreateChangeSet API calls, or the –disable-validation flag in the CLI. Visit the Validate stack deployments User Guide to learn more.
This feature is available in all AWS Regions where CloudFormation is supported, excluding China. Refer to the AWS Region table for service availability details.
AWS CloudFormation customers can now get immediate feedback on deployment errors in seconds, eliminating the need to wait through a full provision-and-rollback cycle to discover preventable failures. CloudFormation now runs pre-deployment validation on Create Stack and Update Stack operations, catching common deployment errors before resource provisioning begins. This accelerates development velocity across all deployment workflows, from manual iteration to CI/CD pipelines to AI agents provisioning infrastructure. Previously, pre-deployment validation was available during change set creation, covering property syntax errors, resource name conflicts, and S3 bucket emptiness constraints. With this release, the same validations now run automatically on Create Stack and Update Stack operations. Additionally, three new validation checks are now available as warnings during change set creation. Service quota limits validation warns when creating resources would exceed your account’s service quotas. AWS Config Recorder conflict detection warns when your template adds Config rules to an account that does not have Config recording enabled, or defines a Config Recorder in an account where one is already active. ECR repository delete readiness validation warns when an ECR repository targeted for deletion still contains images. When validation detects an issue, you can view errors using the DescribeEvents API with the operation ID, or in the CloudFormation console by navigating to your stack’s Events tab and clicking the operation ID (or the link in the banner or status reason column) to open the Operation view page, which opens directly on the Deployment validations tab. Each error includes the logical resource ID and property path, so you can pinpoint and fix the problem before any resources are provisioned. In CDK, both cdk deploy and cdk validate surface validation results with construct-level tracing in a unified report, so AI agents and automation tools can parse structured responses and self-correct immediately. Pre-deployment validation is enabled by default on all stack operations with no configuration required. If you need to skip validation for a specific operation, use the new DisableValidation parameter on CreateStack, UpdateStack and CreateChangeSet API calls, or the –disable-validation flag in the CLI. Visit the Validate stack deployments User Guide to learn more. This feature is available in all AWS Regions where CloudFormation is supported, excluding China. Refer to the AWS Region table for service availability details.
Amazon Relational Database Service (Amazon RDS) now offers dynamic connection scaling for IAM database authentication, allowing connection rates to scale with instance resources.
IAM database authentication performance now scales with available instance resources, enabling enterprise workloads to leverage IAM authentication for high-volume connection patterns. The number of new IAM authentication requests your instance can handle depends on available resources and workload characteristics. For optimal performance, we recommend reusing IAM user or IAM assumed role principals to generate authentication tokens, or reusing the authentication tokens themselves, when possible.
This update is available in all AWS Regions, including the AWS GovCloud (US) Regions, where IAM database authentication is supported for Amazon Aurora and Amazon RDS database engines including PostgreSQL, MySQL, and MariaDB. To learn more, visit the IAM database authentication documentation.
Amazon Relational Database Service (Amazon RDS) now offers dynamic connection scaling for IAM database authentication, allowing connection rates to scale with instance resources. IAM database authentication performance now scales with available instance resources, enabling enterprise workloads to leverage IAM authentication for high-volume connection patterns. The number of new IAM authentication requests your instance can handle depends on available resources and workload characteristics. For optimal performance, we recommend reusing IAM user or IAM assumed role principals to generate authentication tokens, or reusing the authentication tokens themselves, when possible. This update is available in all AWS Regions, including the AWS GovCloud (US) Regions, where IAM database authentication is supported for Amazon Aurora and Amazon RDS database engines including PostgreSQL, MySQL, and MariaDB. To learn more, visit the IAM database authentication documentation.
AWS Parallel Computing Service (PCS) now supports managed in-place Slurm version upgrades for existing clusters. You can move your clusters up to three Slurm major versions ahead with no disruption to running jobs.
To upgrade, update your Cluster configuration with your target Slurm version using the AWS Management Console, AWS CLI, or UpdateCluster API. PCS handles the upgrade of all managed Slurm components — the controller, accounting database, and REST API. Running jobs continue uninterrupted during the upgrade, queued jobs resume once the operation completes, and any accounting data is preserved in the database. You can then update your compute nodes to the new Slurm version at your convenience. Refer to the PCS User Guide for more information on the steps to follow and considerations to review based on your cluster configuration.
AWS PCS is a managed service that simplifies running and scaling HPC workloads on AWS using Slurm. You can build complete, elastic environments that integrate compute, storage, networking, and visualization tools, while the service handles cluster operations with managed updates and built-in observability features.
AWS Parallel Computing Service (PCS) now supports managed in-place Slurm version upgrades for existing clusters. You can move your clusters up to three Slurm major versions ahead with no disruption to running jobs. To upgrade, update your Cluster configuration with your target Slurm version using the AWS Management Console, AWS CLI, or UpdateCluster API. PCS handles the upgrade of all managed Slurm components — the controller, accounting database, and REST API. Running jobs continue uninterrupted during the upgrade, queued jobs resume once the operation completes, and any accounting data is preserved in the database. You can then update your compute nodes to the new Slurm version at your convenience. Refer to the PCS User Guide for more information on the steps to follow and considerations to review based on your cluster configuration. AWS PCS is a managed service that simplifies running and scaling HPC workloads on AWS using Slurm. You can build complete, elastic environments that integrate compute, storage, networking, and visualization tools, while the service handles cluster operations with managed updates and built-in observability features. This feature is available in all AWS Regions where PCS is available. To get started, see the PCS User Guide.
Amazon ElastiCache now supports T4g node types in the following AWS Regions: Africa (Cape Town), Asia Pacific (Jakarta), Asia Pacific (Osaka), AWS GovCloud (US-East), and AWS GovCloud (US-West). T4g nodes are powered by AWS Graviton2 processors and provide a baseline level of CPU performance with the ability to burst CPU usage at any time, making them ideal for applications that experience temporary spikes in usage.
For complete information on pricing and regional availability, please refer to the Amazon ElastiCache pricing page. To get started, create a new cluster or modify an existing cluster using the AWS Management Console, AWS CLI, or API. To learn more, see Supported node types in the Amazon ElastiCache User Guide.
Amazon ElastiCache now supports T4g node types in the following AWS Regions: Africa (Cape Town), Asia Pacific (Jakarta), Asia Pacific (Osaka), AWS GovCloud (US-East), and AWS GovCloud (US-West). T4g nodes are powered by AWS Graviton2 processors and provide a baseline level of CPU performance with the ability to burst CPU usage at any time, making them ideal for applications that experience temporary spikes in usage.
For complete information on pricing and regional availability, please refer to the Amazon ElastiCache pricing page. To get started, create a new cluster or modify an existing cluster using the AWS Management Console, AWS CLI, or API. To learn more, see Supported node types in the Amazon ElastiCache User Guide.
