AWS announces the availability of TwelveLabs Marengo 3.0 as an embedding model in Amazon Bedrock Managed Knowledge Base, enabling customers to create multimodal embeddings for video, audio, and image content. Amazon Bedrock Managed Knowledge Base already supports media search by transcribing audio and video to text and generating text-based embeddings—Marengo 3.0 goes further by encoding visual scenes, speech, and video cues directly into multimodal embeddings, capturing meaning that transcription alone cannot. Simply upload your media assets from data sources such as Amazon S3, sync, and search using natural language—with no infrastructure to manage.
Marengo 3.0 produces compact 512-dimensional vectors, delivering state-of-the-art retrieval accuracy. Results include segment start and end times, enabling applications to jump directly to the relevant moment in a video. This unlocks use cases across sports analytics, media and entertainment, security, education, and retail—from finding specific plays across seasons of game footage to locating lecture segments by concept rather than keywords. The model offers configurable segmentation options to match your content structure.
To learn more, see TwelveLabs Marengo 3.0 embedding model integration in the Amazon Bedrock Knowledge Base User Guide. For more information, visit the Amazon Bedrock Knowledge Bases product page.

​AWS announces the availability of TwelveLabs Marengo 3.0 as an embedding model in Amazon Bedrock Managed Knowledge Base, enabling customers to create multimodal embeddings for video, audio, and image content. Amazon Bedrock Managed Knowledge Base already supports media search by transcribing audio and video to text and generating text-based embeddings—Marengo 3.0 goes further by encoding visual scenes, speech, and video cues directly into multimodal embeddings, capturing meaning that transcription alone cannot. Simply upload your media assets from data sources such as Amazon S3, sync, and search using natural language—with no infrastructure to manage. Marengo 3.0 produces compact 512-dimensional vectors, delivering state-of-the-art retrieval accuracy. Results include segment start and end times, enabling applications to jump directly to the relevant moment in a video. This unlocks use cases across sports analytics, media and entertainment, security, education, and retail—from finding specific plays across seasons of game footage to locating lecture segments by concept rather than keywords. The model offers configurable segmentation options to match your content structure. To learn more, see TwelveLabs Marengo 3.0 embedding model integration in the Amazon Bedrock Knowledge Base User Guide. For more information, visit the Amazon Bedrock Knowledge Bases product page.  

AWS HealthOmics now publishes real-time run metrics to Amazon CloudWatch, giving you visibility into workflow resource utilization as runs execute. The 14 new run metrics span CPU and GPU usage, memory usage, file system usage and I/O metrics, network throughput, and ephemeral storage usage. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.

Real-time run metrics can help you identify CPU or GPU bottlenecks, detect memory or storage exhaustion before a task fails, and track file system throughput, all without opening a support case. By comparing actual usage against allocated resources, you can right-size the compute and storage configurations for your workflows. These metrics are emitted using the Amazon CloudWatch OpenTelemetry standard, so you can integrate them with third-party observability tools in addition to native CloudWatch dashboards and alarms.

Real-time run metrics are now available in the following AWS HealthOmics Regions: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), and Asia Pacific (Singapore, Seoul, Tokyo). To learn more, visit the Monitoring run metrics with CloudWatch documentation. Amazon CloudWatch charges for these run metrics based on the volume of metric data ingested. For more information on pricing, visit Amazon CloudWatch pricing.

​AWS HealthOmics now publishes real-time run metrics to Amazon CloudWatch, giving you visibility into workflow resource utilization as runs execute. The 14 new run metrics span CPU and GPU usage, memory usage, file system usage and I/O metrics, network throughput, and ephemeral storage usage. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
Real-time run metrics can help you identify CPU or GPU bottlenecks, detect memory or storage exhaustion before a task fails, and track file system throughput, all without opening a support case. By comparing actual usage against allocated resources, you can right-size the compute and storage configurations for your workflows. These metrics are emitted using the Amazon CloudWatch OpenTelemetry standard, so you can integrate them with third-party observability tools in addition to native CloudWatch dashboards and alarms.
Real-time run metrics are now available in the following AWS HealthOmics Regions: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), and Asia Pacific (Singapore, Seoul, Tokyo). To learn more, visit the Monitoring run metrics with CloudWatch documentation. Amazon CloudWatch charges for these run metrics based on the volume of metric data ingested. For more information on pricing, visit Amazon CloudWatch pricing.  

