Publicado el — Deja un comentario

IA Responsable en 2026: Cómo nos adaptamos a lo que viene

IA Responsable en 2026: Cómo nos adaptamos a lo que viene

Fondo geométrico abstracto con rectángulos y cuadrados translúcidos superpuestos en tonos azul, índigo y lavanda. Los degradados suaves y las texturas granuladas crean una composición moderna y en capas, con una estética digital y contemporánea.

Por: Natasha Crampton, directora de IA Responsable.

Microsoft ha publicado su Informe de Transparencia en IA Responsable 2026. El informe destaca los avances que hemos logrado en la construcción y despliegue de la IA de manera responsable, el apoyo a nuestros clientes y el fortalecimiento de nuestra gobernanza, herramientas y prácticas responsables en IA. Pueden explorar el informe completo en inglés aquí.

La IA avanza con rapidez, y también las expectativas sociales. Los límites de lo que las personas pueden lograr con la IA se amplían, y las comunidades se hacen más preguntas sobre cómo se diseñan, construyen y utilizan los sistemas de IA. A medida que la IA se vuelve más integral en cómo vivimos y trabajamos, la confianza en que los sistemas de IA funcionan de manera fiable y segura se ha comenzado a convertir en un requisito esencial para su adopción amplia y beneficiosa.

En Microsoft, llevamos casi una década en la construcción de un programa de IA responsable, basado en dos creencias fundamentales: que la confianza es fundamental para aprovechar los beneficios de la IA y que el empoderamiento de las personas y organizaciones debe permanecer en el centro de nuestra estrategia. A medida que las capacidades avanzan y la adopción se acelera, esa experiencia nos ayuda a afrontar este momento y adaptarnos a lo que venga.

Nuestro tercer Informe anual de Transparencia en IA Responsable comparte cómo evoluciona nuestro programa y las prioridades que moldean nuestro trabajo. Durante el último año, invertir en tres áreas específicas nos ha permitido afianzar la confianza de manera más profunda y a mayor escala: gobernanza adaptativa y gestión técnica de riesgos, herramientas y capacidades prácticas, y prácticas compartidas y alianzas sólidas. Estas inversiones atraviesan cinco tendencias que dan forma el panorama de la IA, incluida la rápida expansión de la IA agéntica.

Infografía que presenta cinco tendencias clave de la inteligencia artificial: adopción acelerada, expansión de capacidades generativas y agénticas, mayor uso de IA conversacional, incremento de riesgos de fraude y evolución de la regulación.

En conjunto, estas tendencias e inversiones subrayan nuestra visión de que la capacidad del modelo por sí sola no determinará el impacto de la IA. Eso dependerá de organizaciones que desarrollen y desplieguen tecnologías de IA que aporten un valor real —y las gobiernen con el rigor y la adaptabilidad necesarios para ganarse y mantener la confianza.

Gobernanza adaptativa y gestión técnica de riesgos

A medida que avanzan las fronteras de la IA, hacemos que nuestra gobernanza sea más adaptativa e integrada de manera más estrecha con los flujos de trabajo de ingeniería. En la práctica, esto significa que hemos actualizado nuestras políticas para adaptarnos mejor a la pila tecnológica de IA y a la cadena de valor de IA, hemos evolucionado nuestras prácticas de gestión de riesgos para abordar las capacidades y riesgos emergentes de IA, y hemos fortalecido la preparación de nuestra comunidad responsable de IA: las personas que operacionalizan nuestro programa a escala empresarial.

Este año, hemos rediseñado nuestro Estándar de IA Responsable para hacerlo más adaptativo a las realidades técnicas en evolución, usos, riesgos y requisitos regulatorios. El nuevo Estándar está estructurado en referencia a diferentes componentes de la pila tecnológica —modelos, servicios de plataforma y aplicaciones— y al papel que desempeña Microsoft en el desarrollo o despliegue de esos componentes. Combina requisitos fundamentales que siempre se aplican con requisitos más específicos y enfocados en escenarios específicos, que pueden evolucionar a medida que cambian las capacidades y riesgos. Por ejemplo, aplicamos algunas de nuestras medidas de gestión de riesgos más rigurosas a sistemas de IA con las capacidades cibernéticas más significativas, lo que ayuda a garantizar que los avances en IA favorezcan a los defensores responsables de proteger infraestructuras digitales críticas.

