Today, AWS Direct Connect announced inbound prefix controls, a new capability that lets you allocate and manage inbound route-prefix allocations for your private and transit virtual interfaces (VIFs) based on your workload’s needs. You can now allocate up to 1,000 prefixes each for IPv4 and IPv6 on your VIFs on dedicated and hosted connections.

Previously, Direct Connect VIFs accepted a maximum of 100 route prefixes advertised from your on-premises network to AWS on a private or transit VIF. If you had a larger or growing network, you had to architect around this ceiling, for example, by summarizing routes or segmenting across multiple VIFs or connections. With inbound prefix controls, you can allocate up to 1,000 prefixes to a single VIF and advertise your routes directly.

Inbound prefix controls introduce new prefix capacity pools at the dedicated connection level and at the Direct Connect gateway (DXGW) level. When you create or update a VIF, you allocate a specific number of prefixes to it, and that allocation draws from the dedicated connection’s pool and the DXGW’s pool when you attach it. This lets you right-size prefix capacity per workload—for example, a large allocation for a transit VIF carrying many routes and a smaller allocation for a private VIF on the same connection. Connection pool sizes scale with connection speed, and link aggregation group (LAG) pools scale with the number of member connections.

You can configure prefix allocations using the AWS Direct Connect console or CLI/API. Inbound prefix controls are available at no additional cost in all commercial AWS Regions where AWS Direct Connect is available, AWS GovCloud Regions (US-East and US-West), as well as the Amazon Web Services China (Beijing) Region, operated by Sinnet, and the Amazon Web Services China (Ningxia) Region, operated by NWCD.

To learn more, see Inbound prefix controls for AWS Direct Connect in the AWS Direct Connect User Guide.

​Today, AWS Direct Connect announced inbound prefix controls, a new capability that lets you allocate and manage inbound route-prefix allocations for your private and transit virtual interfaces (VIFs) based on your workload’s needs. You can now allocate up to 1,000 prefixes each for IPv4 and IPv6 on your VIFs on dedicated and hosted connections.
Previously, Direct Connect VIFs accepted a maximum of 100 route prefixes advertised from your on-premises network to AWS on a private or transit VIF. If you had a larger or growing network, you had to architect around this ceiling, for example, by summarizing routes or segmenting across multiple VIFs or connections. With inbound prefix controls, you can allocate up to 1,000 prefixes to a single VIF and advertise your routes directly.
Inbound prefix controls introduce new prefix capacity pools at the dedicated connection level and at the Direct Connect gateway (DXGW) level. When you create or update a VIF, you allocate a specific number of prefixes to it, and that allocation draws from the dedicated connection’s pool and the DXGW’s pool when you attach it. This lets you right-size prefix capacity per workload—for example, a large allocation for a transit VIF carrying many routes and a smaller allocation for a private VIF on the same connection. Connection pool sizes scale with connection speed, and link aggregation group (LAG) pools scale with the number of member connections.
You can configure prefix allocations using the AWS Direct Connect console or CLI/API. Inbound prefix controls are available at no additional cost in all commercial AWS Regions where AWS Direct Connect is available, AWS GovCloud Regions (US-East and US-West), as well as the Amazon Web Services China (Beijing) Region, operated by Sinnet, and the Amazon Web Services China (Ningxia) Region, operated by NWCD.
To learn more, see Inbound prefix controls for AWS Direct Connect in the AWS Direct Connect User Guide.  

• Categoría: Company News

agosto 20, 2026

Construir las bases para la IA agéntica en la atención médica

Por: Kees Hertogh, vicepresidente de marketing global de la industria en Microsoft.

Basados en datos fiables, integrados en el flujo de trabajo y en funcionamiento en una infraestructura siempre activa. Lean cómo tres sistemas de salud ponen en marcha a los agentes.