• Categoría: Company News

septiembre 11, 2026

Desde la preparación de la IA hasta el impacto: Por qué una base sólida de datos determina el éxito en la sanidad

Por: Jonathon Dreyer, director general de marketing de producto, salud global y ciencias de la vida en Microsoft.

Las organizaciones sanitarias han ido más allá de preguntarse si la IA pertenece a la prestación de atención. En entornos clínicos, operativos y administrativos, el impulso se construye a medida que los líderes invierten en IA para mejorar la coordinación, reducir fricciones y ayudar a fortalecer los resultados.

Los líderes sanitarios están cada vez más preparados para desplegar IA. Sus bases de datos a menudo no lo están.

En toda la industria, las organizaciones han comenzado a descubrir que escalar la IA requiere mucho más que introducir nuevos modelos o soluciones puntuales. Depende de si la inteligencia puede operar a través de las realidades de un sistema sanitario: entre departamentos, entre fuentes de datos y en los flujos de trabajo donde se toman decisiones diarias. Por eso la conversación ha comenzado a cambiar del entusiasmo por la IA a la preparación para la IA.

Descubran los hallazgos clave sobre el camino de la sanidad hacia la preparación para la IA

El impulso de la IA es claro, pero la escala sigue desigual

Los líderes sanitarios están cada vez más alineados con el potencial de la IA para mejorar la prestación de cuidados y las operaciones. Muchos la ven como una manera de fortalecer la toma de decisiones, mejorar la coordinación y permitir que la información avance de manera más eficaz entre equipos y entornos de atención.

Una encuesta global reciente a 500 líderes sanitarios de siete países, encargada por Microsoft, revela que el 58% dice estar listo para introducir agentes de IA en la coordinación de la atención y los flujos de trabajo administrativos,¹ y casi todos creen que las iniciativas de IA pueden lograr un impacto escalable. ² Sin embargo, surgió un desafío constante en la investigación. Aunque la confianza es alta, la ejecución sigue desigual. La misma investigación encontró que el 97% de los líderes sanitarios informan que los silos de datos ya afectan su capacidad para ofrecer atención oportuna. ³ Esa estadística subraya qué tan profundo la fragmentación puede afectar a los resultados.

Cuando los datos críticos permanecen distribuidos entre sistemas desconectados, los equipos dedican tiempo a reconciliar la información en lugar de actuar sobre ella. En ese tipo de entorno, la IA tiene dificultades para escalar más allá de casos de uso aislados. La inteligencia no puede llegar de manera constante a las personas y momentos donde más importa, lo que limita la capacidad de convertir el impulso en un impacto sostenido y a nivel empresarial.

Por qué una base sólida de datos se ha convertido en un elemento central para la preparación de la IA

A medida que las organizaciones sanitarias trabajan para cerrar esta brecha, el fortalecimiento de una base sólida de datos emerge como una prioridad máxima. Un entorno de datos unificado y gobernado permite la interoperabilidad y facilita el flujo de información entre sistemas clínicos, operativos y administrativos. Esto permite que la IA opere en contexto y soporte flujos de trabajo reales en lugar de quedarse confinada a pilotos.

La urgencia de ese trabajo se refuerza con la misma investigación global: alrededor del 62% de los líderes sanitarios identifican la tecnología heredada como una fuente primaria de fragmentación.⁴ Esto puede incluir infraestructuras envejecidas y sistemas clínicos, de imagen, operativos y administrativos desconectados que no fueron diseñados para intercambiar datos. El hallazgo apunta a una realidad más amplia. El éxito con la IA depende no solo de avanzar en modelos y capacidades, sino también de modernizar la infraestructura, mejorar la interoperabilidad, reducir la fragmentación y crear entornos de datos conectados que puedan soportar la IA a gran escala.

Una base de datos más sólida también apoya la confianza. A medida que la IA se integra más en la prestación y operaciones de la atención, los líderes necesitan sistemas transparentes, auditables y alineados con los requisitos regulatorios y organizativos. La gobernanza, la rendición de cuentas y la adopción responsable no están separadas de la base; forman parte de ella.

Una base de datos unificada puede convertir la IA en un activo fiable a nivel organizacional