También evolucionamos nuestras prácticas técnicas de gestión de riesgos. Sistemas cada vez más capaces pueden conservar memoria, usar herramientas, acceder a datos y tomar acciones en nombre de los usuarios. Gobernar estos sistemas requiere que pensemos más allá del comportamiento de un modelo o aplicación individual para centrarnos en las interacciones entre modelos, agentes, aplicaciones, herramientas, datos y personas. Nuestro trabajo se centra cada vez más en controles como la identidad de los agentes, permisos de herramientas y monitorización de acciones.

Y la gobernanza solo funciona cuando la gente puede ponerla en práctica. Hemos seguido con el desarrollo de capacidades de IA responsable en Microsoft, para dotar a miles de ingenieros y gestores de producto con formación en temas como el modelado de amenazas por IA agéntica y las defensas por inyección de prompts.

Juntas, estas inversiones nos ayudan a avanzar hacia un enfoque más continuo y basado en el ciclo de vida de la gobernanza de la IA. Con la IA agéntica, los riesgos pueden evolucionar a medida que los sistemas interactúan con sus entornos, usuarios y otros sistemas. Nuestra gobernanza debe evolucionar con estas capacidades agénticas—e incorporar lo que aprendamos de sus pruebas y despliegue.

Herramientas y capacidades prácticas

Una gobernanza eficaz depende de herramientas que ayuden a traducir los objetivos políticos en acción. A medida que desarrolladores y organizaciones navegan por un entorno técnico y regulatorio más complejo, necesitan formas prácticas de identificar riesgos, evaluar sistemas, establecer controles y monitorizar cómo se comporta la IA en el mundo real.

Aplicamos lo que aprendemos al gobernar la IA en Microsoft en herramientas, capacidades y recursos que ayudan a desarrolladores y organizaciones más allá de Microsoft a hacer justo eso, ya sea que construyan sobre nuestras plataformas o aprovechen proyectos de código abierto.

Hemos ampliado las herramientas para evaluar sistemas de IA a lo largo del ciclo de vida. Un nuevo Agente de Equipo Rojo de IA ayuda a acelerar la identificación y evaluación de riesgos. Los evaluadores de agentes ayudan a los desarrolladores a medir la calidad, seguridad y rendimiento de las aplicaciones agentes. RAMPART convierte los hallazgos del equipo rojo en pruebas repetibles, lo que permite una cobertura más continua a medida que cambian los sistemas.

También construimos mayor visibilidad y control en los sistemas agénticos. Con ASSERT y la Especificación de Control de Agentes, los desarrolladores pueden evaluar a los agentes en función de sus políticas, colocar controles en tiempo de ejecución en puntos críticos del flujo de trabajo del agente y monitorizar el comportamiento.

Estas herramientas y capacidades reflejan un cambio: a medida que los sistemas se vuelven más dinámicos, la gobernanza debe volverse más operativa. Las organizaciones deben poder ver qué hacen sus sistemas, probar cómo se comportan e intervenir cuando sea necesario, no solo evaluarlos antes de su despliegue.

Las organizaciones también necesitan confianza—y cada vez más demostrar—que las prácticas responsables de IA se implementan de manera consistente. Microsoft es una de las pocas empresas certificadas bajo ISO 42001 en un amplio portafolio, incluidos Microsoft 365 Copilot, Foundry y GitHub Copilot. Durante el último año, hemos simplificado y fortalecido nuestros procesos internos que apoyan esa certificación.

En última instancia, la gobernanza responsable de la IA es una responsabilidad compartida a lo largo de toda la cadena de valor de la IA. Nuestro objetivo es ayudar a que las prácticas y capacidades necesarias para cumplir con esa responsabilidad sean más accesibles, prácticas y escalables.

Prácticas compartidas y sólidas alianzas