Es martes por la mañana, y el hospital ya va retrasado en aspectos que no se recuperará al final del turno. Una médica lleva 10 pacientes y no ha terminado ni una nota, atrapada en la constante lucha entre la paciente que tiene delante y documentar la que acaba de dejar. Dos pisos más arriba, una enfermera lleva varias horas en un turno de 12 horas y ha pasado más tiempo en un puesto de trabajo que al lado de una cama. Al final del pasillo, los equipos clínicos, de operaciones y financieros persiguen las mismas preguntas urgentes—flujo de pacientes, personal, capacidad y coste—pero las respuestas están dispersas entre sistemas, y cuando los datos se unen, el momento de actuar ya ha pasado. Entonces llega una alerta a TI: la historia clínica electrónica (EHR, por sus siglas en inglés) se ha comenzado a ralentizar, y el CIO sabe que cada minuto que los clínicos no pueden acceder a datos clínicos, de farmacia y de laboratorio en tiempo real, es un minuto que la atención al paciente puede estar en riesgo.

Descubran cómo la IA puede mejorar los resultados reales a gran escala

No son problemas aislados. Son los mismos retos diarios que aparecen en diferentes maneras. Las soluciones desconectadas de proveedores aportan complejidad y coste añadidos, no información ni preocupación.

Las organizaciones sanitarias necesitan soluciones que trabajen en conjunto para evitar la fragmentación.

Una base conectada para la IA agéntica

Microsoft reúne todo lo que la sanidad necesita para desplegar y escalar IA agéntica, reunido en un solo lugar:

• Microsoft Fabric reúne datos de sistemas aislados en una única fuente gobernada de verdad sobre la que los agentes pueden razonar.
• Microsoft Dragon Copilot entrega agentes clínicos que trabajan dentro del flujo de trabajo del clínico.
• Microsoft 365 Copilot y Copilot Studio permiten a cualquier persona de la organización crear y gestionar sus propios agentes empresariales.
• Microsoft Azure y la pila de seguridad de Microsoft proporcionan la infraestructura resiliente y segura que mantiene siempre activos los agentes y el cuidado.

El resultado es un cambio de la fragmentación a la acción coordinada, con agentes que son contextuales, conocedores, fiables y escalables porque están basados en Microsoft IQ —la inteligencia propia de su organización— impulsada por datos de confianza y construida sobre infraestructuras de nivel empresarial.

Como Microsoft IQ es abierto y diversificado en modelos, los clientes construyen sobre su propio IQ y mantienen el control sobre él, en lugar de quedarse atados a la plataforma de otro. Tres sistemas de salud muestran cómo es eso en la práctica.

Los agentes valiosos resuelven problemas reales

Brown University Health, el mayor sistema sanitario de Rhode Island, atiende a un millón de personas y es la columna vertebral de cuidados críticos de la región. Desde 2024 ha crecido con rapidez, ha adquirido dos hospitales en Massachusetts y se ha fusionado con una gran consulta de médicos académicos, todo ello mientras lidia con presiones financieras, escasez de mano de obra y un creciente agotamiento clínico, impulsado en gran parte por la carga documental.

Su primera aplicación de IA, Dragon Copilot, un asistente clínico de IA, abordó esa carga de manera directa, para permitir que los clínicos de todas las especialidades se centraran en el paciente en lugar del teclado, con menos documentación fuera de horario y menor carga cognitiva. Un clínico lo expresó con claridad: «Esto va a prolongar mi carrera.»

Va a devolver la alegría a la práctica de la medicina. Los clínicos entraron en esto porque quieren ayudar a la gente. La mayoría no lo hizo porque quieren interactuar con ordenadores.

Adam Landman, SVP y director de información digital, Brown University Health

Brown pasó entonces de la IA que asiste a la IA que actúa. El equipo creó dos agentes de urgencias integrados en Dragon Copilot: uno que responde a preguntas específicas de políticas y procedimientos del hospital, y otro que muestra horarios y directorios de guardia para que el personal pueda llegar con rapidez al especialista adecuado. Esos son solo dos de más de dos docenas de agentes que el equipo ha construido en toda la organización—y con Copilot Studio, pasaron de la idea al prototipo funcional en un solo día.

La empresa siguió. Brown implementó Microsoft 365 Copilot a nivel organizacional para gestionar las bandejas de entrada, resumir reuniones y analizar contratos. Cuando los líderes necesitaban una política de gobernanza responsable de IA, ponían al agente investigador a trabajar para que estudiara las mejores prácticas e iterara borradores; una política que los líderes esperaban que tardara un año fue ratificada en cuatro meses.

Lean sobre cómo Brown Health escala Microsoft Dragon Copilot