Las organizaciones que más progresan no tratan a la IA como una innovación independiente. Construyen las condiciones que permiten que la inteligencia opere en todo el sistema. Eso incluye modernizar la infraestructura, unificar datos entre dominios y mejorar la interoperabilidad para que la información pueda circular entre sistemas, socios y entornos de atención.

City of Hope ofrece un ejemplo claro. Los médicos allí dedicaban mucho tiempo —a menudo fuera del horario laboral— en revisar extensos historiales de pacientes para prepararse para las citas. Al trabajar con Microsoft, la organización construyó una solución de IA en Microsoft Azure que procesa y resume cientos de páginas de historiales médicos, para ayudar a los médicos a incorporar a miles de pacientes cada año y a pasar más tiempo cara a cara con las personas que tratan.

Queremos aprovechar tecnologías innovadoras para apoyar la toma de decisiones en tiempo real. Queremos hacerlo de manera responsable. Queremos hacerlo juntos. Y, al final del día, queremos ayudar a mejorar la sanidad para todos.

Simon Nazarian, director de digital y tecnología, City of Hope

En las organizaciones que logran este tipo de progreso, estos esfuerzos se combinan con una gobernanza integrada: apoyar la transparencia, la rendición de cuentas y la supervisión humana adecuada forma parte de las operaciones diarias. No son decisiones tan solo técnicas. Son decisiones estratégicas que moldean cómo operan las organizaciones sanitarias.

Cuando estos elementos se unen, la IA puede ir más allá de iniciativas aisladas y convertirse en parte de los modelos operativos que apoyan la coordinación, mejoran la eficiencia y ayudan a los equipos a tomar decisiones más oportunas e informadas.

Convertir el impulso de la IA en impacto real

La sanidad ha comenzado a entrar en una nueva fase de adopción de la IA, definida menos por la experimentación y más por la ejecución. Las organizaciones mejor posicionadas para esta fase tratan los datos como un activo del sistema, alinean a los interesados en torno a resultados compartidos e integran la IA en flujos de trabajo reales donde puede aportar valor medible a través de la prestación de atención, las operaciones y la experiencia del paciente.

La oportunidad que se tiene por delante es significativa. La IA puede ayudar a las organizaciones sanitarias a reducir la carga administrativa, mejorar la coordinación y apoyar decisiones más oportunas e informadas. Pero reconocer ese potencial dependerá de lo que hagan ahora los líderes para fortalecer la base que hay bajo esta. En el sector sanitario, la base de datos ya no es una consideración de fondo. Se ha comenzado a convertir en uno de los indicadores más claros de si una organización puede escalar la IA de forma segura, responsable y eficaz.

El Centro Regional de Salud de Peterborough reunió datos clínicos, operativos y financieros en Microsoft Fabric, para conectar 18 sistemas de producción y pasar de semanas de espera para informes estáticos a una visión iterativa más rápida. Con datos gobernados e IA, los equipos aplicaron esa base a los desafíos operativos, para contribuir a una reducción del 43% en el tiempo de espera para camas hospitalizadas y a una disminución del 20% trimestre tras trimestre en la utilización innecesaria de laboratorios. El resultado muestra cómo una base sólida de datos puede llevar la IA de la ambición a un impacto práctico y medible, al tiempo que genera la confianza necesaria para escalar de forma responsable.

Porque hemos construido la base adecuada, estamos en una posición en la que podemos empezar a construir a gran escala, avanzar rápido y hacerlo con mucha más confianza mientras nos preparamos para un futuro en el que cuidemos a una población de pacientes mucho mayor con los recursos que tenemos.

Lynn Mikula, directora ejecutiva, Centro Regional de Salud de Peterborough

El cambio de la fragmentación a la frontera comienza con esa base. Los líderes que la construyen ahora son quienes convertirán el impulso de la IA en un impacto duradero y crearán las condiciones para que la IA apoye la prestación de atención y la mejora operativa a gran escala.

Exploren la investigación y los conocimientos que dan forma a este cambio

A medida que las organizaciones sanitarias trasladan las iniciativas de IA más allá de los programas piloto hacia un despliegue a gran escala, un creciente cuerpo de investigación y análisis del sector ayuda a definir cómo se presenta la preparación en la práctica.

Para saber más sobre cómo los líderes sanitarios abordan la fragmentación, construyen entornos de datos unificados y establecen la gobernanza necesaria para escalar la IA de forma responsable, exploren los siguientes recursos:

• Informe de analista: Informe de analista de IDC sobre infraestructura de nube sanitaria
• Informe de analista: Informe de Everest Group sobre plataformas de gestión de datos sanitarios
• Libro electrónico de investigación global: De la fragmentación a la frontera: Convertir la preparación para la IA en impacto

En conjunto, estos recursos ofrecen una visión más amplia de cómo las organizaciones sanitarias navegan el cambio del impulso de la IA al impacto real y proporcionan un punto de referencia útil para los líderes que evalúan sus propios datos y la preparación para la IA.

Los productos y servicios de Microsoft (1) no están diseñados, destinados ni puestos a disposición como dispositivos médicos, y (2) no están diseñados ni pretenden sustituir el asesoramiento, diagnóstico, tratamiento o juicio médico profesional y no deben usarse para sustituir o sustituir el asesoramiento, diagnóstico, tratamiento o juicio médico profesional. Los clientes/socios son responsables de garantizar que las soluciones cumplan con las leyes y normativas aplicables.

Todas las cifras son del libro electrónico de Microsoft, From Fragmentation to Frontier: Turning AI Readiness into Impact (2026), una encuesta global a 500 líderes sanitarios en siete países:

¹ 58% de los líderes sanitarios dice estar listo para introducir agentes de IA en la coordinación de la atención y los flujos de trabajo administrativos.

² Casi todos los líderes sanitarios creen que las iniciativas de IA pueden lograr un impacto escalable.

³ 97% de los líderes sanitarios afirman que los silos de datos ya afectan su capacidad para ofrecer atención oportuna.

⁴ Alrededor del 62% de los líderes sanitarios identifican la tecnología heredada como una fuente principal de fragmentación.

Metodología de investigación: Encuesta cuantitativa global en línea realizada en nombre de Microsoft por OnePoll desde el 7 de enero de 2026 hasta el 14 de enero de 2026 entre 500 responsables de la toma de decisiones en IA y/o tecnología en hospitales y organizaciones sanitarias con 400+ camas en Estados Unidos, Reino Unido, Alemania, Francia, Australia, Países Bajos y Suecia.

Etiquetas:

• IA
• Salud

The post Desde la preparación de la IA hasta el impacto: Por qué una base sólida de datos determina el éxito en la sanidad appeared first on Source LATAM.

​The post Desde la preparación de la IA hasta el impacto: Por qué una base sólida de datos determina el éxito en la sanidad appeared first on Source LATAM.  

AWS DevOps Agent now enables engineers to manage the full investigation lifecycle directly within Slack. Previously, on-call engineers and DevOps teams faced fragmented workflows during high-severity incidents, forced to context-switch between communication and investigation platforms. This update consolidates both surfaces into a single, unified location where incident response already happens.

Engineering teams can now initiate an investigation by simply @mentioning AWS DevOps Agent in any connected Slack channel. All investigation activity, including team-contributed context, agent findings, and recommended actions, is captured within a single thread. This eliminates cognitive load during critical moments and preserves a complete audit trail from trigger to mitigation, making post-incident retrospectives significantly more efficient.

This capability is available in all commercial AWS Regions where AWS DevOps Agent is currently supported.

To get started, read the user guide. See all the latest AWS DevOps Agent features on the release history page.

​AWS DevOps Agent now enables engineers to manage the full investigation lifecycle directly within Slack. Previously, on-call engineers and DevOps teams faced fragmented workflows during high-severity incidents, forced to context-switch between communication and investigation platforms. This update consolidates both surfaces into a single, unified location where incident response already happens.
Engineering teams can now initiate an investigation by simply @mentioning AWS DevOps Agent in any connected Slack channel. All investigation activity, including team-contributed context, agent findings, and recommended actions, is captured within a single thread. This eliminates cognitive load during critical moments and preserves a complete audit trail from trigger to mitigation, making post-incident retrospectives significantly more efficient.
This capability is available in all commercial AWS Regions where AWS DevOps Agent is currently supported.
To get started, read the user guide. See all the latest AWS DevOps Agent features on the release history page.  

Today, AWS announced that AWS Transform for .NET can automatically generate unit tests for the code it modernizes. When enabled, AWS Transform generates unit tests that target the testable classes in your transformed .NET application, such as business logic and controllers, giving you an automated test safety net on the modernized code as part of the same job that performs the migration.

