Publicado el — Deja un comentario

3 conclusiones de ejecutar acciones de equipo rojo a 100 productos de IA generativa

enero 13, 2025

3 conclusiones de ejecutar acciones de equipo rojo a 100 productos de IA generativa

Personas en una sala de juntas trabajan con sus laptops

Por: Blake Bullwinkel, investigador de seguridad de IA.

Por: Ram Shankar Siva Kumar, vaquero de datos, equipo rojo de IA.

El equipo rojo de IA de Microsoft se complace en compartir nuestro documento técnico, «Lecciones de aplicar acciones de equipo rojo 100 productos de IA generativa«.

El equipo rojo de IA se formó en 2018 para abordar el creciente panorama de los riesgos de seguridad y protección de la IA. Desde entonces, hemos ampliado de manera significativa el alcance y la escala de nuestro trabajo. Somos uno de los primeros equipos rojos de la industria que cubre tanto la seguridad como la IA responsable, y realizar acciones de equipo rojo (red teaming) se ha convertido en una parte clave del enfoque de Microsoft para el desarrollo de productos de IA generativa. El trabajo en equipo rojo es el primer paso para identificar daños potenciales y es seguido por importantes iniciativas en la empresa para medir, gestionar y gobernar el riesgo de IA para nuestros clientes. El año pasado, también anunciamos PyRIT (The Python Risk Identification Tool for generative AI), un conjunto de herramientas de código abierto para ayudar a los investigadores a identificar vulnerabilidades en sus propios sistemas de IA.

Gráfico circular que muestra el desglose porcentual de los productos probados por el equipo rojo de Microsoft AI. Hasta octubre de 2024, habíamos hecho equipo rojo con más de 100 productos de IA generativa.
Gráfico circular que muestra el desglose porcentual de los productos probados por el equipo rojo de Microsoft AI. Hasta octubre de 2024, habíamos hecho equipo rojo con más de 100 productos de IA generativa.

Con un enfoque en nuestra misión ampliada, ahora hemos creado un equipo rojo de más de 100 productos de IA generativa. El documento técnico que publicamos ahora proporciona más detalles sobre nuestro enfoque del equipo rojo de IA e incluye los siguientes aspectos destacados:

  • Nuestra ontología de equipo rojo de IA, que utilizamos para modelar los componentes principales de un ciberataque, incluidos los actores adversarios o benignos, los TTP (Tácticas, Técnicas y Procedimientos), las debilidades del sistema y los impactos posteriores. Esta ontología proporciona una forma coherente de interpretar y diseminar una amplia gama de hallazgos de seguridad y protección.
  • Ocho lecciones principales aprendidas de nuestra experiencia en la creación de equipos de más de 100 productos de IA generativa. Estas lecciones están dirigidas a los profesionales de la seguridad que buscan identificar riesgos en sus propios sistemas de IA y arrojan luz sobre cómo alinear los esfuerzos de equipo rojo con los daños potenciales en el mundo real.
  • Cinco estudios de caso de nuestras operaciones, que destacan la amplia gama de vulnerabilidades que buscamos, incluida la seguridad tradicional, la IA responsable y los daños psicosociales. Cada caso de estudio demuestra cómo se utiliza nuestra ontología para capturar los componentes principales de un ataque o vulnerabilidad del sistema.

El equipo rojo de IA de Microsoft aborda una multitud de escenarios

A lo largo de los años, el equipo rojo de IA ha abordado una amplia variedad de escenarios con los que tal vez también se hayan encontrado otras organizaciones. Nos centramos en las vulnerabilidades que tienen más probabilidades de causar daño en el mundo real, y nuestro documento técnico comparte estudios de casos de nuestras operaciones que destacan cómo lo hemos hecho en cuatro escenarios, incluida la seguridad, la IA responsable, las capacidades peligrosas (como la capacidad de un modelo para generar contenido peligroso) y los daños psicosociales. Como resultado, somos capaces de reconocer una variedad de posibles amenazas cibernéticas y adaptarnos con rapidez cuando nos enfrentamos a otras nuevas.