Los retos de gobernar la IA son mayores que los de cualquier empresa, y los sistemas de IA cada vez más interconectados hacen que la colaboración sea aún más esencial.

A medida que la adopción de la IA se expande más allá de fronteras y sectores, necesitamos expectativas compartidas sobre cómo se evalúan, supervisan y gobiernan los sistemas, así como estándares interoperables que permitan visibilidad de las interacciones entre herramientas, datos y sistemas. También debemos seguir con el avance en la ciencia subyacente y las prácticas técnicas para poder beneficiarnos de una visión rigurosa y aplicada sobre cómo es una gobernanza efectiva y dónde están las lagunas restantes.

Eso comienza con la investigación. Durante el último año, hemos avanzado nuestro trabajo con el Centro de Estándares e Innovación en IA de EE. UU. y con los Institutos de Seguridad y Protección en IA en Australia, Singapur y el Reino Unido para fortalecer la ciencia y la práctica de la evaluación de IA. También lanzamos una Alianza de Equipos Rojos Externos con 18 universidades de seis continentes para ampliar la comprensión de los riesgos prioritarios.

Las prácticas técnicas y estándares comunes son fundamentales. A través del Frontier Model Forum, OpenTelemetry y la Fundación Appia, ayudamos a desarrollar enfoques que abarcan benchmarks cibernéticos de frontera, observabilidad de extremo a extremo para sistemas cada vez más agénticos y garantía de IA en cadenas de suministro y sectores. También contribuimos a esfuerzos que hacen que la información de transparencia sea más interoperable entre organizaciones y jurisdicciones, incluido un grupo de trabajo informal liderado por la OCDE que desarrolló el Hiroshima AI Process Reporting Framework versión 2.0.

También necesitamos formas compartidas de medir el progreso. No podemos evaluar de forma significativa el progreso si cada organización mide los riesgos de IA de forma diferente. A través de nuestro trabajo con MLCommons, ayudamos a expandir AILuminate hacia un conjunto más amplio de referencias de fiabilidad, lo que crea enfoques comunes para evaluar áreas como la resiliencia a jailbreaks, el rendimiento multilingüe y el riesgo psicosocial en IA conversacional.

El aprendizaje compartido, las prácticas y estándares compartidos, y la medición compartida pueden ayudar a que todo el ecosistema se desarrolle mientras elevan expectativas compartidas de confianza.

Enfrentar el momento e invertir en el futuro

Nuestra experiencia durante el último año ha reforzado que la IA responsable no puede ser estática. Debe estar integrada en los procesos de desarrollo, apoyada por herramientas prácticas e informada de manera continua por lo que aprendemos. Por eso nuestras inversiones en IA responsable van desde los sistemas que construimos, hasta las herramientas que ofrecemos a nuestros clientes, además de pasar por la investigación, las prácticas y enfoques de medición que ayudamos a desarrollar en el ecosistema más amplio.

Nuestro Informe 2026 sobre Transparencia en IA Responsable explora este trabajo con más profundidad: desde cómo reingenierizamos nuestro Estándar de IA Responsable hasta cómo fortalecemos la gobernanza de la IA agéntica, para avanzar en la evaluación y abordar el mal uso de la IA. Los invitamos a explorar el informe para ver qué hemos aprendido, qué hemos cambiado y cómo ponemos en práctica nuestras prioridades.

A medida que la IA se vuelve más poderosa y presente en la vida de las personas, nuestro compromiso es escuchar y aprender siempre, para reforzar nuestras salvaguardas y poner el empoderamiento de las personas y las organizaciones en el centro de nuestra estrategia.

Publicado en Microsoft on the Issues.

The post IA Responsable en 2026: Cómo nos adaptamos a lo que viene appeared first on Source LATAM.

 

​The post IA Responsable en 2026: Cómo nos adaptamos a lo que viene appeared first on Source LATAM.  

Publicado el — Deja un comentario

AWS Elemental MediaTailor introduces in-console analytics dashboard for ad monetization and streaming performance

AWS Elemental MediaTailor now includes an analytics dashboard built directly into the AWS Management Console, giving publishers a global and multi-region view of ad monetization and streaming performance — with the ability to compare across regions and drill into individual playback configurations.