Modernizing a .NET Framework application to modern .NET produces a transformed, buildable codebase, but teams previously had to write test coverage for that modernized code by hand. With this launch, AWS Transform assesses your application for testability in parallel with the standard .NET assessment, plans which classes and methods to cover, and generates the corresponding unit test code, so you complete the migration with tests already in place. Unit test generation is opt-in: you can enable it at the start of a job or after transformation completes.

Unit test generation for AWS Transform for .NET is supported in the AWS Toolkit for Visual Studio extension. It is available in all AWS Regions where AWS Transform for .NET is supported. To get started, run a .NET transformation with AWS Transform for .NET in Visual Studio and choose to generate unit tests. To learn more, refer to Modernizing .NET in the IDE in the AWS Transform User Guide.

​Today, AWS announced that AWS Transform for .NET can automatically generate unit tests for the code it modernizes. When enabled, AWS Transform generates unit tests that target the testable classes in your transformed .NET application, such as business logic and controllers, giving you an automated test safety net on the modernized code as part of the same job that performs the migration.
Modernizing a .NET Framework application to modern .NET produces a transformed, buildable codebase, but teams previously had to write test coverage for that modernized code by hand. With this launch, AWS Transform assesses your application for testability in parallel with the standard .NET assessment, plans which classes and methods to cover, and generates the corresponding unit test code, so you complete the migration with tests already in place. Unit test generation is opt-in: you can enable it at the start of a job or after transformation completes.
Unit test generation for AWS Transform for .NET is supported in the AWS Toolkit for Visual Studio extension. It is available in all AWS Regions where AWS Transform for .NET is supported. To get started, run a .NET transformation with AWS Transform for .NET in Visual Studio and choose to generate unit tests. To learn more, refer to Modernizing .NET in the IDE in the AWS Transform User Guide.  

AWS Lambda recursive loop detection is now supported for functions running in Europe Sovereign Cloud. Recursive loop detection automatically detects and stops recursive invocations between Lambda functions and other supported services, preventing unexpected billing caused by unintended recursive loops.

Customers use event sources such as Amazon S3, Amazon SQS, and Amazon SNS to build event driven applications that trigger Lambda functions. Misconfiguration or code defect can cause events to be sent back to the same source that triggered the Lambda function, causing recursive loops and unintended usage. When such a loop is detected, recursive loop detection automatically stops processing the event and sends you an AWS Health Dashboard notification with troubleshooting steps.

Recursive loop detection is enabled by default for Lambda functions using a supported SDK version. If your function intentionally uses recursive loops, you can use the PutFunctionRecursionConfig API to turn off recursive loop detection on your Lambda function. 

To learn about recursive loop detection, visit Lambda documentation.

​AWS Lambda recursive loop detection is now supported for functions running in Europe Sovereign Cloud. Recursive loop detection automatically detects and stops recursive invocations between Lambda functions and other supported services, preventing unexpected billing caused by unintended recursive loops.
Customers use event sources such as Amazon S3, Amazon SQS, and Amazon SNS to build event driven applications that trigger Lambda functions. Misconfiguration or code defect can cause events to be sent back to the same source that triggered the Lambda function, causing recursive loops and unintended usage. When such a loop is detected, recursive loop detection automatically stops processing the event and sends you an AWS Health Dashboard notification with troubleshooting steps.
Recursive loop detection is enabled by default for Lambda functions using a supported SDK version. If your function intentionally uses recursive loops, you can use the PutFunctionRecursionConfig API to turn off recursive loop detection on your Lambda function. 
To learn about recursive loop detection, visit Lambda documentation.  

Amazon API Gateway now supports configurable delivery destinations and larger log events for REST API execution logs. Previously, execution logs were delivered to a single API Gateway-managed CloudWatch Logs log group with log events truncated at 1 KB, limiting visibility into request and response data.

You can now route execution logs up to 1 MB to your own Amazon CloudWatch Logs log groups, Amazon S3 buckets, or Amazon Data Firehose streams, and deliver to multiple destinations simultaneously. For example, you can route execution logs to Amazon S3 in Apache Parquet format for cost-efficient long-term storage and analysis with Amazon Athena, while simultaneously delivering structured JSON logs to CloudWatch Logs for real-time alerting.

This feature is available in all AWS Regions where API Gateway REST APIs are available, including the AWS GovCloud (US) Regions. Execution logs delivered through this feature are charged at vended logs rates. For pricing details, see Amazon CloudWatch Pricing. You can set up delivery through the API Gateway console, AWS CLI, or AWS CloudFormation. To get started, see Amazon API Gateway documentation and AWS blog post. 