Esta misión le ha dado a nuestro equipo rojo una amplia gama de experiencias para enfrentar con habilidad los riesgos, sin importar:

  • Tipo de sistema, incluido Microsoft Copilot, modelos integrados en sistemas y modelos de código abierto.
  • Modalidad, ya sea de texto a texto, de texto a imagen o de texto a vídeo.
  • Tipo de usuario: el riesgo del usuario empresarial, por ejemplo, es diferente de los riesgos del consumidor y requiere un enfoque único de acciones de equipo rojo. Las audiencias de nicho, como las de una industria específica como la atención médica, también merecen un enfoque matizado.

Las tres principales conclusiones del documento técnico

El equipo rojo de IA es una práctica para sondear la seguridad de los sistemas de IA generativa. En pocas palabras, «rompemos» la tecnología para que otros puedan reconstruirla más fuerte. Años de aplicar acciones de equipo rojo nos han dado una visión invaluable de las estrategias más efectivas. Al reflexionar sobre las ocho lecciones discutidas en el documento técnico, podemos destilar tres puntos principales que los líderes empresariales deben saber.

Conclusión 1: Los sistemas de IA generativa amplifican los riesgos de seguridad existentes e introducen otros nuevos

La integración de modelos de IA generativa en aplicaciones modernas ha introducido nuevos vectores de ciberataque. Sin embargo, muchas discusiones en torno a la seguridad de la IA pasan por alto las vulnerabilidades existentes. Los equipos rojos de IA deben prestar atención a los vectores de ciberataque, tanto antiguos como nuevos.

  • Riesgos de seguridad existentes: Los riesgos de seguridad de las aplicaciones a menudo se derivan de prácticas de ingeniería de seguridad inadecuadas, incluidas dependencias obsoletas, manejo inadecuado de errores, credenciales en el origen, falta de saneamiento de entrada y salida y cifrado de paquetes inseguro. Uno de los casos de estudio de nuestro documento técnico describe cómo un componente FFmpeg obsoleto en una aplicación de IA de procesamiento de video introdujo una vulnerabilidad de seguridad conocida llamada falsificación de solicitudes del lado del servidor (SSRF), que podría permitir a un adversario escalar los privilegios de su sistema.
Ilustración de la vulnerabilidad SSRF en la aplicación de IA generativa de procesamiento de vídeo.
Ilustración de la vulnerabilidad SSRF en la aplicación de IA generativa de procesamiento de vídeo.
  • Debilidades a nivel de modelo: Los modelos de IA han ampliado la superficie de ciberataque mediante la introducción de nuevas vulnerabilidades. Las inyecciones rápidas, por ejemplo, explotan el hecho de que los modelos de IA a menudo tienen dificultades para distinguir entre las instrucciones a nivel de sistema y los datos del usuario. Nuestro documento técnico incluye un estudio de caso de acciones de equipo rojo sobre cómo utilizamos las inyecciones rápidas para engañar a un modelo de lenguaje de visión.

Consejo del equipo rojo: Los equipos rojos de IA deben estar atentos a los nuevos vectores de ciberataque mientras permanecen atentos a los riesgos de seguridad existentes. Las mejores prácticas de seguridad de la IA deben incluir una higiene cibernética básica.

Conclusión 2: Los humanos están en el centro de la mejora y la seguridad de la IA

Si bien las herramientas de automatización son útiles para crear avisos, orquestar ciberataques y calificar respuestas, las acciones de equipo rojo no se puede automatizar por completo. Las acciones de equipo rojo de IA dependen en gran medida de la experiencia humana.