Los agentes de confianza comienzan con datos fiables

Los agentes solo son tan fiables como los datos sobre los que razonan, que es justo donde empezó el Centro Regional de Salud de Peterborough (PRHC, por sus siglas en inglés). Atiende a una población creciente y envejecida frente a presiones conocidas en el sector sanitario: aumento del volumen de pacientes, creciente complejidad clínica y duras limitaciones en personal, financiación y capacidad. Los líderes vieron la oportunidad en la IA y reconocieron que solo funciona cuando se basa en datos sólidos.

Así que empezaron con los datos, no con el modelo. El equipo consolidó 18 sistemas de producción en Microsoft Fabric, una fuente gobernada de verdad para análisis e IA.

Partimos de un lugar de fragmentación e inmadurez de datos bastante significativas. Si alguien necesitaba datos, podía tardar semanas en encontrarlos, y lo que solía aparecer era una hoja de Excel desactualizada que no respondía en verdad a la pregunta.

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

El cambio fue profundo: los equipos pasaron de esperar semanas para informes estáticos y desactualizados a explorar datos en tiempo real juntos, a través de una toma de decisiones más rápidas y seguras en los flujos de trabajo clínicos y operativos. La lección de Mikula refleja un principio fundamental de una estrategia agéntica: la IA escalable no comienza con modelos, comienza con los datos. Con una base gobernada, PRHC creó las condiciones para que los agentes escalen con datos en los que puedan confiar.

Y la recompensa es aparecer donde más importa: en la atención al paciente. PRHC atribuye mejoras en varios departamentos de urgencias y métricas de flujo de pacientes hospitalizados entre enero y marzo de 2026 a este esfuerzo operativo. Menos pacientes esperaban camas de ingreso a las 8 de la mañana, se bajó de 34 a 19, y el tiempo de espera para una cama de ingreso cayó un 43%, de 56,8 a 32 horas. A medida que mejoró el acceso, la proporción de pacientes que se marchaban sin ser atendidos disminuyó del 10% al 8,8%, mientras que las puntuaciones generales de experiencia aumentaron del 77% al 80%. Un nuevo turno de hospitalización mejoró los tiempos de respuesta de las consultas en alrededor de un 20%, lo que ayudó a equilibrar la carga de trabajo hospitalario y la calidad de la atención de apoyo. En conjunto, estos cambios contribuyeron a ganancias a largo plazo en el flujo de pacientes, incluida una reducción aproximada del 70% en los tiempos de descarga de ambulancias.

Exploren cómo PRHC convirtió los datos en información accionable

Agentes fiables se ejecutan sobre infraestructuras resilientes

Los agentes de los que dependen los clínicos no pueden ocultarse. Eso convirtió la infraestructura en la prioridad de Franciscan Health, que migró su Epic EHR a Azure para rendimiento, escalabilidad, recuperación ante desastres y seguridad en una plataforma preparada para el futuro. La apuesta era absoluta. «Si Epic está caído, no tenemos acceso a datos clínicos. No tenemos acceso a farmacia; no tenemos acceso a los resultados de laboratorio», dice el CIO Charles Wagner. «Así que, desde el momento en que eso se cae, la atención al paciente está en riesgo.» El coste es igual de evidente: «nos cuesta entre 10 y 12 millones de dólares al día cada día que nos caemos.»

El corte fue el primer punto de prueba. «Una vez que hicimos el cambio de paso, creo que no recibimos ni una sola llamada. Los clínicos y el personal ni siquiera sabían que había ocurrido», dice Wagner. «Así es como definimos el éxito.» Luego, los resultados se sumaron en rendimiento, coste y recuperación: Franciscan puede ahora poner en funcionamiento su entorno de recuperación ante desastres en menos de una hora, desde las 8 a 12 horas que antes tardaba, para mantener la continuidad de la atención incluso en un incidente grave.

Como migramos a Azure, podemos hacer un conmutador por error y estar listos en 30 minutos. Esto es algo que nunca podríamos hacer en nuestro entorno anterior.

Charles Wagner, CIO, Franciscan Health

La migración a Azure de Franciscan ofreció:

• 45 millones de dólares en ahorros durante cinco años.
• Un 33% menos en los costes de infraestructura.
• Respuesta a la solicitud un 50% más rápida.