The dashboard surfaces key business metrics including fill rate, ad impression rate, video completion rate, and impression recovery data — showing publishers exactly how many billable impressions they are recovering through MediaTailor’s server-side beacon retry logic.

The analytics dashboard is available in all AWS Regions where AWS Elemental MediaTailor is available. The dashboard uses Amazon CloudWatch, which provides a free tier of usage. Some dashboard components use ListMetrics API calls, and pricing applies for usage beyond the free tier. See Amazon CloudWatch pricing for details. Additional streaming metrics, reporting dimensions, and visualizations will be added in subsequent releases to the dashboard.

To learn more, see Monitoring ad insertion performance with the analytics dashboard in the AWS Elemental MediaTailor User Guide.

 

​AWS Elemental MediaTailor now includes an analytics dashboard built directly into the AWS Management Console, giving publishers a global and multi-region view of ad monetization and streaming performance — with the ability to compare across regions and drill into individual playback configurations.
The dashboard surfaces key business metrics including fill rate, ad impression rate, video completion rate, and impression recovery data — showing publishers exactly how many billable impressions they are recovering through MediaTailor’s server-side beacon retry logic.
The analytics dashboard is available in all AWS Regions where AWS Elemental MediaTailor is available. The dashboard uses Amazon CloudWatch, which provides a free tier of usage. Some dashboard components use ListMetrics API calls, and pricing applies for usage beyond the free tier. See Amazon CloudWatch pricing for details. Additional streaming metrics, reporting dimensions, and visualizations will be added in subsequent releases to the dashboard.
To learn more, see Monitoring ad insertion performance with the analytics dashboard in the AWS Elemental MediaTailor User Guide.  

Publicado el — Deja un comentario

Amazon CloudWatch now supports warm-up periods for alarms

Amazon CloudWatch now lets you configure a warm-up period for metric alarms and log alarms, delaying alarm evaluation for a set time after the alarm is created. This reduces noise from missing data while a new resource or service starts up and begins publishing metrics. For example, a team that provisions a new microservice and its alarms together through a CI/CD pipeline can attach a warm-up period so alarms do not page the on-call engineer while the service is still starting up and has not yet published metrics.

Previously, when you created an alarm before the underlying metric was reporting data, CloudWatch evaluated the alarm right away using its «treat missing data» setting. For resources that take time to begin emitting metrics, such as a newly deployed application or service, this could cause the alarm to transition state and run actions on missing data during startup, triggering unnecessary notifications. A warm-up period fixes this by giving you two ways to hold off evaluation during startup: wait a fixed duration you set before evaluation begins, or let CloudWatch start evaluating automatically as soon as the metric actually has enough data to fill the alarm’s evaluation window.

You set the warm-up period with the WarmUpConfiguration parameter when you create or update an alarm. Specify a warm-up duration from 1 to 2,880 minutes (2 days). By default, the alarm ends warm-up early and begins evaluating as soon as enough data fills its evaluation window. Additionally, you can optionally require the alarm to wait the full duration before evaluating.

Warm-up periods are available in all AWS Regions where Amazon CloudWatch is offered at no additional charge beyond standard CloudWatch alarm pricing.

To get started, see  Alarm warm-up periods  and  Create an alarm that uses a warm-up period  in the Amazon CloudWatch User Guide.

 

​Amazon CloudWatch now lets you configure a warm-up period for metric alarms and log alarms, delaying alarm evaluation for a set time after the alarm is created. This reduces noise from missing data while a new resource or service starts up and begins publishing metrics. For example, a team that provisions a new microservice and its alarms together through a CI/CD pipeline can attach a warm-up period so alarms do not page the on-call engineer while the service is still starting up and has not yet published metrics.

Previously, when you created an alarm before the underlying metric was reporting data, CloudWatch evaluated the alarm right away using its «treat missing data» setting. For resources that take time to begin emitting metrics, such as a newly deployed application or service, this could cause the alarm to transition state and run actions on missing data during startup, triggering unnecessary notifications. A warm-up period fixes this by giving you two ways to hold off evaluation during startup: wait a fixed duration you set before evaluation begins, or let CloudWatch start evaluating automatically as soon as the metric actually has enough data to fill the alarm’s evaluation window.