Los seres humanos son importantes por varias razones, entre ellas:

  • Experiencia en la materia: los LLM son capaces de evaluar si la respuesta de un modelo de IA contiene discurso de odio o contenido sexual explícito, pero no son tan fiables a la hora de evaluar el contenido en áreas especializadas como la medicina, la ciberseguridad y la CBRN (química, biológica, radiológica y nuclear). Estas áreas requieren expertos en la materia que puedan evaluar el riesgo del contenido para los equipos rojos de IA.
  • Competencia cultural: Los modelos de lenguaje moderno utilizan de manera principal datos de entrenamiento en inglés, puntos de referencia de rendimiento y evaluaciones de seguridad. Sin embargo, a medida que los modelos de IA se despliegan en todo el mundo, es crucial diseñar sondas de equipo rojo que no solo tengan en cuenta las diferencias lingüísticas, sino que también redefinan los daños en diferentes contextos políticos y culturales. Estos métodos solo pueden desarrollarse a través del esfuerzo colaborativo de personas con diversos antecedentes culturales y experiencia.
  • Inteligencia emocional: En algunos casos, se requiere inteligencia emocional para evaluar los resultados de los modelos de IA. Uno de los estudios de caso de nuestro documento técnico analiza cómo investigamos los daños psicosociales mediante la investigación de cómo responden los chatbots a los usuarios en apuros. En última instancia, solo los humanos pueden evaluar por completo la gama de interacciones que los usuarios pueden tener con los sistemas de IA en la naturaleza.

Consejo del equipo rojo: Adopten herramientas como PyRIT para ampliar las operaciones, pero mantengan a los humanos en el circuito de equipo rojo para tener el mayor éxito en la identificación de vulnerabilidades impactantes de seguridad y protección de la IA.

Conclusión 3: La defensa en profundidad es clave para mantener seguros los sistemas de IA

Se han desarrollado numerosas mitigaciones para abordar los riesgos de seguridad que plantean los sistemas de IA. Sin embargo, es importante recordar que las mitigaciones no eliminan el riesgo por completo. En última instancia, aplicar acciones de equipo rojo de IA es un proceso continuo que debe adaptarse a la rápida evolución del panorama de riesgos y tener como objetivo aumentar el coste de atacar con éxito un sistema tanto como sea posible.

  • Nuevas categorías de daño: A medida que los sistemas de IA se vuelven más sofisticados, a menudo introducen categorías de daño nuevas. Por ejemplo, uno de nuestros estudios de caso explica cómo probamos un LLM de última generación en busca de capacidades persuasivas riesgosas. Los equipos rojos de IA deben actualizar de manera constante sus prácticas para anticipar y sondear estos nuevos riesgos.
  • Economía de la ciberseguridad: Todos los sistemas son vulnerables porque los humanos son falibles y los adversarios son persistentes. Sin embargo, pueden disuadir a los adversarios a través de aumentar el costo de atacar un sistema más allá del valor que se obtendría. Una forma de aumentar el coste de los ciberataques es mediante el uso de ciclos de reparación de averías.1 Esto implica llevar a cabo múltiples rondas de acciones de equipo rojo, medición y mitigación, a veces denominadas «purple teaming», para fortalecer el sistema para manejar una variedad de ataques.
  • Acción del gobierno: La acción de la industria para defenderse contra los ciberatacantes y los fracasos es una cara de la moneda de la seguridad de la IA. El otro lado es la acción del gobierno de una manera que podría disuadir y desalentar estos fracasos más amplios. Tanto el sector público como el privado deben demostrar compromiso y vigilancia, para garantizar que los ciberatacantes ya no tengan la sartén por el mango y que la sociedad en general pueda beneficiarse de los sistemas de IA que son seguros de manera inherente.

Consejo del equipo rojo: Actualicen de manera continua sus prácticas para tener en cuenta los daños novedosos, utilicen ciclos de reparación de averías para que los sistemas de IA sean lo más seguros posible e inviertan en técnicas sólidas de medición y mitigación.

Mejoren su experiencia en equipos rojos de IA

El documento técnico «Lessons From Red Teaming 100 Generative AI Products» incluye nuestra ontología de equipo rojo de IA, lecciones aprendidas adicionales y cinco estudios de casos de nuestras operaciones. Esperamos que el artículo y la ontología les resulten útiles para organizar sus propios ejercicios de red teaming de IA y desarrollar más estudios de casos para aprovechar las ventajas de PyRIT, nuestro marco de automatización de código abierto.