Y como Epic se basa en tecnología de Microsoft, Franciscan obtuvo la ventaja de un solo proveedor que facilita la puesta en marcha al siguiente agente, al siguiente modelo, a la siguiente carga de trabajo—la diferencia entre luchar contra tu infraestructura y construir sobre ella.

Franciscan Health utilizó la IA para mejorar el rendimiento, la escalabilidad y la eficiencia

Una plataforma. IA en la que puedes confiar

Tres sistemas de salud, tres puntos de partida, un patrón. El valor no está en herramientas aisladas: está en una plataforma conectada donde los agentes están conectados, embebidos y fiables.

• Brown Health puso a trabajar agentes clínicos y empresariales en dos docenas de departamentos.
• El Centro Regional de Salud de Peterborough construyó la base de datos de los agentes de confianza para razonar sobre ella.
• Franciscan Health estableció la infraestructura resiliente que mantiene en funcionamiento a los agentes y la atención.

Todo funciona en conjunto, lo que facilita llevar nuevas soluciones online y obtener más valor de nuestras inversiones.

Charles Wagner, CIO, Franciscan Health

Ese es el cambio: no más herramientas, sino un sistema que funciona como uno solo, con datos, flujos de trabajo e inteligencia que entienda el contexto, sus procesos de negocio y las interacciones de sus equipos, para permitir a los agentes pasar de la señal a la acción. Fabric deja a la organización lista para IA. Dragon Copilot transforma el flujo de trabajo clínico. Copilot conecta equipos, decisiones y ejecución. Copilot Studio permite a cualquiera crear flujos de trabajo agénticos, escalables y repetibles. En conjunto, estas capacidades están basadas en Microsoft IQ y funcionan en Azure, parar brindar la resiliencia, seguridad y escala de las que dependen las organizaciones sanitarias. Desde el analista que usa Fabric, hasta el clínico que utiliza Dragon Copilot, el resto de sus empleados que usan Copilot, para pasar por los constructores que crean en Copilot Studio, la organización por fin funciona con la misma inteligencia y los mismos agentes, para convertir señales fragmentadas en acciones coordinadas y datos en mejor atención al paciente.

Así, cuando empiece el siguiente turno, los clínicos pueden dedicar más tiempo a atender a los pacientes, los líderes pueden tomar decisiones con confianza y las organizaciones pueden actuar según las ideas antes de que pase el momento de actuar.

Descubran cómo la IA agéntica genera un impacto real a lo largo del continuo de atención

Desde reducir la carga documental y mejorar el flujo de pacientes hasta modernizar las plataformas de datos y fortalecer infraestructuras críticas, las organizaciones sanitarias han puesto la IA a trabajar de manera práctica. Exploren las estrategias, las lecciones aprendidas y los resultados detrás de estas transformaciones reales.

Descarguen el libro electrónico de AI para una mejor atención médica

Etiquetas:

• IA
• Innovación
• Salud

The post Construir las bases para la IA agéntica en la atención médica appeared first on Source LATAM.

​The post Construir las bases para la IA agéntica en la atención médica appeared first on Source LATAM.  

AWS partners can now configure category-based notifications and multi-channel delivery for AWS Marketplace notifications through AWS User Notifications. Previously, partners received their AWS Marketplace notifications through their AWS account’s root email address or custom email aliases, with no way to select notification categories or route each category to the teams responsible for managing it. With this launch, partners can choose which contacts receive each notification category and how those notifications are delivered.

Four notification categories are available. Product listings notifications cover open product tasks, recurring scan findings for AMI and container products, and Vendor Insights security profile snapshots for SaaS products. Offers and agreements notifications cover private offers, reseller activity, professional services requests, agreement starts and cancellations, cancellation requests, and agreement creation failures. Payments and disbursements notifications cover payment requests, billing adjustments, invoice submission outcomes, payment failures, and disbursement issues. Account management notifications cover business and bank account verification actions, approvals, expirations, and rejections.

By default, notifications are delivered by email to the AWS account’s root email address. Partners can add recipients through additional email addresses and distribution lists. Partners can also receive notifications through the AWS Console Mobile Application or Amazon Q Developer in chat applications such as Slack and Microsoft Teams. After enabling managed notifications, partners can select the contacts and delivery channels that receive each category.

