AWS Clean Rooms now supports Databricks as a data source, so collaboration members and their partners can securely analyze data managed in Databricks without moving or revealing the source data. Members query a Databricks table shared through Delta Sharing directly in a collaboration. Databricks joins AWS Glue, Snowflake, and Amazon Athena as supported data sources in AWS Clean Rooms.
Previously, members with data in Databricks had to export or replicate it into Amazon S3 to use it as a table in a collaboration, which added pipeline work and an extra copy of the data to govern. Now members can register a Databricks table directly by providing the workspace URL, schema, and table along with a Delta Sharing share, and make it available to a collaboration. For example, a retailer that manages its customer data in Databricks can collaborate with a media partner on campaign measurement in AWS Clean Rooms, running approved analyses against its Databricks data without first building and maintaining an export to S3.
AWS Clean Rooms helps companies and their partners easily analyze and collaborate on their collective datasets without revealing or copying one another’s underlying data. For more information about the AWS Regions where AWS Clean Rooms is available, see the AWS Regions table. To learn more about collaborating with AWS Clean Rooms, visit AWS Clean Rooms.
AWS Clean Rooms now supports Databricks as a data source, so collaboration members and their partners can securely analyze data managed in Databricks without moving or revealing the source data. Members query a Databricks table shared through Delta Sharing directly in a collaboration. Databricks joins AWS Glue, Snowflake, and Amazon Athena as supported data sources in AWS Clean Rooms.
Previously, members with data in Databricks had to export or replicate it into Amazon S3 to use it as a table in a collaboration, which added pipeline work and an extra copy of the data to govern. Now members can register a Databricks table directly by providing the workspace URL, schema, and table along with a Delta Sharing share, and make it available to a collaboration. For example, a retailer that manages its customer data in Databricks can collaborate with a media partner on campaign measurement in AWS Clean Rooms, running approved analyses against its Databricks data without first building and maintaining an export to S3.
AWS Clean Rooms helps companies and their partners easily analyze and collaborate on their collective datasets without revealing or copying one another’s underlying data. For more information about the AWS Regions where AWS Clean Rooms is available, see the AWS Regions table. To learn more about collaborating with AWS Clean Rooms, visit AWS Clean Rooms.
Amazon Bedrock now supports structured outputs for all Anthropic Claude models across both the bedrock-runtime and the bedrock-mantle endpoint. Whether you call Claude through boto3 and the bedrock-runtime APIs or through the Messages API and the bedrock-mantle endpoint, you can now receive schema-compliant JSON responses that conform to a defined structure, without custom parsing, retry logic, or post-processing.
With structured outputs for Claude on Amazon Bedrock, you can automate reliable, schema-compliant tasks across industries. Examples include extracting every required field from financial earnings reports and compliance documents, parsing clinical notes into Electronic Health Records (EHR), and enriching product catalogs with consistent, validated results. You can also analyze contracts for key terms, parties, and obligations, or power intelligent support ticket routing where intents, sentiments, and entities always match your application’s data model.
To learn more, see the Amazon Bedrock documentation . Structured outputs is available where claude models are available. For more information check the regional availability details page.
Amazon Bedrock now supports structured outputs for all Anthropic Claude models across both the bedrock-runtime and the bedrock-mantle endpoint. Whether you call Claude through boto3 and the bedrock-runtime APIs or through the Messages API and the bedrock-mantle endpoint, you can now receive schema-compliant JSON responses that conform to a defined structure, without custom parsing, retry logic, or post-processing.
With structured outputs for Claude on Amazon Bedrock, you can automate reliable, schema-compliant tasks across industries. Examples include extracting every required field from financial earnings reports and compliance documents, parsing clinical notes into Electronic Health Records (EHR), and enriching product catalogs with consistent, validated results. You can also analyze contracts for key terms, parties, and obligations, or power intelligent support ticket routing where intents, sentiments, and entities always match your application’s data model.
To learn more, see the Amazon Bedrock documentation . Structured outputs is available where claude models are available. For more information check the regional availability details page.
Today, AWS launched the public beta of TorchNeuron, an open source native PyTorch backend for AWS Trainium. Trainium is a portfolio of AI chips designed to deliver high performance and cost efficiency for deep learning AI training and inference workloads. TorchNeuron enables AI scientists and researchers to experiment and build models with PyTorch natively on Trainium.
With TorchNeuron, developers can enable their PyTorch code on Trainium simply by switching to .to(‘neuron’) while maintaining full PyTorch compatibility with eager execution, torch.compile, and standard PyTorch APIs. Additionally, TorchNeuron integrates with Neuron Kernel Interface (NKI) to enable custom operators and performance optimization for Trainium hardware.
TorchNeuron is available as open source through the TorchNeuron github repo for Amazon EC2 Trainium2 instances and Amazon EC2 Trainium3 instances.
To learn more about TorchNeuron and AWS Trainium accelerators, visit the AWS Neuron page.
Today, AWS launched the public beta of TorchNeuron, an open source native PyTorch backend for AWS Trainium. Trainium is a portfolio of AI chips designed to deliver high performance and cost efficiency for deep learning AI training and inference workloads. TorchNeuron enables AI scientists and researchers to experiment and build models with PyTorch natively on Trainium.
With TorchNeuron, developers can enable their PyTorch code on Trainium simply by switching to .to(‘neuron’) while maintaining full PyTorch compatibility with eager execution, torch.compile, and standard PyTorch APIs. Additionally, TorchNeuron integrates with Neuron Kernel Interface (NKI) to enable custom operators and performance optimization for Trainium hardware.
TorchNeuron is available as open source through the TorchNeuron github repo for Amazon EC2 Trainium2 instances and Amazon EC2 Trainium3 instances.
To learn more about TorchNeuron and AWS Trainium accelerators, visit the AWS Neuron page.
Today, we are introducing a new model behind the Amazon Polly Generative engine that delivers more natural-sounding, accurate speech output with low latency. With this upgrade, you get access to an enhanced voice portfolio with higher overall quality, 14 new voices across nine locales, and two new languages—Hindi and Finnish—now generally available on the Generative engine for the first time. New voices include Kenneth and Nate (US English), Russell and Curtis (Australian English), Kiara and Arjun (Hindi and Indian English), Tina (German), Carlos (US Spanish), Leo and Carolina (Brazilian Portuguese), Hyunduk (Korean), and Suvi (Finnish).
Amazon Polly is a fully managed service that turns text into natural-sounding speech. This drop-in model upgrade makes Generative voices more natural and accurate. Complex content such as numbers, email addresses, and street addresses is designed to sound more reliable, reducing the need to fine-tune speech output. You can continue to use Speech Synthesis Markup Language (SSML) tags to control speech output on the Generative engine, just as before. The low-latency streaming API makes it easy to build contact center experiences, chatbots, and large language model (LLM) based agentic voice applications for real-time conversations. The richness and variety of voice options are also well suited for news, media, entertainment, e-learning, and accessibility use cases. This launch also expands the Amazon Polly Generative offering to AWS GovCloud, providing more options for public sector and regulated industries.
All new Generative voices are now available in the following AWS Regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (Zurich), Europe (London), Asia Pacific (Sydney), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central), and AWS GovCloud (US-West).
Today, we are introducing a new model behind the Amazon Polly Generative engine that delivers more natural-sounding, accurate speech output with low latency. With this upgrade, you get access to an enhanced voice portfolio with higher overall quality, 14 new voices across nine locales, and two new languages—Hindi and Finnish—now generally available on the Generative engine for the first time. New voices include Kenneth and Nate (US English), Russell and Curtis (Australian English), Kiara and Arjun (Hindi and Indian English), Tina (German), Carlos (US Spanish), Leo and Carolina (Brazilian Portuguese), Hyunduk (Korean), and Suvi (Finnish).
Amazon Polly is a fully managed service that turns text into natural-sounding speech. This drop-in model upgrade makes Generative voices more natural and accurate. Complex content such as numbers, email addresses, and street addresses is designed to sound more reliable, reducing the need to fine-tune speech output. You can continue to use Speech Synthesis Markup Language (SSML) tags to control speech output on the Generative engine, just as before. The low-latency streaming API makes it easy to build contact center experiences, chatbots, and large language model (LLM) based agentic voice applications for real-time conversations. The richness and variety of voice options are also well suited for news, media, entertainment, e-learning, and accessibility use cases. This launch also expands the Amazon Polly Generative offering to AWS GovCloud, providing more options for public sector and regulated industries.
All new Generative voices are now available in the following AWS Regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (Zurich), Europe (London), Asia Pacific (Sydney), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central), and AWS GovCloud (US-West).
To hear how Polly voices sound, go to Amazon Polly Features. For more details on the Polly offerings and use, see the Amazon Polly documentation and pricing page.
Avanzar en la soberanía digital con mayor control y elección
12 minuto
Por: Douglas Phillips, presidente y director de tecnología, Microsoft Specialized Clouds.
En mis conversaciones con líderes gubernamentales, infraestructuras críticas e industrias reguladas, una prioridad surge de manera constante: poner la tecnología a trabajar en sus sistemas más importantes mientras se mantiene el control que esos sistemas requieren.
Este desafío se vuelve más importante a medida que las capacidades avanzadas en la nube y la IA se trasladan a los servicios públicos, procesos regulados y operaciones esenciales. Las organizaciones consideran más que dónde residen los datos. También buscan entender quién puede acceder y operar sus sistemas, cómo permanecen protegidos los activos digitales sensibles, qué dependencias tecnológicas son las más importantes y si los servicios críticos pueden continuar a medida que cambien las condiciones regulatorias, geopolíticas, de seguridad o de red. La soberanía digital debería otorgar a las organizaciones mayor control y seguridad sobre la tecnología de la que dependen, al tiempo que continúan con la innovación.
El año pasado introdujimos Microsoft Sovereign Cloud para ofrecer a los clientes más opciones sobre cómo abordar estos requisitos. Desde entonces, hemos convertido nuestros compromisos en capacidades prácticas tanto en entornos de nube pública como operados por clientes, mientras ampliamos la manera en que permitimos a los socios abordar los requisitos de soberanía en sus mercados locales. Hoy, compartimos la siguiente etapa de ese trabajo.
Un continuo de control, construido en torno a la carga de trabajo
Nuestro enfoque de la soberanía digital comienza con la carga de trabajo. Cada carga de trabajo conlleva diferentes requisitos para datos, operaciones, dependencias tecnológicas, continuidad y riesgo. Microsoft Sovereign Cloud está diseñado para facilitar a las organizaciones la aplicación del nivel adecuado de control a cada carga de trabajo sin forzar a todas las aplicaciones a seguir el mismo modelo de despliegue.
Estas necesidades pueden variar mucho entre organizaciones. Un servicio digital público puede beneficiarse de la escala y el ritmo de innovación en la nube pública. Un sistema que soporte operaciones esenciales puede necesitar seguir en funcionamiento a nivel local si la conectividad se ve interrumpida. Una carga de trabajo de IA que maneja datos muy sensibles puede requerir que modelos, datos y procesamiento permanezcan dentro de un entorno controlado por el cliente.
Microsoft Sovereign Cloud está diseñado en torno a este enfoque basado en cargas de trabajo, para brindar un continuo de gestión, control y opciones a través de Sovereign Public Cloud, Sovereign Private Cloud y el Ecosistema de Socios Soberanos. Las organizaciones pueden aplicar el nivel de control adecuado a cada carga de trabajo y mantener un enfoque coherente en la gobernanza y las operaciones en todo su entorno digital. Sovereign Public Cloud añade capacidades para cargas de trabajo que requieren mayor control y transparencia, mientras continúa beneficiándose de la escala e innovación de Azure.
La Sovereign Private Cloud (Nube Privada Soberana) amplía las capacidades de la nube a entornos operados por el cliente, incluidas operaciones conectadas y desconectadas. El Ecosistema de Socios Soberanos amplía el continuo mediante entornos operados de forma independiente, socios especializados, experiencia relevante a nivel local y tecnologías que apoyan los requisitos de soberanía de los clientes.
No son destinos aislados. Los clientes pueden combinar capacidades de nube pública, nube privada y socios en todo su entorno digital, al aplicar diferentes niveles de control a distintas cargas de trabajo a medida que evolucionan sus necesidades operativas.
Hacer que el control sea más visible en la Nube Pública Soberana
Para muchas cargas de trabajo, la nube pública ofrece una combinación de escala, innovación, seguridad integrada y cumplimiento. Las organizaciones pueden beneficiarse de estas capacidades mientras aplican controles adicionales de soberanía para la residencia, confidencialidad, acceso del operador, políticas y continuidad. Nuestro trabajo en la Sovereign Public Cloud (Nube Pública Soberana) facilita la comprensión, la aplicación y la demostración de estos controles.
Sovereign Control Panel, que entra en vista previa pública en Microsoft Ignite, reúne estas señales en una experiencia unificada de portal Azure. Ayuda a las organizaciones a comprender su postura de soberanía, aplicar y gestionar controles, identificar lagunas y riesgos y tomar medidas para abordarlos. También apoya la preparación para la continuidad del negocio al ayudar a los clientes a comprender las dependencias de la carga de trabajo y evaluar la portabilidad entre entornos operativos cuando sea necesario.
Esta visibilidad complementa los controles a lo largo del ciclo de vida del acceso del operador. El acceso justo a tiempo y el Customer Lockbox ofrecen a los clientes un control adicional sobre el acceso a sus entornos. Para los clientes de la Unión Europea (UE) y la Asociación Europea de Libre Comercio (EFTA, por sus siglas en inglés), implementamos Data Guardian, que añade supervisión residente en Europa por parte de un socio de confianza de la UE para calificar el acceso remoto de ingenieros de Microsoft a sistemas de producción dentro del alcance. Production Touch Ledger, también lanzado con despliegue gradual en la UE y la EFTA, crea registros inviolables de ese acceso y de las acciones realizadas.
El Módulo de Seguridad de Hardware Gestionado (HSM, por sus siglas en inglés) de Azure Key Vault ya ofrece a los clientes protección y control dedicados y de un solo inquilino sobre las claves de cifrado utilizadas por los servicios de Azure compatibles. El año pasado, nos comprometimos a extender ese control más allá de la infraestructura de Microsoft. La gestión externa de claves con Azure Managed HSM ya está disponible a nivel general, lo que permite a los clientes mantener la clave raíz de cifrado en hardware que poseen y operar en las instalaciones o a través de un tercero de confianza. Esto ofrece a las organizaciones otra opción para cargas de trabajo que requieren control físico del hardware clave fuera de la infraestructura de Microsoft.
Azure Confidential Computing ayuda a proteger los datos soportados mientras se procesan en un entorno de ejecución confiable basado en hardware y con certificación. También aumentamos la transparencia sobre las tecnologías que sustentan esa confianza. Azure Confidential Clean Rooms, ahora en vista previa limitada, aplica la computación confidencial a la colaboración aprobada por varias partes, lo que permite a los participantes analizar datos sensibles compartidos mientras limitan la exposición más amplia de la información subyacente.
En conjunto, estas capacidades proporcionan controles técnicos y operativos adicionales que pueden apoyar una estrategia más amplia de soberanía digital alineada con los requisitos legales, políticos, de seguridad, resiliencia y negocio de la organización.
Diseñar para la resiliencia y la independencia operativa
Para algunas cargas de trabajo, la soberanía digital también significa mantener operaciones críticas a medida que cambian las condiciones de conectividad, geopolíticas y operativas. La resiliencia debe diseñarse desde el principio para que las cargas de trabajo esenciales puedan seguir con su operación a pesar de la interrupción.
Para ayudar a los clientes a prepararse para estos escenarios, publicamos nuevas guías y patrones de arquitectura de continuidad empresarial soberana. Estos recursos ayudan a las organizaciones a traducir los requisitos de resiliencia en arquitecturas que puedan planificar, implementar y probar antes de que sean necesarios.
Para muchas cargas de trabajo, la escala y el alcance geográfico de la nube pública proporcionan una base sólida para la resiliencia en diferentes ubicaciones y condiciones operativas. Para cargas de trabajo que requieren mayor independencia operativa, la Sovereign Private Cloud extiende ese continuo a entornos operados por el cliente. Soporta modelos operativos conectados y desconectados. La capacidad de transferir cargas de trabajo de operaciones conectadas a desconectadas va a entrar en vista previa pública, lo que otorga a las organizaciones mayor flexibilidad para mantener servicios críticos a medida que cambian los requisitos de conectividad y operativo.
Aportar más del ciclo de vida de la aplicación bajo control local
La independencia operativa requiere más que infraestructura. Cada vez más, las organizaciones necesitan datos, herramientas de desarrollo, capacidades de modelos y servicios de productividad de los que dependen sus aplicaciones para operar dentro del mismo entorno controlado por el cliente.
Sovereign Private Cloud, construida sobre Azure Local, amplía las capacidades de Microsoft Cloud a entornos que los clientes operan y controlan. SQL Server en Azure Local ya está disponible a nivel general para despliegues conectados y desconectados. DocumentDB y Blob Storage en Azure Local van a entrar en la vista previa, para dar a las organizaciones más opciones sobre cómo gestionar y gestionar datos críticos en entornos controlados por el cliente.
GitHub Enterprise Local estará disponible de manera general en Microsoft Ignite como un dispositivo validado de GitHub Enterprise Server en Azure Local, para ayudar a las organizaciones a mantener repositorios, código y artefactos de desarrollo bajo control local. Los desarrolladores también pueden usar GitHub Copilot con modelos alojados a nivel local para la inferencia, para acercar el desarrollo asistido por IA a su código y datos dentro de los entornos que controlan.
El entorno de aplicaciones locales se expande con Foundry Local. En Ignite, Foundry Local estará disponible de manera general para operaciones conectadas y desconectadas en Azure Local, con un catálogo ampliado de modelos que incluirá Microsoft, socios, modelos de peso abierto y de código abierto. La inferencia local y la recuperación agéntica también permitirán a los usuarios interactuar con datos empresariales locales por medio de lenguaje natural y recibir respuestas basadas en esos datos. La integración con Microsoft 365 Local, disponible en versión previa para clientes aprobados, extiende esta funcionalidad a los servidores de SharePoint y Exchange de Microsoft operados a nivel local.
Las máquinas virtuales confidenciales en Azure Local están disponibles de manera general, lo que extiende capacidades informáticas confidenciales a infraestructuras controladas por el cliente. La memoria cifrada por hardware y el aislamiento basado en hardware ayudan a proteger los datos sensibles mientras se procesan. La certificación de carga de trabajo añade garantía antes de que se liberen datos o claves sensibles. Para cargas de trabajo reguladas, sensibles y críticas para la misión, estas salvaguardas proporcionan otra capa de protección mientras otorgan a las organizaciones un mayor control sobre dónde se ejecutan sus datos y aplicaciones.
Azure Local soportará la multitenencia, lo que permite a las organizaciones separar recursos, gobernanza y gestión entre múltiples inquilinos mientras comparten la infraestructura subyacente. Esto amplía de manera significativa lo que los clientes con unidades de negocio o límites de seguridad distintos pueden lograr con la Sovereign Private Cloud. La multitenencia también crea nuevas oportunidades para que los operadores locales y proveedores de servicios ofrezcan servicios de nube soberana diferenciados en la infraestructura de Azure Local.
Estas incorporaciones abarcan una mayor parte del ciclo de vida de la aplicación bajo control local, para abarcar datos, desarrollo, productividad, IA y operaciones. Las organizaciones pueden determinar qué se ejecuta a nivel local en función de los requisitos de cada carga de trabajo.
Ampliación del continuo a través de socios
Navegar por la soberanía es cada vez más complejo. Los requisitos regulatorios, de seguridad, operativos y empresariales varían según países, industrias y cargas de trabajo. Las organizaciones deben traducir estas necesidades en modelos tecnológicos y operativos que funcionen en su contexto local. Satisfacer estas necesidades suele requerir una combinación de tecnología, autoridad operativa local, experiencia sectorial y soluciones especializadas.
El Ecosistema de Socios Soberanos amplía las formas en que los clientes pueden atender estos requisitos. Las nubes de socios nacionales, incluido Bleu en Francia, proporcionan entornos operados de manera independiente para clientes que requieren una propiedad y un modelo operativo diferentes. Los socios de software pueden mejorar entornos locales de Azure con capacidades que abarcan seguridad, identidad, observabilidad, copia de seguridad y recuperación, migración, datos, redes y aplicaciones. Los socios especializados en soberanía digital combinan tecnologías de Microsoft con conocimiento local y experiencia en implementación. Los socios de coinnovación de plataforma amplían la elección de infraestructura desde el centro de datos hasta el entorno.
Este ecosistema ofrece a los clientes la flexibilidad de combinar tecnología, modelos operativos y experiencia de confianza según los requisitos de cada carga de trabajo.
El próximo capítulo de la soberanía digital
La IA amplifica tanto la oportunidad como el impacto de las elecciones tecnológicas. A medida que los sistemas y agentes de IA interactúan con datos sensibles, procesos empresariales e infraestructuras esenciales, también amplían las consideraciones de seguridad que las organizaciones deben gestionar. Las organizaciones necesitan un control claro sobre dónde funcionan estos sistemas, quién puede operarlos, qué acciones pueden tomar y cómo continúan los servicios críticos cuando cambian las condiciones.
Microsoft Sovereign Cloud reúne estas opciones como un continuo de control a través de la nube pública, los entornos gestionados por los clientes y nuestro ecosistema de socios. Ofrece a las organizaciones la flexibilidad para aplicar el nivel adecuado de control a cada carga de trabajo mientras continúan beneficiándose de capacidades en la nube e innovación continua.
Seguiremos con la ampliación de este continuo para que las organizaciones puedan innovar con la nube y la IA, para mantener al mismo tiempo el control, la confidencialidad, la resiliencia y la autoridad operativa que requieren sus cargas de trabajo más importantes.
Douglas Phillips lidera los esfuerzos globales de ingeniería para las nubes especializadas, soberanas y privadas de Microsoft. Es responsable de la estrategia global, los productos y las operaciones de Microsoft que llevan las soluciones líderes en la industria de Microsoft, incluido Azure, nuestro portafolio de nube adaptativa y la suite de colaboración Microsoft 365, a clientes con requisitos adicionales de soberanía, seguridad, bordes y cumplimiento.
AWS IAM Identity Center now retains your workforce identities and their assignments when you change your identity source from Active Directory to an external identity provider (IdP), such as Okta or Microsoft Entra ID, or to the Identity Center directory. Specifically, it preserves your users, groups, group memberships, permission set assignments, and application assignments. Previously, this change required you to recreate them in IAM Identity Center.
IAM Identity Center helps you connect your workforce identities to AWS once and manage their access centrally across AWS applications and accounts. When you change your identity source from Active Directory, your existing identity store remains in place, so your users and groups keep the same IDs. As a result, users retain their access to AWS accounts and applications, and policies that reference your user IDs, group IDs, or identity store ID continue to work.
To make this change, configure your new identity source with the standard setup required for users to sign in. After the change, your workforce signs in through your dual-stack AWS access portal URL. Changing your identity source in the other direction, to Active Directory, works as before. This feature is available for organization instances of IAM Identity Center in all AWS Regions where IAM Identity Center is available. IAM Identity Center is provided at no additional cost.
To get started, navigate to the IAM Identity Center console. For more information, see Change your identity source in the IAM Identity Center User Guide. To learn more about IAM Identity Center, visit the product detail page.
AWS IAM Identity Center now retains your workforce identities and their assignments when you change your identity source from Active Directory to an external identity provider (IdP), such as Okta or Microsoft Entra ID, or to the Identity Center directory. Specifically, it preserves your users, groups, group memberships, permission set assignments, and application assignments. Previously, this change required you to recreate them in IAM Identity Center.
IAM Identity Center helps you connect your workforce identities to AWS once and manage their access centrally across AWS applications and accounts. When you change your identity source from Active Directory, your existing identity store remains in place, so your users and groups keep the same IDs. As a result, users retain their access to AWS accounts and applications, and policies that reference your user IDs, group IDs, or identity store ID continue to work.
To make this change, configure your new identity source with the standard setup required for users to sign in. After the change, your workforce signs in through your dual-stack AWS access portal URL. Changing your identity source in the other direction, to Active Directory, works as before. This feature is available for organization instances of IAM Identity Center in all AWS Regions where IAM Identity Center is available. IAM Identity Center is provided at no additional cost.
To get started, navigate to the IAM Identity Center console. For more information, see Change your identity source in the IAM Identity Center User Guide. To learn more about IAM Identity Center, visit the product detail page.
Amazon Connect Customer Global Resiliency now provides a Global Resiliency page in the admin website, giving administrators a single place to review their Region switch readiness. The page shows an overall readiness status and lists the resources that Global Resiliency natively replicates, including which resource types are in sync, which are still pending synchronization, and which need action. For example, if a phone number or user is not associated with a traffic distribution group, the page flags it and lets the administrator associate the affected resources directly from the page. With this readiness overview, administrators can review their resiliency posture at any time and verify that their instance is ready for a Region switch.
Amazon Connect Customer Global Resiliency now provides a Global Resiliency page in the admin website, giving administrators a single place to review their Region switch readiness. The page shows an overall readiness status and lists the resources that Global Resiliency natively replicates, including which resource types are in sync, which are still pending synchronization, and which need action. For example, if a phone number or user is not associated with a traffic distribution group, the page flags it and lets the administrator associate the affected resources directly from the page. With this readiness overview, administrators can review their resiliency posture at any time and verify that their instance is ready for a Region switch.
This feature is available in all AWS Regions where Amazon Connect Customer Global Resiliency is supported. To learn more, see Amazon Connect Customer admin guide.
AWS announces that Amazon CloudWatch Omni is now available in eight additional AWS Regions. CloudWatch Omni is an AI-powered observability experience, organized around your teams and the applications they run, that helps you observe and troubleshoot your applications and agents in one place. It combines the interoperability of OpenTelemetry with the scale and reliability of CloudWatch, and meets you where you work — a standalone web experience with single sign-on (SSO), or a local IDE extension.
With CloudWatch Omni, You create spaces in your central accounts to see telemetry across your AWS accounts, Regions, and other clouds, including Azure and GCP. Omni discovers services, maps dependencies, and surfaces golden metrics automatically and you can interact with telemetry through chat, point-and-click, or your own tool via Agent Toolkit for AWS to find signals, build dynamic views, and reach root cause powered by AWS DevOps Agent. A dedicated agent observability experience adds an evaluation-driven workflow for frameworks including LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK, and Strands.
With this expansion, CloudWatch Omni is now available in Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (London), and South America (São Paulo), in addition to US East (N. Virginia), US West (Oregon), and Europe (Ireland).
AWS announces that Amazon CloudWatch Omni is now available in eight additional AWS Regions. CloudWatch Omni is an AI-powered observability experience, organized around your teams and the applications they run, that helps you observe and troubleshoot your applications and agents in one place. It combines the interoperability of OpenTelemetry with the scale and reliability of CloudWatch, and meets you where you work — a standalone web experience with single sign-on (SSO), or a local IDE extension.
With CloudWatch Omni, You create spaces in your central accounts to see telemetry across your AWS accounts, Regions, and other clouds, including Azure and GCP. Omni discovers services, maps dependencies, and surfaces golden metrics automatically and you can interact with telemetry through chat, point-and-click, or your own tool via Agent Toolkit for AWS to find signals, build dynamic views, and reach root cause powered by AWS DevOps Agent. A dedicated agent observability experience adds an evaluation-driven workflow for frameworks including LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK, and Strands.
With this expansion, CloudWatch Omni is now available in Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (London), and South America (São Paulo), in addition to US East (N. Virginia), US West (Oregon), and Europe (Ireland).
To get started, create your Omni space from the CloudWatch console, configure SSO, and sign in. Agent developers can install the free CloudWatch Omni extension for VS Code, Cursor, and Kiro. To learn more, see the Amazon CloudWatch Omni product page and documentation. For pricing, see the CloudWatch Omni pricing page.
Amazon Bedrock now supports SpaceXAI Grok 4.7, a frontier model built for coding, agentic tasks, and knowledge work in AWS GovCloud (US).
Grok 4.7 builds on Grok 4.6 with better mixed-document handling, more dependable repo-scale coding with planning and error recovery, and enhanced browser-use agents for form fills and portal navigation.
Get started with Grok 4.7 in the Amazon Bedrock console or programmatically through supported Amazon Bedrock APIs. For information about supported AWS Regions, endpoints, APIs, features, inference profiles and pricing, see the Amazon Bedrock documentation. To learn more, read the launch blog post.
Amazon Bedrock now supports SpaceXAI Grok 4.7, a frontier model built for coding, agentic tasks, and knowledge work in AWS GovCloud (US).
Grok 4.7 builds on Grok 4.6 with better mixed-document handling, more dependable repo-scale coding with planning and error recovery, and enhanced browser-use agents for form fills and portal navigation.
Get started with Grok 4.7 in the Amazon Bedrock console or programmatically through supported Amazon Bedrock APIs. For information about supported AWS Regions, endpoints, APIs, features, inference profiles and pricing, see the Amazon Bedrock documentation. To learn more, read the launch blog post.
Por: Hayete Gallot , vicepresidenta ejecutiva, Microsoft Security.
En los últimos meses, han surgido preocupaciones sobre la seguridad de la IA a medida que se han hecho públicos un número creciente de incidentes. Estos incidentes han puesto de manifiesto lo poderosos que se han vuelto los modelos y cómo representan una amenaza significativa si no se gestionan bien. Y con la carrera global hacia la innovación, el desafío se agravará a medida que los modelos se vuelvan aún más potentes.
Aunque la mayoría ha estado preocupada porque los actores maliciosos usen modelos poderosos para atacar, el foco ha sido menos en los agentes dentro de nuestras propias paredes. Como fuimos nosotros quienes desplegábamos agentes a nivel interno para nuestras empresas, confiábamos de manera implícita en ellos.
Por desgracia, los modelos Frontier, sin importar su origen, no pueden ser de fiar. Esto no se debe a que los modelos sean inherentemente maliciosos. Los modelos han sido entrenados para obtener resultados, lo que a menudo conduce a recompensar el hacking, y los modelos no están optimizados en torno a las normas o juicios organizativos. Los agentes son impredecibles. Se adaptarán a medida que cambia el contexto, pueden no comportarse como se espera y colaborarán y coludirán con otros agentes para alcanzar sus objetivos, sin necesidad de ser comprometidos.
Se han desatado agentes en la empresa, a gran escala, y su número crece con rapidez. Estos agentes suelen estar sobrevalorados, tienen acceso a datos, herramientas y sistemas, y pueden tomar acciones y tomar decisiones en procesos críticos. Se han convertido en participantes activos en la empresa.
Son agentes internos.
La monitorización y la seguridad de esos agentes debe volverse continua. Necesitamos entender en tiempo real qué hacen los agentes y qué riesgos suponen esas acciones, y ajustar su capacidad para actuar en consecuencia.
Para gestionar y controlar a estos insiders, necesitaremos Guardian Agents —un término establecido en la industria— que vigilen y moderen cada acción de cada agente, antes de que ocurra, las 24 horas del día, los 7 días de la semana.
Un agente reúne un modelo, un arnés que orquesta su trabajo, un espacio de acciones de herramientas y recursos y un tiempo de ejecución en el que se ejecuta. Asegurar agentes requiere protección a través de múltiples capas: identidad, permisos, datos, endpoints, red, nube y tiempo de ejecución.
En julio, anunciamos el Proyecto Perception, un sistema de seguridad agente que utiliza nuestra nueva pila cibernética y equipos de agentes rojos, azules y verdes para ayudar a los defensores a actuar con rapidez, mientras se defienden de ataques impulsados por IA desde fuera de la empresa.
La misma pila cibernética también es aplicable de manera directa a la gestión y gobernanza de los insiders agénticos que operan en la empresa.
El Proyecto Perception puede aprovecharse para contener a insiders agénticos, a través de la implementación de controles deterministas sobre inteligencia no determinista:
Sensores/Señales/Actuadores: reúnen señales entre los distintos sensores (identidad, datos, nube, punto final, red, tiempo de ejecución) para descubrir agentes en la empresa y ponerlos bajo gestión a través de asignar una identidad, contenedor y conjunto de políticas y permisos.
Contexto: utiliza esas señales para calcular, de manera dinámica, el riesgo asociado a lo que los agentes intentan hacer.
Aprovechamiento/agentes/modelos: basados en el riesgo dinámico de los agentes, un equipo de Guardian Agents, con agentes verdes y azules, supervisa de manera activa y continua cada acción de cada agente y responde de manera quirúrgica a medida que aumenta el perfil de riesgo, en tiempo real.
Aquí es donde la seguridad agéntica cambia la ecuación para los profesionales de la seguridad.
El Proyecto Perception puede supervisar en tiempo real mientras proporciona trazabilidad para que los profesionales examinen lo ocurrido, comprendan por qué surgió el riesgo y apliquen el juicio necesario para actualizar su sistema de seguridad en consecuencia. La seguridad agéntica proporciona rapidez.Los profesionales proporcionan juicio. Así es como los defensores empiezan a operar a la misma velocidad que los sistemas contra los que se protegen.
Hoy en día, los sistemas de seguridad pueden observar de manera fiable las acciones de los agentes. Esas señales son esenciales y nos indican qué debemos contener. Nuestros controles de seguridad deberían poder preguntar no solo «¿Qué ocurre?» sino también «¿Por qué ocurre?» ¿Es esto coherente con la intención de la tarea?» Esto requerirá mayor transparencia sobre el propio modelo, no solo los tokens de entrada y salida, sino también los tokens de pensamiento y cadena de pensamiento. Solo entonces podremos entender en verdad si la intención del modelo está alineada con el propósito del agente. La transparencia del modelo no reemplazará al contención. Hará que el contención sea más inteligente y más fuerte. Y nos permitirá informar mejor la responsabilidad y la trazabilidad. Este debe ser el siguiente paso para asegurar a los internos agentes.
Hayete Gallot lidera el trabajo de Microsoft para ayudar a las organizaciones a operar de manera segura en un mundo impulsado por IA. Su ámbito incluye identidad, protección contra amenazas, cumplimiento normativo y seguridad de datos a escala global.