Juntos, la comunidad de ciberseguridad puede refinar sus enfoques y compartir las mejores prácticas para abordar de manera efectiva los desafíos que se avecinan. Descarguen nuestro documento técnico de acciones de equipo rojo para obtener más información sobre lo que hemos aprendido. A medida que avanzamos en nuestro propio recorrido de aprendizaje continuo, agradeceríamos sus comentarios y escuchar sobre sus propias experiencias de equipo rojo de IA.

Más información de Microsoft Security

Para obtener más información sobre las soluciones de seguridad de Microsoft, visiten nuestro sitio web. Agreguen a Favoritos el blog de Seguridad para mantenerse al día con nuestra cobertura experta en asuntos de seguridad. Además, síganos en LinkedIn (Microsoft Security) y X (@MSFTSecurity) para conocer las últimas noticias y actualizaciones sobre ciberseguridad.

¹ Phi-3 Safety Post-Training: Alineando Modelos de Lenguaje con un Ciclo de «Break-Fix»

The post 3 conclusiones de ejecutar acciones de equipo rojo a 100 productos de IA generativa appeared first on Source LATAM.

 

​The post 3 conclusiones de ejecutar acciones de equipo rojo a 100 productos de IA generativa appeared first on Source LATAM.  

Publicado el — Deja un comentario

Amazon Connect Contact Lens launches agent performance evaluations for email contacts

You can now evaluate agent performance on emails in Amazon Connect, enabling managers to assess agent performance across contact channels (voice, chat, email, and tasks) in a single easy-to-use web interface, and get aggregated insights across cohorts of agents over time. With this launch, managers can evaluate agent performance by reviewing email threads and additional details of the email interaction (e.g., handle time) in a single UI. Contact centers can also use public APIs to incorporate data from third-party systems (e.g., CSAT, sales volumes, customer retention, etc.) into performance evaluations of email contacts, providing managers with comprehensive insights on agent performance.

This feature is available in all regions where Contact Lens performance evaluations is already available. To learn more, please visit our documentation and our webpage. For information about Contact Lens pricing, please visit our pricing page.

 

​You can now evaluate agent performance on emails in Amazon Connect, enabling managers to assess agent performance across contact channels (voice, chat, email, and tasks) in a single easy-to-use web interface, and get aggregated insights across cohorts of agents over time. With this launch, managers can evaluate agent performance by reviewing email threads and additional details of the email interaction (e.g., handle time) in a single UI. Contact centers can also use public APIs to incorporate data from third-party systems (e.g., CSAT, sales volumes, customer retention, etc.) into performance evaluations of email contacts, providing managers with comprehensive insights on agent performance. This feature is available in all regions where Contact Lens performance evaluations is already available. To learn more, please visit our documentation and our webpage. For information about Contact Lens pricing, please visit our pricing page.  

Publicado el — Deja un comentario

AWS End User Messaging expands self-service sender ID registration support in 19 new countries

Today, AWS End User Messaging launched self-service Sender ID registrations for 19 additional countries, helping developers correctly configure SMS messaging for their applications. The new countries include Australia, Belarus, Egypt, India, Indonesia, Jordan, Kenya, Kuwait, Kazakhstan, Philippines, Qatar, Russia, Saudi Arabia, Singapore, Sri Lanka, Thailand, Turkey, United Arab Emirates, Vietnam, and Zambia.

Phone numbers and sender IDs act as an extension of a business’s brand, and mobile carriers and governments worldwide have implemented SMS registrations as a form of «know your customer» check to protect end-users from unwanted and spam messages. By registering, application developers ensure a higher level of deliverability and ensure their use-cases comply with local rules and regulations, avoiding message filtering.

Previously, customers needed to open a support case to request these sender IDs, but now they can self-service via the AWS Management Console or programmatically via the APIs, saving time-to-onboard. The registration support is available in all commercial regions where AWS End User Messaging is generally available.
 

 