You set the warm-up period with the WarmUpConfiguration parameter when you create or update an alarm. Specify a warm-up duration from 1 to 2,880 minutes (2 days). By default, the alarm ends warm-up early and begins evaluating as soon as enough data fills its evaluation window. Additionally, you can optionally require the alarm to wait the full duration before evaluating.

Warm-up periods are available in all AWS Regions where Amazon CloudWatch is offered at no additional charge beyond standard CloudWatch alarm pricing.

To get started, see  Alarm warm-up periods  and  Create an alarm that uses a warm-up period  in the Amazon CloudWatch User Guide.  

Publicado el — Deja un comentario

Amazon DocumentDB now supports direct major version upgrades to version 8.0

Amazon DocumentDB (with MongoDB compatibility) now supports in-place major version upgrades (MVU) directly from engine versions 3.6 and 4.0 to version 8.0. This upgrade capability removes the need for intermediate version upgrades and allows you to upgrade your version 3.6 or 4.0 clusters while preserving existing data, configurations, and cluster settings.

Upgrading to version 8.0 provides access to the latest security patches, performance improvements, and new developer capabilities. Major version upgrades from DocumentDB 3.6 and 4.0 to 8.0 are available in all AWS regions where these versions are currently supported.

To learn more about upgrading to Amazon DocumentDB 8.0, including detailed guidance on version differences and upgrade paths, visit the Amazon DocumentDB MVU documentation, review version support dates, and explore the full list of new capabilities on the Amazon DocumentDB 8.0 announcement page.

 

​Amazon DocumentDB (with MongoDB compatibility) now supports in-place major version upgrades (MVU) directly from engine versions 3.6 and 4.0 to version 8.0. This upgrade capability removes the need for intermediate version upgrades and allows you to upgrade your version 3.6 or 4.0 clusters while preserving existing data, configurations, and cluster settings.
Upgrading to version 8.0 provides access to the latest security patches, performance improvements, and new developer capabilities. Major version upgrades from DocumentDB 3.6 and 4.0 to 8.0 are available in all AWS regions where these versions are currently supported.
To learn more about upgrading to Amazon DocumentDB 8.0, including detailed guidance on version differences and upgrade paths, visit the Amazon DocumentDB MVU documentation, review version support dates, and explore the full list of new capabilities on the Amazon DocumentDB 8.0 announcement page.  

Publicado el — Deja un comentario

Partner Revenue Measurement expands service coverage for User Agent string capability

Partner Revenue Measurement User Agent string now supports additional AWS services. Partner Revenue Measurement allows Partners to better understand their AWS revenue impact and product consumption patterns. Previously, the User Agent string capability measured AWS service consumption across select services. With this expansion, Partners can now measure attributed revenue across additional applicable AWS services that log control plane activity in AWS CloudTrail, significantly increasing the visibility Partners have into the revenue their solutions drive.

Partners who have already embedded a user agent (format APN_1.1/pc_<AWS Marketplace product-code>$) in their applications automatically benefit from the expanded coverage with no additional implementation needed. The additional service consumption measured through this expansion is now visible in the Attributed Revenue Dashboard, accessible through Partner Analytics in AWS Partner Central on the AWS Console. This User Agent string method complements Partner Revenue Measurement’s Resource Tagging and AWS Marketplace Metering integration capabilities.

Partner Revenue Measurement is generally available in all commercial regions. To learn more about User Agent string implementation or other Partner Revenue Measurement capabilities, review the onboarding guide and services supported.

 