AWS Marketplace category-based notifications are available in all AWS Commercial Regions where AWS Marketplace is available. To learn more, see Managing email notifications for AWS Marketplace events in the AWS Marketplace documentation. To enable managed notifications, visit the AWS User Notifications console.

​AWS partners can now configure category-based notifications and multi-channel delivery for AWS Marketplace notifications through AWS User Notifications. Previously, partners received their AWS Marketplace notifications through their AWS account’s root email address or custom email aliases, with no way to select notification categories or route each category to the teams responsible for managing it. With this launch, partners can choose which contacts receive each notification category and how those notifications are delivered.
Four notification categories are available. Product listings notifications cover open product tasks, recurring scan findings for AMI and container products, and Vendor Insights security profile snapshots for SaaS products. Offers and agreements notifications cover private offers, reseller activity, professional services requests, agreement starts and cancellations, cancellation requests, and agreement creation failures. Payments and disbursements notifications cover payment requests, billing adjustments, invoice submission outcomes, payment failures, and disbursement issues. Account management notifications cover business and bank account verification actions, approvals, expirations, and rejections.
By default, notifications are delivered by email to the AWS account’s root email address. Partners can add recipients through additional email addresses and distribution lists. Partners can also receive notifications through the AWS Console Mobile Application or Amazon Q Developer in chat applications such as Slack and Microsoft Teams. After enabling managed notifications, partners can select the contacts and delivery channels that receive each category.
AWS Marketplace category-based notifications are available in all AWS Commercial Regions where AWS Marketplace is available. To learn more, see Managing email notifications for AWS Marketplace events in the AWS Marketplace documentation. To enable managed notifications, visit the AWS User Notifications console.  

Amazon CloudWatch pipelines now includes three new processors that parse and enrich log data as it’s ingested: an Amazon RDS log parser, an XML parser and a GeoIP enrichment processor. CloudWatch pipelines is a fully managed service that ingests, transforms, and routes telemetry to CloudWatch without managing infrastructure.

Log sources often produce data that isn’t immediately queryable without reprocessing the data. RDS Aurora logs arrive in their native engine format, application logs carry embedded XML, and IP addresses lack location context. The new processors address each case. The Amazon RDS processor parses Aurora audit and error logs into structured fields, the XML parser converts a field containing an XML string into JSON, and the GeoIP processor enriches any IP address field with geographic context such as city, country, and coordinates. For example, you can parse an Aurora audit log into structured fields for compliance reporting. In a separate pipeline, you can extract the XML payload from a Windows Event Log into JSON and resolve its source IP to a city and country for security analysis. You can use these processors independently or combine them in one pipeline.

These processors are available at no additional cost in all AWS Regions where CloudWatch pipelines is generally available. CloudWatch logs ingestion and storage rates apply. You can add these processors to your pipelines using the AWS Management Console, AWS CLI, or AWS SDKs. To get started, see the Amazon CloudWatch pipelines documentation.

​Amazon CloudWatch pipelines now includes three new processors that parse and enrich log data as it’s ingested: an Amazon RDS log parser, an XML parser and a GeoIP enrichment processor. CloudWatch pipelines is a fully managed service that ingests, transforms, and routes telemetry to CloudWatch without managing infrastructure.
Log sources often produce data that isn’t immediately queryable without reprocessing the data. RDS Aurora logs arrive in their native engine format, application logs carry embedded XML, and IP addresses lack location context. The new processors address each case. The Amazon RDS processor parses Aurora audit and error logs into structured fields, the XML parser converts a field containing an XML string into JSON, and the GeoIP processor enriches any IP address field with geographic context such as city, country, and coordinates. For example, you can parse an Aurora audit log into structured fields for compliance reporting. In a separate pipeline, you can extract the XML payload from a Windows Event Log into JSON and resolve its source IP to a city and country for security analysis. You can use these processors independently or combine them in one pipeline.
These processors are available at no additional cost in all AWS Regions where CloudWatch pipelines is generally available. CloudWatch logs ingestion and storage rates apply. You can add these processors to your pipelines using the AWS Management Console, AWS CLI, or AWS SDKs. To get started, see the Amazon CloudWatch pipelines documentation.  