​Today, AWS End User Messaging launched self-service Sender ID registrations for 19 additional countries, helping developers correctly configure SMS messaging for their applications. The new countries include Australia, Belarus, Egypt, India, Indonesia, Jordan, Kenya, Kuwait, Kazakhstan, Philippines, Qatar, Russia, Saudi Arabia, Singapore, Sri Lanka, Thailand, Turkey, United Arab Emirates, Vietnam, and Zambia. Phone numbers and sender IDs act as an extension of a business’s brand, and mobile carriers and governments worldwide have implemented SMS registrations as a form of «know your customer» check to protect end-users from unwanted and spam messages. By registering, application developers ensure a higher level of deliverability and ensure their use-cases comply with local rules and regulations, avoiding message filtering. Previously, customers needed to open a support case to request these sender IDs, but now they can self-service via the AWS Management Console or programmatically via the APIs, saving time-to-onboard. The registration support is available in all commercial regions where AWS End User Messaging is generally available.    

Publicado el — Deja un comentario

Amazon RDS for MariaDB supports Innovation Release 11.7 in Amazon RDS Database Preview Environment

Amazon RDS for MariaDB now supports MariaDB Innovation Release 11.7 in the Amazon RDS Database Preview Environment, allowing you to evaluate the latest Innovation Release on Amazon RDS for MariaDB. You can deploy MariaDB 11.7 in the Amazon RDS Database Preview Environment that has the benefits of a fully managed database, making it simpler to set up, operate, and monitor databases.

MariaDB 11.7 is the latest Innovation Release from the MariaDB community, and includes support for vector datatype, indexing, and search capabilities. MariaDB Innovation releases are supported by the community until the next Innovation release, whereas MariaDB Long Term Maintenance Releases, such as MariaDB 10.11 and MariaDB 11.4, are supported by the community for up to five years. Please refer to the MariaDB 11.7 release notes for more details about this release.

The Amazon RDS Database Preview Environment supports both Single-AZ and Multi-AZ deployments on the latest generation of instance classes. Amazon RDS Database Preview Environment database instances are retained for a maximum period of 60 days and are automatically deleted after the retention period. Amazon RDS database snapshots that are created in the preview environment can only be used to create or restore database instances within the preview environment.

Amazon RDS Database Preview Environment database instances are priced the same as production RDS instances created in the US East (Ohio) Region.

 

​Amazon RDS for MariaDB now supports MariaDB Innovation Release 11.7 in the Amazon RDS Database Preview Environment, allowing you to evaluate the latest Innovation Release on Amazon RDS for MariaDB. You can deploy MariaDB 11.7 in the Amazon RDS Database Preview Environment that has the benefits of a fully managed database, making it simpler to set up, operate, and monitor databases. MariaDB 11.7 is the latest Innovation Release from the MariaDB community, and includes support for vector datatype, indexing, and search capabilities. MariaDB Innovation releases are supported by the community until the next Innovation release, whereas MariaDB Long Term Maintenance Releases, such as MariaDB 10.11 and MariaDB 11.4, are supported by the community for up to five years. Please refer to the MariaDB 11.7 release notes for more details about this release. The Amazon RDS Database Preview Environment supports both Single-AZ and Multi-AZ deployments on the latest generation of instance classes. Amazon RDS Database Preview Environment database instances are retained for a maximum period of 60 days and are automatically deleted after the retention period. Amazon RDS database snapshots that are created in the preview environment can only be used to create or restore database instances within the preview environment. Amazon RDS Database Preview Environment database instances are priced the same as production RDS instances created in the US East (Ohio) Region.  

Publicado el — Deja un comentario

AWS CodeBuild now supports batch builds with reserved capacity and Lambda compute

AWS CodeBuild has expanded its batch build capabilities to include support for reserved capacity fleets and Lambda compute. This enhancement allows you to select a mix of on-demand instances, reserved capacity fleets, or Lambda compute resources for your build batches. AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages ready for deployment.

Batch builds in CodeBuild enable the simultaneous execution of multiple, coordinated builds within a project. This feature is particularly beneficial for developers working on multi-platform projects or those with interdependent build processes. You can define the build sequence using various methods, such as a build list, a build matrix, or a dependency graph of build definitions. CodeBuild then manages the orchestration of these builds, streamlining the overall development and integration process.

The new compute options are now available in US East (N. Virginia), US East (Ohio), US West (Oregon), South America (Sao Paulo), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Mumbai), Europe (Ireland), and Europe (Frankfurt). For more information about the AWS Regions where CodeBuild is available, see the AWS Regions page.

