On October 22, 2026 Amazon announced quarterly security and critical updates for Amazon Corretto Long-Term Supported (LTS) versions of OpenJDK. Corretto 27.0.1.0.10, 25.0.5.0.9, 21.0.13.0.10, 17.0.21.0.10, 11.0.33.0.9, and 8u512 are now available for download. Amazon Corretto is a no-cost, multi-platform, production-ready distribution of OpenJDK.
Visit the Corretto home page to download Corretto 27, Corretto 25, Corretto 21, Corretto 17, Corretto 11, or Corretto 8. You can also get the updates on your Linux system by configuring a Corretto Apt, Yum, or Apk repo.
On October 22, 2026 Amazon announced quarterly security and critical updates for Amazon Corretto Long-Term Supported (LTS) versions of OpenJDK. Corretto 27.0.1.0.10, 25.0.5.0.9, 21.0.13.0.10, 17.0.21.0.10, 11.0.33.0.9, and 8u512 are now available for download. Amazon Corretto is a no-cost, multi-platform, production-ready distribution of OpenJDK.
Visit the Corretto home page to download Corretto 27, Corretto 25, Corretto 21, Corretto 17, Corretto 11, or Corretto 8. You can also get the updates on your Linux system by configuring a Corretto Apt, Yum, or Apk repo.
Feedback is welcomed!
Amazon EMR announces a reduction of 30 percent in the EMR charge added to EKS when running EMR on EKS. This price decrease applies to both the per-vCPU-hour charge and the per-GB-hour charge, while the underlying Amazon EKS charges remain unchanged. All EMR workloads running on the EKS deployment option benefit from this change. Now, you can run Apache Spark workloads on Amazon Elastic Kubernetes Service (EKS) at a lower cost, and the new price automatically applies to your EMR on EKS workloads with no additional action required on your end.
The 30% reduction in EMR on EKS pricing is available in all AWS Regions where Amazon EMR on EKS is available. To learn more about EMR on EKS, visit the Amazon EMR on EKS documentation and the Amazon EMR pricing page.
Amazon EMR announces a reduction of 30 percent in the EMR charge added to EKS when running EMR on EKS. This price decrease applies to both the per-vCPU-hour charge and the per-GB-hour charge, while the underlying Amazon EKS charges remain unchanged. All EMR workloads running on the EKS deployment option benefit from this change. Now, you can run Apache Spark workloads on Amazon Elastic Kubernetes Service (EKS) at a lower cost, and the new price automatically applies to your EMR on EKS workloads with no additional action required on your end.
The 30% reduction in EMR on EKS pricing is available in all AWS Regions where Amazon EMR on EKS is available. To learn more about EMR on EKS, visit the Amazon EMR on EKS documentation and the Amazon EMR pricing page.
Amazon Managed Workflows for Apache Airflow (Amazon MWAA) Provisioned environments are now available in the Mexico (Central) Region (mx-central-1). Amazon MWAA Serverless was already available in this Region, and customers can now also use Amazon MWAA Provisioned environments for their Apache Airflow workflows. Amazon MWAA is a managed orchestration service for Apache Airflow that makes it easier for customers to set up and operate end-to-end data pipelines in the cloud at scale.
Customers can create Amazon MWAA Provisioned environments using the AWS Management Console, the AWS CLI, the AWS SDKs, or AWS CloudFormation. Customers in Mexico (Central) can now run their Amazon MWAA Provisioned workflows closer to their data sources and end users, reducing latency and helping meet data residency requirements. To learn more, visit the Amazon MWAA product page and the Amazon MWAA supported Regions documentation.
Amazon Managed Workflows for Apache Airflow (Amazon MWAA) Provisioned environments are now available in the Mexico (Central) Region (mx-central-1). Amazon MWAA Serverless was already available in this Region, and customers can now also use Amazon MWAA Provisioned environments for their Apache Airflow workflows. Amazon MWAA is a managed orchestration service for Apache Airflow that makes it easier for customers to set up and operate end-to-end data pipelines in the cloud at scale.
Customers can create Amazon MWAA Provisioned environments using the AWS Management Console, the AWS CLI, the AWS SDKs, or AWS CloudFormation. Customers in Mexico (Central) can now run their Amazon MWAA Provisioned workflows closer to their data sources and end users, reducing latency and helping meet data residency requirements. To learn more, visit the Amazon MWAA product page and the Amazon MWAA supported Regions documentation.
AWS Transit Gateway and AWS Cloud WAN now provide managed one-to-one network address translation (NAT) directly on their attachments, through integration with Regional Private NAT Gateway. This enables customers to connect private networks that share the same IP address ranges without renumbering either network, deploying a NAT appliance, or writing return-traffic rules.
Networks with overlapping Classless Inter-Domain Routing (CIDR) blocks have long been unable to communicate, a common blocker during mergers and acquisitions, when connecting partner networks over AWS Site-to-Site VPN, in multicloud connectivity, and when independently provisioned VPCs need to interconnect. Using this capability, customers can define address-translation rules on a AWS Transit Gateway or AWS Cloud WAN attachment, specifying the private IP range each source CIDR translates to, across Amazon VPC, AWS Site-to-Site VPN, AWS Direct Connect, and SD-WAN appliances connected through Transit Gateway Connect. Both services apply translation automatically in both directions, with no separate return-traffic rule and no NAT appliance to deploy. AWS operates, scales, and manages the NAT capability as part of the attachment. For example, if a customer acquires a business and both VPCs use 10.0.0.0/16, they translate one VPC’s addresses to a non-overlapping range on its attachment and connect the networks immediately. Customers set it up in minutes using the AWS Management Console, AWS Command Line Interface (AWS CLI), AWS SDKs, and AWS CloudFormation, and monitor translated traffic through Amazon CloudWatch metrics and Amazon EventBridge events.
AWS Transit Gateway and AWS Cloud WAN now provide managed one-to-one network address translation (NAT) directly on their attachments, through integration with Regional Private NAT Gateway. This enables customers to connect private networks that share the same IP address ranges without renumbering either network, deploying a NAT appliance, or writing return-traffic rules.
Networks with overlapping Classless Inter-Domain Routing (CIDR) blocks have long been unable to communicate, a common blocker during mergers and acquisitions, when connecting partner networks over AWS Site-to-Site VPN, in multicloud connectivity, and when independently provisioned VPCs need to interconnect. Using this capability, customers can define address-translation rules on a AWS Transit Gateway or AWS Cloud WAN attachment, specifying the private IP range each source CIDR translates to, across Amazon VPC, AWS Site-to-Site VPN, AWS Direct Connect, and SD-WAN appliances connected through Transit Gateway Connect. Both services apply translation automatically in both directions, with no separate return-traffic rule and no NAT appliance to deploy. AWS operates, scales, and manages the NAT capability as part of the attachment. For example, if a customer acquires a business and both VPCs use 10.0.0.0/16, they translate one VPC’s addresses to a non-overlapping range on its attachment and connect the networks immediately. Customers set it up in minutes using the AWS Management Console, AWS Command Line Interface (AWS CLI), AWS SDKs, and AWS CloudFormation, and monitor translated traffic through Amazon CloudWatch metrics and Amazon EventBridge events.
AWS Transit Gateway and AWS Cloud WAN offer 1:1 NAT through Regional Private NAT Gateway in all AWS commercial regions where they operate. For full pricing details, see Amazon VPC pricing . To learn more, see the AWS Transit Gateway and AWS Cloud WAN product pages, and the AWS Transit Gateway and AWS Cloud WAN documentation.
Today, AWS announces the general availability of AWS Continuum for code vulnerabilities. Continuum for code vulnerabilities discovers, validates, prioritizes, and remediates code vulnerabilities at machine speed.
Continuum for code vulnerabilities builds a context graph from your AWS environment, including resource topology, identity relationships, and network reachability. It knows which resources are part of your application, and which findings carry real business risk. It ingests your existing vulnerability findings, scans your code, and then confirms which findings are exploitable by testing them in an isolated sandbox. The findings are prioritized by business impact. And finally, it provides remediation patches as pull requests directly to developer workflows with exploitability proof and blast radius assessment attached.
Continuum for code vulnerabilities picks the right AI model for each task. Continuum starts in Learn mode where it proposes the remediation fixes that you approve. When it builds sufficient trust in its precision, you switch to the Enforce mode and let it act autonomous within the guardrails you set.
AWS Continuum works alongside your existing AWS security services, including Amazon GuardDuty and AWS Security Hub. For more information about the AWS Regions where AWS Continuum is available, see the AWS Region table. To learn more, see the AWS Continuum product page.
Today, AWS announces the general availability of AWS Continuum for code vulnerabilities. Continuum for code vulnerabilities discovers, validates, prioritizes, and remediates code vulnerabilities at machine speed.
Continuum for code vulnerabilities builds a context graph from your AWS environment, including resource topology, identity relationships, and network reachability. It knows which resources are part of your application, and which findings carry real business risk. It ingests your existing vulnerability findings, scans your code, and then confirms which findings are exploitable by testing them in an isolated sandbox. The findings are prioritized by business impact. And finally, it provides remediation patches as pull requests directly to developer workflows with exploitability proof and blast radius assessment attached.
Continuum for code vulnerabilities picks the right AI model for each task. Continuum starts in Learn mode where it proposes the remediation fixes that you approve. When it builds sufficient trust in its precision, you switch to the Enforce mode and let it act autonomous within the guardrails you set.
AWS Continuum works alongside your existing AWS security services, including Amazon GuardDuty and AWS Security Hub. For more information about the AWS Regions where AWS Continuum is available, see the AWS Region table. To learn more, see the AWS Continuum product page.
Amazon Connect Customer Profiles now allows administrators to customize which customer data that agents see in the agent workspace, and how it is displayed, using layouts they build in Profile Explorer. Customer Profiles provides agents with a real-time, unified view of each customer during interactions, combining contact history with customer data from multiple sources. Agents who handle different kinds of requests need different customer data in front of them.
Within Profile Explorer, administrators can create and save each layout of Customer Profiles widgets, such as contact history, contact information, and lifetime value calculated attributes, and assign it to agents in place of the legacy Customer Profiles view. For example, an airline baggage claims agent sees contact history, active flights, and baggage ticket information, while a loyalty agent sees loyalty status, preferences, and upcoming flights. Layouts can also include an AI Profile Summary that focuses the agent’s attention on key customer insights by summarizing the customer profile.
You can use Profile Explorer in the following AWS Regions: US East (N. Virginia), US West (Oregon), Africa (Cape Town), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), Europe (Frankfurt), and Europe (London).
To learn more about Profile Explorer, see Profile Explorer in the Amazon Connect Customer administrator guide.
Amazon Connect Customer Profiles now allows administrators to customize which customer data that agents see in the agent workspace, and how it is displayed, using layouts they build in Profile Explorer. Customer Profiles provides agents with a real-time, unified view of each customer during interactions, combining contact history with customer data from multiple sources. Agents who handle different kinds of requests need different customer data in front of them. Within Profile Explorer, administrators can create and save each layout of Customer Profiles widgets, such as contact history, contact information, and lifetime value calculated attributes, and assign it to agents in place of the legacy Customer Profiles view. For example, an airline baggage claims agent sees contact history, active flights, and baggage ticket information, while a loyalty agent sees loyalty status, preferences, and upcoming flights. Layouts can also include an AI Profile Summary that focuses the agent’s attention on key customer insights by summarizing the customer profile. You can use Profile Explorer in the following AWS Regions: US East (N. Virginia), US West (Oregon), Africa (Cape Town), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), Europe (Frankfurt), and Europe (London). To learn more about Profile Explorer, see Profile Explorer in the Amazon Connect Customer administrator guide.
Starting today, Amazon OpenSearch Serverless reduces the default refresh interval to 5 seconds for both search and vector collections. The refresh interval controls how quickly newly ingested documents become available for search. By lowering the default from 10 seconds to 5 seconds, newly written data becomes searchable faster, giving applications quicker read-after-write visibility automatically, with no configuration changes and no action required on your part.
This improvement applies to the next generation of Amazon OpenSearch Serverless and takes effect by default on both search and vector collections. Faster refresh is valuable for workloads that continuously ingest data and need near real-time retrieval, including full-text search over frequently updated content as well as vector use cases such as retrieval-augmented generation (RAG), semantic search, and recommendation and personalization systems. This means applications and AI agents can retrieve and act on the most recently ingested data sooner, improving the relevance and accuracy of search results and RAG responses for datasets that change frequently.
The 5-second default refresh interval is available in all 24 regions where Amazon OpenSearch Serverless is available today. To learn more, see the Amazon OpenSearch Serverless documentation.
Starting today, Amazon OpenSearch Serverless reduces the default refresh interval to 5 seconds for both search and vector collections. The refresh interval controls how quickly newly ingested documents become available for search. By lowering the default from 10 seconds to 5 seconds, newly written data becomes searchable faster, giving applications quicker read-after-write visibility automatically, with no configuration changes and no action required on your part.
This improvement applies to the next generation of Amazon OpenSearch Serverless and takes effect by default on both search and vector collections. Faster refresh is valuable for workloads that continuously ingest data and need near real-time retrieval, including full-text search over frequently updated content as well as vector use cases such as retrieval-augmented generation (RAG), semantic search, and recommendation and personalization systems. This means applications and AI agents can retrieve and act on the most recently ingested data sooner, improving the relevance and accuracy of search results and RAG responses for datasets that change frequently.
The 5-second default refresh interval is available in all 24 regions where Amazon OpenSearch Serverless is available today. To learn more, see the Amazon OpenSearch Serverless documentation.
¿Y si la IA pudiera ayudar a los clínicos a trabajar un diagnóstico médico complejo, paso a paso, y alcanzar mayor precisión, a menor coste y con menos pruebas médicas?
Ese futuro ya se ha comenzado a presentar. En las presentaciones habituales a urgencias de EE. UU., MAI-DxO – nuestro sistema diagnóstico de IA – es 1,7 veces más preciso que los médicos cuando se evalúan con casos de MIMIC-IV-ED.
Y en los casos más complejos de la medicina, publicados en The New England Journal of Medicine, MAI-DxO es más del doble de preciso que los médicos que usan libros de texto e internet, y casi cuatro veces más preciso cuando diagnostican sin esos recursos. Además, consigue hacerlo a mitad o incluso un tercio del coste, llegando al diagnóstico correcto con menos pruebas y procedimientos.
Lean más sobre nuestra visión para la superinteligencia médica, también publicada esta semana en BMJ Digital Health and AI.
Repensar cómo se construye y prueba la IA
La IA tiene el potencial de transformar la salud y la sanidad, y el progreso se acelera con rapidez. El reto ahora es construir y evaluar con rigor, sistemas de IA que traduzcan los avances en sus capacidades de razonamiento clínico en un impacto significativo.
El artículo de hoy, basándose en trabajos anteriores, introduce dos bases para ese cambio: el Sequential Diagnosis Benchmark (SDBench), que pone a prueba el razonamiento diagnóstico paso a paso, y el Microsoft AI Diagnostic Orchestrator (MAI-DxO), nuestro sistema líder de IA en el benchmark.
Los exámenes de licencia médica, como los Exámenes de Licencia Médica de Estados Unidos (USMLEs, por sus siglas en inglés), están diseñados para evaluar el conocimiento de los médicos, no las realidades de hacer un diagnóstico clínico. En estos tests, toda la información se presenta desde el principio y se selecciona una única respuesta; en la práctica, los clínicos deben construir el panorama paso a paso, para decidir qué preguntar, qué pruebas solicitar y cómo cada nuevo hallazgo cambia el diagnóstico probable. Estos exámenes se han convertido en los referentes habituales para evaluar el rendimiento de la IA en salud.
Por eso desarrollamos SDBench, que evalúa el rendimiento en dos conjuntos complementarios de casos: 304 casos complejos tomados de las actas de casos de The New England Journal of Medicine (NEJM) y un conjunto de presentaciones más típicas en urgencias de MIMIC-IV-ED. Cada uno se convierte en un caso interactivo en el que los modelos de IA y/o los médicos parten con información limitada y eligen qué solicitar a continuación. El benchmark mide la precisión diagnóstica, la evidencia solicitada y los costes estimados de las pruebas, evaluando tanto la respuesta como el camino seguido.
Construimos MAI-DxO y lo probamos dentro de SDBench. En lugar de depender de un solo modelo para una respuesta inmediata, funciona como un panel de médicos virtuales: cada uno propone diagnósticos, selecciona preguntas o pruebas útiles y cuestiona la visión emergente. MAI-DxO coordina este intercambio a lo largo de varias rondas de debate, a través de actualizar su evaluación a medida que llega evidencia y sopesar el probable valor de cada prueba frente a su coste.
Lo que hemos encontrado:
En casos complejos de NEJM, MAI-DxO alcanzó una precisión diagnóstica del 83%. Los médicos lograron un 22% sin recursos de referencia externos y un 36% con ellos, para hacer que MAI-DxO fuera alrededor de 3,7 y 2,3 veces más preciso, de maner respectiva.
En casos más típicos de urgencias de MIMIC-IV-ED, MAI-DxO alcanzó un 80% de precisión frente al 47% de los médicos, más de 1,7 veces más.
Cuando se optimizó más en cuanto al coste, el rendimiento de MAI-DxO se mantuvo sólido mientras elegía evaluaciones más rentables. En casos NEJM, una configuración alcanzó un 81% de precisión a menos de la mitad del coste de los sistemas comparativos.
En ambos conjuntos de datos, ningún otro enfoque humano o de IA fue más preciso y menos costoso que MAI-DxO.
Estos avances persistieron —y mejoraron— cuando repetimos la evaluación con modelos más recientes, incluido GPT-5.5, sin cambiar el método de orquestación, lo que sugiere que el enfoque no está ligado a una sola generación de modelo.
Abrimos SDBench para casos seleccionados de NEJM – incluido el código de referencia, Gatekeeper, Judge y estimación de costes – para que los investigadores puedan reproducir la evaluación, probar otros modelos y desafiar o ampliar los hallazgos.
La Figura 1 muestra el rendimiento de MAI-DxO en casos de NEJM en comparación con médicos individuales y modelos de fundación. Los mejores empleados aparecen hacia el cuadrante superior izquierdo, reflejando mayor precisión y menor coste.La Figura 2 muestra el rendimiento de MAI-DxO en casos de urgencias en comparación con médicos individuales y modelos de base. Los mejores resultados aparecen hacia el cuadrante superior izquierdo, reflejando mayor precisión y menor coste.
De un mejor diagnóstico a una mejor atención
El diagnóstico es solo una parte del camino de la atención. Una mejor atención también requiere mantenerse al día con el conocimiento médico, seleccionar el tratamiento adecuado, comprender el cambio a lo largo del tiempo y apoyar elecciones que reflejen los valores y el acceso a la atención de una persona. La oportunidad es unir estas capacidades en un estándar de atención que hoy en día no está disponible de manera amplia. En The Building Blocks of Medical Superintelligence, publicado en BMJ Digital Health and AI, exploramos qué haría falta para que la IA apoyara esta visión más amplia y, en última instancia, superara las capacidades de los equipos clínicos y sistemas de salud más sólidos de la actualidad.
El diagnóstico secuencial ofrece un ejemplo temprano: médicos de IA que colaboran, cuestionan suposiciones y refinan su razonamiento clínico a medida que surge la evidencia. Nuestra ambición es construir IA que conecte conocimiento, contexto y decisiones a lo largo del recorrido asistencial, no tan solo destacar en una sola tarea clínica. A través de nuestra colaboración con Mayo Clinic, pretendemos combinar IA de vanguardia, experiencia clínica y datos multimodales longitudinales para construir sistemas que permitan la complejidad y diversidad de la atención en el mundo real.
Pruebas en el mundo real
Los puntos de referencia importan, pero la verdadera prueba es el rendimiento en entornos clínicos reales. A través de una nueva colaboración con el Beth Israel Deaconess Medical Center en Boston, evaluaremos las capacidades de razonamiento clínico en diferentes entornos hospitalarios. En un estudio prospectivo, los pacientes interactuarán directo con el sistema, para medir el rendimiento en función de las evaluaciones independientes de los médicos. Trabajar junto a equipos clínicos mostrará dónde la tecnología tiene éxito, dónde falla y cómo puede encajar en flujos de trabajo intensos.
Salud en Microsoft
Los rápidos avances en la IA médica abren nuevas posibilidades para pacientes y clínicos. Para convertir este progreso en impacto práctico, reunimos equipos de salud de toda Microsoft —incluidos científicos de Microsoft Research y los equipos detrás de productos como Dragon Copilot y PowerScribe— en un esfuerzo integrado en Microsoft AI. Al trabajar juntos, aceleraremos la entrega de sistemas de IA de confianza que impulsen mejores resultados clínicos y experiencias de atención.
AWS CloudFormation now makes it simpler to complete an update rollback and get back to deploying. An update rollback returns your stack to a known good state. Starting today, if some resources cannot roll back automatically, force rollback enables you to complete the rollback it in a single operation. It works across every CloudFormation workflow, from the AWS CLI, and SDKs to AWS CDK and AI agents.
With force rollback, CloudFormation completes the update rollback and returns your stack to a deployable state in a single operation, instead of requiring you to identify, list, and retry the operation for each affected resource. Any resource that still needs attention, such as one affected a change outside CloudFormation, is recorded for you to review and resolve it before your next deployment.
To get started, run continue update rollback with the force rollback option, then create a drift-aware change set to review any configuration differences before your next deployment. To learn more, see Continue rolling back an update in the AWS CloudFormation User Guide.
Force rollback is available in all Regions at no additional cost. Refer to the AWS Region table for service availability details.
AWS CloudFormation now makes it simpler to complete an update rollback and get back to deploying. An update rollback returns your stack to a known good state. Starting today, if some resources cannot roll back automatically, force rollback enables you to complete the rollback it in a single operation. It works across every CloudFormation workflow, from the AWS CLI, and SDKs to AWS CDK and AI agents.
With force rollback, CloudFormation completes the update rollback and returns your stack to a deployable state in a single operation, instead of requiring you to identify, list, and retry the operation for each affected resource. Any resource that still needs attention, such as one affected a change outside CloudFormation, is recorded for you to review and resolve it before your next deployment.
To get started, run continue update rollback with the force rollback option, then create a drift-aware change set to review any configuration differences before your next deployment. To learn more, see Continue rolling back an update in the AWS CloudFormation User Guide.
Force rollback is available in all Regions at no additional cost. Refer to the AWS Region table for service availability details.
Amazon SageMaker AI serverless model customization now supports training session APIs, giving customers full control over their post-training algorithm without provisioning or managing GPU infrastructure. Managed techniques, including SFT, DPO, and other reinforcement learning methods, let customers pick a technique and a model and have SageMaker AI run the training. With training session APIs, teams get to write the training loop, whether that’s reproducing SFT or DPO on their own terms or implementing a custom loss, a new RL reward signal, a data curriculum, or an algorithm straight from the latest research. Operations such as forward_backward(), optim_step(), and sample() become API calls against a live, stateful session, so customers compose whatever training procedure their technique requires while SageMaker AI handles GPU allocation, model and LoRA loading, distributed execution, fault recovery, checkpoint storage, and security.
Customers can call these operations directly from their own Python code to drive reinforcement learning, supervised fine-tuning, or custom training objectives against a live session, with checkpointing and resume built in. Billing is per token processed, so local computation like reward scoring isn’t billed as GPU time. SageMaker AI is also releasing the SageMaker training sessions cookbook, a set of ready-to-run SFT and RL recipes customers can use as blueprints for their own training loops.
Training session APIs are generally available today in US East (N. Virginia), US West (Oregon), and Asia Pacific (Mumbai). To get started, install the SageMaker Python SDK and clone the cookbook, or launch a notebook in SageMaker Studio and connect a coding agent. To learn more, visit the documentation and the Amazon SageMaker AI webpage.
Amazon SageMaker AI serverless model customization now supports training session APIs, giving customers full control over their post-training algorithm without provisioning or managing GPU infrastructure. Managed techniques, including SFT, DPO, and other reinforcement learning methods, let customers pick a technique and a model and have SageMaker AI run the training. With training session APIs, teams get to write the training loop, whether that’s reproducing SFT or DPO on their own terms or implementing a custom loss, a new RL reward signal, a data curriculum, or an algorithm straight from the latest research. Operations such as forward_backward(), optim_step(), and sample() become API calls against a live, stateful session, so customers compose whatever training procedure their technique requires while SageMaker AI handles GPU allocation, model and LoRA loading, distributed execution, fault recovery, checkpoint storage, and security. Customers can call these operations directly from their own Python code to drive reinforcement learning, supervised fine-tuning, or custom training objectives against a live session, with checkpointing and resume built in. Billing is per token processed, so local computation like reward scoring isn’t billed as GPU time. SageMaker AI is also releasing the SageMaker training sessions cookbook, a set of ready-to-run SFT and RL recipes customers can use as blueprints for their own training loops.
Training session APIs are generally available today in US East (N. Virginia), US West (Oregon), and Asia Pacific (Mumbai). To get started, install the SageMaker Python SDK and clone the cookbook, or launch a notebook in SageMaker Studio and connect a coding agent. To learn more, visit the documentation and the Amazon SageMaker AI webpage.