Web Search in Amazon Bedrock AgentCore now supports domain filtering and published-date filtering, giving agents per-request control over which web sources and time windows they search. Amazon Bedrock AgentCore provides the infrastructure to build, connect, and optimize AI agents, and Web Search enables those agents to ground responses in current web data.

With runtime domain filtering, agents can narrow search results to trusted sources or block unwanted domains on a per-call basis without requiring admin reconfiguration. Published-date filtering allows agents to constrain results to a specific time window using inclusive from and to date bounds, ensuring responses reflect only timely, relevant content.

With this launch, agents can pass include and exclude domain lists and a published-date range directly in each tool call, while admins gain new gateway-level allowlist support and an increased domain cap of up to 100 domains per list. These capabilities are ideal for regulated industries, research workflows, and applications that require strict control over information sources and recency.

The Web Search Tool is also expanding to Europe (Ireland) (eu-west-1) and Asia Pacific (Tokyo) (ap-northeast-1), joining the existing US East (N. Virginia) (us-east-1) availability. To learn more, read the technical blog about domain and published date filters , and review the Amazon Bedrock AgentCore product documentation.

​Web Search in Amazon Bedrock AgentCore now supports domain filtering and published-date filtering, giving agents per-request control over which web sources and time windows they search. Amazon Bedrock AgentCore provides the infrastructure to build, connect, and optimize AI agents, and Web Search enables those agents to ground responses in current web data. With runtime domain filtering, agents can narrow search results to trusted sources or block unwanted domains on a per-call basis without requiring admin reconfiguration. Published-date filtering allows agents to constrain results to a specific time window using inclusive from and to date bounds, ensuring responses reflect only timely, relevant content. With this launch, agents can pass include and exclude domain lists and a published-date range directly in each tool call, while admins gain new gateway-level allowlist support and an increased domain cap of up to 100 domains per list. These capabilities are ideal for regulated industries, research workflows, and applications that require strict control over information sources and recency. The Web Search Tool is also expanding to Europe (Ireland) (eu-west-1) and Asia Pacific (Tokyo) (ap-northeast-1), joining the existing US East (N. Virginia) (us-east-1) availability. To learn more, read the technical blog about domain and published date filters , and review the Amazon Bedrock AgentCore product documentation.  

Earlier this month, we announced Web Search on Amazon Bedrock, a built-in server-side tool that allows you to ground model responses with current web knowledge, while maintaining data within your secured AWS environment with zero data egress. Today, we are expanding Web Search to enable the external_web_access parameter allowing Web Search to retrieve content directly from the public web so models can ground responses in the latest information.

To enable external_web_access, grant the bedrock-websearch:ExternalWebAccess IAM permission to the request identity and leave the external_web_access parameter at its default of true.  In doing so, Web Search can then fetch content live from the public web for use cases that need the freshest possible information, such as latest sports score, live pricing, or newly released documentation. If handling sensitive data, to keep retrieval entirely within your AWS boundary, set external_web_access: false. By setting it false, Web Search serves results only from Amazon’s in-AWS web index and knowledge graph, with no request data leaving the AWS boundary.  

Enabling External Web Access is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), and US West (Oregon). To learn more, read our blog post Introducing Web Search on Amazon Bedrock for foundation model grounding, review Controlling external web access in the Amazon Bedrock User Guide, and visit the Amazon Bedrock pricing page for cost details.

​Earlier this month, we announced Web Search on Amazon Bedrock, a built-in server-side tool that allows you to ground model responses with current web knowledge, while maintaining data within your secured AWS environment with zero data egress. Today, we are expanding Web Search to enable the external_web_access parameter allowing Web Search to retrieve content directly from the public web so models can ground responses in the latest information.
To enable external_web_access, grant the bedrock-websearch:ExternalWebAccess IAM permission to the request identity and leave the external_web_access parameter at its default of true.  In doing so, Web Search can then fetch content live from the public web for use cases that need the freshest possible information, such as latest sports score, live pricing, or newly released documentation. If handling sensitive data, to keep retrieval entirely within your AWS boundary, set external_web_access: false. By setting it false, Web Search serves results only from Amazon’s in-AWS web index and knowledge graph, with no request data leaving the AWS boundary.  
Enabling External Web Access is available in the following AWS Regions: US East (N. Virginia), US East (Ohio), and US West (Oregon). To learn more, read our blog post Introducing Web Search on Amazon Bedrock for foundation model grounding, review Controlling external web access in the Amazon Bedrock User Guide, and visit the Amazon Bedrock pricing page for cost details.
   