To learn more about running batch builds in CodeBuild, please visit our documentation. To learn more about how to get started with CodeBuild, visit the AWS CodeBuild product page.
 

 

​AWS CodeBuild has expanded its batch build capabilities to include support for reserved capacity fleets and Lambda compute. This enhancement allows you to select a mix of on-demand instances, reserved capacity fleets, or Lambda compute resources for your build batches. AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages ready for deployment. Batch builds in CodeBuild enable the simultaneous execution of multiple, coordinated builds within a project. This feature is particularly beneficial for developers working on multi-platform projects or those with interdependent build processes. You can define the build sequence using various methods, such as a build list, a build matrix, or a dependency graph of build definitions. CodeBuild then manages the orchestration of these builds, streamlining the overall development and integration process. The new compute options are now available in US East (N. Virginia), US East (Ohio), US West (Oregon), South America (Sao Paulo), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Mumbai), Europe (Ireland), and Europe (Frankfurt). For more information about the AWS Regions where CodeBuild is available, see the AWS Regions page. To learn more about running batch builds in CodeBuild, please visit our documentation. To learn more about how to get started with CodeBuild, visit the AWS CodeBuild product page.    

Publicado el — Deja un comentario

Amazon EC2 C8g instances now available in additional regions

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C8g instances are available in AWS Europe (Ireland) and AWS Europe (Spain) regions. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 C8g instances are built for general-purpose workloads, such as application servers, microservices, gaming servers, midsize data stores, and caching fleets. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads.

AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. These instances offer larger instance sizes with up to 3x more vCPUs and memory compared to Graviton3-based Amazon C7g instances. AWS Graviton4 processors are up to 40% faster for databases, 30% faster for web applications, and 45% faster for large Java applications than AWS Graviton3 processors. C8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS).

To learn more, see Amazon EC2 C8g Instances. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.
 

 

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C8g instances are available in AWS Europe (Ireland) and AWS Europe (Spain) regions. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 C8g instances are built for general-purpose workloads, such as application servers, microservices, gaming servers, midsize data stores, and caching fleets. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads. AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. These instances offer larger instance sizes with up to 3x more vCPUs and memory compared to Graviton3-based Amazon C7g instances. AWS Graviton4 processors are up to 40% faster for databases, 30% faster for web applications, and 45% faster for large Java applications than AWS Graviton3 processors. C8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). To learn more, see Amazon EC2 C8g Instances. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.    

Publicado el — Deja un comentario

AWS Marketplace launches disbursement pause notifications

AWS Marketplace launched email notification and Amazon EventBridge event that informs AWS Marketplace selling partners, including ISVs and Channel Partners, when their disbursements have been paused due to invalid bank account information. With this launch, selling partners can be alerted to these events and take immediate action to update their banking details so they receive their disbursements promptly.

Until now, AWS Marketplace selling partners had to check disbursement status in Insights tab in AMMP. With this release, disbursement paused events that are caused by invalid bank accounts will be sent to Amazon EventBridge and AWS Marketplace sellers can subscribe to these events by defining appropriate rule patterns. Each event will contain a failure reason, payment instrument ARN that is invalid, and a link to the remediation steps. The source for these EventBridge events is aws.marketplace and the possible detail-type value is Disbursement Paused.

To learn more about this new email notification, see Managing email notifications for AWS Marketplace events – AWS Marketplace and to get started with creating event rules in Amazon EventBridge, see Amazon EventBridge events – AWS Marketplace.

 

​AWS Marketplace launched email notification and Amazon EventBridge event that informs AWS Marketplace selling partners, including ISVs and Channel Partners, when their disbursements have been paused due to invalid bank account information. With this launch, selling partners can be alerted to these events and take immediate action to update their banking details so they receive their disbursements promptly. Until now, AWS Marketplace selling partners had to check disbursement status in Insights tab in AMMP. With this release, disbursement paused events that are caused by invalid bank accounts will be sent to Amazon EventBridge and AWS Marketplace sellers can subscribe to these events by defining appropriate rule patterns. Each event will contain a failure reason, payment instrument ARN that is invalid, and a link to the remediation steps. The source for these EventBridge events is aws.marketplace and the possible detail-type value is Disbursement Paused. To learn more about this new email notification, see Managing email notifications for AWS Marketplace events – AWS Marketplace and to get started with creating event rules in Amazon EventBridge, see Amazon EventBridge events – AWS Marketplace.  