​Amazon API Gateway now supports configurable delivery destinations and larger log events for REST API execution logs. Previously, execution logs were delivered to a single API Gateway-managed CloudWatch Logs log group with log events truncated at 1 KB, limiting visibility into request and response data. You can now route execution logs up to 1 MB to your own Amazon CloudWatch Logs log groups, Amazon S3 buckets, or Amazon Data Firehose streams, and deliver to multiple destinations simultaneously. For example, you can route execution logs to Amazon S3 in Apache Parquet format for cost-efficient long-term storage and analysis with Amazon Athena, while simultaneously delivering structured JSON logs to CloudWatch Logs for real-time alerting. This feature is available in all AWS Regions where API Gateway REST APIs are available, including the AWS GovCloud (US) Regions. Execution logs delivered through this feature are charged at vended logs rates. For pricing details, see Amazon CloudWatch Pricing. You can set up delivery through the API Gateway console, AWS CLI, or AWS CloudFormation. To get started, see Amazon API Gateway documentation and AWS blog post.   

Today, AWS Lambda durable functions announces an integration with Pydantic AI, an open source framework for building AI agents in Python. AWS Lambda durable functions saves your Pydantic AI agent’s progress as it runs, so after an interruption like a timeout, your agent resumes from the last completed step instead of starting over. Your agent gains fault tolerance without you having to write the checkpoint and retry logic yourself.

With this integration, each model and tool call your agent makes is a durable execution step, so an interrupted run does not repeat calls that already completed. This matters when the work is expensive to repeat, such as a chain of model calls that reviews a set of documents or researches a topic across many sources, where starting over means paying again for tokens to do the same work. It also helps to avoid unwanted side-effects when resuming execution, such as billing a customer twice. Because your agent runs on AWS Lambda, you manage no servers and pay only for the compute it uses.

You can use this integration in any Python AWS Lambda durable function. It is available in all AWS Regions where AWS Lambda durable functions is available. To get started, install Pydantic AI and follow its AWS Lambda durability page. You can also find the integration details in the durable execution SDK reference. For more information about AWS Lambda durable functions, see the developer guide and the AWS Lambda product page.

​Today, AWS Lambda durable functions announces an integration with Pydantic AI, an open source framework for building AI agents in Python. AWS Lambda durable functions saves your Pydantic AI agent’s progress as it runs, so after an interruption like a timeout, your agent resumes from the last completed step instead of starting over. Your agent gains fault tolerance without you having to write the checkpoint and retry logic yourself.
With this integration, each model and tool call your agent makes is a durable execution step, so an interrupted run does not repeat calls that already completed. This matters when the work is expensive to repeat, such as a chain of model calls that reviews a set of documents or researches a topic across many sources, where starting over means paying again for tokens to do the same work. It also helps to avoid unwanted side-effects when resuming execution, such as billing a customer twice. Because your agent runs on AWS Lambda, you manage no servers and pay only for the compute it uses.
You can use this integration in any Python AWS Lambda durable function. It is available in all AWS Regions where AWS Lambda durable functions is available. To get started, install Pydantic AI and follow its AWS Lambda durability page. You can also find the integration details in the durable execution SDK reference. For more information about AWS Lambda durable functions, see the developer guide and the AWS Lambda product page.  

Amazon MQ now supports RabbitMQ version 4.3 which adds quorum queue feature enhancements such as compaction, increased priority levels, native delayed retries, and graceful consumer timeouts. RabbitMQ 4.3 also includes various bug fixes and performance improvements for memory management.

Quorum queues on RabbitMQ 4.3 performs compaction to reduce disk usage for queues and native support for 32 strict priority levels, compared to the relative 2 levels supported in previous RabbitMQ versions. Quorum queues can now automatically set failed messages aside and retry delivery after a set cooldown delay. Consumer timeouts have moved from global protocol channels to quorum queues and can be configured specific to the protocol now. Both consumer timeouts and delayed retries can be configured and managed by RabbitMQ Policies. Transient non-exclusive queues, Global QoS, and Classic queues v1 storage are no longer supported on RabbitMQ 4.3. Consumer timeouts also do not apply to classic queues.