​Partner Revenue Measurement User Agent string now supports additional AWS services. Partner Revenue Measurement allows Partners to better understand their AWS revenue impact and product consumption patterns. Previously, the User Agent string capability measured AWS service consumption across select services. With this expansion, Partners can now measure attributed revenue across additional applicable AWS services that log control plane activity in AWS CloudTrail, significantly increasing the visibility Partners have into the revenue their solutions drive.
Partners who have already embedded a user agent (format APN_1.1/pc_<AWS Marketplace product-code>$) in their applications automatically benefit from the expanded coverage with no additional implementation needed. The additional service consumption measured through this expansion is now visible in the Attributed Revenue Dashboard, accessible through Partner Analytics in AWS Partner Central on the AWS Console. This User Agent string method complements Partner Revenue Measurement’s Resource Tagging and AWS Marketplace Metering integration capabilities.
Partner Revenue Measurement is generally available in all commercial regions. To learn more about User Agent string implementation or other Partner Revenue Measurement capabilities, review the onboarding guide and services supported.  

Publicado el — Deja un comentario

AWS Agent Registry agents and MCP servers now available in Amazon Quick

Today, Amazon Quick announces integration with AWS Agent Registry, enabling users to discover and use resources from their organization’s AWS Agent Registry directly within Amazon Quick. AWS Agent Registry supports MCP servers and agents, which users can now search and browse directly within Amazon Quick. After finding the agent or MCP server they need, users can enable it with a few clicks. Connection details are already populated from the registry. Once enabled, these resources can be shared with teams for use across chat, agents, apps, flows, and deep research. 

This integration bridges the gap between technical teams who build agents with Amazon Bedrock AgentCore and business users who work in Amazon Quick. Organizations no longer need to manually configure connections to agents and tools that already exist in their AWS Agent Registry. Business users get access through their familiar Amazon Quick workspace without duplicate effort. 

Amazon Quick integration with AWS Agent Registry is available in all AWS Regions where both Amazon Quick and Amazon Bedrock AgentCore are available. This includes US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland). 

To get started, open the Amazon Quick admin console and go to Manage account, Permissions, AWS Agent Registry to connect your registry. To learn more, see the Amazon Quick Integrations documentation and the AWS Agent Registry documentation.

 

​Today, Amazon Quick announces integration with AWS Agent Registry, enabling users to discover and use resources from their organization’s AWS Agent Registry directly within Amazon Quick. AWS Agent Registry supports MCP servers and agents, which users can now search and browse directly within Amazon Quick. After finding the agent or MCP server they need, users can enable it with a few clicks. Connection details are already populated from the registry. Once enabled, these resources can be shared with teams for use across chat, agents, apps, flows, and deep research. 
This integration bridges the gap between technical teams who build agents with Amazon Bedrock AgentCore and business users who work in Amazon Quick. Organizations no longer need to manually configure connections to agents and tools that already exist in their AWS Agent Registry. Business users get access through their familiar Amazon Quick workspace without duplicate effort. 
Amazon Quick integration with AWS Agent Registry is available in all AWS Regions where both Amazon Quick and Amazon Bedrock AgentCore are available. This includes US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), and Europe (Ireland). 
To get started, open the Amazon Quick admin console and go to Manage account, Permissions, AWS Agent Registry to connect your registry. To learn more, see the Amazon Quick Integrations documentation and the AWS Agent Registry documentation.  

Publicado el — Deja un comentario

Amazon Redshift now supports AWS IAM Identity Center authentication with enhanced VPC routing

Amazon Redshift now supports AWS IAM Identity Center authentication for provisioned clusters and serverless workgroups configured with enhanced VPC routing (EVR). You can access Amazon Redshift with single sign-on with your corporate credentials, and the traffic traverses Amazon Virtual Private Cloud (Amazon VPC) and stays on the AWS network. This is valuable for customers with data residency, regulatory, or network-isolation requirements that mandate no public internet egress for analytics.

With Redshift EVR, all traffic between your Redshift warehouse and other AWS services goes through your VPC, where you can govern it with security groups, network ACLs, and endpoint policies, and observe it in VPC Flow Logs. With this launch, Redshift validates and exchanges IAM Identity Center tokens over AWS PrivateLink interface VPC endpoints from inside your VPC, so authentication and authorization follows the same governed network path as the rest of your Redshift traffic. This feature also supports IAM Identity Center multi-Region replication for customers running Redshift in a different Region than their primary Identity Center instance.