Publicado el — Deja un comentario

AWS Compute Optimizer now expands idle and rightsizing recommendations for Amazon EC2 Auto Scaling groups

AWS Compute Optimizer now expands idle and rightsizing recommendations to Amazon EC2 Auto Scaling groups with scaling policies and multiple instance types. With the new recommendations, you can take actions to optimize cost and performance of these groups without requiring specialized knowledge or engineering resources to analyze them.

Compute Optimizer analyzes EC2 Auto Scaling groups’ scaling policies, instance configurations, and utilization metrics to understand their usage patterns and identify opportunities for cost and performance optimization. For EC2 Auto Scaling groups using multiple instance types, Compute Optimizer helps identify the most cost-efficient instance types, enabling you to prioritize them in your groups. When EC2 Auto Scaling groups use scaling policies to scale based on CPU utilization, Compute Optimizer recommends optimizing the CPU-to-memory ratio by considering only instance types with identical vCPU counts. Compute Optimizer also identifies and flags EC2 Auto Scaling groups that demonstrate consistently low CPU and network usage throughout the lookback period as idle, recommending that you scale them down to save costs.

This new feature is available in all AWS Regions where AWS Compute Optimizer is available, except the AWS GovCloud (US) and AWS China Regions. To learn more about the new feature updates, please visit Compute Optimizer’s product page and user guide.

 

​AWS Compute Optimizer now expands idle and rightsizing recommendations to Amazon EC2 Auto Scaling groups with scaling policies and multiple instance types. With the new recommendations, you can take actions to optimize cost and performance of these groups without requiring specialized knowledge or engineering resources to analyze them. Compute Optimizer analyzes EC2 Auto Scaling groups’ scaling policies, instance configurations, and utilization metrics to understand their usage patterns and identify opportunities for cost and performance optimization. For EC2 Auto Scaling groups using multiple instance types, Compute Optimizer helps identify the most cost-efficient instance types, enabling you to prioritize them in your groups. When EC2 Auto Scaling groups use scaling policies to scale based on CPU utilization, Compute Optimizer recommends optimizing the CPU-to-memory ratio by considering only instance types with identical vCPU counts. Compute Optimizer also identifies and flags EC2 Auto Scaling groups that demonstrate consistently low CPU and network usage throughout the lookback period as idle, recommending that you scale them down to save costs. This new feature is available in all AWS Regions where AWS Compute Optimizer is available, except the AWS GovCloud (US) and AWS China Regions. To learn more about the new feature updates, please visit Compute Optimizer’s product page and user guide.  

Publicado el — Deja un comentario

Announcing the general availability of a new AWS Local Zone in New York City

Today, AWS announces the general availability of a new AWS Local Zone in New York City, supporting a wide range of workloads at the edge. This new Local Zone offers Amazon Elastic Compute Cloud (Amazon EC2) C7i, R7i, M6i, and M6in instances and Amazon Elastic Block Store (Amazon EBS) volume types gp2, gp3, io1, sc1, and st1. You can also access Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Application Load Balancer, AWS Direct Connect, and the microsecond-accurate time of Amazon Time Sync in this new Local Zone to support your workloads at the edge.

Local Zones are an AWS infrastructure deployment that place compute, storage, database, and other select services closer to large population, industry, and IT centers where no AWS Region exists. You can use Local Zones to run applications that require single-digit millisecond latency for use cases such as real-time gaming, hybrid migrations, media and entertainment content creation, live video streaming, engineering simulations, financial services payment processing, capital market operations, and AR/VR.

Local Zones are available in the US in 17 metro areas and globally in an additional 17 metro areas, allowing you to deliver low-latency applications to end users worldwide. For more information about where other Local Zones are available, visit Local Zones locations.

