Amazon EC2 Capacity Blocks for ML is now available in AWS GovCloud (US-West) and AWS GovCloud (US-East), enabling government and regulated-industry customers to reserve GPU capacity for machine learning workloads.
EC2 Capacity Blocks for ML allows you to reserve GPU instances in advance for a defined duration, giving you assured access to accelerated compute for short-duration pre-training, fine-tuning, rapid prototyping, and inference demand surges. Capacity Blocks deliver low-latency, high-throughput connectivity through colocation in Amazon EC2 UltraClusters.
You can reserve capacity up to eight weeks in advance for durations up to 6 months, in cluster sizes of one to 64 instances. Capacity Blocks can also be shared across multiple accounts using AWS Resource Access Manager (RAM), helping organizations coordinate ML infrastructure investments and keep reserved capacity in continuous use across workloads.
In AWS GovCloud (US), EC2 Capacity Blocks for ML is available on P6-B200 instances in AWS GovCloud (US-West), and P6-B200 and P6-B300 instances in AWS GovCloud (US-East). To get started, visit the EC2 Capacity Blocks documentation.
Amazon EC2 Capacity Blocks for ML is now available in AWS GovCloud (US-West) and AWS GovCloud (US-East), enabling government and regulated-industry customers to reserve GPU capacity for machine learning workloads.
EC2 Capacity Blocks for ML allows you to reserve GPU instances in advance for a defined duration, giving you assured access to accelerated compute for short-duration pre-training, fine-tuning, rapid prototyping, and inference demand surges. Capacity Blocks deliver low-latency, high-throughput connectivity through colocation in Amazon EC2 UltraClusters.
You can reserve capacity up to eight weeks in advance for durations up to 6 months, in cluster sizes of one to 64 instances. Capacity Blocks can also be shared across multiple accounts using AWS Resource Access Manager (RAM), helping organizations coordinate ML infrastructure investments and keep reserved capacity in continuous use across workloads.
In AWS GovCloud (US), EC2 Capacity Blocks for ML is available on P6-B200 instances in AWS GovCloud (US-West), and P6-B200 and P6-B300 instances in AWS GovCloud (US-East). To get started, visit the EC2 Capacity Blocks documentation.
En el piso 11 de la sede de BNY en el bajo Manhattan, un diagrama de flujo de gobernanza llena una pared curva de monitores: dieciséis pasos de juntas de revisión, puertas de cumplimiento y evaluaciones de riesgos de modelos, que trazan el camino de una buena idea a un agente en funcionamiento en una de las instituciones más reguladas del mundo. Parece un poco un juego de mesa, pero en un banco que liquida bonos del Tesoro estadounidense y mueve 2,5 billones de dólares en transacciones al día, cada casilla del tablero existe para que la IA sea observable, controlable y con la suficiente seguridad como para confiar en ella.
Unas pocas docenas de empleados se sientan con los portátiles abiertos; otros se incorporan desde oficinas en Londres, Singapur, Pittsburgh, Pune y más allá. Todos ellos están aquí para aprender a usar la IA para ayudar a tomar decisiones y resolver problemas. Este es el bootcamp de IA de BNY, un programa de 40 horas que se lleva a cabo durante el horario laboral remunerado que ha graduado a cerca de 2.300 empleados desde su lanzamiento que contó con solo 35 participantes en abril de 2025. Sesiones como esta ahora cuentan con cerca de 800.
La premisa del programa es que cada empleado que salga de esta sala debería poder diseñar trabajo, no solo hacerlo. Para la sesión final, cada participante debe haber construido un prototipo de IA funcional, una solución real a un problema real desde su propio rincón del banco. «La IA cambia la manera en que se realiza el trabajo. Invertimos en que nuestra gente haga más con la IA, no solo menos de lo mundano, sino más de todo», dice Michael Demissie, jefe de IA aplicada de BNY.
El instinto de dejar lo tedioso y recuperar lo valioso ocurre en todas partes en BNY. Las soluciones de IA y agénticas absorben cada vez más el trabajo que antes desgastaba la atención y la paciencia; las tareas repetitivas y con reglas que se acumulan las 24 horas del día, para que las personas que los acompañan puedan centrarse en lo que ningún algoritmo puede replicar. Es un movimiento audaz para el banco más antiguo de Estados Unidos, y uno que requiere replantearse cómo trabajan los empleados, cómo toman decisiones los líderes y cómo aprende la organización.
Fundado en 1784 por Alexander Hamilton, BNY ocupa una posición singular en el sistema financiero, ya que es una de las 29 instituciones en el mundo cuyo fracaso podría desestabilizar mercados en continentes. Hoy en día, el banco liquida la mayoría de los bonos del Tesoro estadounidenses emitidos por el gobierno federal, posee 59,4 billones de dólares en activos en nombre de instituciones de todo el mundo y cuenta entre sus clientes a 96 de las 100 mayores firmas financieras del planeta. Cuando BNY empezó a explorar la IA generativa, la pregunta de sus líderes no era «¿Deberíamos?» Era «¿Cómo podríamos?»
A pesar de estas limitaciones, BNY ha avanzado con rapidez, al invertir 3.800 millones de dólares en tecnología el año pasado, casi el 19 por ciento de sus ingresos, y acumular 171.000 horas de aprendizaje solo con IA. BNY ha trabajado con Microsoft a lo largo de su trayectoria en la IA, incluido el uso de la infraestructura en la nube de Azure y la puesta en manos de sus empleados de las herramientas de Copilot. BNY también es miembro fundador de la Frontier Firm AI Initiative, una colaboración con Microsoft y el Instituto de IA de la Harvard Business School.
El banco es uno de los ejemplos más claros hasta ahora de cómo es en realidad una empresa Frontier: lo que significa para quienes realizan el trabajo, los líderes que lo reestructuran y la institución que se rediseña a sí misma. Pasen un día en BNY y escucharán el mantra del CEO Robin Vince en casi todas las salas: «La IA es para todos, en todas partes y para todo.»
Elevar el techo de lo que la gente puede hacer
Rachel Lewis, que lidera la habilitación de IA en toda la organización de operaciones de BNY, tiene un trabajo que ningún manual de gestión cubre del todo. Supervisa múltiples soluciones agénticas junto a miles de empleados humanos. BNY llama a estos «empleados digitales», y hay casi 140 en toda la empresa: «superagentes» formados por múltiples agentes. Cada uno tiene credenciales de acceso, un avatar, un número de empleado en el directorio corporativo y un supervisor que asigna tareas y revisa los resultados.
En el lenguaje de la Frontier Firm, Lewis es una jefa agente, y su experiencia muestra lo que significa para un líder reimaginar el trabajo en lugar de tan solo gestionarlo.
Durante años, el equipo de pagos de BNY se encargó de alrededor de miles de intervenciones manuales al día: códigos de país faltantes, direcciones mal formadas, campos de enrutamiento distorsionados. Probaron la automatización robótica de procesos. Los bots tenían que ser guionizados paso a paso por cada pantalla, y la compleja infraestructura de BNY—mainframes, interfaces HTML, sistemas híbridos—luchaba de manera constante contra esos scripts. «Mantener los bots consumía tanto esfuerzo que los humanos hacían, en efecto, dos tareas en vez de una», dice Lewis.
La pasada primavera, su equipo trabajó con ingenieros de BNY para crear el primer empleado digital dedicado al pago del banco con una tarea muy concreta: leer la dirección de un proveedor en una transacción transfronteriza; llamar a una API de mapeo para determinar si «York» significa Reino Unido, Sudáfrica o Australia Occidental; validar el código de país; y enviar el pago corregido para que un humano lo revise. El alcance era limitado de manera deliberada—no porque la tecnología no pudiera hacer más, sino porque el alcance limitado es lo que hace que los empleados digitales sean de confianza y auditables en un banco donde un pago mal dirigido puede congelar una transferencia de mil millones de dólares. Lewis ahora ve cómo las validaciones de pago que antes tardaban cinco o seis minutos se limpian en menos de 30 segundos. Las investigaciones abiertas en pagos cayeron casi un 80%.
Luego está el empleado digital de BNY para consultas de pagos a clientes, que opera dentro de los sistemas del banco de manera similar a como lo haría un empleado. Por ejemplo, un gestor de fondos en Hong Kong envía un correo electrónico a las 2 de la madrugada, hora de Nueva York, para preguntar por qué no se ha liquidado una transferencia. El empleado digital lee el mensaje, evalúa la urgencia, extrae registros de varios sistemas, redacta una respuesta con el tono adecuado y la pone en cola para revisión por un responsable humano. Una consulta que antes esperaba días ahora se resuelve el mismo día.
La suposición era que gestionar máquinas se sentiría menos humano. En BNY, ha resultado ser todo lo contrario.
Bajo la dirección de gestores humanos de toda la organización, los empleados digitales de BNY abordan la reconciliación, la detección de anomalías, el aseguramiento de la calidad y mucho más. Esto permite a la empresa procesar más de 500.000 imágenes de cheques al día a través del servicio de cajas fuertes de BNY, para utilizar la inteligencia documental de Azure para leer escritura a mano y archivos adjuntos escaneados que superaron sistemas OCR antiguos.
A Lewis le encanta la eficiencia, pero reconoce un resultado aún mayor: la IA ha comenzado a cambiar la forma del trabajo operativo en sí. Tareas que antes se centraban en la gestión repetitiva de excepciones están volviéndose más analíticas, estratégicas y de desarrollo. Los miembros del equipo que antes dedicaban gran parte del día a reparar de manera manual las excepciones de pago ahora identifican patrones de calidad de datos, para hacer los benchmarks de los clientes en cuanto a la calidad de los datos, para contribuir a las discusiones estratégicas del cliente y apoyar el diseño y la prueba de nuevas herramientas de IA.
Un nuevo organigrama: de una pirámide a un diamante
¿Qué se necesita para ser un buen gestor en este entorno cambiante? Empieza con «la disposición a decir ‘no lo sé’», dice Michelle O’Reilly, jefa de talento de BNY. «Los buenos gestores ahora son facilitadores del diálogo. Fomentan la experimentación, aceptan ideas de todas partes y escuchan sus ideas.» Puede que no sepan cómo construir al próximo agente. Pero saben cómo poner a las personas adecuadas en la sala para que eso suceda.
El equipo de O’Reilly desarrolla lo que BNY llama una Agencia de Empleados Digitales: un proceso formal para decidir cuándo un problema empresarial justifica desplegar empleados digitales en lugar de añadir un empleado humano o contratista. Piénsenlo como RRHH para la IA: incorporación, scorecards y, de manera eventual, cuando llegue una versión mejor, una salida estructurada. «¿Necesito un empleado? ¿Un contratista? ¿Un empleado digital? A veces la respuesta no está clara», dice O’Reilly. El objetivo de su equipo es eliminar por completo esa fricción: describir el trabajo y luego dejar que el sistema recomiende la solución adecuada.
La suposición era que gestionar máquinas se sentiría menos humano. En BNY, ha resultado ser todo lo contrario. Gestionar empleados digitales se parece más a ejecutar un proceso de evaluación de desempeño que a un software operativo. Los jefes de los agentes supervisan un panel en directo que muestra el volumen procesado, los tiempos de ciclo, las transacciones perdidas y los resultados de aprobación. Cuando el equipo de empleados digitales de pagos notó que algunas de sus respuestas eran enviadas por revisores —no porque estuvieran equivocados, sino porque los revisores tenían hábitos arraigados de la forma en que se hacía el trabajo antes— el equipo lo gestionó como lo haría con cualquier nueva contratación: coaching, recalibración, reentrenamiento.
Estas innovaciones tienen el potencial de transformar el propio organigrama. BNY se prepara para un escenario en el que la fuerza laboral humana evoluciona de una pirámide a un diamante: el trabajo de procesamiento repetitivo, que antes era gestionado por grandes equipos en la base, pertenece cada vez más a empleados digitales. Los roles analíticos y creativos en el centro han comenzado a crecer. El liderazgo estratégico en la cúpula aun toma las decisiones que importan. BNY planea seguir con la incorporación empleados digitales en los próximos meses, pero el banco sigue con la contratación de miles de empleados humanos cada año. La institución se rediseña bajo una convicción sencilla: que la IA hace que el trabajo humano sea más grande, no más pequeño.
Una fuerza laboral humana en evolución
A medida que los empleados digitales asumen tareas rutinarias, BNY ve el potencial de su plantilla humana para evolucionar de una pirámide a un diamante: más delgada en los extremos, más ancha donde reside el juicio humano.
Nada de esto ocurre sin una infraestructura seria debajo. BNY ejecuta su plataforma interna de IA, Eliza, en parte en Microsoft Azure. Eliza (llamada así por Elizabeth Schuyler Hamilton, la esposa del fundador) es independiente del modelo por diseño, pero se conecta al entorno Microsoft 365 del banco a través de la API Graph, para extraer contexto de Azure, Outlook, Teams, SharePoint y Dynamics CRM. Y en noviembre de 2023, BNY se convirtió en el primer gran banco global en poner Copilot a disposición de sus empleados de manera generalizada. Hoy en día, decenas de miles de empleados de BNY—cerca de la mitad de la plantilla—tienen licencia para Microsoft 365 Copilot.
En un entorno con una fuerte regulación, contar con defensores internos de la IA es esencial. En BNY, el departamento legal —el grupo que la mayoría asumía que resistiría más tiempo— fue el primero en alcanzar el 100% en el entrenamiento preliminar de IA. Seema Phekoo, directora general y asesora legal que lidera la transformación de la IA del departamento, ayudó a implementar 500 licencias Copilot y formación personalizada en jurídicos, desarrolló a los agentes para que definieran documentos y redujeran el tiempo de revisión de contratos, y organizó un hackathon con Microsoft en donde se emparejó a asesores jurídicos senior en retos pro bono.
«Los abogados son los campeones ideales para este tipo de lanzamiento», dice Phekoo. Entienden las barreras de seguridad. Leen con detenimiento, cuestionan suposiciones y revisan hacia la precisión, lo que resulta ser una excelente preparación para trabajar con IA. «Cuando un grupo que la mayoría estereotiparía como adverso al riesgo se convierte en el más entusiasta, la conversación en el resto de la empresa cambia con rapidez», dice.
La habitación donde todo ocurre
De vuelta en el bootcamp, los empleados de BNY han descubierto qué significa en verdad trabajar junto a la IA—no como una herramienta que manejan, sino como una fuerza que cambia de lo que son capaces.
Un facilitador activa una configuración en la interfaz de Eliza. Aparece una casilla de verificación junto a un botón de subida. Igor Kaplevich, que trabaja en finanzas en la sección de divisas de BNY, se inclina hacia delante y empieza a tomar notas—había buscado justo esa característica. Su equipo suele pasar horas en analizar PDFs—gráficos, gráficos, datos de ingresos mensuales que llegan sin estructurar. Eliza, al ser multimodal, ahora puede leer un gráfico financiero, extraer las cifras, calcular la varianza y redactar la explicación. «Si soy franco», dice Kaplevich, «esta es una manera estupenda de sortear una de las partes más aburridas de mi trabajo.»
BNY lo llama apalancamiento de inteligencia: IA como paralelo al apalancamiento mecánico que hizo indispensable a las máquinas industriales en generaciones anteriores. La idea es que el trabajo humano se vuelve más valioso, no menos, cuando las partes repetitivas se desarrollan a gran escala las 24 horas del día. El banco ya explora una herramienta que permitiría a cualquier empleado registrar un flujo de trabajo, que Eliza lo analice y mapee, señalar ineficiencias y luego crear un borrador preliminar de instrucciones para un nuevo trabajador digital. Lo que antes llevaba semanas, ahora dura alrededor de una hora, a veces menos. La IA ahora ayuda a construir IA.
Lo que BNY reúne, bajo las plataformas y los protocolos, es menos una estrategia tecnológica que una teoría del potencial humano: que las personas hacen su mejor trabajo cuando la rutina está gestionada por ellas.
¿Quieren más conocimientos esenciales sobre la IA y el futuro del trabajo? Suscríbanse al boletín de WorkLab.
Amazon EC2 High Memory U7i-8TB instances (u7i-8tb.112xlarge) are now available in AWS Europe (Paris) region. U7i instances are part of the AWS 7th generation and are powered by custom fourth-generation Intel Xeon Scalable processors (Sapphire Rapids). U7i-8TB instances offer 8 TiB of DDR5 memory, enabling customers to scale transaction processing throughput in a fast-growing data environment. U7i instances offer up to 45% better price performance over existing U-1 instances.
U7i-8TB instances deliver 448 vCPUs and support up to 100 Gbps of Amazon EBS bandwidth for faster data loading and backups, 100 Gbps of network bandwidth, and ENA Express. U7i instances are ideal for customers running mission-critical in-memory databases like SAP HANA, Oracle, and SQL Server.
Amazon EC2 High Memory U7i-8TB instances (u7i-8tb.112xlarge) are now available in AWS Europe (Paris) region. U7i instances are part of the AWS 7th generation and are powered by custom fourth-generation Intel Xeon Scalable processors (Sapphire Rapids). U7i-8TB instances offer 8 TiB of DDR5 memory, enabling customers to scale transaction processing throughput in a fast-growing data environment. U7i instances offer up to 45% better price performance over existing U-1 instances.
U7i-8TB instances deliver 448 vCPUs and support up to 100 Gbps of Amazon EBS bandwidth for faster data loading and backups, 100 Gbps of network bandwidth, and ENA Express. U7i instances are ideal for customers running mission-critical in-memory databases like SAP HANA, Oracle, and SQL Server.
To learn more about U7i instances, visit the High Memory instances page.
AWS is announcing the availability of high performance Storage optimized Amazon EC2 I7i instances in AWS Europe (Paris) region. Powered by 5th Gen Intel Xeon Processors with an all-core turbo frequency of 3.2 GHz, these new instances deliver up to 23% better compute performance and more than 10% better price performance over previous generation I4i instances. Powered by 3rd generation AWS Nitro SSDs, I7i instances offer up to 45TB of NVMe storage with up to 50% better real-time storage performance, up to 50% lower storage I/O latency, and up to 60% lower storage I/O latency variability compared to I4i instances.
I7i instances offer compute and storage performance for x86-based storage optimized instances in Amazon EC2 ideal for I/O intensive and latency-sensitive workloads that demand very high random IOPS performance with real-time latency to access the small to medium size datasets. Additionally, torn write prevention feature support up to 16KB block sizes, enabling customers to eliminate database performance bottlenecks.
I7i instances are available in eleven sizes – nine virtual sizes up to 48xlarge and two bare metal sizes – delivering up to 100Gbps of network bandwidth and 60Gbps of Amazon Elastic Block Store (EBS) bandwidth. To learn more, visit the I7i instances page.
AWS is announcing the availability of high performance Storage optimized Amazon EC2 I7i instances in AWS Europe (Paris) region. Powered by 5th Gen Intel Xeon Processors with an all-core turbo frequency of 3.2 GHz, these new instances deliver up to 23% better compute performance and more than 10% better price performance over previous generation I4i instances. Powered by 3rd generation AWS Nitro SSDs, I7i instances offer up to 45TB of NVMe storage with up to 50% better real-time storage performance, up to 50% lower storage I/O latency, and up to 60% lower storage I/O latency variability compared to I4i instances. I7i instances offer compute and storage performance for x86-based storage optimized instances in Amazon EC2 ideal for I/O intensive and latency-sensitive workloads that demand very high random IOPS performance with real-time latency to access the small to medium size datasets. Additionally, torn write prevention feature support up to 16KB block sizes, enabling customers to eliminate database performance bottlenecks. I7i instances are available in eleven sizes – nine virtual sizes up to 48xlarge and two bare metal sizes – delivering up to 100Gbps of network bandwidth and 60Gbps of Amazon Elastic Block Store (EBS) bandwidth. To learn more, visit the I7i instances page.
Amazon Quick now integrates with Snowflake Cortex AI through the Model Context Protocol (MCP), enabling teams to query their Snowflake data and documents using natural language, and automate multi-step workflows directly within their Quick workspace. After setting up the connection using Snowflake’s managed MCP server with OAuth authentication, you can ask questions across structured data through Cortex Analyst and retrieve insights from unstructured documents through Cortex Search.
With this integration, you can build Flows in Quick that orchestrate Snowflake Cortex Agents to execute repeatable, governed workflows with consistent structured output. This is ideal for any multi-step process that spans structured data and unstructured documents. The same MCP connection is also accessible from Quick Chat and other Quick features. For example, users can ask ad-hoc follow-up questions or explore their Snowflake data conversationally alongside their automated flows. Quick intelligently routes relevant prompts to Snowflake Cortex AI and returns contextualized answers alongside enterprise knowledge stored in Quick Spaces, giving teams both the rigor of a structured process and the flexibility of a conversational interface.
The Snowflake Cortex AI integration with Amazon Quick is available in all AWS Regions where Amazon Quick is available.
Visit the Amazon Quick website to learn more and start your Quick free trial. To learn more about the Snowflake Cortex AI integration, read the blog. To learn more about Quick integrations, visit the integrations page.
Amazon Quick now integrates with Snowflake Cortex AI through the Model Context Protocol (MCP), enabling teams to query their Snowflake data and documents using natural language, and automate multi-step workflows directly within their Quick workspace. After setting up the connection using Snowflake’s managed MCP server with OAuth authentication, you can ask questions across structured data through Cortex Analyst and retrieve insights from unstructured documents through Cortex Search.
With this integration, you can build Flows in Quick that orchestrate Snowflake Cortex Agents to execute repeatable, governed workflows with consistent structured output. This is ideal for any multi-step process that spans structured data and unstructured documents. The same MCP connection is also accessible from Quick Chat and other Quick features. For example, users can ask ad-hoc follow-up questions or explore their Snowflake data conversationally alongside their automated flows. Quick intelligently routes relevant prompts to Snowflake Cortex AI and returns contextualized answers alongside enterprise knowledge stored in Quick Spaces, giving teams both the rigor of a structured process and the flexibility of a conversational interface.
The Snowflake Cortex AI integration with Amazon Quick is available in all AWS Regions where Amazon Quick is available.
Visit the Amazon Quick website to learn more and start your Quick free trial. To learn more about the Snowflake Cortex AI integration, read the blog. To learn more about Quick integrations, visit the integrations page.
Amazon CloudWatch Application Signals introduces service health ranking on the application map and new infrastructure, logs, and traces tabs on the service overview page. These capabilities let operators triage unhealthy services and inspect the underlying compute environment, log snippets, and trace details in one place, making it easier to find root causes without switching tools. Customers use Application Signals to monitor the health of distributed applications, but identifying why a service was unhealthy often required leaving CloudWatch to correlate infrastructure data across separate tools. The application map now ranks services by health and shows runtime indicators on service nodes for Amazon EKS, Amazon ECS, AWS Lambda, and Amazon EC2, along with a new infrastructure tab that surfaces the compute and runtime environment, its components, and curated default metrics with deep links to the relevant monitoring tools. In addition, the service overview page provides the infrastructure, logs, and traces tab, helping operators spot issues in context of their application. With health-ranked services on the application map and new infrastructure, logs, and traces tabs, operators can instantly identify their most degraded services and drill into the compute environment, error-producing log snippets, and slow or failing transactions — all without leaving Application Signals. These capabilities span workloads running on Amazon EKS, Amazon ECS, AWS Lambda, and Amazon EC2, giving teams a single pane to move from symptom to root cause in minutes instead of hours.
Amazon CloudWatch Application Signals introduces service health ranking on the application map and new infrastructure, logs, and traces tabs on the service overview page. These capabilities let operators triage unhealthy services and inspect the underlying compute environment, log snippets, and trace details in one place, making it easier to find root causes without switching tools. Customers use Application Signals to monitor the health of distributed applications, but identifying why a service was unhealthy often required leaving CloudWatch to correlate infrastructure data across separate tools. The application map now ranks services by health and shows runtime indicators on service nodes for Amazon EKS, Amazon ECS, AWS Lambda, and Amazon EC2, along with a new infrastructure tab that surfaces the compute and runtime environment, its components, and curated default metrics with deep links to the relevant monitoring tools. In addition, the service overview page provides the infrastructure, logs, and traces tab, helping operators spot issues in context of their application. With health-ranked services on the application map and new infrastructure, logs, and traces tabs, operators can instantly identify their most degraded services and drill into the compute environment, error-producing log snippets, and slow or failing transactions — all without leaving Application Signals. These capabilities span workloads running on Amazon EKS, Amazon ECS, AWS Lambda, and Amazon EC2, giving teams a single pane to move from symptom to root cause in minutes instead of hours. These capabilities are available in all AWS Regions where Amazon CloudWatch Application Signals is supported. To learn more about this feature, see the Amazon CloudWatch Application Signals documentation . For pricing details, see the Amazon CloudWatch pricing page
Amazon Aurora PostgreSQL-Compatible Edition now supports PostgreSQL major version 18, starting with version 18.3. This release brings community improvements to query performance and database management, and introduces support for pg_roaringbitmap, a new extension that performs fast, memory-efficient set operations on large collections of integers. This enables use cases such as audience segmentation, tag-based filtering, and permission checks directly in the database without application-layer processing.
PostgreSQL 18 introduces B-tree skip scans, which improve query performance, and reduce index storage and maintenance overhead. Major version upgrades now retain optimizer statistics, ensuring consistent query performance immediately after upgrading without waiting for statistics to be regenerated. Logical replication can now stream large transactions in parallel, reducing replication lag and keeping downstream systems more current. Please refer to the Amazon Aurora PostgreSQL release notes for details.
You can upgrade your database using several options including RDS Blue/Green deployments, upgrade in-place, or restoring a snapshot. Learn more about upgrading your database instances in the Amazon Aurora User Guide. Aurora PostgreSQL 18.3 is available in all commercial AWS Regions and AWS GovCloud (US) Regions.
Amazon Aurora is designed for unparalleled high performance and availability at global scale with full PostgreSQL and MySQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.
Amazon Aurora PostgreSQL-Compatible Edition now supports PostgreSQL major version 18, starting with version 18.3. This release brings community improvements to query performance and database management, and introduces support for pg_roaringbitmap, a new extension that performs fast, memory-efficient set operations on large collections of integers. This enables use cases such as audience segmentation, tag-based filtering, and permission checks directly in the database without application-layer processing. PostgreSQL 18 introduces B-tree skip scans, which improve query performance, and reduce index storage and maintenance overhead. Major version upgrades now retain optimizer statistics, ensuring consistent query performance immediately after upgrading without waiting for statistics to be regenerated. Logical replication can now stream large transactions in parallel, reducing replication lag and keeping downstream systems more current. Please refer to the Amazon Aurora PostgreSQL release notes for details. You can upgrade your database using several options including RDS Blue/Green deployments, upgrade in-place, or restoring a snapshot. Learn more about upgrading your database instances in the Amazon Aurora User Guide. Aurora PostgreSQL 18.3 is available in all commercial AWS Regions and AWS GovCloud (US) Regions. Amazon Aurora is designed for unparalleled high performance and availability at global scale with full PostgreSQL and MySQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.
AWS Elastic Beanstalk now provides a CloudWatch Logs integration directly in the environment Logs tab of the Elastic Beanstalk console. Previously, customers had to navigate to the CloudWatch console to find the relevant log groups and log streams for their environments. With this launch, customers can view CloudWatch log events without leaving the Elastic Beanstalk console.
The Logs tab displays log groups that an environment streams logs to, as well as log groups matching the aws/elasticbeanstalk/<env-name>/* prefix. Customers can select a log group to view its log streams, with the most recently active stream selected by default. A log stream dropdown allows switching between streams and filtering results. For deeper analysis, a View in CloudWatch dropdown provides direct links to the log group, log stream, or CloudWatch Logs Insights in the CloudWatch console.
This feature is available across all Elastic Beanstalk platform branches in all AWS Commercial Regions and AWS GovCloud (US) Regions where Elastic Beanstalk is available. For a complete list of supported Regions, see AWS Regions.
AWS Elastic Beanstalk now provides a CloudWatch Logs integration directly in the environment Logs tab of the Elastic Beanstalk console. Previously, customers had to navigate to the CloudWatch console to find the relevant log groups and log streams for their environments. With this launch, customers can view CloudWatch log events without leaving the Elastic Beanstalk console.
The Logs tab displays log groups that an environment streams logs to, as well as log groups matching the aws/elasticbeanstalk/<env-name>/* prefix. Customers can select a log group to view its log streams, with the most recently active stream selected by default. A log stream dropdown allows switching between streams and filtering results. For deeper analysis, a View in CloudWatch dropdown provides direct links to the log group, log stream, or CloudWatch Logs Insights in the CloudWatch console.
This feature is available across all Elastic Beanstalk platform branches in all AWS Commercial Regions and AWS GovCloud (US) Regions where Elastic Beanstalk is available. For a complete list of supported Regions, see AWS Regions.
For more information about using Elastic Beanstalk with Amazon CloudWatch, see the AWS Elastic Beanstalk developer guide. To learn more, visit the AWS Elastic Beanstalk product page.
Amazon Managed Workflows for Apache Airflow (MWAA) Serverless now supports workflow and task state change events to Amazon EventBridge, enabling data engineering and platform teams to build event-driven automation for their Apache Airflow workflows.
Previously, monitoring workflow execution required custom polling logic or manual observation. With this launch, MWAA Serverless can emit events when workflows transition between states, including started, running, succeeded, or failed, and when individual tasks change state, such as scheduled, succeeded, failed, or up for retry. With this feature, you can further automate your existing workflows – for example, using EventBridge notifications to trigger alerts when a production workflow fails, automatically restart dependent pipelines when an upstream workflow succeeds, or log state transitions to Amazon S3 for compliance and auditing.
This feature is available in all AWS Regions where Amazon MWAA Serverless is available. For the complete list of supported Regions, see Regions in the Amazon MWAA Serverless User Guide. For pricing details, see Amazon EventBridge pricing.
Amazon Managed Workflows for Apache Airflow (MWAA) Serverless now supports workflow and task state change events to Amazon EventBridge, enabling data engineering and platform teams to build event-driven automation for their Apache Airflow workflows.
Previously, monitoring workflow execution required custom polling logic or manual observation. With this launch, MWAA Serverless can emit events when workflows transition between states, including started, running, succeeded, or failed, and when individual tasks change state, such as scheduled, succeeded, failed, or up for retry. With this feature, you can further automate your existing workflows – for example, using EventBridge notifications to trigger alerts when a production workflow fails, automatically restart dependent pipelines when an upstream workflow succeeds, or log state transitions to Amazon S3 for compliance and auditing.
This feature is available in all AWS Regions where Amazon MWAA Serverless is available. For the complete list of supported Regions, see Regions in the Amazon MWAA Serverless User Guide. For pricing details, see Amazon EventBridge pricing.
To learn more, see Monitoring Amazon MWAA Serverless in the Amazon MWAA Serverless User Guide and Amazon MWAA Serverless events in the Amazon EventBridge Events Reference.
Amazon Managed Service for Prometheus now supports out-of-order sample ingestion and a workspace-level rule query offset. All workspaces have a default out-of-order time window of 1 minute, allowing the workspace to accept metric samples arriving outside strict chronological order. You can adjust this window to match your ingestion patterns or set it to 0 to disable the feature and discard out-of-order samples. You can also configure a global rule query offset that introduces a delay before rule evaluation queries run, giving late-arriving samples time to be ingested before rules execute.
Together, these features reduce data loss and improve alerting accuracy for workloads with distributed collectors, batched exports, or variable network latency. Out-of-order sample support ensures late-arriving data points are ingested rather than discarded, preserving metric completeness. The rule query offset compensates for the expected ingestion delay. Without it, rules evaluate instantly and may miss samples that haven’t landed yet, producing results that differ from the same expression evaluated after all metrics arrive. Two new CloudWatch vended metrics, OutOfOrderIngestionRate and OutOfOrderSampleAge give you visibility into ingestion patterns, helping you tune both settings for your workload.
Out-of-order sample ingestion and rule query offset are available in all AWS regions where Amazon Managed Service for Prometheus is generally available. To get started, configure the out-of-order time window and ruler query offset in your workspace settings via AWS console, API or CLI. For more information, see Amazon Managed Service for Prometheus user documentation.
Amazon Managed Service for Prometheus now supports out-of-order sample ingestion and a workspace-level rule query offset. All workspaces have a default out-of-order time window of 1 minute, allowing the workspace to accept metric samples arriving outside strict chronological order. You can adjust this window to match your ingestion patterns or set it to 0 to disable the feature and discard out-of-order samples. You can also configure a global rule query offset that introduces a delay before rule evaluation queries run, giving late-arriving samples time to be ingested before rules execute.
Together, these features reduce data loss and improve alerting accuracy for workloads with distributed collectors, batched exports, or variable network latency. Out-of-order sample support ensures late-arriving data points are ingested rather than discarded, preserving metric completeness. The rule query offset compensates for the expected ingestion delay. Without it, rules evaluate instantly and may miss samples that haven’t landed yet, producing results that differ from the same expression evaluated after all metrics arrive. Two new CloudWatch vended metrics, OutOfOrderIngestionRate and OutOfOrderSampleAge give you visibility into ingestion patterns, helping you tune both settings for your workload.
Out-of-order sample ingestion and rule query offset are available in all AWS regions where Amazon Managed Service for Prometheus is generally available. To get started, configure the out-of-order time window and ruler query offset in your workspace settings via AWS console, API or CLI. For more information, see Amazon Managed Service for Prometheus user documentation.