Amazon CloudWatch Centralization now copies log group tags from source accounts to the destination log groups created by centralization rules. CloudWatch Centralization aggregates log data from multiple accounts and Regions into one destination account. With tag propagation, the cost, ownership, and compliance tags you maintain at the source now apply to the copied log groups.

With today’s launch, CloudWatch copies the tags of each source log group to its destination log group and keeps them in sync based on the tag propogation behaviour selected as part of the centralization rule setup. For example, a platform team can preserve Application and CostCenter tags on centralized log groups, then use those tags to scope access with IAM conditions and report centralized log spend by team in AWS Cost Explorer.

Tag propagation is available in all AWS Regions where CloudWatch Centralization is available. For a list of Regions, see the AWS Regions table.

To get started, turn on tag propagation for a centralization rule in the Amazon CloudWatch console, or by using the AWS CLI or AWS SDKs. To learn more about centralizing logs while preserving their tags, see Log Centralization User Guide. For Centralization pricing, see Amazon CloudWatch pricing.

​Amazon CloudWatch Centralization now copies log group tags from source accounts to the destination log groups created by centralization rules. CloudWatch Centralization aggregates log data from multiple accounts and Regions into one destination account. With tag propagation, the cost, ownership, and compliance tags you maintain at the source now apply to the copied log groups.
With today’s launch, CloudWatch copies the tags of each source log group to its destination log group and keeps them in sync based on the tag propogation behaviour selected as part of the centralization rule setup. For example, a platform team can preserve Application and CostCenter tags on centralized log groups, then use those tags to scope access with IAM conditions and report centralized log spend by team in AWS Cost Explorer.
Tag propagation is available in all AWS Regions where CloudWatch Centralization is available. For a list of Regions, see the AWS Regions table.
To get started, turn on tag propagation for a centralization rule in the Amazon CloudWatch console, or by using the AWS CLI or AWS SDKs. To learn more about centralizing logs while preserving their tags, see Log Centralization User Guide. For Centralization pricing, see Amazon CloudWatch pricing.  

Amazon SageMaker Notebooks now support Trusted Identity Propagation (TIP) with Amazon Athena, Amazon Redshift, and Amazon EMR Serverless, enabling per-user access control for data analytics.

When connected to a TIP-enabled compute in a TIP-enabled Project, each notebook user’s IAM Identity Center identity flows through to AWS Lake Formation, ensuring they see only the tables, columns, and rows their permissions allow, without sharing a single broad execution role. With TIP, enterprises get per-user data boundaries enforced based on who is running the query, full audit attribution with CloudTrail recording which user accessed data, and reduced admin friction since identity propagates automatically through the existing compute connection with no extra login, token, or role management required.

To get started, use a notebook in a TIP enabled Project with the supported engines.  This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, see Trusted identity propagation in the Amazon SageMaker Unified Studio Administrator Guide and Notebooks in the Amazon SageMaker Unified Studio User Guide.

​Amazon SageMaker Notebooks now support Trusted Identity Propagation (TIP) with Amazon Athena, Amazon Redshift, and Amazon EMR Serverless, enabling per-user access control for data analytics.
When connected to a TIP-enabled compute in a TIP-enabled Project, each notebook user’s IAM Identity Center identity flows through to AWS Lake Formation, ensuring they see only the tables, columns, and rows their permissions allow, without sharing a single broad execution role. With TIP, enterprises get per-user data boundaries enforced based on who is running the query, full audit attribution with CloudTrail recording which user accessed data, and reduced admin friction since identity propagates automatically through the existing compute connection with no extra login, token, or role management required.
To get started, use a notebook in a TIP enabled Project with the supported engines.  This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, see Trusted identity propagation in the Amazon SageMaker Unified Studio Administrator Guide and Notebooks in the Amazon SageMaker Unified Studio User Guide.  