You can enable the new Local Zone in New York City from the Zones tab in the Amazon EC2 console settings or the ModifyAvailabilityZoneGroup API. Check out Local Zones pricing for information on Amazon EC2 instances available as On-Demand Instances, Spot Instances, or part of Savings Plans in the new Local Zone in New York City. To learn more, visit Local Zones.

 

​Today, AWS announces the general availability of a new AWS Local Zone in New York City, supporting a wide range of workloads at the edge. This new Local Zone offers Amazon Elastic Compute Cloud (Amazon EC2) C7i, R7i, M6i, and M6in instances and Amazon Elastic Block Store (Amazon EBS) volume types gp2, gp3, io1, sc1, and st1. You can also access Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Application Load Balancer, AWS Direct Connect, and the microsecond-accurate time of Amazon Time Sync in this new Local Zone to support your workloads at the edge.
Local Zones are an AWS infrastructure deployment that place compute, storage, database, and other select services closer to large population, industry, and IT centers where no AWS Region exists. You can use Local Zones to run applications that require single-digit millisecond latency for use cases such as real-time gaming, hybrid migrations, media and entertainment content creation, live video streaming, engineering simulations, financial services payment processing, capital market operations, and AR/VR.
Local Zones are available in the US in 17 metro areas and globally in an additional 17 metro areas, allowing you to deliver low-latency applications to end users worldwide. For more information about where other Local Zones are available, visit Local Zones locations.
You can enable the new Local Zone in New York City from the Zones tab in the Amazon EC2 console settings or the ModifyAvailabilityZoneGroup API. Check out Local Zones pricing for information on Amazon EC2 instances available as On-Demand Instances, Spot Instances, or part of Savings Plans in the new Local Zone in New York City. To learn more, visit Local Zones.  

Publicado el — Deja un comentario

Amazon EC2 C7i instances now available in the AWS GovCloud (US-West) Region

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7i instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in the AWS GovCloud (US-West) Region. These custom processors, available only on AWS, offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers.

C7i instances deliver up to 15% better price-performance versus C6i instances and are a great choice for all compute-intensive workloads, such as batch processing, distributed analytics, ad-serving, and video encoding. C7i instances offer larger instance sizes, up to 48xlarge, and two bare metal sizes (metal-24xl, metal-48xl). These bare-metal sizes support built-in Intel accelerators: Data Streaming Accelerator, In-Memory Analytics Accelerator, and QuickAssist Technology that are used to facilitate efficient offload and acceleration of data operations and optimize performance for workloads.

C7i instances also support new Intel Advanced Matrix Extensions (AMX) that accelerate matrix multiplication operations for applications such as CPU-based ML. Customers can attach up to 128 EBS volumes to a C7i instance vs. up to 28 EBS volumes to a C6i instance. This allows processing of larger amounts of data, scale workloads, and improved performance over C6i instances. To learn more, visit the EC2 C7i instances Page.

 

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7i instances powered by custom 4th Gen Intel Xeon Scalable processors (code-named Sapphire Rapids) are available in the AWS GovCloud (US-West) Region. These custom processors, available only on AWS, offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers. C7i instances deliver up to 15% better price-performance versus C6i instances and are a great choice for all compute-intensive workloads, such as batch processing, distributed analytics, ad-serving, and video encoding. C7i instances offer larger instance sizes, up to 48xlarge, and two bare metal sizes (metal-24xl, metal-48xl). These bare-metal sizes support built-in Intel accelerators: Data Streaming Accelerator, In-Memory Analytics Accelerator, and QuickAssist Technology that are used to facilitate efficient offload and acceleration of data operations and optimize performance for workloads. C7i instances also support new Intel Advanced Matrix Extensions (AMX) that accelerate matrix multiplication operations for applications such as CPU-based ML. Customers can attach up to 128 EBS volumes to a C7i instance vs. up to 28 EBS volumes to a C6i instance. This allows processing of larger amounts of data, scale workloads, and improved performance over C6i instances. To learn more, visit the EC2 C7i instances Page.