To start using RabbitMQ 4.3 on Amazon MQ, simply select RabbitMQ 4.3 when creating a new broker using the m7g instance type through the AWS Management console, AWS CLI, or AWS SDKs. Amazon MQ automatically manages patch version upgrades for your RabbitMQ 4.3 brokers, so you need to only specify the major.minor version. To learn more about the changes in RabbitMQ 4.3, see the Amazon MQ release notes and the Amazon MQ developer guide. This version is available in all regions where Amazon MQ m7g type instances are available today. 

​Amazon MQ now supports RabbitMQ version 4.3 which adds quorum queue feature enhancements such as compaction, increased priority levels, native delayed retries, and graceful consumer timeouts. RabbitMQ 4.3 also includes various bug fixes and performance improvements for memory management.
Quorum queues on RabbitMQ 4.3 performs compaction to reduce disk usage for queues and native support for 32 strict priority levels, compared to the relative 2 levels supported in previous RabbitMQ versions. Quorum queues can now automatically set failed messages aside and retry delivery after a set cooldown delay. Consumer timeouts have moved from global protocol channels to quorum queues and can be configured specific to the protocol now. Both consumer timeouts and delayed retries can be configured and managed by RabbitMQ Policies. Transient non-exclusive queues, Global QoS, and Classic queues v1 storage are no longer supported on RabbitMQ 4.3. Consumer timeouts also do not apply to classic queues.
To start using RabbitMQ 4.3 on Amazon MQ, simply select RabbitMQ 4.3 when creating a new broker using the m7g instance type through the AWS Management console, AWS CLI, or AWS SDKs. Amazon MQ automatically manages patch version upgrades for your RabbitMQ 4.3 brokers, so you need to only specify the major.minor version. To learn more about the changes in RabbitMQ 4.3, see the Amazon MQ release notes and the Amazon MQ developer guide. This version is available in all regions where Amazon MQ m7g type instances are available today.   

Today, AWS announces the general availability of second-generation single-rack AWS Outposts, a self-contained 42U rack that integrates compute, storage and networking into a single compact unit purpose-built for workloads requiring low latency, local data processing, and data residency in space and power constrained locations. A single-rack Outposts delivers up to 2,688 vCPU and 100 TB of Amazon Elastic Block Store (Amazon EBS) storage. Moreover, like multi-rack Outposts, single-rack Outposts support the latest x86-powered EC2 instances, including general purpose (M7i, M8i), compute-optimized (C7i, C8i), memory-optimized (R7i, R8i), and Outposts accelerated networking (Bmn-sf2e, Bmn-cx2, Bmn-cx3a) instances.

For organizations that operate in locations with limited rack space, such as manufacturing, gaming, and other industries, single-rack Outposts brings the latest AWS compute, storage, and networking features on-premises, and gives customers a direct path to modernize while leveraging their currently available space and power. Single-rack and multi-rack Outposts offer customers a consistent experience with the same AWS APIs, management console, automation, governance policies, and security controls across AWS Regions and on-premises locations.

For a current list of AWS Regions and countries/territories where Outposts racks are supported, check out the Outposts rack FAQs page. To get started, open the AWS Outposts console.

​Today, AWS announces the general availability of second-generation single-rack AWS Outposts, a self-contained 42U rack that integrates compute, storage and networking into a single compact unit purpose-built for workloads requiring low latency, local data processing, and data residency in space and power constrained locations. A single-rack Outposts delivers up to 2,688 vCPU and 100 TB of Amazon Elastic Block Store (Amazon EBS) storage. Moreover, like multi-rack Outposts, single-rack Outposts support the latest x86-powered EC2 instances, including general purpose (M7i, M8i), compute-optimized (C7i, C8i), memory-optimized (R7i, R8i), and Outposts accelerated networking (Bmn-sf2e, Bmn-cx2, Bmn-cx3a) instances.
For organizations that operate in locations with limited rack space, such as manufacturing, gaming, and other industries, single-rack Outposts brings the latest AWS compute, storage, and networking features on-premises, and gives customers a direct path to modernize while leveraging their currently available space and power. Single-rack and multi-rack Outposts offer customers a consistent experience with the same AWS APIs, management console, automation, governance policies, and security controls across AWS Regions and on-premises locations.
For a current list of AWS Regions and countries/territories where Outposts racks are supported, check out the Outposts rack FAQs page. To get started, open the AWS Outposts console.