Read the Amazon Redshift enhanced VPC routing documentation and the blog post to get started. This capability is available in all AWS Regions where both Amazon Redshift and IAM Identity Center are available. 

 

​Amazon Redshift now supports AWS IAM Identity Center authentication for provisioned clusters and serverless workgroups configured with enhanced VPC routing (EVR). You can access Amazon Redshift with single sign-on with your corporate credentials, and the traffic traverses Amazon Virtual Private Cloud (Amazon VPC) and stays on the AWS network. This is valuable for customers with data residency, regulatory, or network-isolation requirements that mandate no public internet egress for analytics.
With Redshift EVR, all traffic between your Redshift warehouse and other AWS services goes through your VPC, where you can govern it with security groups, network ACLs, and endpoint policies, and observe it in VPC Flow Logs. With this launch, Redshift validates and exchanges IAM Identity Center tokens over AWS PrivateLink interface VPC endpoints from inside your VPC, so authentication and authorization follows the same governed network path as the rest of your Redshift traffic. This feature also supports IAM Identity Center multi-Region replication for customers running Redshift in a different Region than their primary Identity Center instance.
Read the Amazon Redshift enhanced VPC routing documentation and the blog post to get started. This capability is available in all AWS Regions where both Amazon Redshift and IAM Identity Center are available.   

Publicado el — Deja un comentario

Amazon Timestream for InfluxDB is now available in 8 additional AWS Regions

You can now use Amazon Timestream for InfluxDB in the Africa (Cape Town), Asia Pacific (Bangkok), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Asia Pacific (Seoul), Europe (Zurich), and Israel (Tel Aviv) AWS Regions. Timestream for InfluxDB makes it easy for application developers and DevOps teams to run fully managed InfluxDB databases on AWS for real-time time-series applications using open-source APIs.

Timestream for InfluxDB offers Multi-AZ high availability, read replicas, enhanced durability, and multi-node scaling — giving you flexible deployment options to match your workload as it evolves. Whether you’re starting with a single-node setup or scaling to a 15-node Enterprise cluster, you can right-size your infrastructure without re-architecting.

You can create your InfluxDB databases using the Amazon Timestream for InfluxDB console. AWS CLI, or AWS SDKs . Amazon Timestream for InfluxDB is available in the following AWS Regions.
For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.

 

​You can now use Amazon Timestream for InfluxDB in the Africa (Cape Town), Asia Pacific (Bangkok), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Asia Pacific (Seoul), Europe (Zurich), and Israel (Tel Aviv) AWS Regions. Timestream for InfluxDB makes it easy for application developers and DevOps teams to run fully managed InfluxDB databases on AWS for real-time time-series applications using open-source APIs.
Timestream for InfluxDB offers Multi-AZ high availability, read replicas, enhanced durability, and multi-node scaling — giving you flexible deployment options to match your workload as it evolves. Whether you’re starting with a single-node setup or scaling to a 15-node Enterprise cluster, you can right-size your infrastructure without re-architecting.
You can create your InfluxDB databases using the Amazon Timestream for InfluxDB console. AWS CLI, or AWS SDKs . Amazon Timestream for InfluxDB is available in the following AWS Regions. For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.  

Publicado el — Deja un comentario

Amazon EC2 R9g and R9gd memory optimized instances are now available

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R9g and R9gd instances, powered by AWS Graviton5 processors, are generally available. AWS Graviton5 processors are the fifth generation of custom-designed CPUs, delivering the best price performance for memory-intensive workloads running on Amazon EC2.

R9g instances are ideal for memory-intensive workloads including databases, in-memory caches, real-time big data analytics, Linux-based workloads including containerized and micro-service-based applications (e.g. Kubernetes, Docker, EKS, ECS), as well as applications written in popular programming languages such as C/C++, Rust, Go, Java, Python, .NET Core, Node.js, Ruby, and PHP.

R9gd instances offer local NVMe-based SSD block-level storage for customers. R9gd instances are great for memory-intensive workloads such as open-source databases, distributed real-time big data analytics, large in-memory databases, and large caching workloads.