AWS Cost Anomaly Detection now monitors spend on third-party foundation models running on Amazon Bedrock, such as Anthropic Claude and other provider-hosted models. Cost Anomaly Detection uses machine learning to detect and alert on unusual spend, and this launch extends that coverage to third-party model usage on Amazon Bedrock. Teams running production generative AI workloads now get automatic anomaly detection on their Amazon Bedrock model spend alongside the rest of their AWS costs.

With this launch, Cost Anomaly Detection automatically evaluates your third-party Amazon Bedrock model costs through your AWS managed service monitor, with no setup required. When spend on a model changes unexpectedly, you receive an alert and a root-cause breakdown ranked by dollar impact across AWS service, account, Region, and usage type, so you can understand and act on generative AI cost changes as quickly as you do for any other AWS spend.

This feature is available in all AWS commercial regions, except the AWS GovCloud and the China Regions.

To learn more, see Detecting unusual spend with AWS Cost Anomaly Detection in the AWS Billing and Cost Management User Guide.

​AWS Cost Anomaly Detection now monitors spend on third-party foundation models running on Amazon Bedrock, such as Anthropic Claude and other provider-hosted models. Cost Anomaly Detection uses machine learning to detect and alert on unusual spend, and this launch extends that coverage to third-party model usage on Amazon Bedrock. Teams running production generative AI workloads now get automatic anomaly detection on their Amazon Bedrock model spend alongside the rest of their AWS costs.
With this launch, Cost Anomaly Detection automatically evaluates your third-party Amazon Bedrock model costs through your AWS managed service monitor, with no setup required. When spend on a model changes unexpectedly, you receive an alert and a root-cause breakdown ranked by dollar impact across AWS service, account, Region, and usage type, so you can understand and act on generative AI cost changes as quickly as you do for any other AWS spend.
This feature is available in all AWS commercial regions, except the AWS GovCloud and the China Regions.
To learn more, see Detecting unusual spend with AWS Cost Anomaly Detection in the AWS Billing and Cost Management User Guide.  

Starting today, customers can use Amazon OpenSearch Ingestion in AWS GovCloud (US-East) and AWS GovCloud (US-West), for ingesting data into their Amazon OpenSearch Service managed clusters or serverless collections.

Amazon OpenSearch Ingestion is a fully managed data ingestion tier that allows you to ingest and process data before indexing it in Amazon OpenSearch managed clusters or serverless collections. Amazon OpenSearch Ingestion provides a no-code experience to filter, transform, redact, and route data into Amazon OpenSearch Service. Amazon OpenSearch Ingestion automatically provisions and scales the underlying resources to meet the fluctuating demands of your workloads.

With this launch, Amazon OpenSearch Ingestion is now generally available in 19 AWS regions: US East (Ohio), US East (N. Virginia), US West (Oregon), US West (N. California), Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Spain), Europe (Paris), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Mumbai), Asia Pacific (Seoul), Canada (Central), South America (Sao Paulo), Europe (Stockholm), GovCloud (US-East) and GovCloud (US-West).

To learn more, see the Amazon OpenSearch Ingestion webpage and the Amazon OpenSearch Ingestion Developer Guide.

​Starting today, customers can use Amazon OpenSearch Ingestion in AWS GovCloud (US-East) and AWS GovCloud (US-West), for ingesting data into their Amazon OpenSearch Service managed clusters or serverless collections. Amazon OpenSearch Ingestion is a fully managed data ingestion tier that allows you to ingest and process data before indexing it in Amazon OpenSearch managed clusters or serverless collections. Amazon OpenSearch Ingestion provides a no-code experience to filter, transform, redact, and route data into Amazon OpenSearch Service. Amazon OpenSearch Ingestion automatically provisions and scales the underlying resources to meet the fluctuating demands of your workloads. With this launch, Amazon OpenSearch Ingestion is now generally available in 19 AWS regions: US East (Ohio), US East (N. Virginia), US West (Oregon), US West (N. California), Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Spain), Europe (Paris), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Singapore), Asia Pacific (Mumbai), Asia Pacific (Seoul), Canada (Central), South America (Sao Paulo), Europe (Stockholm), GovCloud (US-East) and GovCloud (US-West). To learn more, see the Amazon OpenSearch Ingestion webpage and the Amazon OpenSearch Ingestion Developer Guide.