R9g and R9gd instances deliver up to 25% better compute performance compared to AWS Graviton4-based R8g and R8gd instances. They are up to 30% faster for databases, up to 35% faster for web applications, and up to 35% faster for machine learning. They feature 5x larger cache and the fastest memory of any processor instances in the cloud. These instances are built on the sixth generation AWS Nitro System and are the first to feature the Nitro Isolation Engine, harnessing formal verification to provide mathematical assurance that customer workloads are isolated from each other and AWS operators, pioneering a new standard for mathematically proven cloud security.

R9g and R9gd instances are available in US East (N. Virginia, Ohio), US West (Oregon), and EU (Frankfurt) regions. R9g and R9gd instances are available for purchase via Savings Plans, On-Demand, Spot instances, Dedicated instances, or Dedicated hosts.

Level up your compute with AWS Graviton and get started today.

 

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R9g and R9gd instances, powered by AWS Graviton5 processors, are generally available. AWS Graviton5 processors are the fifth generation of custom-designed CPUs, delivering the best price performance for memory-intensive workloads running on Amazon EC2.
R9g instances are ideal for memory-intensive workloads including databases, in-memory caches, real-time big data analytics, Linux-based workloads including containerized and micro-service-based applications (e.g. Kubernetes, Docker, EKS, ECS), as well as applications written in popular programming languages such as C/C++, Rust, Go, Java, Python, .NET Core, Node.js, Ruby, and PHP.
R9gd instances offer local NVMe-based SSD block-level storage for customers. R9gd instances are great for memory-intensive workloads such as open-source databases, distributed real-time big data analytics, large in-memory databases, and large caching workloads.
R9g and R9gd instances deliver up to 25% better compute performance compared to AWS Graviton4-based R8g and R8gd instances. They are up to 30% faster for databases, up to 35% faster for web applications, and up to 35% faster for machine learning. They feature 5x larger cache and the fastest memory of any processor instances in the cloud. These instances are built on the sixth generation AWS Nitro System and are the first to feature the Nitro Isolation Engine, harnessing formal verification to provide mathematical assurance that customer workloads are isolated from each other and AWS operators, pioneering a new standard for mathematically proven cloud security.
R9g and R9gd instances are available in US East (N. Virginia, Ohio), US West (Oregon), and EU (Frankfurt) regions. R9g and R9gd instances are available for purchase via Savings Plans, On-Demand, Spot instances, Dedicated instances, or Dedicated hosts.
Level up your compute with AWS Graviton and get started today.  

Publicado el — Deja un comentario

AWS Lambda recursive loop detection is now available in all commercial AWS Regions

AWS Lambda recursive loop detection has expanded support to all commercial AWS Regions. This feature, which is enabled by default, is a guardrail that automatically detects and stops recursive invocations between Lambda functions and other supported services, preventing runaway workloads.

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

With this expansion, you now benefit from recursive loop detection in all commercial AWS Regions when using a supported SDK version or later. If your function uses intentional recursive loops, you can use the PutFunctionRecursionConfig API to turn off recursive loop detection on your Lambda function. 
 
To learn more about Lambda recursive loop detection, please refer to Lambda documentation.

 

​AWS Lambda recursive loop detection has expanded support to all commercial AWS Regions. This feature, which is enabled by default, is a guardrail that automatically detects and stops recursive invocations between Lambda functions and other supported services, preventing runaway workloads.
When using event sources such as Amazon S3, Amazon SQS, and Amazon SNS to trigger Lambda functions, a misconfiguration or code defect can cause events to be sent back to the same source that triggered the Lambda function, causing recursive loops, unintended usage, and unexpected billing. When such a loop is detected, Lambda recursive loop detection automatically stops processing the event and sends you an AWS Health Dashboard notification with troubleshooting steps. 
With this expansion, you now benefit from recursive loop detection in all commercial AWS Regions when using a supported SDK version or later. If your function uses intentional recursive loops, you can use the PutFunctionRecursionConfig API to turn off recursive loop detection on your Lambda function.    To learn more about Lambda recursive loop detection, please refer to Lambda documentation.